From nick.bastin at gmail.com  Thu Nov  1 06:53:27 2007
From: nick.bastin at gmail.com (Nicholas Bastin)
Date: Wed, 31 Oct 2007 23:53:27 -0600
Subject: [Python-3000] plat-mac seriously broken?
In-Reply-To: <ca471dc20710301139v73834dd6uc8623a6033ff851f@mail.gmail.com>
References: <18211.33450.332197.304601@montanaro.dyndns.org>
	<1209807056282906541@unknownmsgid>
	<ca471dc20710291041s3f66d478se6168310164e6f60@mail.gmail.com>
	<bbaeab100710301105j4f149731sbb89b255554be85e@mail.gmail.com>
	<ca471dc20710301139v73834dd6uc8623a6033ff851f@mail.gmail.com>
Message-ID: <66d0a6e10710312253x12798d61r9259fc8ddce40c22@mail.gmail.com>

On Oct 30, 2007 12:39 PM, Guido van Rossum <guido at python.org> wrote:
> Also, IMO the Mac-specific stuff was a lot more important before OSX.
>
> The really interesting Mac stuff is the ObjC bridge which is not
> maintained here anyway.

The carbon stuff is still useful, even on MacOS X, but I don't see why
it should be given any preference over win32all.

--
Nick

From ronaldoussoren at mac.com  Thu Nov  1 10:47:47 2007
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Thu, 1 Nov 2007 10:47:47 +0100
Subject: [Python-3000] plat-mac seriously broken?
In-Reply-To: <bbaeab100710301105j4f149731sbb89b255554be85e@mail.gmail.com>
References: <18211.33450.332197.304601@montanaro.dyndns.org>
	<1209807056282906541@unknownmsgid>
	<ca471dc20710291041s3f66d478se6168310164e6f60@mail.gmail.com>
	<bbaeab100710301105j4f149731sbb89b255554be85e@mail.gmail.com>
Message-ID: <C9173044-2C47-4D81-8249-0D7464A5426A@mac.com>


On 30 Oct, 2007, at 19:05, Brett Cannon wrote:

> On 10/29/07, Guido van Rossum <guido at python.org> wrote:
>> 2007/10/27, Bill Janssen <janssen at parc.com>:
>>>> ISTR much of the plat-mac stuff was generated by Tools/bgen.  If  
>>>> so, that
>>>> would be the place to fix things.
>>>
>>> Sure looks like generated code.  Be nice if that generator was run
>>> during the build process, on OS X.  That way you'd be sure to get  
>>> code
>>> that matches the platform and codebase.
>>
>> ISTR that the generator needs a lot of hand-holding. Fixing it would
>> be A Project.

and I wonder if it is worth the effort...

>
> Just so that it is publicly known, when the Great Stdlib Reorg begins,
> I am seriously thinking of paring down the Mac stuff to the bare
> minimum.  I think the only reason all the Mac stuff was even allowed
> in to begin with was because Jack was one of the first contributors to
> Python (but that is just a hunch).  It seems rather unfair to have all
> of this Mac stuff in the stdlib while Windows doesn't go far beyond
> _winreg and everything else is kept in win32all.  Considering it has
> gone this far into Py3K and no one has noticed that it was broken kind
> of says something anyway.
>
> And no, I don't know when I am going to start doing the cleanup as I
> am under time pressure for three proposals between now and late
> December.

For what it is worth: I agree that most of the mac libraries, such as  
the entire Carbon package, shouldn't be part of the standard library.

The reason for that is simple: the release-cycle of the MacOS bindings  
are currently bound to the release cycle of major releases of Python  
(e.g. one cannot do functional changes to the Carbon in the 2.5.x  
branch), but should IMO be synchronized with platform releases.

However, I also think the mac libraries shouldn't be removed from the  
standard library without someone stepping in to transform them into  
(a) standalone package(s). Alternatively the functionality should be  
available in other packages (such as PyObjC).


Ronald
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2224 bytes
Desc: not available
Url : http://mail.python.org/pipermail/python-3000/attachments/20071101/e6c7d632/attachment-0001.bin 

From guido at python.org  Thu Nov  1 15:06:50 2007
From: guido at python.org (Guido van Rossum)
Date: Thu, 1 Nov 2007 07:06:50 -0700
Subject: [Python-3000] plat-mac seriously broken?
In-Reply-To: <C9173044-2C47-4D81-8249-0D7464A5426A@mac.com>
References: <18211.33450.332197.304601@montanaro.dyndns.org>
	<1209807056282906541@unknownmsgid>
	<ca471dc20710291041s3f66d478se6168310164e6f60@mail.gmail.com>
	<bbaeab100710301105j4f149731sbb89b255554be85e@mail.gmail.com>
	<C9173044-2C47-4D81-8249-0D7464A5426A@mac.com>
Message-ID: <ca471dc20711010706t2eebea64je8e296563d181906@mail.gmail.com>

On 11/1/07, Ronald Oussoren <ronaldoussoren at mac.com> wrote:
> For what it is worth: I agree that most of the mac libraries, such as
> the entire Carbon package, shouldn't be part of the standard library.
>
> The reason for that is simple: the release-cycle of the MacOS bindings
> are currently bound to the release cycle of major releases of Python
> (e.g. one cannot do functional changes to the Carbon in the 2.5.x
> branch), but should IMO be synchronized with platform releases.

Very good point.

> However, I also think the mac libraries shouldn't be removed from the
> standard library without someone stepping in to transform them into
> (a) standalone package(s). Alternatively the functionality should be
> available in other packages (such as PyObjC).

Are you volunteering?

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

From guido at python.org  Thu Nov  1 15:18:32 2007
From: guido at python.org (Guido van Rossum)
Date: Thu, 1 Nov 2007 07:18:32 -0700
Subject: [Python-3000] pickle compatibility between 2.x and 3.0
Message-ID: <ca471dc20711010718u5d437d60i9fd549e9c7271993@mail.gmail.com>

It's time to start thinking about pickle compatibility between 2.x and
3.0. The main problem is the 2.x str type -- it doesn't have a true
equivalent in 3.0.

When 3.0 encounters a 'str' object in a pickle written by 2.x, it has
two choices: trying to convert it to a 3.0 (unicode) str object by
applying some encoding, or interpreting it as a 3.0 bytes object. The
latter would be trivial, but likely wrong, as the 2.x program that
wrote the pickle would likely have meant it to be a text string
(although there are certainly cases where binary data gets pickled as
well, in which case bytes is of course the correct translation). Since
in 3.0, bytes don't interact with text strings the way in 2.x str
interacts with unicode, receiving bytes is somewhat inconvenient for
the 3.0 program.

OTOH, applying an encoding gives us the painful choice of deciding
what encoding to use -- the input pickle doesn't give us any hints,
and as indicated we're not even sure that text was intended.

I could leave this all up to the 3.0 application, which would have to
"fix up" any bytes in the pickle it receives explicitly if it wants
to. Alternatively, I could add an encoding option to the pickle
loading APIs (and for full flexibility an errors option as well) so
that at least simple text-based applications might have a chance of
reading the data that they themselves wrote before they were ported to
3.0 with minimal changes (only the unpickling calls would have to be
modified).

Do people here think it's worth it? Think of any place where you
currently are using pickles. What would your 3.0 porting strategy
likely be? Would not having automatic decoding of pickled 8-bit
strings be a major burden?

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

From guido at python.org  Thu Nov  1 15:18:32 2007
From: guido at python.org (Guido van Rossum)
Date: Thu, 1 Nov 2007 07:18:32 -0700
Subject: [Python-3000] pickle compatibility between 2.x and 3.0
Message-ID: <ca471dc20711010718u5d437d60i9fd549e9c7271993@mail.gmail.com>

It's time to start thinking about pickle compatibility between 2.x and
3.0. The main problem is the 2.x str type -- it doesn't have a true
equivalent in 3.0.

When 3.0 encounters a 'str' object in a pickle written by 2.x, it has
two choices: trying to convert it to a 3.0 (unicode) str object by
applying some encoding, or interpreting it as a 3.0 bytes object. The
latter would be trivial, but likely wrong, as the 2.x program that
wrote the pickle would likely have meant it to be a text string
(although there are certainly cases where binary data gets pickled as
well, in which case bytes is of course the correct translation). Since
in 3.0, bytes don't interact with text strings the way in 2.x str
interacts with unicode, receiving bytes is somewhat inconvenient for
the 3.0 program.

OTOH, applying an encoding gives us the painful choice of deciding
what encoding to use -- the input pickle doesn't give us any hints,
and as indicated we're not even sure that text was intended.

I could leave this all up to the 3.0 application, which would have to
"fix up" any bytes in the pickle it receives explicitly if it wants
to. Alternatively, I could add an encoding option to the pickle
loading APIs (and for full flexibility an errors option as well) so
that at least simple text-based applications might have a chance of
reading the data that they themselves wrote before they were ported to
3.0 with minimal changes (only the unpickling calls would have to be
modified).

Do people here think it's worth it? Think of any place where you
currently are using pickles. What would your 3.0 porting strategy
likely be? Would not having automatic decoding of pickled 8-bit
strings be a major burden?

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

From ronaldoussoren at mac.com  Thu Nov  1 15:19:40 2007
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Thu, 1 Nov 2007 15:19:40 +0100
Subject: [Python-3000] plat-mac seriously broken?
In-Reply-To: <ca471dc20711010706t2eebea64je8e296563d181906@mail.gmail.com>
References: <18211.33450.332197.304601@montanaro.dyndns.org>
	<1209807056282906541@unknownmsgid>
	<ca471dc20710291041s3f66d478se6168310164e6f60@mail.gmail.com>
	<bbaeab100710301105j4f149731sbb89b255554be85e@mail.gmail.com>
	<C9173044-2C47-4D81-8249-0D7464A5426A@mac.com>
	<ca471dc20711010706t2eebea64je8e296563d181906@mail.gmail.com>
Message-ID: <91DA47AE-6A69-4FB0-879F-48D7672227D6@mac.com>


On 1 Nov, 2007, at 15:06, Guido van Rossum wrote:

> On 11/1/07, Ronald Oussoren <ronaldoussoren at mac.com> wrote:
>> For what it is worth: I agree that most of the mac libraries, such as
>> the entire Carbon package, shouldn't be part of the standard library.
>>
>> The reason for that is simple: the release-cycle of the MacOS  
>> bindings
>> are currently bound to the release cycle of major releases of Python
>> (e.g. one cannot do functional changes to the Carbon in the 2.5.x
>> branch), but should IMO be synchronized with platform releases.
>
> Very good point.
>
>> However, I also think the mac libraries shouldn't be removed from the
>> standard library without someone stepping in to transform them into
>> (a) standalone package(s). Alternatively the functionality should be
>> available in other packages (such as PyObjC).
>
> Are you volunteering?

I'm volunteering to keep improving PyObjC, but I won't promise that  
PyObjC will be complete enough to replace the Carbon tree by the time  
Python 3.0 goes into beta. Heck, just commiting the version of PyObjC  
that is in Leopard into a public repository took me three weeks :-(

Does anyone have suggestions on how to mobilize people for this  
without scaring them away when explaining what needs to be done?  
People, including myself to be honest, seem to find other things to do  
when the realize that fixing the Carbon wrappers involves  working  
with and hacking on bgen :-(

Ronald
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2224 bytes
Desc: not available
Url : http://mail.python.org/pipermail/python-3000/attachments/20071101/93f1d296/attachment.bin 

From lists at cheimes.de  Thu Nov  1 15:20:31 2007
From: lists at cheimes.de (Christian Heimes)
Date: Thu, 01 Nov 2007 15:20:31 +0100
Subject: [Python-3000] PEP3137: "".encode() return type
Message-ID: <4729E0AF.3050608@cheimes.de>

I'm trying to fix some of the errors in the py3k-pep3137 branch and I
stumbled over an issue with encode().

TypeError: encoder did not return a bytes object (type=bytes)

The sentence "... encoding always takes a Unicode string and returns a
bytes sequence, and decoding always takes a bytes sequence and returns a
Unicode string." isn't helpful because it's ambiguous. Do you mean the
old bytes type PyBytes or the new bytes type PyString?

One of the encode methods in unicodeobject.c PyUnicode_AsEncodedString()
checks for PyString and converts it into a buffer (PyBytes).

    if (!PyBytes_Check(v)) {
        if (PyString_Check(v)) {
            /* Old codec, turn it into bytes */
            PyObject *b = PyBytes_FromObject(v);
            Py_DECREF(v);
            return b;
        }

unicode_encode() doesn't like PyString at all and immediately raises a
type error.

* What's the correct return type, PyBytes or PyString?

* If PyString is wrong shouldn't we fix the PyUnicode_AsEncodedString
and remove PyBytes_FromObject?

Christian


From guido at python.org  Thu Nov  1 15:22:42 2007
From: guido at python.org (Guido van Rossum)
Date: Thu, 1 Nov 2007 07:22:42 -0700
Subject: [Python-3000] plat-mac seriously broken?
In-Reply-To: <91DA47AE-6A69-4FB0-879F-48D7672227D6@mac.com>
References: <18211.33450.332197.304601@montanaro.dyndns.org>
	<1209807056282906541@unknownmsgid>
	<ca471dc20710291041s3f66d478se6168310164e6f60@mail.gmail.com>
	<bbaeab100710301105j4f149731sbb89b255554be85e@mail.gmail.com>
	<C9173044-2C47-4D81-8249-0D7464A5426A@mac.com>
	<ca471dc20711010706t2eebea64je8e296563d181906@mail.gmail.com>
	<91DA47AE-6A69-4FB0-879F-48D7672227D6@mac.com>
Message-ID: <ca471dc20711010722h73c3e68j72c43000569e8d61@mail.gmail.com>

On 11/1/07, Ronald Oussoren <ronaldoussoren at mac.com> wrote:
> I'm volunteering to keep improving PyObjC, but I won't promise that
> PyObjC will be complete enough to replace the Carbon tree by the time
> Python 3.0 goes into beta. Heck, just commiting the version of PyObjC
> that is in Leopard into a public repository took me three weeks :-(

Which reminds me -- what version of Python is in Leopard?

> Does anyone have suggestions on how to mobilize people for this
> without scaring them away when explaining what needs to be done?
> People, including myself to be honest, seem to find other things to do
> when the realize that fixing the Carbon wrappers involves  working
> with and hacking on bgen :-(

I admit bgen is too ancient and too ad-hoc to try and bother with (and
I wrote most of it!). How would you solve the problem it solves today?

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

From ronaldoussoren at mac.com  Thu Nov  1 15:31:41 2007
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Thu, 1 Nov 2007 15:31:41 +0100
Subject: [Python-3000] plat-mac seriously broken?
In-Reply-To: <ca471dc20711010722h73c3e68j72c43000569e8d61@mail.gmail.com>
References: <18211.33450.332197.304601@montanaro.dyndns.org>
	<1209807056282906541@unknownmsgid>
	<ca471dc20710291041s3f66d478se6168310164e6f60@mail.gmail.com>
	<bbaeab100710301105j4f149731sbb89b255554be85e@mail.gmail.com>
	<C9173044-2C47-4D81-8249-0D7464A5426A@mac.com>
	<ca471dc20711010706t2eebea64je8e296563d181906@mail.gmail.com>
	<91DA47AE-6A69-4FB0-879F-48D7672227D6@mac.com>
	<ca471dc20711010722h73c3e68j72c43000569e8d61@mail.gmail.com>
Message-ID: <6B26A0FC-DEAA-45A8-8A77-B7AA5FE73AFD@mac.com>


On 1 Nov, 2007, at 15:22, Guido van Rossum wrote:

> On 11/1/07, Ronald Oussoren <ronaldoussoren at mac.com> wrote:
>> I'm volunteering to keep improving PyObjC, but I won't promise that
>> PyObjC will be complete enough to replace the Carbon tree by the time
>> Python 3.0 goes into beta. Heck, just commiting the version of PyObjC
>> that is in Leopard into a public repository took me three weeks :-(
>
> Which reminds me -- what version of Python is in Leopard?

2.5.1 + most of the patches that will be in 2.5.2 + some additional  
patches by Apple. AFAIK the latter are some patches to support their  
build machinery and patches that add support for DTrace.

>
>
>> Does anyone have suggestions on how to mobilize people for this
>> without scaring them away when explaining what needs to be done?
>> People, including myself to be honest, seem to find other things to  
>> do
>> when the realize that fixing the Carbon wrappers involves  working
>> with and hacking on bgen :-(
>
> I admit bgen is too ancient and too ad-hoc to try and bother with (and
> I wrote most of it!). How would you solve the problem it solves today?

Bgen is pretty good at what it does, but it does have a very steep  
learning curve. It doesn't help that you have to be logged on as Jack  
on Jack's machine to regenerate the Carbon bindings, meaning that  
anyone else will have to do some work just to be able to *use* bgen.

I have a different code parsing tool for PyObjC, and AFAIK there is a  
another one that generates ctypes code.

On the bright side: Carbon is basicly dead: there will be no new  
development on Carbon and it also not supported in 64-bit mode (at  
least the GUI bits).

Ronald

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2224 bytes
Desc: not available
Url : http://mail.python.org/pipermail/python-3000/attachments/20071101/c184feb6/attachment-0001.bin 

From guido at python.org  Thu Nov  1 15:34:07 2007
From: guido at python.org (Guido van Rossum)
Date: Thu, 1 Nov 2007 07:34:07 -0700
Subject: [Python-3000] PEP3137: "".encode() return type
In-Reply-To: <4729E0AF.3050608@cheimes.de>
References: <4729E0AF.3050608@cheimes.de>
Message-ID: <ca471dc20711010734h576c1ea0t3e5f616d836e7014@mail.gmail.com>

I know; right before 3.0a1 was released I fixed all encoders to return
PyBytes. IMO they should return PyString though. The best place to fix
this quickly is in the wrapper function(s) -- if the codec returned
PyBytes, just change it to PyString again. Then we can fix the codecs
later (or leave it as it is for now and wait until we rename the C
types :-).

To avoid us doing double work, can you just submit any straightforward
fixes you might already have made, and email me about projects you
have underway? I expect to be getting back to this in about two hours.
:-)

--Guido

On 11/1/07, Christian Heimes <lists at cheimes.de> wrote:
> I'm trying to fix some of the errors in the py3k-pep3137 branch and I
> stumbled over an issue with encode().
>
> TypeError: encoder did not return a bytes object (type=bytes)
>
> The sentence "... encoding always takes a Unicode string and returns a
> bytes sequence, and decoding always takes a bytes sequence and returns a
> Unicode string." isn't helpful because it's ambiguous. Do you mean the
> old bytes type PyBytes or the new bytes type PyString?
>
> One of the encode methods in unicodeobject.c PyUnicode_AsEncodedString()
> checks for PyString and converts it into a buffer (PyBytes).
>
>     if (!PyBytes_Check(v)) {
>         if (PyString_Check(v)) {
>             /* Old codec, turn it into bytes */
>             PyObject *b = PyBytes_FromObject(v);
>             Py_DECREF(v);
>             return b;
>         }
>
> unicode_encode() doesn't like PyString at all and immediately raises a
> type error.
>
> * What's the correct return type, PyBytes or PyString?
>
> * If PyString is wrong shouldn't we fix the PyUnicode_AsEncodedString
> and remove PyBytes_FromObject?
>
> Christian
>
> _______________________________________________
> 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 lists at cheimes.de  Thu Nov  1 16:43:42 2007
From: lists at cheimes.de (Christian Heimes)
Date: Thu, 01 Nov 2007 16:43:42 +0100
Subject: [Python-3000] PEP3137: "".encode() return type
In-Reply-To: <ca471dc20711010734h576c1ea0t3e5f616d836e7014@mail.gmail.com>
References: <4729E0AF.3050608@cheimes.de>
	<ca471dc20711010734h576c1ea0t3e5f616d836e7014@mail.gmail.com>
Message-ID: <4729F42E.1060303@cheimes.de>

Guido van Rossum wrote:
> To avoid us doing double work, can you just submit any straightforward
> fixes you might already have made, and email me about projects you
> have underway? I expect to be getting back to this in about two hours.
> :-)

I'm walking through Lib/ and Lib/test/ and I'm fixing obvious problems
caused by read only bytes(), missing str8() and so on. Can you please
fix the issues with the encoding() return type and codecs? A good bunch
of errors is related to it and you know the system. :)

Christian

From guido at python.org  Thu Nov  1 17:24:01 2007
From: guido at python.org (Guido van Rossum)
Date: Thu, 1 Nov 2007 09:24:01 -0700
Subject: [Python-3000] PEP3137: "".encode() return type
In-Reply-To: <4729F42E.1060303@cheimes.de>
References: <4729E0AF.3050608@cheimes.de>
	<ca471dc20711010734h576c1ea0t3e5f616d836e7014@mail.gmail.com>
	<4729F42E.1060303@cheimes.de>
Message-ID: <ca471dc20711010924y5fefb8eap12aa298810663904@mail.gmail.com>

OK, after I'm done with the merge from hell (I decided to merge from
the trunk to py3k).

On 11/1/07, Christian Heimes <lists at cheimes.de> wrote:
> Guido van Rossum wrote:
> > To avoid us doing double work, can you just submit any straightforward
> > fixes you might already have made, and email me about projects you
> > have underway? I expect to be getting back to this in about two hours.
> > :-)
>
> I'm walking through Lib/ and Lib/test/ and I'm fixing obvious problems
> caused by read only bytes(), missing str8() and so on. Can you please
> fix the issues with the encoding() return type and codecs? A good bunch
> of errors is related to it and you know the system. :)
>
> Christian
>


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

From janssen at parc.com  Thu Nov  1 17:36:11 2007
From: janssen at parc.com (Bill Janssen)
Date: Thu, 1 Nov 2007 09:36:11 PDT
Subject: [Python-3000] pickle compatibility between 2.x and 3.0
In-Reply-To: <ca471dc20711010718u5d437d60i9fd549e9c7271993@mail.gmail.com> 
References: <ca471dc20711010718u5d437d60i9fd549e9c7271993@mail.gmail.com>
Message-ID: <07Nov1.083617pst."57996"@synergy1.parc.xerox.com>

> I could leave this all up to the 3.0 application, which would have to
> "fix up" any bytes in the pickle it receives explicitly if it wants
> to. Alternatively, I could add an encoding option to the pickle
> loading APIs (and for full flexibility an errors option as well) so
> that at least simple text-based applications might have a chance of
> reading the data that they themselves wrote before they were ported to
> 3.0 with minimal changes (only the unpickling calls would have to be
> modified).

I like this idea.  I'd suggest just a global encoding option, and
making the default be null; that is, if your program didn't set a
default pickle string encoding, you get bytes, which is almost
certainly the right thing to do.  But if you've set a default
encoding, you get a string.  Then "simple text-based applications"
only have to add one line to get the behavior they expect.

Bill

From janssen at parc.com  Thu Nov  1 17:39:31 2007
From: janssen at parc.com (Bill Janssen)
Date: Thu, 1 Nov 2007 09:39:31 PDT
Subject: [Python-3000] plat-mac seriously broken?
In-Reply-To: <6B26A0FC-DEAA-45A8-8A77-B7AA5FE73AFD@mac.com> 
References: <18211.33450.332197.304601@montanaro.dyndns.org>
	<1209807056282906541@unknownmsgid>
	<ca471dc20710291041s3f66d478se6168310164e6f60@mail.gmail.com>
	<bbaeab100710301105j4f149731sbb89b255554be85e@mail.gmail.com>
	<C9173044-2C47-4D81-8249-0D7464A5426A@mac.com>
	<ca471dc20711010706t2eebea64je8e296563d181906@mail.gmail.com>
	<91DA47AE-6A69-4FB0-879F-48D7672227D6@mac.com>
	<ca471dc20711010722h73c3e68j72c43000569e8d61@mail.gmail.com>
	<6B26A0FC-DEAA-45A8-8A77-B7AA5FE73AFD@mac.com>
Message-ID: <07Nov1.083932pst."57996"@synergy1.parc.xerox.com>

> On the bright side: Carbon is basicly dead: there will be no new  
> development on Carbon and it also not supported in 64-bit mode (at  
> least the GUI bits).

Unfortunately, the "gotcha" is that some existing functionality is not
available via Objective-C (yet?); I looked at this when writing an
MDQuery interface for Python, and found that I needed to use the
Carbon bindings instead of the ObjC ones.  For the GUI bits, Ronald
is right, but there's lots of stuff in plat-mac that isn't about the
GUI (all of it!?).

Bill

From facundobatista at gmail.com  Thu Nov  1 17:50:57 2007
From: facundobatista at gmail.com (Facundo Batista)
Date: Thu, 1 Nov 2007 13:50:57 -0300
Subject: [Python-3000] pickle compatibility between 2.x and 3.0
In-Reply-To: <ca471dc20711010718u5d437d60i9fd549e9c7271993@mail.gmail.com>
References: <ca471dc20711010718u5d437d60i9fd549e9c7271993@mail.gmail.com>
Message-ID: <e04bdf310711010950k3c6e8b9cp7fbafe2c2c6e53e9@mail.gmail.com>

2007/11/1, Guido van Rossum <guido at python.org>:

> I could leave this all up to the 3.0 application, which would have to
> "fix up" any bytes in the pickle it receives explicitly if it wants
> to. Alternatively, I could add an encoding option to the pickle
> loading APIs (and for full flexibility an errors option as well) so
> that at least simple text-based applications might have a chance of
> reading the data that they themselves wrote before they were ported to
> 3.0 with minimal changes (only the unpickling calls would have to be
> modified).

I think that to make possible to the unpickling appl to specify which
encoding to use is the best option here, so to avoid:

- Need to change the appl that created the pickle (that can be not accesible).

- Have to make the work by hand of dealing with that "fix up" everywhere.

- Requests from developers to add a "magic guess" to discover
automatically which encoding use.

Regards,

-- 
.    Facundo

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

From brett at python.org  Thu Nov  1 18:24:37 2007
From: brett at python.org (Brett Cannon)
Date: Thu, 1 Nov 2007 10:24:37 -0700
Subject: [Python-3000] plat-mac seriously broken?
In-Reply-To: <5051605463779624296@unknownmsgid>
References: <18211.33450.332197.304601@montanaro.dyndns.org>
	<1209807056282906541@unknownmsgid>
	<ca471dc20710291041s3f66d478se6168310164e6f60@mail.gmail.com>
	<bbaeab100710301105j4f149731sbb89b255554be85e@mail.gmail.com>
	<C9173044-2C47-4D81-8249-0D7464A5426A@mac.com>
	<ca471dc20711010706t2eebea64je8e296563d181906@mail.gmail.com>
	<91DA47AE-6A69-4FB0-879F-48D7672227D6@mac.com>
	<ca471dc20711010722h73c3e68j72c43000569e8d61@mail.gmail.com>
	<6B26A0FC-DEAA-45A8-8A77-B7AA5FE73AFD@mac.com>
	<5051605463779624296@unknownmsgid>
Message-ID: <bbaeab100711011024l3eada313y80d7a7ccfeca6ba4@mail.gmail.com>

On 11/1/07, Bill Janssen <janssen at parc.com> wrote:
> > On the bright side: Carbon is basicly dead: there will be no new
> > development on Carbon and it also not supported in 64-bit mode (at
> > least the GUI bits).
>
> Unfortunately, the "gotcha" is that some existing functionality is not
> available via Objective-C (yet?); I looked at this when writing an
> MDQuery interface for Python, and found that I needed to use the
> Carbon bindings instead of the ObjC ones.  For the GUI bits, Ronald
> is right, but there's lots of stuff in plat-mac that isn't about the
> GUI (all of it!?).

Can we identify what the modules are then that cannot be reproduced in
Objective-C yet (and thus through PyObjC)?  Considering Apple has said
Carbon's hey-day is over and people need to move over to Cocoa, maybe
Py3K just take the leap and say if you need Carbon, you stick with
2.x, otherwise Py3K is requiring you modernize your Mac code and move
to Cocoa and PyObjC.

-Brett

From janssen at parc.com  Thu Nov  1 20:22:35 2007
From: janssen at parc.com (Bill Janssen)
Date: Thu, 1 Nov 2007 12:22:35 PDT
Subject: [Python-3000] plat-mac seriously broken?
In-Reply-To: <bbaeab100711011024l3eada313y80d7a7ccfeca6ba4@mail.gmail.com> 
References: <18211.33450.332197.304601@montanaro.dyndns.org>
	<1209807056282906541@unknownmsgid>
	<ca471dc20710291041s3f66d478se6168310164e6f60@mail.gmail.com>
	<bbaeab100710301105j4f149731sbb89b255554be85e@mail.gmail.com>
	<C9173044-2C47-4D81-8249-0D7464A5426A@mac.com>
	<ca471dc20711010706t2eebea64je8e296563d181906@mail.gmail.com>
	<91DA47AE-6A69-4FB0-879F-48D7672227D6@mac.com>
	<ca471dc20711010722h73c3e68j72c43000569e8d61@mail.gmail.com>
	<6B26A0FC-DEAA-45A8-8A77-B7AA5FE73AFD@mac.com>
	<5051605463779624296@unknownmsgid>
	<bbaeab100711011024l3eada313y80d7a7ccfeca6ba4@mail.gmail.com>
Message-ID: <07Nov1.112237pst."57996"@synergy1.parc.xerox.com>

> if you need Carbon, you stick with
> 2.x, otherwise Py3K is requiring you modernize your Mac code and move
> to Cocoa and PyObjC.

Brett,

It's not just Carbon and Cocoa, which are primarily different bindings
for developing Apple-style "applications", and primarily in my mind
for GUI functionality (well, more than that, but primarily that --
QuickDraw vs. NeXTStep).  There's a lot of really nifty non-GUI stuff
on the Mac (heck, I do everything with X11 and GNU Emacs), and Python
works particularly well there because it has bindings to some of that
functionality.  Those system libraries are largely C/C++ based,
particularly in BSD userland, and seem to have differing levels of
Objective-C wrappers.  But these wrappers don't seem to typically
provide the same functionality that the C API does, particularly for
Core Foundation, which is a collection of C APIs.

http://developer.apple.com/documentation/CoreFoundation/index.html

The "plat-mac" stuff is a mix of GUI and "application" things, which I
agree have been largely superseded by PyObjC, and "internals" things,
which have not.  So it needs some sorting.  Maybe on the Mac-SIG
mailing list?  Maybe send out a message there saying, "We intend to
jettison plat-mac for Python 3K because PyObjC makes it unnecessary",
and see if anyone objects.

Personally, I think it makes sense to replace the existing
undocumented plat-mac non-GUI modules with documented ctypes-based
modules.

I don't develop Apple-style applications (or at least, not in C or
Objective-C), thus I don't use either Carbon or Cocoa much, so others
may have more information on this.

Bill

From martin at v.loewis.de  Thu Nov  1 21:42:03 2007
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 01 Nov 2007 21:42:03 +0100
Subject: [Python-3000] plat-mac seriously broken?
In-Reply-To: <91DA47AE-6A69-4FB0-879F-48D7672227D6@mac.com>
References: <18211.33450.332197.304601@montanaro.dyndns.org>	<1209807056282906541@unknownmsgid>	<ca471dc20710291041s3f66d478se6168310164e6f60@mail.gmail.com>	<bbaeab100710301105j4f149731sbb89b255554be85e@mail.gmail.com>	<C9173044-2C47-4D81-8249-0D7464A5426A@mac.com>	<ca471dc20711010706t2eebea64je8e296563d181906@mail.gmail.com>
	<91DA47AE-6A69-4FB0-879F-48D7672227D6@mac.com>
Message-ID: <472A3A1B.3060806@v.loewis.de>

> Does anyone have suggestions on how to mobilize people for this without
> scaring them away when explaining what needs to be done? People,
> including myself to be honest, seem to find other things to do when the
> realize that fixing the Carbon wrappers involves  working with and
> hacking on bgen :-(

One solution would be to declare the files to be written manually, i.e.
cut the connection to bgen. Then people would be free to perform any
corrections directly to the C code.

Of course, major changes would be tedious to implement, then.

Regards,
Martin

From nnorwitz at gmail.com  Thu Nov  1 22:51:54 2007
From: nnorwitz at gmail.com (Neal Norwitz)
Date: Thu, 1 Nov 2007 14:51:54 -0700
Subject: [Python-3000] plat-mac seriously broken?
In-Reply-To: <6B26A0FC-DEAA-45A8-8A77-B7AA5FE73AFD@mac.com>
References: <18211.33450.332197.304601@montanaro.dyndns.org>
	<1209807056282906541@unknownmsgid>
	<ca471dc20710291041s3f66d478se6168310164e6f60@mail.gmail.com>
	<bbaeab100710301105j4f149731sbb89b255554be85e@mail.gmail.com>
	<C9173044-2C47-4D81-8249-0D7464A5426A@mac.com>
	<ca471dc20711010706t2eebea64je8e296563d181906@mail.gmail.com>
	<91DA47AE-6A69-4FB0-879F-48D7672227D6@mac.com>
	<ca471dc20711010722h73c3e68j72c43000569e8d61@mail.gmail.com>
	<6B26A0FC-DEAA-45A8-8A77-B7AA5FE73AFD@mac.com>
Message-ID: <ee2a432c0711011451rcbcd175q8074b7738ecf7139@mail.gmail.com>

On Nov 1, 2007 7:31 AM, Ronald Oussoren <ronaldoussoren at mac.com> wrote:
>
> On 1 Nov, 2007, at 15:22, Guido van Rossum wrote:
>
> > On 11/1/07, Ronald Oussoren <ronaldoussoren at mac.com> wrote:
> >> I'm volunteering to keep improving PyObjC, but I won't promise that
> >> PyObjC will be complete enough to replace the Carbon tree by the time
> >> Python 3.0 goes into beta. Heck, just commiting the version of PyObjC
> >> that is in Leopard into a public repository took me three weeks :-(
> >
> > Which reminds me -- what version of Python is in Leopard?
>
> 2.5.1 + most of the patches that will be in 2.5.2 + some additional
> patches by Apple. AFAIK the latter are some patches to support their
> build machinery and patches that add support for DTrace.

Should any of the Apple changes be merged into the 2.5 branch?

n

From martin at v.loewis.de  Thu Nov  1 23:04:37 2007
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 01 Nov 2007 23:04:37 +0100
Subject: [Python-3000] plat-mac seriously broken?
In-Reply-To: <ee2a432c0711011451rcbcd175q8074b7738ecf7139@mail.gmail.com>
References: <18211.33450.332197.304601@montanaro.dyndns.org>	<1209807056282906541@unknownmsgid>	<ca471dc20710291041s3f66d478se6168310164e6f60@mail.gmail.com>	<bbaeab100710301105j4f149731sbb89b255554be85e@mail.gmail.com>	<C9173044-2C47-4D81-8249-0D7464A5426A@mac.com>	<ca471dc20711010706t2eebea64je8e296563d181906@mail.gmail.com>	<91DA47AE-6A69-4FB0-879F-48D7672227D6@mac.com>	<ca471dc20711010722h73c3e68j72c43000569e8d61@mail.gmail.com>	<6B26A0FC-DEAA-45A8-8A77-B7AA5FE73AFD@mac.com>
	<ee2a432c0711011451rcbcd175q8074b7738ecf7139@mail.gmail.com>
Message-ID: <472A4D75.8080703@v.loewis.de>

> Should any of the Apple changes be merged into the 2.5 branch?

Not without the Apple authors signing a contributor form.

Regards,
Martin

From greg.ewing at canterbury.ac.nz  Thu Nov  1 23:34:02 2007
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Fri, 02 Nov 2007 11:34:02 +1300
Subject: [Python-3000] pickle compatibility between 2.x and 3.0
In-Reply-To: <ca471dc20711010718u5d437d60i9fd549e9c7271993@mail.gmail.com>
References: <ca471dc20711010718u5d437d60i9fd549e9c7271993@mail.gmail.com>
Message-ID: <472A545A.3030902@canterbury.ac.nz>

Guido van Rossum wrote:
> I could add an encoding option to the pickle
> loading APIs

That sounds like the right thing to me. Or at least I
can't think of anything better.

Applications wanting to deal with pickles containing
strings of binary data would just have to specify
latin1 and translate the resulting strings to bytes
themselves.

--
Greg

From greg.ewing at canterbury.ac.nz  Thu Nov  1 23:42:14 2007
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Fri, 02 Nov 2007 11:42:14 +1300
Subject: [Python-3000] plat-mac seriously broken?
In-Reply-To: <91DA47AE-6A69-4FB0-879F-48D7672227D6@mac.com>
References: <18211.33450.332197.304601@montanaro.dyndns.org>
	<1209807056282906541@unknownmsgid>
	<ca471dc20710291041s3f66d478se6168310164e6f60@mail.gmail.com>
	<bbaeab100710301105j4f149731sbb89b255554be85e@mail.gmail.com>
	<C9173044-2C47-4D81-8249-0D7464A5426A@mac.com>
	<ca471dc20711010706t2eebea64je8e296563d181906@mail.gmail.com>
	<91DA47AE-6A69-4FB0-879F-48D7672227D6@mac.com>
Message-ID: <472A5646.8050107@canterbury.ac.nz>

Ronald Oussoren wrote:
> 
> People, 
> including myself to be honest, seem to find other things to do  when the 
> realize that fixing the Carbon wrappers involves  working  with and 
> hacking on bgen :-(

Perhaps a volunteer could be found to re-do them in Pyrex?

(No, I'm not volunteering for this myself.:-)

--
Greg

From guido at python.org  Fri Nov  2 03:21:11 2007
From: guido at python.org (Guido van Rossum)
Date: Thu, 1 Nov 2007 19:21:11 -0700
Subject: [Python-3000] What to do about "".join([b""])?
Message-ID: <ca471dc20711011921y3aca3149pe642f159baa7e027@mail.gmail.com>

Currently (in 3.0), "".join(<seq>) automatically applies str() to the
items of <seq>, *except* if the item is a bytes instance -- then it
raises a TypeError. Is that proper behavior? The alternative is to
uniformly apply str(), which for bytes returns a string of the form
"b'...'" or "buffer(b'...')" (depending on whether the bytes are
immutable or not). Given that we killed the exception for "" == b""
earlier, I'm tempted to remove the exception. Any opinions to the
contrary?

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

From jyasskin at gmail.com  Fri Nov  2 03:37:29 2007
From: jyasskin at gmail.com (Jeffrey Yasskin)
Date: Thu, 1 Nov 2007 19:37:29 -0700
Subject: [Python-3000] What to do about "".join([b""])?
In-Reply-To: <ca471dc20711011921y3aca3149pe642f159baa7e027@mail.gmail.com>
References: <ca471dc20711011921y3aca3149pe642f159baa7e027@mail.gmail.com>
Message-ID: <5d44f72f0711011937r2ab292cfj6ce33b6af9d67bfd@mail.gmail.com>

I'd na?vely vote for having "".join([non-strings]) raise a TypeError
unconditionally like it did in 2.5. I agree that it doesn't make sense
to special-case bytes here, but I don't know the reasons for changing
it to call str() in other cases.

On 11/1/07, Guido van Rossum <guido at python.org> wrote:
> Currently (in 3.0), "".join(<seq>) automatically applies str() to the
> items of <seq>, *except* if the item is a bytes instance -- then it
> raises a TypeError. Is that proper behavior? The alternative is to
> uniformly apply str(), which for bytes returns a string of the form
> "b'...'" or "buffer(b'...')" (depending on whether the bytes are
> immutable or not). Given that we killed the exception for "" == b""
> earlier, I'm tempted to remove the exception. Any opinions to the
> contrary?
>
> --
> --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/jyasskin%40gmail.com
>


-- 
Namast?,
Jeffrey Yasskin
http://jeffrey.yasskin.info/

"Religion is an improper response to the Divine." ? "Skinny Legs and
All", by Tom Robbins

From guido at python.org  Fri Nov  2 03:41:40 2007
From: guido at python.org (Guido van Rossum)
Date: Thu, 1 Nov 2007 19:41:40 -0700
Subject: [Python-3000] What to do about "".join([b""])?
In-Reply-To: <5d44f72f0711011937r2ab292cfj6ce33b6af9d67bfd@mail.gmail.com>
References: <ca471dc20711011921y3aca3149pe642f159baa7e027@mail.gmail.com>
	<5d44f72f0711011937r2ab292cfj6ce33b6af9d67bfd@mail.gmail.com>
Message-ID: <ca471dc20711011941i4112d90dn30d5a8567aed0da0@mail.gmail.com>

People wanted it for convenience. I agree it's debatable. OTOH "
".join([...]) could behave similarly to print(...) and there's
something to say for that. print(b"") will print b'' too once PEP 3137
is fully implemented.

On 11/1/07, Jeffrey Yasskin <jyasskin at gmail.com> wrote:
> I'd na?vely vote for having "".join([non-strings]) raise a TypeError
> unconditionally like it did in 2.5. I agree that it doesn't make sense
> to special-case bytes here, but I don't know the reasons for changing
> it to call str() in other cases.
>
> On 11/1/07, Guido van Rossum <guido at python.org> wrote:
> > Currently (in 3.0), "".join(<seq>) automatically applies str() to the
> > items of <seq>, *except* if the item is a bytes instance -- then it
> > raises a TypeError. Is that proper behavior? The alternative is to
> > uniformly apply str(), which for bytes returns a string of the form
> > "b'...'" or "buffer(b'...')" (depending on whether the bytes are
> > immutable or not). Given that we killed the exception for "" == b""
> > earlier, I'm tempted to remove the exception. Any opinions to the
> > contrary?
> >
> > --
> > --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/jyasskin%40gmail.com
> >
>
>
> --
> Namast?,
> Jeffrey Yasskin
> http://jeffrey.yasskin.info/
>
> "Religion is an improper response to the Divine." ? "Skinny Legs and
> All", by Tom Robbins
>


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

From facundobatista at gmail.com  Fri Nov  2 04:00:43 2007
From: facundobatista at gmail.com (Facundo Batista)
Date: Fri, 2 Nov 2007 00:00:43 -0300
Subject: [Python-3000] What to do about "".join([b""])?
In-Reply-To: <ca471dc20711011921y3aca3149pe642f159baa7e027@mail.gmail.com>
References: <ca471dc20711011921y3aca3149pe642f159baa7e027@mail.gmail.com>
Message-ID: <e04bdf310711012000l4077a534kf60adab394058bb4@mail.gmail.com>

2007/11/1, Guido van Rossum <guido at python.org>:

> Currently (in 3.0), "".join(<seq>) automatically applies str() to the
> items of <seq>, *except* if the item is a bytes instance -- then it
> raises a TypeError. Is that proper behavior? The alternative is to

I'd prefer to *always* apply the str() function: simpler, no except
when teaching it, always the same behaviour.


> uniformly apply str(), which for bytes returns a string of the form
> "b'...'" or "buffer(b'...')" (depending on whether the bytes are

Don't understand... From the trunk:

Python 3.0a1+ (py3k:58762, Nov  1 2007, 21:17:44)
[GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> str(b"hola")
'hola'


> immutable or not). Given that we killed the exception for "" == b""
> earlier, I'm tempted to remove the exception. Any opinions to the
> contrary?

+1 to remove the exception

Regards,

-- 
.    Facundo

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

From guido at python.org  Fri Nov  2 04:15:39 2007
From: guido at python.org (Guido van Rossum)
Date: Thu, 1 Nov 2007 20:15:39 -0700
Subject: [Python-3000] What to do about "".join([b""])?
In-Reply-To: <e04bdf310711012000l4077a534kf60adab394058bb4@mail.gmail.com>
References: <ca471dc20711011921y3aca3149pe642f159baa7e027@mail.gmail.com>
	<e04bdf310711012000l4077a534kf60adab394058bb4@mail.gmail.com>
Message-ID: <ca471dc20711012015o19ed1e18l3be4c3f77559a616@mail.gmail.com>

On 11/1/07, Facundo Batista <facundobatista at gmail.com> wrote:
> > uniformly apply str(), which for bytes returns a string of the form
> > "b'...'" or "buffer(b'...')" (depending on whether the bytes are
>
> Don't understand... From the trunk:
>
> Python 3.0a1+ (py3k:58762, Nov  1 2007, 21:17:44)
> [GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> str(b"hola")
> 'hola'

Ah, but now try it in the py3k-pep3137 trunk...

Python 3.0a1+ (py3k-pep3137, Nov  1 2007, 19:17:57)
[GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> str(b"hola")
"b'hola'"


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

From facundobatista at gmail.com  Fri Nov  2 05:12:03 2007
From: facundobatista at gmail.com (Facundo Batista)
Date: Fri, 2 Nov 2007 01:12:03 -0300
Subject: [Python-3000]  What to do about "".join([b""])?
In-Reply-To: <e04bdf310711012111j39573c21ob021d8da8c7769a4@mail.gmail.com>
References: <ca471dc20711011921y3aca3149pe642f159baa7e027@mail.gmail.com>
	<e04bdf310711012000l4077a534kf60adab394058bb4@mail.gmail.com>
	<ca471dc20711012015o19ed1e18l3be4c3f77559a616@mail.gmail.com>
	<e04bdf310711012111j39573c21ob021d8da8c7769a4@mail.gmail.com>
Message-ID: <e04bdf310711012112o71cd3732vd32a490d5abe67c0@mail.gmail.com>

2007/11/2, Guido van Rossum <guido at python.org>:

> Ah, but now try it in the py3k-pep3137 trunk...
>
> Python 3.0a1+ (py3k-pep3137, Nov  1 2007, 19:17:57)
> [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> str(b"hola")
> "b'hola'"

Ha. Bloody Universe glue, :)

Now I understand, :) Thanks.

Anyway, I keep my +1 to *always* apply str() to each element.

Thanks again,

.
--

.    Facundo

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

From greg at krypto.org  Fri Nov  2 05:21:32 2007
From: greg at krypto.org (Gregory P. Smith)
Date: Thu, 1 Nov 2007 21:21:32 -0700
Subject: [Python-3000] What to do about "".join([b""])?
In-Reply-To: <ca471dc20711011921y3aca3149pe642f159baa7e027@mail.gmail.com>
References: <ca471dc20711011921y3aca3149pe642f159baa7e027@mail.gmail.com>
Message-ID: <52dc1c820711012121y2b58ac55n82328e0df4054695@mail.gmail.com>

-1 on having "".join() call str at all.  yuck.  shouldn't the caller just
write:

 "".join((str(x) for x in thing))

when they desire guaranteed stringification instead of a TypeError?

Anyways others disagree and this was already implemented so I assume my -1
is rejected, I at least agree on this:

+1 get rid of the inconsistent TypeError if a bytes or buffer object is in
the list.  thats inconsistent.  inserting the b'' or buffer(b'') syntax is
the consistent thing to do in that situation.

-gps

On 11/1/07, Guido van Rossum <guido at python.org> wrote:
>
> Currently (in 3.0), "".join(<seq>) automatically applies str() to the
> items of <seq>, *except* if the item is a bytes instance -- then it
> raises a TypeError. Is that proper behavior? The alternative is to
> uniformly apply str(), which for bytes returns a string of the form
> "b'...'" or "buffer(b'...')" (depending on whether the bytes are
> immutable or not). Given that we killed the exception for "" == b""
> earlier, I'm tempted to remove the exception. Any opinions to the
> contrary?
>
> --
> --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/greg%40krypto.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20071101/792de2b5/attachment-0001.htm 

From greg at krypto.org  Fri Nov  2 05:37:59 2007
From: greg at krypto.org (Gregory P. Smith)
Date: Thu, 1 Nov 2007 21:37:59 -0700
Subject: [Python-3000] pickle compatibility between 2.x and 3.0
In-Reply-To: <e04bdf310711010950k3c6e8b9cp7fbafe2c2c6e53e9@mail.gmail.com>
References: <ca471dc20711010718u5d437d60i9fd549e9c7271993@mail.gmail.com>
	<e04bdf310711010950k3c6e8b9cp7fbafe2c2c6e53e9@mail.gmail.com>
Message-ID: <52dc1c820711012137k5c0ab46cq840021361c5406a4@mail.gmail.com>

On 11/1/07, Facundo Batista <facundobatista at gmail.com> wrote:
>
> 2007/11/1, Guido van Rossum <guido at python.org>:
>
> > I could leave this all up to the 3.0 application, which would have to
> > "fix up" any bytes in the pickle it receives explicitly if it wants
> > to. Alternatively, I could add an encoding option to the pickle
> > loading APIs (and for full flexibility an errors option as well) so
> > that at least simple text-based applications might have a chance of
> > reading the data that they themselves wrote before they were ported to
> > 3.0 with minimal changes (only the unpickling calls would have to be
> > modified).
>
> I think that to make possible to the unpickling appl to specify which
> encoding to use is the best option here, so to avoid:
>
> - Need to change the appl that created the pickle (that can be not
> accesible).
>
> - Have to make the work by hand of dealing with that "fix up" everywhere.
>
> - Requests from developers to add a "magic guess" to discover
> automatically which encoding use.
>
> Regards,
>
> --
> .    Facundo


Brainstorming here... how about an optional callable argument when
unpickling to let the developers write their own "magic guess" function?
This callable should take a single parameter and its return value would be
used as the unpickled string.

Or is that too much work and not enough context in the callable to be
useful? People could just as easily write code to recurse through the
unpickled output converting the appropriate bytes objects as needed.

-gps
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20071101/57478d08/attachment.htm 

From fdrake at acm.org  Fri Nov  2 05:54:29 2007
From: fdrake at acm.org (Fred Drake)
Date: Fri, 2 Nov 2007 00:54:29 -0400
Subject: [Python-3000] pickle compatibility between 2.x and 3.0
In-Reply-To: <52dc1c820711012137k5c0ab46cq840021361c5406a4@mail.gmail.com>
References: <ca471dc20711010718u5d437d60i9fd549e9c7271993@mail.gmail.com>
	<e04bdf310711010950k3c6e8b9cp7fbafe2c2c6e53e9@mail.gmail.com>
	<52dc1c820711012137k5c0ab46cq840021361c5406a4@mail.gmail.com>
Message-ID: <5F00F6F3-634B-441A-B8B2-2ACBB4350779@acm.org>

On Nov 2, 2007, at 12:37 AM, Gregory P. Smith wrote:
> Or is that too much work and not enough context in the callable to  
> be useful? People could just as easily write code to recurse  
> through the unpickled output converting the appropriate bytes  
> objects as needed.

Not enough context to be useful, but it might be the best that can be  
done.  Calling a function and passing a bytes value allows the  
application to know that Python 2 str was encountered, and gives the  
application the opportunity to deal with it when the unpickling is  
done, or raise an exception.

I'd be happy if the "default" behavior on str values is to raise an  
exception, rather than ever making a guess silently.


   -Fred

-- 
Fred Drake   <fdrake at acm.org>




From brett at python.org  Fri Nov  2 06:26:20 2007
From: brett at python.org (Brett Cannon)
Date: Thu, 1 Nov 2007 22:26:20 -0700
Subject: [Python-3000] What to do about "".join([b""])?
In-Reply-To: <ca471dc20711011921y3aca3149pe642f159baa7e027@mail.gmail.com>
References: <ca471dc20711011921y3aca3149pe642f159baa7e027@mail.gmail.com>
Message-ID: <bbaeab100711012226n4ede98f9pb5c88bfa2765426a@mail.gmail.com>

On 11/1/07, Guido van Rossum <guido at python.org> wrote:
> Currently (in 3.0), "".join(<seq>) automatically applies str() to the
> items of <seq>, *except* if the item is a bytes instance -- then it
> raises a TypeError. Is that proper behavior? The alternative is to
> uniformly apply str(), which for bytes returns a string of the form
> "b'...'" or "buffer(b'...')" (depending on whether the bytes are
> immutable or not). Given that we killed the exception for "" == b""
> earlier, I'm tempted to remove the exception. Any opinions to the
> contrary?

I say all or nothing; uniformly apply str and duck typing or only
accept str objects.  For transition reasons the latter would probably
work out nicer than the former.  But for purity I prefer applying
str().

-Brett

From ronaldoussoren at mac.com  Fri Nov  2 07:23:45 2007
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Fri, 2 Nov 2007 07:23:45 +0100
Subject: [Python-3000] plat-mac seriously broken?
In-Reply-To: <bbaeab100711011024l3eada313y80d7a7ccfeca6ba4@mail.gmail.com>
References: <18211.33450.332197.304601@montanaro.dyndns.org>
	<1209807056282906541@unknownmsgid>
	<ca471dc20710291041s3f66d478se6168310164e6f60@mail.gmail.com>
	<bbaeab100710301105j4f149731sbb89b255554be85e@mail.gmail.com>
	<C9173044-2C47-4D81-8249-0D7464A5426A@mac.com>
	<ca471dc20711010706t2eebea64je8e296563d181906@mail.gmail.com>
	<91DA47AE-6A69-4FB0-879F-48D7672227D6@mac.com>
	<ca471dc20711010722h73c3e68j72c43000569e8d61@mail.gmail.com>
	<6B26A0FC-DEAA-45A8-8A77-B7AA5FE73AFD@mac.com>
	<5051605463779624296@unknownmsgid>
	<bbaeab100711011024l3eada313y80d7a7ccfeca6ba4@mail.gmail.com>
Message-ID: <563B4C57-D9DE-4C40-BCDF-5E0AD884891E@mac.com>


On 1 Nov, 2007, at 18:24, Brett Cannon wrote:

> On 11/1/07, Bill Janssen <janssen at parc.com> wrote:
>>> On the bright side: Carbon is basicly dead: there will be no new
>>> development on Carbon and it also not supported in 64-bit mode (at
>>> least the GUI bits).
>>
>> Unfortunately, the "gotcha" is that some existing functionality is  
>> not
>> available via Objective-C (yet?); I looked at this when writing an
>> MDQuery interface for Python, and found that I needed to use the
>> Carbon bindings instead of the ObjC ones.  For the GUI bits, Ronald
>> is right, but there's lots of stuff in plat-mac that isn't about the
>> GUI (all of it!?).
>
> Can we identify what the modules are then that cannot be reproduced in
> Objective-C yet (and thus through PyObjC)?  Considering Apple has said
> Carbon's hey-day is over and people need to move over to Cocoa, maybe
> Py3K just take the leap and say if you need Carbon, you stick with
> 2.x, otherwise Py3K is requiring you modernize your Mac code and move
> to Cocoa and PyObjC.

The MDQuery API's are not Carbon, but CoreFoundation. The latter is  
available through the very latest version of PyObjC (the one that  
ships with Leopard).

Someone will have to go over the rest of plat-mac to check which bits  
are worth saving/modernizing. There is a lot of  ancient and barely  
tested junk in there.  I don't mind being that someone, but don't know  
when I'll be able to do that.

Ronald
>
>
> -Brett

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2224 bytes
Desc: not available
Url : http://mail.python.org/pipermail/python-3000/attachments/20071102/7f1a607f/attachment.bin 

From ronaldoussoren at mac.com  Fri Nov  2 07:37:35 2007
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Fri, 2 Nov 2007 07:37:35 +0100
Subject: [Python-3000] plat-mac seriously broken?
In-Reply-To: <ee2a432c0711011451rcbcd175q8074b7738ecf7139@mail.gmail.com>
References: <18211.33450.332197.304601@montanaro.dyndns.org>
	<1209807056282906541@unknownmsgid>
	<ca471dc20710291041s3f66d478se6168310164e6f60@mail.gmail.com>
	<bbaeab100710301105j4f149731sbb89b255554be85e@mail.gmail.com>
	<C9173044-2C47-4D81-8249-0D7464A5426A@mac.com>
	<ca471dc20711010706t2eebea64je8e296563d181906@mail.gmail.com>
	<91DA47AE-6A69-4FB0-879F-48D7672227D6@mac.com>
	<ca471dc20711010722h73c3e68j72c43000569e8d61@mail.gmail.com>
	<6B26A0FC-DEAA-45A8-8A77-B7AA5FE73AFD@mac.com>
	<ee2a432c0711011451rcbcd175q8074b7738ecf7139@mail.gmail.com>
Message-ID: <3EBE3CB5-EA66-4B95-A90D-96812EAFB327@mac.com>


On 1 Nov, 2007, at 22:51, Neal Norwitz wrote:

> On Nov 1, 2007 7:31 AM, Ronald Oussoren <ronaldoussoren at mac.com>  
> wrote:
>>
>> On 1 Nov, 2007, at 15:22, Guido van Rossum wrote:
>>
>>> On 11/1/07, Ronald Oussoren <ronaldoussoren at mac.com> wrote:
>>>> I'm volunteering to keep improving PyObjC, but I won't promise that
>>>> PyObjC will be complete enough to replace the Carbon tree by the  
>>>> time
>>>> Python 3.0 goes into beta. Heck, just commiting the version of  
>>>> PyObjC
>>>> that is in Leopard into a public repository took me three weeks :-(
>>>
>>> Which reminds me -- what version of Python is in Leopard?
>>
>> 2.5.1 + most of the patches that will be in 2.5.2 + some additional
>> patches by Apple. AFAIK the latter are some patches to support their
>> build machinery and patches that add support for DTrace.
>
> Should any of the Apple changes be merged into the 2.5 branch?

I haven't seen their patches yet, but I'd like to keep the python.org  
close to whatever Apple ships (at least featurewise) to make it easier  
to move my code to later versions of Python without loosing usuful  
functionality in the process (and DTrace&friends promise to be very  
useful during development and tuning)

Ronald

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2224 bytes
Desc: not available
Url : http://mail.python.org/pipermail/python-3000/attachments/20071102/980e1c07/attachment.bin 

From lists at cheimes.de  Fri Nov  2 09:40:46 2007
From: lists at cheimes.de (Christian Heimes)
Date: Fri, 02 Nov 2007 09:40:46 +0100
Subject: [Python-3000] What to do about "".join([b""])?
In-Reply-To: <ca471dc20711011921y3aca3149pe642f159baa7e027@mail.gmail.com>
References: <ca471dc20711011921y3aca3149pe642f159baa7e027@mail.gmail.com>
Message-ID: <472AE28E.7070702@cheimes.de>

Guido van Rossum wrote:
> Currently (in 3.0), "".join(<seq>) automatically applies str() to the
> items of <seq>, *except* if the item is a bytes instance -- then it
> raises a TypeError. Is that proper behavior? The alternative is to
> uniformly apply str(), which for bytes returns a string of the form
> "b'...'" or "buffer(b'...')" (depending on whether the bytes are
> immutable or not). Given that we killed the exception for "" == b""
> earlier, I'm tempted to remove the exception. Any opinions to the
> contrary?

-1

In Python 2.x the implicit encoding of a string with
sys.getdefaultencoding() caused me more than one headache. If fear the
implicit conversion of a byte sequence to its representation may cause
similar problems. If we take one step down that road we can't go back again.

''.join() could grow an encoding argument but that's ugly, too.
''.join(s if isinstance(s) else str(s, 'utf-8') for s in seq) works for
me. :)

However I like b''.join, buffer().join and the other methods to accept
buffers and bytes. I don't see a reason why the methods shouldn't accept
them.

>>> b"".join((b'1', b'2'))
b'12'
>>> b"".join((buffer(b'1'), buffer(b'2')))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: sequence item 0: expected string, buffer found
>>> buffer().join((buffer(b'1'), buffer(b'2')))
buffer(b'12')
>>> buffer().join((b'1', b'2'))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: can only join an iterable of bytes (item 0 has type 'bytes')

Christian


From lists at cheimes.de  Fri Nov  2 10:02:01 2007
From: lists at cheimes.de (Christian Heimes)
Date: Fri, 02 Nov 2007 10:02:01 +0100
Subject: [Python-3000] pickle compatibility between 2.x and 3.0
In-Reply-To: <52dc1c820711012137k5c0ab46cq840021361c5406a4@mail.gmail.com>
References: <ca471dc20711010718u5d437d60i9fd549e9c7271993@mail.gmail.com>	<e04bdf310711010950k3c6e8b9cp7fbafe2c2c6e53e9@mail.gmail.com>
	<52dc1c820711012137k5c0ab46cq840021361c5406a4@mail.gmail.com>
Message-ID: <fgep2a$anq$1@ger.gmane.org>

Gregory P. Smith wrote:
> Brainstorming here... how about an optional callable argument when
> unpickling to let the developers write their own "magic guess" function?
> This callable should take a single parameter and its return value would be
> used as the unpickled string.

The general idea is good however a single magic method won't do any
good. The system must be able to handle cases where an object may
contain text strings and byte strings. Developers must be able to handle
the conversation on a per class base.

Here is some pseudo code. It should be able to handle most use cases.

def convertMyClass(args, state, reduceargs):
    """Convert MyClass instances

    A converter is a callable which accepts three arguments:
      args - __getinitargs__() or __getnewargs__()
      state - __getstate__()
      reduce - __reduce__()
    """
    # code here
    return args, state, reduceargs

class MyClass:
    pass

pickletools.registerMigrator(MyClass, convertMyClass)

Christian


From lists at cheimes.de  Fri Nov  2 11:24:21 2007
From: lists at cheimes.de (Christian Heimes)
Date: Fri, 02 Nov 2007 11:24:21 +0100
Subject: [Python-3000] PEP3137: "".encode() return type
In-Reply-To: <ca471dc20711010924y5fefb8eap12aa298810663904@mail.gmail.com>
References: <4729E0AF.3050608@cheimes.de>	<ca471dc20711010734h576c1ea0t3e5f616d836e7014@mail.gmail.com>	<4729F42E.1060303@cheimes.de>
	<ca471dc20711010924y5fefb8eap12aa298810663904@mail.gmail.com>
Message-ID: <472AFAD5.2040904@cheimes.de>

Guido van Rossum wrote:
> OK, after I'm done with the merge from hell (I decided to merge from
> the trunk to py3k).

r58763 is causing a stack dump when I run the unit test suite (Ubuntu
7.10, UCS4 build, no debug).

$ ./python Lib/test/regrtest.py test_ftplib
test_ftplib
Segmentation fault (core dumped)

The backtrace of the core dump is:

#0  0xb7e3358e in getaddrinfo () from /lib/tls/i686/cmov/libc.so.6
#1  0xb7c70717 in socket_getaddrinfo (self=0x0, args=0x9bf398c) at
/home/heimes/dev/python/py3k-pep3137/Modules/socketmodule.c:3691
...

I've fixed the bug in r58767.

Christian

From adam at hupp.org  Fri Nov  2 13:18:02 2007
From: adam at hupp.org (Adam Hupp)
Date: Fri, 2 Nov 2007 08:18:02 -0400
Subject: [Python-3000] What to do about "".join([b""])?
In-Reply-To: <ca471dc20711011921y3aca3149pe642f159baa7e027@mail.gmail.com>
References: <ca471dc20711011921y3aca3149pe642f159baa7e027@mail.gmail.com>
Message-ID: <766a29bd0711020518x3e8a1ff8wa8fb9a8201bd402a@mail.gmail.com>

On 11/1/07, Guido van Rossum <guido at python.org> wrote:

> The alternative is to uniformly apply str(), which for bytes returns a string of the form
> "b'...'" or "buffer(b'...')" (depending on whether the bytes are
> immutable or not). Given that we killed the exception for "" == b""
> earlier, I'm tempted to remove the exception. Any opinions to the
> contrary?

+1 on removing bytes-specific behavior from join.  Whatever the
behavior is it should be consistent.

I prefer removing the str call on .join entirely.  Is there any other
string method that implicitly str's it's argument?  I can't think of
any.   If this works I would expect that concatenation also implicitly
converts (ala java).


-- 
Adam Hupp | http://hupp.org/adam/

From barry at python.org  Fri Nov  2 13:40:38 2007
From: barry at python.org (Barry Warsaw)
Date: Fri, 2 Nov 2007 08:40:38 -0400
Subject: [Python-3000] What to do about "".join([b""])?
In-Reply-To: <766a29bd0711020518x3e8a1ff8wa8fb9a8201bd402a@mail.gmail.com>
References: <ca471dc20711011921y3aca3149pe642f159baa7e027@mail.gmail.com>
	<766a29bd0711020518x3e8a1ff8wa8fb9a8201bd402a@mail.gmail.com>
Message-ID: <420EE378-F66E-453F-A6AC-A3CBFF31EA4F@python.org>

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

On Nov 2, 2007, at 8:18 AM, Adam Hupp wrote:

> I prefer removing the str call on .join entirely.  Is there any other
> string method that implicitly str's it's argument?  I can't think of
> any.   If this works I would expect that concatenation also implicitly
> converts (ala java).

 From a purity standpoint, I agree with removing the implicit  
str'ing.  I'm just sure what is more practical.

- -Barry

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

iQCVAwUBRysaxnEjvBPtnXfVAQIj1QQAm9sDwrJXWr9jRc1MSG5wNo868qJwFp0w
84F2ekvFgirnHCV41Ljz6omxXAuvknnKpRzF/zqPWtyUzcEkhMOAVxZMuYHe/q5Y
kqRTHlL4gYdUbJEArqAOyaJFXGjVlhH6KcphbzbPShdCmG3xY8d0E6cwONQmy3sJ
6yawM4T68BA=
=TAGo
-----END PGP SIGNATURE-----

From shiblon at gmail.com  Fri Nov  2 13:44:39 2007
From: shiblon at gmail.com (Chris Monson)
Date: Fri, 2 Nov 2007 08:44:39 -0400
Subject: [Python-3000] What to do about "".join([b""])?
In-Reply-To: <766a29bd0711020518x3e8a1ff8wa8fb9a8201bd402a@mail.gmail.com>
References: <ca471dc20711011921y3aca3149pe642f159baa7e027@mail.gmail.com>
	<766a29bd0711020518x3e8a1ff8wa8fb9a8201bd402a@mail.gmail.com>
Message-ID: <da3f900e0711020544r5ea2fda7ice7b9046ac4060aa@mail.gmail.com>

+1 on removing implicit str calls from join altogether.


On 11/2/07, Adam Hupp <adam at hupp.org> wrote:
> On 11/1/07, Guido van Rossum <guido at python.org> wrote:
>
> > The alternative is to uniformly apply str(), which for bytes returns a
> string of the form
> > "b'...'" or "buffer(b'...')" (depending on whether the bytes are
> > immutable or not). Given that we killed the exception for "" == b""
> > earlier, I'm tempted to remove the exception. Any opinions to the
> > contrary?
>
> +1 on removing bytes-specific behavior from join.  Whatever the
> behavior is it should be consistent.
>
> I prefer removing the str call on .join entirely.  Is there any other
> string method that implicitly str's it's argument?  I can't think of
> any.   If this works I would expect that concatenation also implicitly
> converts (ala java).
>
>
> --
> Adam Hupp | http://hupp.org/adam/
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe:
> http://mail.python.org/mailman/options/python-3000/shiblon%40gmail.com
>

From adam at hupp.org  Fri Nov  2 13:48:05 2007
From: adam at hupp.org (Adam Hupp)
Date: Fri, 2 Nov 2007 08:48:05 -0400
Subject: [Python-3000] status of buildbots
In-Reply-To: <ee2a432c0710310013n66af2851u775e35eb7e86f43f@mail.gmail.com>
References: <ee2a432c0710310013n66af2851u775e35eb7e86f43f@mail.gmail.com>
Message-ID: <766a29bd0711020548h3547bcblcd120e9147b57539@mail.gmail.com>

On 10/31/07, Neal Norwitz <nnorwitz at gmail.com> wrote:
> We've made a lot of progress with the tests.  Several buildbots are
> green.  http://python.org/dev/buildbot/3.0/
>
> There are some tests that are unstable, at least:
>    test_asynchat test_urllib2net test_xmlrpc

Here's a patch for the test_xmlrpc issue:

http://bugs.python.org/issue1373

-- 
Adam Hupp | http://hupp.org/adam/

From guido at python.org  Fri Nov  2 15:20:55 2007
From: guido at python.org (Guido van Rossum)
Date: Fri, 2 Nov 2007 07:20:55 -0700
Subject: [Python-3000] What to do about "".join([b""])?
In-Reply-To: <da3f900e0711020544r5ea2fda7ice7b9046ac4060aa@mail.gmail.com>
References: <ca471dc20711011921y3aca3149pe642f159baa7e027@mail.gmail.com>
	<766a29bd0711020518x3e8a1ff8wa8fb9a8201bd402a@mail.gmail.com>
	<da3f900e0711020544r5ea2fda7ice7b9046ac4060aa@mail.gmail.com>
Message-ID: <ca471dc20711020720gede5109g5033cd7fa196373f@mail.gmail.com>

OK, that's what I'll do. I was never really comfortable with it, and
now I know why.

On 11/2/07, Chris Monson <shiblon at gmail.com> wrote:
> +1 on removing implicit str calls from join altogether.
>
>
> On 11/2/07, Adam Hupp <adam at hupp.org> wrote:
> > On 11/1/07, Guido van Rossum <guido at python.org> wrote:
> >
> > > The alternative is to uniformly apply str(), which for bytes returns a
> > string of the form
> > > "b'...'" or "buffer(b'...')" (depending on whether the bytes are
> > > immutable or not). Given that we killed the exception for "" == b""
> > > earlier, I'm tempted to remove the exception. Any opinions to the
> > > contrary?
> >
> > +1 on removing bytes-specific behavior from join.  Whatever the
> > behavior is it should be consistent.
> >
> > I prefer removing the str call on .join entirely.  Is there any other
> > string method that implicitly str's it's argument?  I can't think of
> > any.   If this works I would expect that concatenation also implicitly
> > converts (ala java).
> >
> >
> > --
> > Adam Hupp | http://hupp.org/adam/
> > _______________________________________________
> > Python-3000 mailing list
> > Python-3000 at python.org
> > http://mail.python.org/mailman/listinfo/python-3000
> > Unsubscribe:
> > http://mail.python.org/mailman/options/python-3000/shiblon%40gmail.com
> >
>


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

From phd at phd.pp.ru  Fri Nov  2 09:40:25 2007
From: phd at phd.pp.ru (Oleg Broytmann)
Date: Fri, 2 Nov 2007 11:40:25 +0300
Subject: [Python-3000] What to do about "".join([b""])?
In-Reply-To: <5d44f72f0711011937r2ab292cfj6ce33b6af9d67bfd@mail.gmail.com>
References: <ca471dc20711011921y3aca3149pe642f159baa7e027@mail.gmail.com>
	<5d44f72f0711011937r2ab292cfj6ce33b6af9d67bfd@mail.gmail.com>
Message-ID: <20071102084025.GB20234@phd.pp.ru>

On Thu, Nov 01, 2007 at 07:37:29PM -0700, Jeffrey Yasskin wrote:
> I'd na??vely vote for having "".join([non-strings]) raise a TypeError
> unconditionally like it did in 2.5.

   +1 for always TypeError.

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

From janssen at parc.com  Fri Nov  2 17:41:23 2007
From: janssen at parc.com (Bill Janssen)
Date: Fri, 2 Nov 2007 09:41:23 PDT
Subject: [Python-3000] What to do about "".join([b""])?
In-Reply-To: <da3f900e0711020544r5ea2fda7ice7b9046ac4060aa@mail.gmail.com> 
References: <ca471dc20711011921y3aca3149pe642f159baa7e027@mail.gmail.com>
	<766a29bd0711020518x3e8a1ff8wa8fb9a8201bd402a@mail.gmail.com>
	<da3f900e0711020544r5ea2fda7ice7b9046ac4060aa@mail.gmail.com>
Message-ID: <07Nov2.084127pst."57996"@synergy1.parc.xerox.com>

> +1 on removing implicit str calls from join altogether.

+1 from me, too.

Bill

From guido at python.org  Fri Nov  2 17:59:35 2007
From: guido at python.org (Guido van Rossum)
Date: Fri, 2 Nov 2007 09:59:35 -0700
Subject: [Python-3000] What to do about "".join([b""])?
In-Reply-To: <-2003892247779967429@unknownmsgid>
References: <ca471dc20711011921y3aca3149pe642f159baa7e027@mail.gmail.com>
	<766a29bd0711020518x3e8a1ff8wa8fb9a8201bd402a@mail.gmail.com>
	<da3f900e0711020544r5ea2fda7ice7b9046ac4060aa@mail.gmail.com>
	<-2003892247779967429@unknownmsgid>
Message-ID: <ca471dc20711020959w9c2bbefn2d24f7b583acf6c0@mail.gmail.com>

Too late. It's already gone. ;-)

On 11/2/07, Bill Janssen <janssen at parc.com> wrote:
> > +1 on removing implicit str calls from join altogether.
>
> +1 from me, too.
>
> Bill
>


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

From guido at python.org  Sat Nov  3 01:08:30 2007
From: guido at python.org (Guido van Rossum)
Date: Fri, 2 Nov 2007 17:08:30 -0700
Subject: [Python-3000] need help fixing broken tests in py3k-pep3137 branch
Message-ID: <ca471dc20711021708s7125932ka699abb759e262dd@mail.gmail.com>

In the py3k-pep3137 branch I've been working on the implementation of PEP 3137.
The work is largely done, but I'm stuck with about 20 failing tests,
and very little time this weekend to work on these. Here's the list:

test_array
test_asynchat
test_asyncore
test_bsddb3
test_ctypes
test_email
test_exceptions
test_gettext
test_httplib
test_import (*)
test_mailbox
test_old_mailbox
test_pickle
test_pickletools
test_sqlite
test_urllib
test_urllib2
test_urllibnet

(*) test_import also fails in the py3k branch; see
http://bugs.python.org/issue1377.

If you want to know more details about any particular failure, just
check out the branch and run it.

If you fix something, just check it in if you can (unless you're not
sure); if you don't have submit priviliges, open a bug and send an
email to python-3000 at python.org to tell others about it.

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

From greg at krypto.org  Sat Nov  3 08:34:10 2007
From: greg at krypto.org (Gregory P. Smith)
Date: Sat, 3 Nov 2007 00:34:10 -0700
Subject: [Python-3000] What to do about "".join([b""])?
In-Reply-To: <ca471dc20711020959w9c2bbefn2d24f7b583acf6c0@mail.gmail.com>
References: <ca471dc20711011921y3aca3149pe642f159baa7e027@mail.gmail.com>
	<766a29bd0711020518x3e8a1ff8wa8fb9a8201bd402a@mail.gmail.com>
	<da3f900e0711020544r5ea2fda7ice7b9046ac4060aa@mail.gmail.com>
	<-2003892247779967429@unknownmsgid>
	<ca471dc20711020959w9c2bbefn2d24f7b583acf6c0@mail.gmail.com>
Message-ID: <52dc1c820711030034v202c6ac8w85285f72b112f559@mail.gmail.com>

and there was much rejoicing!

On 11/2/07, Guido van Rossum <guido at python.org> wrote:
>
> Too late. It's already gone. ;-)
>
> On 11/2/07, Bill Janssen <janssen at parc.com> wrote:
> > > +1 on removing implicit str calls from join altogether.
> >
> > +1 from me, too.
> >
> > Bill
> >
>
>
> --
> --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/greg%40krypto.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20071103/f5ddffb5/attachment.htm 

From brett at python.org  Sat Nov  3 08:39:32 2007
From: brett at python.org (Brett Cannon)
Date: Sat, 3 Nov 2007 00:39:32 -0700
Subject: [Python-3000] need help fixing broken tests in py3k-pep3137
	branch
In-Reply-To: <ca471dc20711021708s7125932ka699abb759e262dd@mail.gmail.com>
References: <ca471dc20711021708s7125932ka699abb759e262dd@mail.gmail.com>
Message-ID: <bbaeab100711030039n194640b6rb8e45f9d94333951@mail.gmail.com>

On 11/2/07, Guido van Rossum <guido at python.org> wrote:
> In the py3k-pep3137 branch I've been working on the implementation of PEP 3137.
> The work is largely done, but I'm stuck with about 20 failing tests,
> and very little time this weekend to work on these. Here's the list:
>

I decided to look at a few of these tests before I went to bed.  Here
is what I found out:

> test_array

_fileio.c for read() calls is using PyBytes instead of PyString, so a
type check in array.array().fromfile() is failing.  I am assuming that
_fileio.c should be moved from PyBytes to PyString, right?

There is another failure but I didn't look at it.

[SNIP]
> test_exceptions

pickle is returning buffers for pickled bytes::

  >>> pickle.loads(pickle.dumps(b'bytes'))
  buffer(b'bytes')

Obviously that's not right.  =)

[SNIP]
> test_httplib

Fixed in revision 58823.  HTTPConnection.putheaders() was doing "%s:
%s" but not checking if its arguments were strings or bytes/buffers.
Changed so that if the function's arguments had an 'encode' method it
is called so that instead of string interpolation bytes concatenation
is used.

> test_import (*)

This is passing for me on OS X 10.4.

-Brett

From lists at cheimes.de  Sat Nov  3 12:29:24 2007
From: lists at cheimes.de (Christian Heimes)
Date: Sat, 03 Nov 2007 12:29:24 +0100
Subject: [Python-3000] need help fixing broken tests in py3k-pep3137
	branch
In-Reply-To: <bbaeab100711030039n194640b6rb8e45f9d94333951@mail.gmail.com>
References: <ca471dc20711021708s7125932ka699abb759e262dd@mail.gmail.com>
	<bbaeab100711030039n194640b6rb8e45f9d94333951@mail.gmail.com>
Message-ID: <fghm2l$40t$1@ger.gmane.org>

Brett Cannon wrote:
>> test_import (*)
> 
> This is passing for me on OS X 10.4.

It passes on my Ubuntu box, too. But on Guido's Ubuntu box it's failing.
It's also failing on Windows but that's expected. I added the test to
verify a bug that prevents Windows to load modules from a sys.path entry
with non ASCII letters.

Georg has told me that I shouldn't add tests that are known to break.
The test seems to be locale dependent, too.

Guido, what's the output of the locale command on your box?

Christian


From p.f.moore at gmail.com  Sat Nov  3 13:50:08 2007
From: p.f.moore at gmail.com (Paul Moore)
Date: Sat, 3 Nov 2007 12:50:08 +0000
Subject: [Python-3000] need help fixing broken tests in py3k-pep3137
	branch
In-Reply-To: <ca471dc20711021708s7125932ka699abb759e262dd@mail.gmail.com>
References: <ca471dc20711021708s7125932ka699abb759e262dd@mail.gmail.com>
Message-ID: <79990c6b0711030550w4cecea52xd9f9bb6c9e809bff@mail.gmail.com>

On 03/11/2007, Guido van Rossum <guido at python.org> wrote:
> In the py3k-pep3137 branch I've been working on the implementation of PEP 3137.
> The work is largely done, but I'm stuck with about 20 failing tests,
> and very little time this weekend to work on these. Here's the list:
>
> test_array

One of the failures here is in

    def test_create_from_bytes(self):
        a = array.array('H', b"1234")
        self.assertEqual(len(a) * a.itemsize, 4)

Traceback (most recent call last):
  File "Lib/test/test_array.py", line 737, in test_create_from_bytes
    self.assertEqual(len(a) * a.itemsize, 4)
AssertionError: 8 != 4

However, 'H' is unsigned short, so I'd expect a.itemsize to be 2, and
so the results *should* be 8 rather than 4.

Is this just a bug in the test?

Paul.

From lists at cheimes.de  Sat Nov  3 14:18:32 2007
From: lists at cheimes.de (Christian Heimes)
Date: Sat, 03 Nov 2007 14:18:32 +0100
Subject: [Python-3000] need help fixing broken tests in py3k-pep3137
	branch
In-Reply-To: <79990c6b0711030550w4cecea52xd9f9bb6c9e809bff@mail.gmail.com>
References: <ca471dc20711021708s7125932ka699abb759e262dd@mail.gmail.com>
	<79990c6b0711030550w4cecea52xd9f9bb6c9e809bff@mail.gmail.com>
Message-ID: <fghsf9$jqm$1@ger.gmane.org>

Paul Moore wrote:
> One of the failures here is in
> 
>     def test_create_from_bytes(self):
>         a = array.array('H', b"1234")
>         self.assertEqual(len(a) * a.itemsize, 4)
> 
> Traceback (most recent call last):
>   File "Lib/test/test_array.py", line 737, in test_create_from_bytes
>     self.assertEqual(len(a) * a.itemsize, 4)
> AssertionError: 8 != 4
> 
> However, 'H' is unsigned short, so I'd expect a.itemsize to be 2, and
> so the results *should* be 8 rather than 4.
> 
> Is this just a bug in the test?

No, it was a bug in the C code. 'H' represents a 16bit type. The correct
result is

>>> array.array('H', b"1234")
array('H', [12849, 13363])

However the code was reading the byte sequence int by int and created an
array with 4 elements instead of 2 elements. I've already fixed it.

Christian


From p.f.moore at gmail.com  Sat Nov  3 14:25:49 2007
From: p.f.moore at gmail.com (Paul Moore)
Date: Sat, 3 Nov 2007 13:25:49 +0000
Subject: [Python-3000] need help fixing broken tests in py3k-pep3137
	branch
In-Reply-To: <fghsf9$jqm$1@ger.gmane.org>
References: <ca471dc20711021708s7125932ka699abb759e262dd@mail.gmail.com>
	<79990c6b0711030550w4cecea52xd9f9bb6c9e809bff@mail.gmail.com>
	<fghsf9$jqm$1@ger.gmane.org>
Message-ID: <79990c6b0711030625s24bbae27q1c7dbddc5d73056@mail.gmail.com>

On 03/11/2007, Christian Heimes <lists at cheimes.de> wrote:
> No, it was a bug in the C code. 'H' represents a 16bit type. The correct
> result is

Ah, I misunderstood what the documentation was getting at. Thanks.
Paul.

From p.f.moore at gmail.com  Sat Nov  3 14:37:53 2007
From: p.f.moore at gmail.com (Paul Moore)
Date: Sat, 3 Nov 2007 13:37:53 +0000
Subject: [Python-3000] need help fixing broken tests in py3k-pep3137
	branch
In-Reply-To: <79990c6b0711030625s24bbae27q1c7dbddc5d73056@mail.gmail.com>
References: <ca471dc20711021708s7125932ka699abb759e262dd@mail.gmail.com>
	<79990c6b0711030550w4cecea52xd9f9bb6c9e809bff@mail.gmail.com>
	<fghsf9$jqm$1@ger.gmane.org>
	<79990c6b0711030625s24bbae27q1c7dbddc5d73056@mail.gmail.com>
Message-ID: <79990c6b0711030637w3ff762ddtae1613d6673efa20@mail.gmail.com>

On 03/11/2007, Paul Moore <p.f.moore at gmail.com> wrote:
> On 03/11/2007, Christian Heimes <lists at cheimes.de> wrote:
> > No, it was a bug in the C code. 'H' represents a 16bit type. The correct
> > result is
>
> Ah, I misunderstood what the documentation was getting at. Thanks.
> Paul.

Hmm, I'm not sure if I did.

function:: array(typecode[, initializer])

   Return a new array whose items are restricted by *typecode*, and initialized
   from the optional *initializer* value, which must be a list,
string, or iterable
   over elements of the appropriate type.

My instinct says that a bytes object is "an iterable over elements of
the appropriate type" for 'H', in the sense that iterating over bytes
returns a sequence of integers.

>>> [n for n in b"1234"]
[49, 50, 51, 52]

On that basis, array.array('H', b"1234") should construct an array out
of the 4 integers 49, 50, 51 and 52.

You seem to be saying that array.array treats the bytes object as a
block of memory, and splits it up according to the typecode. Isn't
that the job of the struct module?

I think this needs clarifying - if your interpretation is correct, the
documentation needs an overhaul (and in the short term, the behaviour
needs explicitly stating in the PEP).

Paul.

From lists at cheimes.de  Sat Nov  3 14:49:13 2007
From: lists at cheimes.de (Christian Heimes)
Date: Sat, 03 Nov 2007 14:49:13 +0100
Subject: [Python-3000] need help fixing broken tests in py3k-pep3137
	branch
In-Reply-To: <79990c6b0711030637w3ff762ddtae1613d6673efa20@mail.gmail.com>
References: <ca471dc20711021708s7125932ka699abb759e262dd@mail.gmail.com>	
	<79990c6b0711030550w4cecea52xd9f9bb6c9e809bff@mail.gmail.com>	
	<fghsf9$jqm$1@ger.gmane.org>	
	<79990c6b0711030625s24bbae27q1c7dbddc5d73056@mail.gmail.com>
	<79990c6b0711030637w3ff762ddtae1613d6673efa20@mail.gmail.com>
Message-ID: <472C7C59.4000602@cheimes.de>

Paul Moore wrote:
>    Return a new array whose items are restricted by *typecode*, and initialized
>    from the optional *initializer* value, which must be a list,
> string, or iterable
>    over elements of the appropriate type.
> 
> My instinct says that a bytes object is "an iterable over elements of
> the appropriate type" for 'H', in the sense that iterating over bytes
> returns a sequence of integers.

You are partly right. The documentation needs an update. It should say
"which mist be a list, string, byte sequence or iterable ...".

> On that basis, array.array('H', b"1234") should construct an array out
> of the 4 integers 49, 50, 51 and 52.
> 
> You seem to be saying that array.array treats the bytes object as a
> block of memory, and splits it up according to the typecode. Isn't
> that the job of the struct module?

In Python 2.x the array module handles strings in the same way:

Python 2.5.1 (r251:54863, Oct  5 2007, 13:36:32)
[GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import array
>>> array.array('H', "1234")
array('H', [12849, 13363])

Bytes are the successor of Python 2.x's byte strings (str). They are
even using the same C type PyString. My patch has only restored the old
behavior of PyString.

Christian

From ncoghlan at gmail.com  Sat Nov  3 14:50:42 2007
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 03 Nov 2007 23:50:42 +1000
Subject: [Python-3000] need help fixing broken tests in
	py3k-pep3137	branch
In-Reply-To: <79990c6b0711030637w3ff762ddtae1613d6673efa20@mail.gmail.com>
References: <ca471dc20711021708s7125932ka699abb759e262dd@mail.gmail.com>	<79990c6b0711030550w4cecea52xd9f9bb6c9e809bff@mail.gmail.com>	<fghsf9$jqm$1@ger.gmane.org>	<79990c6b0711030625s24bbae27q1c7dbddc5d73056@mail.gmail.com>
	<79990c6b0711030637w3ff762ddtae1613d6673efa20@mail.gmail.com>
Message-ID: <472C7CB2.1020201@gmail.com>

Paul Moore wrote:
> I think this needs clarifying - if your interpretation is correct, the
> documentation needs an overhaul (and in the short term, the behaviour
> needs explicitly stating in the PEP).

I haven't checked the code to make sure, but I suspect that where the 
documentation says "string" it actually means anything implementing the 
buffer API at the C level, which will then be interpreted as a block of 
memory. That job is being taken over by bytes/buffer objects in 3.0.

Cheers,
Nick.

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

From lists at cheimes.de  Sat Nov  3 14:56:44 2007
From: lists at cheimes.de (Christian Heimes)
Date: Sat, 03 Nov 2007 14:56:44 +0100
Subject: [Python-3000] need help fixing broken tests in py3k-pep3137
	branch
In-Reply-To: <472C7C59.4000602@cheimes.de>
References: <ca471dc20711021708s7125932ka699abb759e262dd@mail.gmail.com>		<79990c6b0711030550w4cecea52xd9f9bb6c9e809bff@mail.gmail.com>		<fghsf9$jqm$1@ger.gmane.org>		<79990c6b0711030625s24bbae27q1c7dbddc5d73056@mail.gmail.com>	<79990c6b0711030637w3ff762ddtae1613d6673efa20@mail.gmail.com>
	<472C7C59.4000602@cheimes.de>
Message-ID: <472C7E1C.2020903@cheimes.de>

Christian Heimes wrote:
> You are partly right. The documentation needs an update. It should say
> "which mist be a list, string, byte sequence or iterable ...".

Apropos documentation the method fromstring and fromunicode should be
renamed: fromstring -> frombytes and fromunicode -> fromstring. It may
also be a good idea to keep fromunicode() and rename only fromstring.

Christian

From p.f.moore at gmail.com  Sat Nov  3 15:23:02 2007
From: p.f.moore at gmail.com (Paul Moore)
Date: Sat, 3 Nov 2007 14:23:02 +0000
Subject: [Python-3000] need help fixing broken tests in py3k-pep3137
	branch
In-Reply-To: <472C7C59.4000602@cheimes.de>
References: <ca471dc20711021708s7125932ka699abb759e262dd@mail.gmail.com>
	<79990c6b0711030550w4cecea52xd9f9bb6c9e809bff@mail.gmail.com>
	<fghsf9$jqm$1@ger.gmane.org>
	<79990c6b0711030625s24bbae27q1c7dbddc5d73056@mail.gmail.com>
	<79990c6b0711030637w3ff762ddtae1613d6673efa20@mail.gmail.com>
	<472C7C59.4000602@cheimes.de>
Message-ID: <79990c6b0711030723v6f611f93w2fdf2bc732912e45@mail.gmail.com>

On 03/11/2007, Christian Heimes <lists at cheimes.de> wrote:
> You are partly right. The documentation needs an update. It should say
> "which mist be a list, string, byte sequence or iterable ...".

Actually, "string" is a holdover from the Python 2.x behaviour you
point out below. In 3.x, strings are not special:

>>> array.array('H',"1234")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: an integer is required

Also, based on Nick Coghlan's comment, this should be an object
implementing the buffer protocol rather than a byte sequence. This
isn't the case in Python 2.x, but seems to be in Python 3.0.

So, the wording should probably be: "which must be a list, object
supporting the buffer interface or iterable ...".

> In Python 2.x the array module handles strings in the same way:
>
> Python 2.5.1 (r251:54863, Oct  5 2007, 13:36:32)
> [GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import array
> >>> array.array('H', "1234")
> array('H', [12849, 13363])
>
> Bytes are the successor of Python 2.x's byte strings (str). They are
> even using the same C type PyString. My patch has only restored the old
> behavior of PyString.

OK, thanks for the clarification (again!).

Paul

From guido at python.org  Sat Nov  3 16:25:48 2007
From: guido at python.org (Guido van Rossum)
Date: Sat, 3 Nov 2007 08:25:48 -0700
Subject: [Python-3000] need help fixing broken tests in py3k-pep3137
	branch
In-Reply-To: <79990c6b0711030723v6f611f93w2fdf2bc732912e45@mail.gmail.com>
References: <ca471dc20711021708s7125932ka699abb759e262dd@mail.gmail.com>
	<79990c6b0711030550w4cecea52xd9f9bb6c9e809bff@mail.gmail.com>
	<fghsf9$jqm$1@ger.gmane.org>
	<79990c6b0711030625s24bbae27q1c7dbddc5d73056@mail.gmail.com>
	<79990c6b0711030637w3ff762ddtae1613d6673efa20@mail.gmail.com>
	<472C7C59.4000602@cheimes.de>
	<79990c6b0711030723v6f611f93w2fdf2bc732912e45@mail.gmail.com>
Message-ID: <ca471dc20711030825x56be102bv7f50cc2a6ca74d30@mail.gmail.com>

To clarify: while a bytes object *could* be interpreted as either a
sequence of ints or a memory array, the *intent* is that the memory
array interpretation prevails. An Christian correctly fixed it to do
so. The external docs and docstrings of many, many modules are
currently incorrectly referring to strings; I hope I can get some more
volunteers to help clean up all that. Also, almost everywhere that
checks for bytes should be recoded to accept any buffer-API-supporting
object. The docs should reflect that. We could use a better term than
buffer-API-supporting object though!

--Guido

On 11/3/07, Paul Moore <p.f.moore at gmail.com> wrote:
> On 03/11/2007, Christian Heimes <lists at cheimes.de> wrote:
> > You are partly right. The documentation needs an update. It should say
> > "which mist be a list, string, byte sequence or iterable ...".
>
> Actually, "string" is a holdover from the Python 2.x behaviour you
> point out below. In 3.x, strings are not special:
>
> >>> array.array('H',"1234")
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> TypeError: an integer is required
>
> Also, based on Nick Coghlan's comment, this should be an object
> implementing the buffer protocol rather than a byte sequence. This
> isn't the case in Python 2.x, but seems to be in Python 3.0.
>
> So, the wording should probably be: "which must be a list, object
> supporting the buffer interface or iterable ...".
>
> > In Python 2.x the array module handles strings in the same way:
> >
> > Python 2.5.1 (r251:54863, Oct  5 2007, 13:36:32)
> > [GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2
> > Type "help", "copyright", "credits" or "license" for more information.
> > >>> import array
> > >>> array.array('H', "1234")
> > array('H', [12849, 13363])
> >
> > Bytes are the successor of Python 2.x's byte strings (str). They are
> > even using the same C type PyString. My patch has only restored the old
> > behavior of PyString.
>
> OK, thanks for the clarification (again!).
>
> Paul
> _______________________________________________
> 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 alexandre at peadrop.com  Sat Nov  3 17:07:57 2007
From: alexandre at peadrop.com (Alexandre Vassalotti)
Date: Sat, 3 Nov 2007 12:07:57 -0400
Subject: [Python-3000] pickle compatibility between 2.x and 3.0
In-Reply-To: <ca471dc20711010718u5d437d60i9fd549e9c7271993@mail.gmail.com>
References: <ca471dc20711010718u5d437d60i9fd549e9c7271993@mail.gmail.com>
Message-ID: <acd65fa20711030907i799218f6wa0d5020ee7a15146@mail.gmail.com>

On 11/1/07, Guido van Rossum <guido at python.org> wrote:
> When 3.0 encounters a 'str' object in a pickle written by 2.x, it has
> two choices: trying to convert it to a 3.0 (unicode) str object by
> applying some encoding, or interpreting it as a 3.0 bytes object.

Currently, pickle decodes old string objects using latin-1. To me,
these seems to be a reasonable default (IMHO,
sys.getfilesystemencoding() would be slightly better). However, having
a default encoding might hide decoding errors. So, it may be a better
idea to simply return bytes by default and leave it to the application
to specify the encoding in the unpickling call.

-- Alexandre

From alexandre at peadrop.com  Sat Nov  3 17:12:59 2007
From: alexandre at peadrop.com (Alexandre Vassalotti)
Date: Sat, 3 Nov 2007 12:12:59 -0400
Subject: [Python-3000] pickle compatibility between 2.x and 3.0
In-Reply-To: <52dc1c820711012137k5c0ab46cq840021361c5406a4@mail.gmail.com>
References: <ca471dc20711010718u5d437d60i9fd549e9c7271993@mail.gmail.com>
	<e04bdf310711010950k3c6e8b9cp7fbafe2c2c6e53e9@mail.gmail.com>
	<52dc1c820711012137k5c0ab46cq840021361c5406a4@mail.gmail.com>
Message-ID: <acd65fa20711030912r2f9718e6y606ea19e88edc542@mail.gmail.com>

On 11/2/07, Gregory P. Smith <greg at krypto.org> wrote:
> Brainstorming here... how about an optional callable argument when
> unpickling to let the developers write their own "magic guess" function?

I think the use cases for this are fairly rare. And, this can easily
be done by subclassing Pickler and Unpickler, without increasing the
overall complexity of the pickle module.

-- Alexandre

From lists at cheimes.de  Sat Nov  3 17:25:51 2007
From: lists at cheimes.de (Christian Heimes)
Date: Sat, 03 Nov 2007 17:25:51 +0100
Subject: [Python-3000] need help fixing broken tests in py3k-pep3137
	branch
In-Reply-To: <ca471dc20711021708s7125932ka699abb759e262dd@mail.gmail.com>
References: <ca471dc20711021708s7125932ka699abb759e262dd@mail.gmail.com>
Message-ID: <472CA10F.9070102@cheimes.de>

Guido van Rossum wrote:
> In the py3k-pep3137 branch I've been working on the implementation of PEP 3137.
> The work is largely done, but I'm stuck with about 20 failing tests,
> and very little time this weekend to work on these. Here's the list:

Houston, we have a problem! The py3k PEP 3137 branch is seriously broken
under Windows.

C:\dev\python\py3k-pep3137\PCbuild>python
Fatal Python error: Py_Initialize: can't initialize sys standard streams
Traceback (most recent call last):
  File "C:\dev\python\py3k-pep3137\lib\encodings\__init__.py", line 32,
in <module>
    from . import aliases
ImportError: cannot import name aliases

This application has requested the Runtime to terminate it in an unusual
way. Please contact the application's support team for more information.

The py3k branch still works so it wasn't caused by the merge from the trunk.

Christian

From lists at cheimes.de  Sat Nov  3 17:25:51 2007
From: lists at cheimes.de (Christian Heimes)
Date: Sat, 03 Nov 2007 17:25:51 +0100
Subject: [Python-3000] need help fixing broken tests in py3k-pep3137
	branch
In-Reply-To: <ca471dc20711021708s7125932ka699abb759e262dd@mail.gmail.com>
References: <ca471dc20711021708s7125932ka699abb759e262dd@mail.gmail.com>
Message-ID: <472CA10F.9070102@cheimes.de>

Guido van Rossum wrote:
> In the py3k-pep3137 branch I've been working on the implementation of PEP 3137.
> The work is largely done, but I'm stuck with about 20 failing tests,
> and very little time this weekend to work on these. Here's the list:

Houston, we have a problem! The py3k PEP 3137 branch is seriously broken
under Windows.

C:\dev\python\py3k-pep3137\PCbuild>python
Fatal Python error: Py_Initialize: can't initialize sys standard streams
Traceback (most recent call last):
  File "C:\dev\python\py3k-pep3137\lib\encodings\__init__.py", line 32,
in <module>
    from . import aliases
ImportError: cannot import name aliases

This application has requested the Runtime to terminate it in an unusual
way. Please contact the application's support team for more information.

The py3k branch still works so it wasn't caused by the merge from the trunk.

Christian


From alexandre at peadrop.com  Sat Nov  3 17:39:15 2007
From: alexandre at peadrop.com (Alexandre Vassalotti)
Date: Sat, 3 Nov 2007 12:39:15 -0400
Subject: [Python-3000] pickle compatibility between 2.x and 3.0
In-Reply-To: <fgep2a$anq$1@ger.gmane.org>
References: <ca471dc20711010718u5d437d60i9fd549e9c7271993@mail.gmail.com>
	<e04bdf310711010950k3c6e8b9cp7fbafe2c2c6e53e9@mail.gmail.com>
	<52dc1c820711012137k5c0ab46cq840021361c5406a4@mail.gmail.com>
	<fgep2a$anq$1@ger.gmane.org>
Message-ID: <acd65fa20711030939w54655795p806d3b8badaf268a@mail.gmail.com>

On 11/2/07, Christian Heimes <lists at cheimes.de> wrote:
> The general idea is good however a single magic method won't do any
> good. The system must be able to handle cases where an object may
> contain text strings and byte strings. Developers must be able to handle
> the conversation on a per class base.

Container objects are recursively pickled. IOW, pickle doesn't know if
a string is part of a user-defined class or some other container
object (e.g., a dict, or a tuple). Pickling objects on a per class
basis would require the pickle module to keep some sort of state
mechanism to know when a class begin and end. IMHO, the complexity
added wouldn't really worth it.

-- Alexandre

From lists at cheimes.de  Sat Nov  3 18:36:16 2007
From: lists at cheimes.de (Christian Heimes)
Date: Sat, 03 Nov 2007 18:36:16 +0100
Subject: [Python-3000] need help fixing broken tests in py3k-pep3137
	branch
In-Reply-To: <472CA10F.9070102@cheimes.de>
References: <ca471dc20711021708s7125932ka699abb759e262dd@mail.gmail.com>
	<472CA10F.9070102@cheimes.de>
Message-ID: <fgibig$s8n$1@ger.gmane.org>

Christian Heimes wrote:
> Houston, we have a problem! The py3k PEP 3137 branch is seriously broken
> under Windows.

Fixed!

The PyUnicode_*MBCS* methods returned PyBytes instead of PyString. The
import machinery used PyString_AS_STRING() on it in once place and
triggered a nasty problem.

Christian


From adam at hupp.org  Sat Nov  3 18:57:39 2007
From: adam at hupp.org (Adam Hupp)
Date: Sat, 3 Nov 2007 13:57:39 -0400
Subject: [Python-3000] need help fixing broken tests in py3k-pep3137
	branch
In-Reply-To: <bbaeab100711030039n194640b6rb8e45f9d94333951@mail.gmail.com>
References: <ca471dc20711021708s7125932ka699abb759e262dd@mail.gmail.com>
	<bbaeab100711030039n194640b6rb8e45f9d94333951@mail.gmail.com>
Message-ID: <766a29bd0711031057p72767b99n798dae06ff3d306c@mail.gmail.com>

On 11/3/07, Brett Cannon <brett at python.org> wrote:
>
> > test_array
>
> _fileio.c for read() calls is using PyBytes instead of PyString, so a
> type check in array.array().fromfile() is failing.  I am assuming that
> _fileio.c should be moved from PyBytes to PyString, right?

Should array.fromfile accept any kind of byte buffer out of .read() or
is it important to only accept PyString?  Changing .fromfile to use
_CheckBuffer instead of Bytes_Check also works.

Also in array,  I'm not sure if array('u',...) .tofile and .fromfile
works correctly.    Currently tofile writes out the raw unicode bytes
without any encoding, and fromfile reads in without any decoding.   It
seems like that could cause problems between e.g. 4 byte and 2 byte
unicode builds, not to mention endianess issues.

-- 
Adam Hupp | http://hupp.org/adam/

From adam at hupp.org  Sat Nov  3 19:17:58 2007
From: adam at hupp.org (Adam Hupp)
Date: Sat, 3 Nov 2007 14:17:58 -0400
Subject: [Python-3000] need help fixing broken tests in py3k-pep3137
	branch
In-Reply-To: <ca471dc20711021708s7125932ka699abb759e262dd@mail.gmail.com>
References: <ca471dc20711021708s7125932ka699abb759e262dd@mail.gmail.com>
Message-ID: <766a29bd0711031117pde4020fq1b9f64fb11e5eef8@mail.gmail.com>

On 11/2/07, Guido van Rossum <guido at python.org> wrote:
>
> test_asynchat
> test_asyncore

A patch for these is in http://bugs.python.org/issue1380

One of the errors was an explicit isinstance test for bytes when the
actual type was buffer.  Is there a way to test for 'bytes-like'?   Is
the presence of a 'decode' method sufficient?

-- 
Adam Hupp | http://hupp.org/adam/

From lists at cheimes.de  Sat Nov  3 19:46:43 2007
From: lists at cheimes.de (Christian Heimes)
Date: Sat, 03 Nov 2007 19:46:43 +0100
Subject: [Python-3000] need help fixing broken tests in py3k-pep3137
	branch
In-Reply-To: <766a29bd0711031117pde4020fq1b9f64fb11e5eef8@mail.gmail.com>
References: <ca471dc20711021708s7125932ka699abb759e262dd@mail.gmail.com>
	<766a29bd0711031117pde4020fq1b9f64fb11e5eef8@mail.gmail.com>
Message-ID: <472CC213.2010006@cheimes.de>

Adam Hupp wrote:
> A patch for these is in http://bugs.python.org/issue1380
> 
> One of the errors was an explicit isinstance test for bytes when the
> actual type was buffer.  Is there a way to test for 'bytes-like'?   Is
> the presence of a 'decode' method sufficient?

I've applied your patch. Thank you very much!

No, Python has no means to check for the buffer interface yet. You could
do isinstance(ob, (bytes, buffer)) but it wouldn't catch every object.
We could create a PyObject_CheckWriteBuffer() API function and expose
PyObject_CheckReadBuffer() and PyObject_CheckWriteBuffer() expose them.
Or we could abuse isinstance(ob, memoryview). Or an ABC?

Christian


From g.brandl at gmx.net  Sat Nov  3 21:07:28 2007
From: g.brandl at gmx.net (Georg Brandl)
Date: Sat, 03 Nov 2007 21:07:28 +0100
Subject: [Python-3000] pickle compatibility between 2.x and 3.0
In-Reply-To: <acd65fa20711030907i799218f6wa0d5020ee7a15146@mail.gmail.com>
References: <ca471dc20711010718u5d437d60i9fd549e9c7271993@mail.gmail.com>
	<acd65fa20711030907i799218f6wa0d5020ee7a15146@mail.gmail.com>
Message-ID: <fgike1$n5c$2@ger.gmane.org>

Alexandre Vassalotti schrieb:
> On 11/1/07, Guido van Rossum <guido at python.org> wrote:
>> When 3.0 encounters a 'str' object in a pickle written by 2.x, it has
>> two choices: trying to convert it to a 3.0 (unicode) str object by
>> applying some encoding, or interpreting it as a 3.0 bytes object.
> 
> Currently, pickle decodes old string objects using latin-1. To me,
> these seems to be a reasonable default (IMHO,
> sys.getfilesystemencoding() would be slightly better). However, having
> a default encoding might hide decoding errors. So, it may be a better
> idea to simply return bytes by default and leave it to the application
> to specify the encoding in the unpickling call.

+1 for that. If no encoding is given, return bytes; if encoding (and
possibly an errors argument) is given, return Unicode.

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 brett at python.org  Sat Nov  3 21:26:16 2007
From: brett at python.org (Brett Cannon)
Date: Sat, 3 Nov 2007 13:26:16 -0700
Subject: [Python-3000] need help fixing broken tests in py3k-pep3137
	branch
In-Reply-To: <472CC213.2010006@cheimes.de>
References: <ca471dc20711021708s7125932ka699abb759e262dd@mail.gmail.com>
	<766a29bd0711031117pde4020fq1b9f64fb11e5eef8@mail.gmail.com>
	<472CC213.2010006@cheimes.de>
Message-ID: <bbaeab100711031326o2e844178u323cdcdf81779c97@mail.gmail.com>

On 11/3/07, Christian Heimes <lists at cheimes.de> wrote:
> Adam Hupp wrote:
> > A patch for these is in http://bugs.python.org/issue1380
> >
> > One of the errors was an explicit isinstance test for bytes when the
> > actual type was buffer.  Is there a way to test for 'bytes-like'?   Is
> > the presence of a 'decode' method sufficient?
>
> I've applied your patch. Thank you very much!
>
> No, Python has no means to check for the buffer interface yet. You could
> do isinstance(ob, (bytes, buffer)) but it wouldn't catch every object.
> We could create a PyObject_CheckWriteBuffer() API function and expose
> PyObject_CheckReadBuffer() and PyObject_CheckWriteBuffer() expose them.
> Or we could abuse isinstance(ob, memoryview). Or an ABC?

An ABC would be best.  I know there was a discussion about what the
best name would be for such an ABC but I don't remember the conclusion
reached.

-Brett

From greg.ewing at canterbury.ac.nz  Sat Nov  3 21:50:03 2007
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sun, 04 Nov 2007 09:50:03 +1300
Subject: [Python-3000] What to do about "".join([b""])?
In-Reply-To: <420EE378-F66E-453F-A6AC-A3CBFF31EA4F@python.org>
References: <ca471dc20711011921y3aca3149pe642f159baa7e027@mail.gmail.com>
	<766a29bd0711020518x3e8a1ff8wa8fb9a8201bd402a@mail.gmail.com>
	<420EE378-F66E-453F-A6AC-A3CBFF31EA4F@python.org>
Message-ID: <472CDEFB.3040806@canterbury.ac.nz>

Barry Warsaw wrote:
>  From a purity standpoint, I agree with removing the implicit  
> str'ing.  I'm just sure what is more practical.

If it's really considered worth providing this extra
convenience, how about a different method for it:

   "".joinstr(...)

Just as convenient, and explicit rather than implicit,
so it won't cause any surprises.

--
Greg

From greg.ewing at canterbury.ac.nz  Sat Nov  3 22:37:38 2007
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sun, 04 Nov 2007 10:37:38 +1300
Subject: [Python-3000] need help fixing broken tests in
	py3k-pep3137	branch
In-Reply-To: <ca471dc20711030825x56be102bv7f50cc2a6ca74d30@mail.gmail.com>
References: <ca471dc20711021708s7125932ka699abb759e262dd@mail.gmail.com>
	<79990c6b0711030550w4cecea52xd9f9bb6c9e809bff@mail.gmail.com>
	<fghsf9$jqm$1@ger.gmane.org>
	<79990c6b0711030625s24bbae27q1c7dbddc5d73056@mail.gmail.com>
	<79990c6b0711030637w3ff762ddtae1613d6673efa20@mail.gmail.com>
	<472C7C59.4000602@cheimes.de>
	<79990c6b0711030723v6f611f93w2fdf2bc732912e45@mail.gmail.com>
	<ca471dc20711030825x56be102bv7f50cc2a6ca74d30@mail.gmail.com>
Message-ID: <472CEA22.508@canterbury.ac.nz>

Guido van Rossum wrote:
> We could use a better term than
> buffer-API-supporting object though!

Especially if you're also going to be using the term
'buffer' for a particular Python type. That seems like
a recipe for confusion to me.

--
Greg

From guido at python.org  Sat Nov  3 23:19:32 2007
From: guido at python.org (Guido van Rossum)
Date: Sat, 3 Nov 2007 15:19:32 -0700
Subject: [Python-3000] pickle compatibility between 2.x and 3.0
In-Reply-To: <fgike1$n5c$2@ger.gmane.org>
References: <ca471dc20711010718u5d437d60i9fd549e9c7271993@mail.gmail.com>
	<acd65fa20711030907i799218f6wa0d5020ee7a15146@mail.gmail.com>
	<fgike1$n5c$2@ger.gmane.org>
Message-ID: <ca471dc20711031519n23fc4255hdc244c19a049965d@mail.gmail.com>

On 11/3/07, Georg Brandl <g.brandl at gmx.net> wrote:
> Alexandre Vassalotti schrieb:
> > On 11/1/07, Guido van Rossum <guido at python.org> wrote:
> >> When 3.0 encounters a 'str' object in a pickle written by 2.x, it has
> >> two choices: trying to convert it to a 3.0 (unicode) str object by
> >> applying some encoding, or interpreting it as a 3.0 bytes object.
> >
> > Currently, pickle decodes old string objects using latin-1. To me,
> > these seems to be a reasonable default (IMHO,
> > sys.getfilesystemencoding() would be slightly better). However, having
> > a default encoding might hide decoding errors. So, it may be a better
> > idea to simply return bytes by default and leave it to the application
> > to specify the encoding in the unpickling call.
>
> +1 for that. If no encoding is given, return bytes; if encoding (and
> possibly an errors argument) is given, return Unicode.

Right, this is exactly what I was originally suggesting. I still like
it better than any of the more elaborate proposals. As someone said,
you can do anything by subclassing Unpickler.

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

From brett at python.org  Sat Nov  3 23:26:06 2007
From: brett at python.org (Brett Cannon)
Date: Sat, 3 Nov 2007 15:26:06 -0700
Subject: [Python-3000] What to do about "".join([b""])?
In-Reply-To: <472CDEFB.3040806@canterbury.ac.nz>
References: <ca471dc20711011921y3aca3149pe642f159baa7e027@mail.gmail.com>
	<766a29bd0711020518x3e8a1ff8wa8fb9a8201bd402a@mail.gmail.com>
	<420EE378-F66E-453F-A6AC-A3CBFF31EA4F@python.org>
	<472CDEFB.3040806@canterbury.ac.nz>
Message-ID: <bbaeab100711031526m3b46bb51k917191d636d660cb@mail.gmail.com>

On 11/3/07, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Barry Warsaw wrote:
> >  From a purity standpoint, I agree with removing the implicit
> > str'ing.  I'm just sure what is more practical.
>
> If it's really considered worth providing this extra
> convenience, how about a different method for it:
>
>    "".joinstr(...)
>
> Just as convenient, and explicit rather than implicit,
> so it won't cause any surprises.

Convenience of that over either of these::

  ''.join(map(str, args))
  ''.join(str(x) for x in args)

is just not worth tacking on another method to str in my opinion.

-Brett

From guido at python.org  Sat Nov  3 23:48:54 2007
From: guido at python.org (Guido van Rossum)
Date: Sat, 3 Nov 2007 15:48:54 -0700
Subject: [Python-3000] need help fixing broken tests in py3k-pep3137
	branch
In-Reply-To: <472CEA22.508@canterbury.ac.nz>
References: <ca471dc20711021708s7125932ka699abb759e262dd@mail.gmail.com>
	<79990c6b0711030550w4cecea52xd9f9bb6c9e809bff@mail.gmail.com>
	<fghsf9$jqm$1@ger.gmane.org>
	<79990c6b0711030625s24bbae27q1c7dbddc5d73056@mail.gmail.com>
	<79990c6b0711030637w3ff762ddtae1613d6673efa20@mail.gmail.com>
	<472C7C59.4000602@cheimes.de>
	<79990c6b0711030723v6f611f93w2fdf2bc732912e45@mail.gmail.com>
	<ca471dc20711030825x56be102bv7f50cc2a6ca74d30@mail.gmail.com>
	<472CEA22.508@canterbury.ac.nz>
Message-ID: <ca471dc20711031548q3afdaeag2353115d79e797ce@mail.gmail.com>

On 11/3/07, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Guido van Rossum wrote:
> > We could use a better term than
> > buffer-API-supporting object though!
>
> Especially if you're also going to be using the term
> 'buffer' for a particular Python type. That seems like
> a recipe for confusion to me.

I'd love a better term. It seems we could use several new names:

1. a new name for what PEP 3137 calls buffer
2. a new name for the union of bytes and buffer (*)
3. a new name for all types  supporting the "buffer API"

(*) We really do need to distinguish between #2 and #3, since buffer
and bytes have many methods in common that the other members of
category #3 don't have.

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

From guido at python.org  Sat Nov  3 23:52:09 2007
From: guido at python.org (Guido van Rossum)
Date: Sat, 3 Nov 2007 15:52:09 -0700
Subject: [Python-3000] need help fixing broken tests in py3k-pep3137
	branch
In-Reply-To: <766a29bd0711031057p72767b99n798dae06ff3d306c@mail.gmail.com>
References: <ca471dc20711021708s7125932ka699abb759e262dd@mail.gmail.com>
	<bbaeab100711030039n194640b6rb8e45f9d94333951@mail.gmail.com>
	<766a29bd0711031057p72767b99n798dae06ff3d306c@mail.gmail.com>
Message-ID: <ca471dc20711031552qf8565eeub6cd402089ebe604@mail.gmail.com>

On 11/3/07, Adam Hupp <adam at hupp.org> wrote:
> Also in array,  I'm not sure if array('u',...) .tofile and .fromfile
> works correctly.    Currently tofile writes out the raw unicode bytes
> without any encoding, and fromfile reads in without any decoding.   It
> seems like that could cause problems between e.g. 4 byte and 2 byte
> unicode builds, not to mention endianess issues.

This behavior is correct -- it is how it always worked in 2.x. The
array module writes machine specific data in general (try floats or
doubles or ints). For machine-independent binary data, the struct
module can help.

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

From guido at python.org  Sat Nov  3 23:56:33 2007
From: guido at python.org (Guido van Rossum)
Date: Sat, 3 Nov 2007 15:56:33 -0700
Subject: [Python-3000] need help fixing broken tests in py3k-pep3137
	branch
In-Reply-To: <fghm2l$40t$1@ger.gmane.org>
References: <ca471dc20711021708s7125932ka699abb759e262dd@mail.gmail.com>
	<bbaeab100711030039n194640b6rb8e45f9d94333951@mail.gmail.com>
	<fghm2l$40t$1@ger.gmane.org>
Message-ID: <ca471dc20711031556y2dfb55a4pfb3645f646bb196@mail.gmail.com>

On 11/3/07, Christian Heimes <lists at cheimes.de> wrote:
> Brett Cannon wrote:
> >> test_import (*)
> >
> > This is passing for me on OS X 10.4.
>
> It passes on my Ubuntu box, too. But on Guido's Ubuntu box it's failing.
> It's also failing on Windows but that's expected. I added the test to
> verify a bug that prevents Windows to load modules from a sys.path entry
> with non ASCII letters.
>
> Georg has told me that I shouldn't add tests that are known to break.

He's absolutely right.

I never realized that your test was meant to fail until the behavior
was fixed -- then I would've just disabled it. :-)

> The test seems to be locale dependent, too.
>
> Guido, what's the output of the locale command on your box?

LANG=en_US
LANGUAGE=en
LC_CTYPE="en_US"
LC_NUMERIC=C
LC_TIME=C
LC_COLLATE=C
LC_MONETARY=C
LC_MESSAGES="en_US"
LC_PAPER="en_US"
LC_NAME="en_US"
LC_ADDRESS="en_US"
LC_TELEPHONE="en_US"
LC_MEASUREMENT="en_US"
LC_IDENTIFICATION="en_US"
LC_ALL=

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

From guido at python.org  Sun Nov  4 00:02:43 2007
From: guido at python.org (Guido van Rossum)
Date: Sat, 3 Nov 2007 16:02:43 -0700
Subject: [Python-3000] Please re-add __cmp__ to python 3000
In-Reply-To: <aac2c7cb0710302253y26fd3847rfa90a35a69837885@mail.gmail.com>
References: <E1IiBwH-0003sz-04@fenris.runbox.com>
	<aac2c7cb0710291249y31a74c9cw66c5e7fbff818ea@mail.gmail.com>
	<47267607.2000806@canterbury.ac.nz>
	<aac2c7cb0710291836u28894c1epceb45b3640c794f6@mail.gmail.com>
	<4727973B.3060203@canterbury.ac.nz>
	<aac2c7cb0710301436j44c1dd26i682def6facfd9cef@mail.gmail.com>
	<d11dcfba0710301717r22a2c37t38af72e5b6a1d9b8@mail.gmail.com>
	<aac2c7cb0710301857r7a2d7148q45191a1cbd22621e@mail.gmail.com>
	<47280F00.1050002@canterbury.ac.nz>
	<aac2c7cb0710302253y26fd3847rfa90a35a69837885@mail.gmail.com>
Message-ID: <ca471dc20711031602p415e5780v560bfa8abd3ff73f@mail.gmail.com>

Everyone who cares about this topic, please collaborate on a PEP. If
we're going to put __cmp__ back in I'd like to have it in 3.0a2 if at
all possible. I'd like to release 3.0a2 around mid November. I don't
personally have much time to devote to the topic, but I've seen some
pretty well-motivated opinions here, so I think it's possible.

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

From guido at python.org  Sun Nov  4 00:03:24 2007
From: guido at python.org (Guido van Rossum)
Date: Sat, 3 Nov 2007 16:03:24 -0700
Subject: [Python-3000] What to do about "".join([b""])?
In-Reply-To: <bbaeab100711031526m3b46bb51k917191d636d660cb@mail.gmail.com>
References: <ca471dc20711011921y3aca3149pe642f159baa7e027@mail.gmail.com>
	<766a29bd0711020518x3e8a1ff8wa8fb9a8201bd402a@mail.gmail.com>
	<420EE378-F66E-453F-A6AC-A3CBFF31EA4F@python.org>
	<472CDEFB.3040806@canterbury.ac.nz>
	<bbaeab100711031526m3b46bb51k917191d636d660cb@mail.gmail.com>
Message-ID: <ca471dc20711031603t1f53fdf3w8227b4af4b247b05@mail.gmail.com>

On 11/3/07, Brett Cannon <brett at python.org> wrote:
> On 11/3/07, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> > Barry Warsaw wrote:
> > >  From a purity standpoint, I agree with removing the implicit
> > > str'ing.  I'm just sure what is more practical.
> >
> > If it's really considered worth providing this extra
> > convenience, how about a different method for it:
> >
> >    "".joinstr(...)
> >
> > Just as convenient, and explicit rather than implicit,
> > so it won't cause any surprises.
>
> Convenience of that over either of these::
>
>   ''.join(map(str, args))
>   ''.join(str(x) for x in args)
>
> is just not worth tacking on another method to str in my opinion.

Exactly.

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

From brett at python.org  Sun Nov  4 00:10:45 2007
From: brett at python.org (Brett Cannon)
Date: Sat, 3 Nov 2007 16:10:45 -0700
Subject: [Python-3000] Please re-add __cmp__ to python 3000
In-Reply-To: <ca471dc20711031602p415e5780v560bfa8abd3ff73f@mail.gmail.com>
References: <E1IiBwH-0003sz-04@fenris.runbox.com>
	<47267607.2000806@canterbury.ac.nz>
	<aac2c7cb0710291836u28894c1epceb45b3640c794f6@mail.gmail.com>
	<4727973B.3060203@canterbury.ac.nz>
	<aac2c7cb0710301436j44c1dd26i682def6facfd9cef@mail.gmail.com>
	<d11dcfba0710301717r22a2c37t38af72e5b6a1d9b8@mail.gmail.com>
	<aac2c7cb0710301857r7a2d7148q45191a1cbd22621e@mail.gmail.com>
	<47280F00.1050002@canterbury.ac.nz>
	<aac2c7cb0710302253y26fd3847rfa90a35a69837885@mail.gmail.com>
	<ca471dc20711031602p415e5780v560bfa8abd3ff73f@mail.gmail.com>
Message-ID: <bbaeab100711031610g700f449ct6235f9b5d4a46c25@mail.gmail.com>

On 11/3/07, Guido van Rossum <guido at python.org> wrote:
> Everyone who cares about this topic, please collaborate on a PEP. If
> we're going to put __cmp__ back in I'd like to have it in 3.0a2 if at
> all possible. I'd like to release 3.0a2 around mid November. I don't
> personally have much time to devote to the topic, but I've seen some
> pretty well-motivated opinions here, so I think it's possible.

And for anyone who wants to hash this out, python-ideas is a
reasonable place to do it.

-Brett

From brett at python.org  Sun Nov  4 00:27:19 2007
From: brett at python.org (Brett Cannon)
Date: Sat, 3 Nov 2007 16:27:19 -0700
Subject: [Python-3000] need help fixing broken tests in py3k-pep3137
	branch
In-Reply-To: <ca471dc20711021708s7125932ka699abb759e262dd@mail.gmail.com>
References: <ca471dc20711021708s7125932ka699abb759e262dd@mail.gmail.com>
Message-ID: <bbaeab100711031627j2d64f6f2wf0e4166f25624e1c@mail.gmail.com>

On 11/2/07, Guido van Rossum <guido at python.org> wrote:
> In the py3k-pep3137 branch I've been working on the implementation of PEP 3137.
> The work is largely done, but I'm stuck with about 20 failing tests,
> and very little time this weekend to work on these. Here's the list:

... now updated:

test_bsddb3
test_ctypes
test_email
test_import (*)
test_mailbox
test_old_mailbox
test_pickle
test_pickletools
test_sqlite
test_urllib2


> (*) test_import also fails in the py3k branch; see
> http://bugs.python.org/issue1377.

And just a reminder for people, the -f option for regrtest.py was
designed for situations like this.  Just copy the above list to a test
file, like OUTPUT, and run regrtest like this::

  ./python Lib/test/regrtest.py -f OUTPUT -uall

and that way you run all the tests that are failing.  The -u is
optional if you don't want to run stuff like test_bsddb3 that have
certain resource requirements.   You can also comment out stuff in the
file.  The help from regrest.py -h explains the details.

-Brett

From jimjjewett at gmail.com  Sun Nov  4 00:51:41 2007
From: jimjjewett at gmail.com (Jim Jewett)
Date: Sat, 3 Nov 2007 19:51:41 -0400
Subject: [Python-3000] need help fixing broken tests in py3k-pep3137
	branch
In-Reply-To: <ca471dc20711031548q3afdaeag2353115d79e797ce@mail.gmail.com>
References: <ca471dc20711021708s7125932ka699abb759e262dd@mail.gmail.com>
	<79990c6b0711030550w4cecea52xd9f9bb6c9e809bff@mail.gmail.com>
	<fghsf9$jqm$1@ger.gmane.org>
	<79990c6b0711030625s24bbae27q1c7dbddc5d73056@mail.gmail.com>
	<79990c6b0711030637w3ff762ddtae1613d6673efa20@mail.gmail.com>
	<472C7C59.4000602@cheimes.de>
	<79990c6b0711030723v6f611f93w2fdf2bc732912e45@mail.gmail.com>
	<ca471dc20711030825x56be102bv7f50cc2a6ca74d30@mail.gmail.com>
	<472CEA22.508@canterbury.ac.nz>
	<ca471dc20711031548q3afdaeag2353115d79e797ce@mail.gmail.com>
Message-ID: <fb6fbf560711031651m66812d0cjce74be84b5a871e@mail.gmail.com>

On 11/3/07, Guido van Rossum <guido at python.org> wrote:
> On 11/3/07, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> > Guido van Rossum wrote:
> > > We could use a better term than
> > > buffer-API-supporting object though!

> > Especially if you're also going to be using the term
> > 'buffer' for a particular Python type. That seems like
> > a recipe for confusion to me.

So don't do that.

> I'd love a better term. It seems we could use several new names:

> 1. a new name for what PEP 3137 calls buffer

ByteBuffer

> 2. a new name for the union of bytes and buffer (*)

ByteSequence

> 3. a new name for all types  supporting the "buffer API"

buffer

-jJ

From guido at python.org  Sun Nov  4 01:00:51 2007
From: guido at python.org (Guido van Rossum)
Date: Sat, 3 Nov 2007 17:00:51 -0700
Subject: [Python-3000] need help fixing broken tests in py3k-pep3137
	branch
In-Reply-To: <fb6fbf560711031651m66812d0cjce74be84b5a871e@mail.gmail.com>
References: <ca471dc20711021708s7125932ka699abb759e262dd@mail.gmail.com>
	<fghsf9$jqm$1@ger.gmane.org>
	<79990c6b0711030625s24bbae27q1c7dbddc5d73056@mail.gmail.com>
	<79990c6b0711030637w3ff762ddtae1613d6673efa20@mail.gmail.com>
	<472C7C59.4000602@cheimes.de>
	<79990c6b0711030723v6f611f93w2fdf2bc732912e45@mail.gmail.com>
	<ca471dc20711030825x56be102bv7f50cc2a6ca74d30@mail.gmail.com>
	<472CEA22.508@canterbury.ac.nz>
	<ca471dc20711031548q3afdaeag2353115d79e797ce@mail.gmail.com>
	<fb6fbf560711031651m66812d0cjce74be84b5a871e@mail.gmail.com>
Message-ID: <ca471dc20711031700q5b0ef237xc828567bcf4b8cb@mail.gmail.com>

On 11/3/07, Jim Jewett <jimjjewett at gmail.com> wrote:
> On 11/3/07, Guido van Rossum <guido at python.org> wrote:
> > I'd love a better term. It seems we could use several new names:
>
> > 1. a new name for what PEP 3137 calls buffer
>
> ByteBuffer

Fails the rule that built-in types have all-lowercase names. I've been
thinking to call it bytesbuffer or bytes_buffer though.

> > 2. a new name for the union of bytes and buffer (*)
>
> ByteSequence

That could work, it's an ABC after all (to be imported from collections).

> > 3. a new name for all types  supporting the "buffer API"
>
> buffer

Another ABC, so should have a CamelCase name. Also, we probably
shouldn't use plain, unadorned "buffer" or "Buffer" for any of these
-- it has too many meanings. Also "buffer" is a popular variable name
(much more so than bytes).

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

From guido at python.org  Sun Nov  4 01:19:06 2007
From: guido at python.org (Guido van Rossum)
Date: Sat, 3 Nov 2007 17:19:06 -0700
Subject: [Python-3000] need help fixing broken tests in py3k-pep3137
	branch
In-Reply-To: <472D0C2E.90304@hastings.org>
References: <ca471dc20711021708s7125932ka699abb759e262dd@mail.gmail.com>
	<fghsf9$jqm$1@ger.gmane.org>
	<79990c6b0711030625s24bbae27q1c7dbddc5d73056@mail.gmail.com>
	<79990c6b0711030637w3ff762ddtae1613d6673efa20@mail.gmail.com>
	<472C7C59.4000602@cheimes.de>
	<79990c6b0711030723v6f611f93w2fdf2bc732912e45@mail.gmail.com>
	<ca471dc20711030825x56be102bv7f50cc2a6ca74d30@mail.gmail.com>
	<472CEA22.508@canterbury.ac.nz>
	<ca471dc20711031548q3afdaeag2353115d79e797ce@mail.gmail.com>
	<472D0C2E.90304@hastings.org>
Message-ID: <ca471dc20711031719p6456d567x85f650282965ed8@mail.gmail.com>

On 11/3/07, Larry Hastings <larry at hastings.org> wrote:
>
>  Guido van Rossum wrote:
>  3. a new name for all types supporting the "buffer API"
>  "supporting the __call__ API" == "callable"
>  "supporting the iterator API" == "iterable"
>  "supporting the buffer API" ==... "bufferable" ?

I don't think so, since what you do with it isn't called "buffering".
That verb exists but has a different meaning -- it applies to the
things you put into the buffer, while here we're talking about the
buffer. In fact, buffer isn't really a great name for it -- an opaque
container of bytes is more like it.

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

From ncoghlan at gmail.com  Sun Nov  4 02:11:23 2007
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 04 Nov 2007 11:11:23 +1000
Subject: [Python-3000] need help fixing broken tests in
	py3k-pep3137	branch
In-Reply-To: <ca471dc20711031700q5b0ef237xc828567bcf4b8cb@mail.gmail.com>
References: <ca471dc20711021708s7125932ka699abb759e262dd@mail.gmail.com>	<fghsf9$jqm$1@ger.gmane.org>	<79990c6b0711030625s24bbae27q1c7dbddc5d73056@mail.gmail.com>	<79990c6b0711030637w3ff762ddtae1613d6673efa20@mail.gmail.com>	<472C7C59.4000602@cheimes.de>	<79990c6b0711030723v6f611f93w2fdf2bc732912e45@mail.gmail.com>	<ca471dc20711030825x56be102bv7f50cc2a6ca74d30@mail.gmail.com>	<472CEA22.508@canterbury.ac.nz>	<ca471dc20711031548q3afdaeag2353115d79e797ce@mail.gmail.com>	<fb6fbf560711031651m66812d0cjce74be84b5a871e@mail.gmail.com>
	<ca471dc20711031700q5b0ef237xc828567bcf4b8cb@mail.gmail.com>
Message-ID: <472D1C3B.8000107@gmail.com>

Guido van Rossum wrote:
> On 11/3/07, Jim Jewett <jimjjewett at gmail.com> wrote:
>> On 11/3/07, Guido van Rossum <guido at python.org> wrote:
>>> I'd love a better term. It seems we could use several new names:
>>> 1. a new name for what PEP 3137 calls buffer
>> ByteBuffer
> 
> Fails the rule that built-in types have all-lowercase names. I've been
> thinking to call it bytesbuffer or bytes_buffer though.

bytelist or byteslist? (It combines the mutable nature of a list with 
the other characteristics of the bytes type, after all)

>>> 2. a new name for the union of bytes and buffer (*)
>> ByteSequence
> 
> That could work, it's an ABC after all (to be imported from collections).

ByteSequence works for me (I believe it has been suggested at least once 
before)

>>> 3. a new name for all types  supporting the "buffer API"
>> buffer
> 
> Another ABC, so should have a CamelCase name. Also, we probably
> shouldn't use plain, unadorned "buffer" or "Buffer" for any of these
> -- it has too many meanings. Also "buffer" is a popular variable name
> (much more so than bytes).

BinaryData? When using the enhanced buffer API, an object may be 
exposing binary data formatted in the specified format rather than just 
basic bytes.

So the 'buffer API' would become the 'binary data API', and in cases 
where it mattered (such as the constructors for binary data types like 
array.array) the binary data interface would take precedence over the 
iterable interface. Coming from a comms background where "buffer" means 
"FIFO queue" most of the time, it would also be a lot more intuitive.

Cheers,
Nick.

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

From tjreedy at udel.edu  Sun Nov  4 02:13:08 2007
From: tjreedy at udel.edu (Terry Reedy)
Date: Sat, 3 Nov 2007 21:13:08 -0400
Subject: [Python-3000] need help fixing broken tests in
	py3k-pep3137branch
References: <ca471dc20711021708s7125932ka699abb759e262dd@mail.gmail.com><79990c6b0711030550w4cecea52xd9f9bb6c9e809bff@mail.gmail.com><fghsf9$jqm$1@ger.gmane.org><79990c6b0711030625s24bbae27q1c7dbddc5d73056@mail.gmail.com><79990c6b0711030637w3ff762ddtae1613d6673efa20@mail.gmail.com><472C7C59.4000602@cheimes.de><79990c6b0711030723v6f611f93w2fdf2bc732912e45@mail.gmail.com><ca471dc20711030825x56be102bv7f50cc2a6ca74d30@mail.gmail.com><472CEA22.508@canterbury.ac.nz>
	<ca471dc20711031548q3afdaeag2353115d79e797ce@mail.gmail.com>
Message-ID: <fgj6b0$32o$1@ger.gmane.org>


"Guido van Rossum" <guido at python.org> wrote in message 
news:ca471dc20711031548q3afdaeag2353115d79e797ce at mail.gmail.com...
|| I'd love a better term. It seems we could use several new names:
|
| 1. a new name for what PEP 3137 calls buffer

The definining difference is mutability or editability, so 'mubytes' or 
'ebytes'.

| 2. a new name for the union of bytes and buffer (*)

Bytable (ABC) = able to be split into bytes.

| 3. a new name for all types  supporting the "buffer API"

MemBuf, MemArray, MemRay 




From jyasskin at gmail.com  Sun Nov  4 02:18:41 2007
From: jyasskin at gmail.com (Jeffrey Yasskin)
Date: Sat, 3 Nov 2007 18:18:41 -0700
Subject: [Python-3000] need help fixing broken tests in py3k-pep3137
	branch
In-Reply-To: <472D1C3B.8000107@gmail.com>
References: <ca471dc20711021708s7125932ka699abb759e262dd@mail.gmail.com>
	<79990c6b0711030637w3ff762ddtae1613d6673efa20@mail.gmail.com>
	<472C7C59.4000602@cheimes.de>
	<79990c6b0711030723v6f611f93w2fdf2bc732912e45@mail.gmail.com>
	<ca471dc20711030825x56be102bv7f50cc2a6ca74d30@mail.gmail.com>
	<472CEA22.508@canterbury.ac.nz>
	<ca471dc20711031548q3afdaeag2353115d79e797ce@mail.gmail.com>
	<fb6fbf560711031651m66812d0cjce74be84b5a871e@mail.gmail.com>
	<ca471dc20711031700q5b0ef237xc828567bcf4b8cb@mail.gmail.com>
	<472D1C3B.8000107@gmail.com>
Message-ID: <5d44f72f0711031818t4bcb2e3l432e6cc243c943ba@mail.gmail.com>

Those look clearly better than the previous suggestions to me. +1.

I think 'bytelist' is more correct than 'byteslist'. It's a list of
'byte's rather than a list of 'bytes'es. Which isn't particularly
convincing... Maybe the fact that we say "chicken farm" instead of
"chickens farm" is better? I think this is a specifically English
convention for pluralization that's different in many other languages.

On 11/3/07, Nick Coghlan <ncoghlan at gmail.com> wrote:
> Guido van Rossum wrote:
> > On 11/3/07, Jim Jewett <jimjjewett at gmail.com> wrote:
> >> On 11/3/07, Guido van Rossum <guido at python.org> wrote:
> >>> I'd love a better term. It seems we could use several new names:
> >>> 1. a new name for what PEP 3137 calls buffer
> >> ByteBuffer
> >
> > Fails the rule that built-in types have all-lowercase names. I've been
> > thinking to call it bytesbuffer or bytes_buffer though.
>
> bytelist or byteslist? (It combines the mutable nature of a list with
> the other characteristics of the bytes type, after all)
>
> >>> 2. a new name for the union of bytes and buffer (*)
> >> ByteSequence
> >
> > That could work, it's an ABC after all (to be imported from collections).
>
> ByteSequence works for me (I believe it has been suggested at least once
> before)
>
> >>> 3. a new name for all types  supporting the "buffer API"
> >> buffer
> >
> > Another ABC, so should have a CamelCase name. Also, we probably
> > shouldn't use plain, unadorned "buffer" or "Buffer" for any of these
> > -- it has too many meanings. Also "buffer" is a popular variable name
> > (much more so than bytes).
>
> BinaryData? When using the enhanced buffer API, an object may be
> exposing binary data formatted in the specified format rather than just
> basic bytes.
>
> So the 'buffer API' would become the 'binary data API', and in cases
> where it mattered (such as the constructors for binary data types like
> array.array) the binary data interface would take precedence over the
> iterable interface. Coming from a comms background where "buffer" means
> "FIFO queue" most of the time, it would also be a lot more intuitive.
>
> 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/jyasskin%40gmail.com
>


-- 
Namast?,
Jeffrey Yasskin
http://jeffrey.yasskin.info/

"Religion is an improper response to the Divine." ? "Skinny Legs and
All", by Tom Robbins

From brett at python.org  Sun Nov  4 08:22:27 2007
From: brett at python.org (Brett Cannon)
Date: Sun, 4 Nov 2007 00:22:27 -0700
Subject: [Python-3000] need help fixing broken tests in py3k-pep3137
	branch
In-Reply-To: <bbaeab100711031627j2d64f6f2wf0e4166f25624e1c@mail.gmail.com>
References: <ca471dc20711021708s7125932ka699abb759e262dd@mail.gmail.com>
	<bbaeab100711031627j2d64f6f2wf0e4166f25624e1c@mail.gmail.com>
Message-ID: <bbaeab100711040022y293ffd8en7bab65e9ac4ae45f@mail.gmail.com>

On 11/3/07, Brett Cannon <brett at python.org> wrote:
> On 11/2/07, Guido van Rossum <guido at python.org> wrote:
> > In the py3k-pep3137 branch I've been working on the implementation of PEP 3137.
> > The work is largely done, but I'm stuck with about 20 failing tests,
> > and very little time this weekend to work on these. Here's the list:
>
> ... now updated:
>
> test_bsddb3

The big failure spewing out all of this stuff about an assert in
getGenre() failing is because the code in
Modules/_bsddb.c:_db_associateCallback() uses "y#' to build an
argument tuple when the test expects a bytes type and not a buffer
type.  Now I searched in Python/modsupport.c and there is not a single
PyString_*() call in there.  What format string are we supposed to use
for PyString/bytes instances?  Should we change 'y' from
PyBytes/buffer to PyString/bytes, or add yet another format string?

-Brett

From brett at python.org  Sun Nov  4 09:16:52 2007
From: brett at python.org (Brett Cannon)
Date: Sun, 4 Nov 2007 01:16:52 -0700
Subject: [Python-3000] need help fixing broken tests in py3k-pep3137
	branch
In-Reply-To: <bbaeab100711031627j2d64f6f2wf0e4166f25624e1c@mail.gmail.com>
References: <ca471dc20711021708s7125932ka699abb759e262dd@mail.gmail.com>
	<bbaeab100711031627j2d64f6f2wf0e4166f25624e1c@mail.gmail.com>
Message-ID: <bbaeab100711040116y1cf016a0jd4e5686b6381589d@mail.gmail.com>

On 11/3/07, Brett Cannon <brett at python.org> wrote:
> On 11/2/07, Guido van Rossum <guido at python.org> wrote:
> > In the py3k-pep3137 branch I've been working on the implementation of PEP 3137.
> > The work is largely done, but I'm stuck with about 20 failing tests,
> > and very little time this weekend to work on these. Here's the list:
>
> ... now updated:
>

Some more preliminary digging:

> test_email

Looks like multiple places where str and buffers are being compared,
but  I am not sure exactly which is correct.

> test_mailbox
> test_old_mailbox

Seems rfc822 is getting called with both str and bytes arguments but
is using str constants for operations.  Going to guess bytes is the
more proper answer.  But then again this module is supposed to get
replaced by the email package so the issue could be solved if someone
reworked the mailbox module to use the email package instead.

> test_pickle

The string constants of what is being loaded from is returning bytes
instead of str since the 'S' type in pickles is now bytes.  Probably
need to regenerate the comparison data along with possibly adding some
bytes to create_data().

-Brett

From lists at cheimes.de  Sun Nov  4 14:08:58 2007
From: lists at cheimes.de (Christian Heimes)
Date: Sun, 04 Nov 2007 14:08:58 +0100
Subject: [Python-3000] need help fixing broken tests in py3k-pep3137
	branch
In-Reply-To: <ca471dc20711031556y2dfb55a4pfb3645f646bb196@mail.gmail.com>
References: <ca471dc20711021708s7125932ka699abb759e262dd@mail.gmail.com>	<bbaeab100711030039n194640b6rb8e45f9d94333951@mail.gmail.com>	<fghm2l$40t$1@ger.gmane.org>
	<ca471dc20711031556y2dfb55a4pfb3645f646bb196@mail.gmail.com>
Message-ID: <472DC46A.2080307@cheimes.de>

Guido van Rossum wrote:
> He's absolutely right.
> 
> I never realized that your test was meant to fail until the behavior
> was fixed -- then I would've just disabled it. :-)

I've disabled the test for you. :)

>> Guido, what's the output of the locale command on your box?
> 
> LANG=en_US

My locales start with LANG=de_DE.UTF-8. I'm not sure what your system is
using as default encoding but I'd guess it's ASCII or latin-1.

Christian


From aahz at pythoncraft.com  Sun Nov  4 15:09:37 2007
From: aahz at pythoncraft.com (Aahz)
Date: Sun, 4 Nov 2007 06:09:37 -0800
Subject: [Python-3000] need help fixing broken tests in py3k-pep3137
	branch
In-Reply-To: <bbaeab100711031326o2e844178u323cdcdf81779c97@mail.gmail.com>
References: <ca471dc20711021708s7125932ka699abb759e262dd@mail.gmail.com>
	<766a29bd0711031117pde4020fq1b9f64fb11e5eef8@mail.gmail.com>
	<472CC213.2010006@cheimes.de>
	<bbaeab100711031326o2e844178u323cdcdf81779c97@mail.gmail.com>
Message-ID: <20071104140937.GA9349@panix.com>

On Sat, Nov 03, 2007, Brett Cannon wrote:
> On 11/3/07, Christian Heimes <lists at cheimes.de> wrote:
>>
>> No, Python has no means to check for the buffer interface yet. You could
>> do isinstance(ob, (bytes, buffer)) but it wouldn't catch every object.
>> We could create a PyObject_CheckWriteBuffer() API function and expose
>> PyObject_CheckReadBuffer() and PyObject_CheckWriteBuffer() expose them.
>> Or we could abuse isinstance(ob, memoryview). Or an ABC?
> 
> An ABC would be best.  I know there was a discussion about what the
> best name would be for such an ABC but I don't remember the conclusion
> reached.

Guido said ByteSequence for the bytes, so MutableByteSequence?
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

"Typing is cheap.  Thinking is expensive."  --Roy Smith

From lists at cheimes.de  Sun Nov  4 15:43:25 2007
From: lists at cheimes.de (Christian Heimes)
Date: Sun, 04 Nov 2007 15:43:25 +0100
Subject: [Python-3000] need help fixing broken tests in py3k-pep3137
	branch
In-Reply-To: <ca471dc20711021708s7125932ka699abb759e262dd@mail.gmail.com>
References: <ca471dc20711021708s7125932ka699abb759e262dd@mail.gmail.com>
Message-ID: <472DDA8D.2050000@cheimes.de>

Guido van Rossum wrote:
> In the py3k-pep3137 branch I've been working on the implementation of PEP 3137.
> The work is largely done, but I'm stuck with about 20 failing tests,
> and very little time this weekend to work on these. Here's the list:

Windows test results:

test_bytes
test_csv
test_ctypes
test_email
test_import (fix in http://bugs.python.org/issue1293)
test_inspect
test_mailbox
test_netrc
test_old_mailbox
test_pickle
test_pickletools
test_sqlite
test_urllib2
test_uuid

Christian

From guido at python.org  Sun Nov  4 16:51:31 2007
From: guido at python.org (Guido van Rossum)
Date: Sun, 4 Nov 2007 08:51:31 -0700
Subject: [Python-3000] need help fixing broken tests in py3k-pep3137
	branch
In-Reply-To: <5d44f72f0711031818t4bcb2e3l432e6cc243c943ba@mail.gmail.com>
References: <ca471dc20711021708s7125932ka699abb759e262dd@mail.gmail.com>
	<472C7C59.4000602@cheimes.de>
	<79990c6b0711030723v6f611f93w2fdf2bc732912e45@mail.gmail.com>
	<ca471dc20711030825x56be102bv7f50cc2a6ca74d30@mail.gmail.com>
	<472CEA22.508@canterbury.ac.nz>
	<ca471dc20711031548q3afdaeag2353115d79e797ce@mail.gmail.com>
	<fb6fbf560711031651m66812d0cjce74be84b5a871e@mail.gmail.com>
	<ca471dc20711031700q5b0ef237xc828567bcf4b8cb@mail.gmail.com>
	<472D1C3B.8000107@gmail.com>
	<5d44f72f0711031818t4bcb2e3l432e6cc243c943ba@mail.gmail.com>
Message-ID: <ca471dc20711040751i3280f7bg299554e20dc25859@mail.gmail.com>

I'm beginning to settle on the following:

1. concrete types: bytes (immutable) and bytearray (mutable)
2. their common ABC: ByteString (derives from Sequence)
3. the ABC corresponding to buffer-API objects: MemoryBlock

--Guido

On 11/3/07, Jeffrey Yasskin <jyasskin at gmail.com> wrote:
> Those look clearly better than the previous suggestions to me. +1.
>
> I think 'bytelist' is more correct than 'byteslist'.

But it's not a list, it's a sequence. :-)

> It's a list of
> 'byte's rather than a list of 'bytes'es. Which isn't particularly
> convincing... Maybe the fact that we say "chicken farm" instead of
> "chickens farm" is better? I think this is a specifically English
> convention for pluralization that's different in many other languages.
>
> On 11/3/07, Nick Coghlan <ncoghlan at gmail.com> wrote:
> > Guido van Rossum wrote:
> > > On 11/3/07, Jim Jewett <jimjjewett at gmail.com> wrote:
> > >> On 11/3/07, Guido van Rossum <guido at python.org> wrote:
> > >>> I'd love a better term. It seems we could use several new names:
> > >>> 1. a new name for what PEP 3137 calls buffer
> > >> ByteBuffer
> > >
> > > Fails the rule that built-in types have all-lowercase names. I've been
> > > thinking to call it bytesbuffer or bytes_buffer though.
> >
> > bytelist or byteslist? (It combines the mutable nature of a list with
> > the other characteristics of the bytes type, after all)
> >
> > >>> 2. a new name for the union of bytes and buffer (*)
> > >> ByteSequence
> > >
> > > That could work, it's an ABC after all (to be imported from collections).
> >
> > ByteSequence works for me (I believe it has been suggested at least once
> > before)
> >
> > >>> 3. a new name for all types  supporting the "buffer API"
> > >> buffer
> > >
> > > Another ABC, so should have a CamelCase name. Also, we probably
> > > shouldn't use plain, unadorned "buffer" or "Buffer" for any of these
> > > -- it has too many meanings. Also "buffer" is a popular variable name
> > > (much more so than bytes).
> >
> > BinaryData? When using the enhanced buffer API, an object may be
> > exposing binary data formatted in the specified format rather than just
> > basic bytes.
> >
> > So the 'buffer API' would become the 'binary data API', and in cases
> > where it mattered (such as the constructors for binary data types like
> > array.array) the binary data interface would take precedence over the
> > iterable interface. Coming from a comms background where "buffer" means
> > "FIFO queue" most of the time, it would also be a lot more intuitive.
> >
> > 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/jyasskin%40gmail.com
> >
>
>
> --
> Namast?,
> Jeffrey Yasskin
> http://jeffrey.yasskin.info/
>
> "Religion is an improper response to the Divine." ? "Skinny Legs and
> All", by Tom Robbins
>


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

From p.f.moore at gmail.com  Sun Nov  4 17:51:55 2007
From: p.f.moore at gmail.com (Paul Moore)
Date: Sun, 4 Nov 2007 16:51:55 +0000
Subject: [Python-3000] need help fixing broken tests in py3k-pep3137
	branch
In-Reply-To: <ca471dc20711040751i3280f7bg299554e20dc25859@mail.gmail.com>
References: <ca471dc20711021708s7125932ka699abb759e262dd@mail.gmail.com>
	<79990c6b0711030723v6f611f93w2fdf2bc732912e45@mail.gmail.com>
	<ca471dc20711030825x56be102bv7f50cc2a6ca74d30@mail.gmail.com>
	<472CEA22.508@canterbury.ac.nz>
	<ca471dc20711031548q3afdaeag2353115d79e797ce@mail.gmail.com>
	<fb6fbf560711031651m66812d0cjce74be84b5a871e@mail.gmail.com>
	<ca471dc20711031700q5b0ef237xc828567bcf4b8cb@mail.gmail.com>
	<472D1C3B.8000107@gmail.com>
	<5d44f72f0711031818t4bcb2e3l432e6cc243c943ba@mail.gmail.com>
	<ca471dc20711040751i3280f7bg299554e20dc25859@mail.gmail.com>
Message-ID: <79990c6b0711040851s49c96303k4ef15249fb534261@mail.gmail.com>

On 04/11/2007, Guido van Rossum <guido at python.org> wrote:
> I'm beginning to settle on the following:
>
> 1. concrete types: bytes (immutable) and bytearray (mutable)

bytearray seems a bit clumsy, but I can't think of anything better...

> 2. their common ABC: ByteString (derives from Sequence)

Would ByteSequence not be better?

> 3. the ABC corresponding to buffer-API objects: MemoryBlock

Sounds reasonable. Would it make sense to rename the buffer API as the
memory block API in that case? (PyBufferProcs --> PyMemoryBlockProcs,
or maybe PyMemBlockProcs to make for less typing, etc)

Paul

From g.brandl at gmx.net  Sun Nov  4 18:40:33 2007
From: g.brandl at gmx.net (Georg Brandl)
Date: Sun, 04 Nov 2007 18:40:33 +0100
Subject: [Python-3000] need help fixing broken tests in py3k-pep3137
	branch
In-Reply-To: <79990c6b0711040851s49c96303k4ef15249fb534261@mail.gmail.com>
References: <ca471dc20711021708s7125932ka699abb759e262dd@mail.gmail.com>	<79990c6b0711030723v6f611f93w2fdf2bc732912e45@mail.gmail.com>	<ca471dc20711030825x56be102bv7f50cc2a6ca74d30@mail.gmail.com>	<472CEA22.508@canterbury.ac.nz>	<ca471dc20711031548q3afdaeag2353115d79e797ce@mail.gmail.com>	<fb6fbf560711031651m66812d0cjce74be84b5a871e@mail.gmail.com>	<ca471dc20711031700q5b0ef237xc828567bcf4b8cb@mail.gmail.com>	<472D1C3B.8000107@gmail.com>	<5d44f72f0711031818t4bcb2e3l432e6cc243c943ba@mail.gmail.com>	<ca471dc20711040751i3280f7bg299554e20dc25859@mail.gmail.com>
	<79990c6b0711040851s49c96303k4ef15249fb534261@mail.gmail.com>
Message-ID: <fgl06i$4ok$1@ger.gmane.org>

Paul Moore schrieb:
> On 04/11/2007, Guido van Rossum <guido at python.org> wrote:
>> I'm beginning to settle on the following:
>>
>> 1. concrete types: bytes (immutable) and bytearray (mutable)
> 
> bytearray seems a bit clumsy, but I can't think of anything better...

It's much better than "buffer". Also I don't think it will be used
too often...

>> 2. their common ABC: ByteString (derives from Sequence)
> 
> Would ByteSequence not be better?

ByteString stresses the relationship with str, with which the ByteString
derivatives share their methods.

>> 3. the ABC corresponding to buffer-API objects: MemoryBlock
> 
> Sounds reasonable. Would it make sense to rename the buffer API as the
> memory block API in that case? (PyBufferProcs --> PyMemoryBlockProcs,
> or maybe PyMemBlockProcs to make for less typing, etc)

It certainly would make sense, during the Great C Api Rename (tm).

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 brett at python.org  Sun Nov  4 19:39:46 2007
From: brett at python.org (Brett Cannon)
Date: Sun, 4 Nov 2007 10:39:46 -0800
Subject: [Python-3000] need help fixing broken tests in py3k-pep3137
	branch
In-Reply-To: <ca471dc20711040751i3280f7bg299554e20dc25859@mail.gmail.com>
References: <ca471dc20711021708s7125932ka699abb759e262dd@mail.gmail.com>
	<79990c6b0711030723v6f611f93w2fdf2bc732912e45@mail.gmail.com>
	<ca471dc20711030825x56be102bv7f50cc2a6ca74d30@mail.gmail.com>
	<472CEA22.508@canterbury.ac.nz>
	<ca471dc20711031548q3afdaeag2353115d79e797ce@mail.gmail.com>
	<fb6fbf560711031651m66812d0cjce74be84b5a871e@mail.gmail.com>
	<ca471dc20711031700q5b0ef237xc828567bcf4b8cb@mail.gmail.com>
	<472D1C3B.8000107@gmail.com>
	<5d44f72f0711031818t4bcb2e3l432e6cc243c943ba@mail.gmail.com>
	<ca471dc20711040751i3280f7bg299554e20dc25859@mail.gmail.com>
Message-ID: <bbaeab100711041039r715cd989jd3b752c437344920@mail.gmail.com>

On 11/4/07, Guido van Rossum <guido at python.org> wrote:
> I'm beginning to settle on the following:
>
> 1. concrete types: bytes (immutable) and bytearray (mutable)
> 2. their common ABC: ByteString (derives from Sequence)
> 3. the ABC corresponding to buffer-API objects: MemoryBlock
>

All seem fine to me.  But I am also okay with Paul's suggestion of ByteSequence.

-Brett



> --Guido
>
> On 11/3/07, Jeffrey Yasskin <jyasskin at gmail.com> wrote:
> > Those look clearly better than the previous suggestions to me. +1.
> >
> > I think 'bytelist' is more correct than 'byteslist'.
>
> But it's not a list, it's a sequence. :-)
>
> > It's a list of
> > 'byte's rather than a list of 'bytes'es. Which isn't particularly
> > convincing... Maybe the fact that we say "chicken farm" instead of
> > "chickens farm" is better? I think this is a specifically English
> > convention for pluralization that's different in many other languages.
> >
> > On 11/3/07, Nick Coghlan <ncoghlan at gmail.com> wrote:
> > > Guido van Rossum wrote:
> > > > On 11/3/07, Jim Jewett <jimjjewett at gmail.com> wrote:
> > > >> On 11/3/07, Guido van Rossum <guido at python.org> wrote:
> > > >>> I'd love a better term. It seems we could use several new names:
> > > >>> 1. a new name for what PEP 3137 calls buffer
> > > >> ByteBuffer
> > > >
> > > > Fails the rule that built-in types have all-lowercase names. I've been
> > > > thinking to call it bytesbuffer or bytes_buffer though.
> > >
> > > bytelist or byteslist? (It combines the mutable nature of a list with
> > > the other characteristics of the bytes type, after all)
> > >
> > > >>> 2. a new name for the union of bytes and buffer (*)
> > > >> ByteSequence
> > > >
> > > > That could work, it's an ABC after all (to be imported from collections).
> > >
> > > ByteSequence works for me (I believe it has been suggested at least once
> > > before)
> > >
> > > >>> 3. a new name for all types  supporting the "buffer API"
> > > >> buffer
> > > >
> > > > Another ABC, so should have a CamelCase name. Also, we probably
> > > > shouldn't use plain, unadorned "buffer" or "Buffer" for any of these
> > > > -- it has too many meanings. Also "buffer" is a popular variable name
> > > > (much more so than bytes).
> > >
> > > BinaryData? When using the enhanced buffer API, an object may be
> > > exposing binary data formatted in the specified format rather than just
> > > basic bytes.
> > >
> > > So the 'buffer API' would become the 'binary data API', and in cases
> > > where it mattered (such as the constructors for binary data types like
> > > array.array) the binary data interface would take precedence over the
> > > iterable interface. Coming from a comms background where "buffer" means
> > > "FIFO queue" most of the time, it would also be a lot more intuitive.
> > >
> > > 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/jyasskin%40gmail.com
> > >
> >
> >
> > --
> > Namast?,
> > Jeffrey Yasskin
> > http://jeffrey.yasskin.info/
> >
> > "Religion is an improper response to the Divine." ? "Skinny Legs and
> > All", by Tom Robbins
> >
>
>
> --
> --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 lists at cheimes.de  Sun Nov  4 20:02:52 2007
From: lists at cheimes.de (Christian Heimes)
Date: Sun, 04 Nov 2007 20:02:52 +0100
Subject: [Python-3000] need help fixing broken tests in py3k-pep3137
	branch
In-Reply-To: <ca471dc20711040751i3280f7bg299554e20dc25859@mail.gmail.com>
References: <ca471dc20711021708s7125932ka699abb759e262dd@mail.gmail.com>	<472C7C59.4000602@cheimes.de>	<79990c6b0711030723v6f611f93w2fdf2bc732912e45@mail.gmail.com>	<ca471dc20711030825x56be102bv7f50cc2a6ca74d30@mail.gmail.com>	<472CEA22.508@canterbury.ac.nz>	<ca471dc20711031548q3afdaeag2353115d79e797ce@mail.gmail.com>	<fb6fbf560711031651m66812d0cjce74be84b5a871e@mail.gmail.com>	<ca471dc20711031700q5b0ef237xc828567bcf4b8cb@mail.gmail.com>	<472D1C3B.8000107@gmail.com>	<5d44f72f0711031818t4bcb2e3l432e6cc243c943ba@mail.gmail.com>
	<ca471dc20711040751i3280f7bg299554e20dc25859@mail.gmail.com>
Message-ID: <472E175C.9040908@cheimes.de>

Guido van Rossum wrote:
> I'm beginning to settle on the following:
> 
> 1. concrete types: bytes (immutable) and bytearray (mutable)
> 2. their common ABC: ByteString (derives from Sequence)

I prefer ByteSequence. Bytes and buffer are a sequence of bytes.

> 3. the ABC corresponding to buffer-API objects: MemoryBlock

What do you think about RawData, RawBlock, RawView or RawSequence? From
my point of view a PyBuffer allows me to access the raw data of a
PyString or PyBytes.

Christian

From guido at python.org  Sun Nov  4 21:31:11 2007
From: guido at python.org (Guido van Rossum)
Date: Sun, 4 Nov 2007 12:31:11 -0800
Subject: [Python-3000] need help fixing broken tests in py3k-pep3137
	branch
In-Reply-To: <472E175C.9040908@cheimes.de>
References: <ca471dc20711021708s7125932ka699abb759e262dd@mail.gmail.com>
	<ca471dc20711030825x56be102bv7f50cc2a6ca74d30@mail.gmail.com>
	<472CEA22.508@canterbury.ac.nz>
	<ca471dc20711031548q3afdaeag2353115d79e797ce@mail.gmail.com>
	<fb6fbf560711031651m66812d0cjce74be84b5a871e@mail.gmail.com>
	<ca471dc20711031700q5b0ef237xc828567bcf4b8cb@mail.gmail.com>
	<472D1C3B.8000107@gmail.com>
	<5d44f72f0711031818t4bcb2e3l432e6cc243c943ba@mail.gmail.com>
	<ca471dc20711040751i3280f7bg299554e20dc25859@mail.gmail.com>
	<472E175C.9040908@cheimes.de>
Message-ID: <ca471dc20711041231l1a5fd368qc11c3ed2ae9e73fb@mail.gmail.com>

On 11/4/07, Christian Heimes <lists at cheimes.de> wrote:
> Guido van Rossum wrote:
> > I'm beginning to settle on the following:
> >
> > 1. concrete types: bytes (immutable) and bytearray (mutable)
> > 2. their common ABC: ByteString (derives from Sequence)
>
> I prefer ByteSequence. Bytes and buffer are a sequence of bytes.

Well, a string is a sequence with additional behavior (the set of
methods common to PyUnicode, PyString, PyBuffer). So ByteString is
more specific.

> > 3. the ABC corresponding to buffer-API objects: MemoryBlock
>
> What do you think about RawData, RawBlock, RawView or RawSequence? From
> my point of view a PyBuffer allows me to access the raw data of a
> PyString or PyBytes.

"Raw" has lots of different connotations (e.g. raw_input() in 2.x). I
like "Memory" best since it indicates directly that it's connected to
the computer's (primary) memory.

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

From lists at cheimes.de  Mon Nov  5 18:24:43 2007
From: lists at cheimes.de (Christian Heimes)
Date: Mon, 05 Nov 2007 18:24:43 +0100
Subject: [Python-3000] need help fixing broken tests in py3k-pep3137
	branch
In-Reply-To: <ca471dc20711021708s7125932ka699abb759e262dd@mail.gmail.com>
References: <ca471dc20711021708s7125932ka699abb759e262dd@mail.gmail.com>
Message-ID: <472F51DB.8060204@cheimes.de>

Guido van Rossum wrote:
> In the py3k-pep3137 branch I've been working on the implementation of PEP 3137.
> The work is largely done, but I'm stuck with about 20 failing tests,
> and very little time this weekend to work on these. Here's the list:

Here is an updated list. 4 unit tests are failing on Linux and 7
(sometimes 8) are failing on Windows:

test_mailbox
test_old_mailbox
test_pickle
test_sqlite

Windows only:
test_csv
test_import (fix available at http://bugs.python.org/issue1293)
test_inspect (only on some occasions, http://bugs.python.org/issue1384)
test_netrc

One test is leaking reference:
test_struct (http://bugs.python.org/issue1389)

Other open issues:
* pdb has problems with the "with" statement
http://bugs.python.org/issue1265
* On Windows Python doesn't start if the path to Python contains non
ASCII chars. Python can't load modules from paths with non ASCII chars,
too. http://bugs.python.org/issue1342
* I like to change str(buffer()) and str(bytes()) to return the
bytes/buffer decoded with "ascii" instead of returning the
representation of the bytes/buffer. http://bugs.python.org/issue1392

Christian

From janssen at parc.com  Mon Nov  5 18:43:58 2007
From: janssen at parc.com (Bill Janssen)
Date: Mon, 5 Nov 2007 09:43:58 PST
Subject: [Python-3000] need help fixing broken tests in py3k-pep3137
	branch
In-Reply-To: <ca471dc20711041231l1a5fd368qc11c3ed2ae9e73fb@mail.gmail.com> 
References: <ca471dc20711021708s7125932ka699abb759e262dd@mail.gmail.com>
	<ca471dc20711030825x56be102bv7f50cc2a6ca74d30@mail.gmail.com>
	<472CEA22.508@canterbury.ac.nz>
	<ca471dc20711031548q3afdaeag2353115d79e797ce@mail.gmail.com>
	<fb6fbf560711031651m66812d0cjce74be84b5a871e@mail.gmail.com>
	<ca471dc20711031700q5b0ef237xc828567bcf4b8cb@mail.gmail.com>
	<472D1C3B.8000107@gmail.com>
	<5d44f72f0711031818t4bcb2e3l432e6cc243c943ba@mail.gmail.com>
	<ca471dc20711040751i3280f7bg299554e20dc25859@mail.gmail.com>
	<472E175C.9040908@cheimes.de>
	<ca471dc20711041231l1a5fd368qc11c3ed2ae9e73fb@mail.gmail.com>
Message-ID: <07Nov5.094404pst."57996"@synergy1.parc.xerox.com>

> > > 3. the ABC corresponding to buffer-API objects: MemoryBlock
> >
> > What do you think about RawData, RawBlock, RawView or RawSequence? From
> > my point of view a PyBuffer allows me to access the raw data of a
> > PyString or PyBytes.
> 
> "Raw" has lots of different connotations (e.g. raw_input() in 2.x). I
> like "Memory" best since it indicates directly that it's connected to
> the computer's (primary) memory.

How about ByteBlock?  I like the "Block" part.

Two points:  Every other type of data structure is connected to the the
"memory" in the same way, strings no less than buffers.  And it (and all
the other data types) are not really connected to the computer's
primary memory these days; virtual at best.  It's the bytes which are
the interesting piece of info here; they should be in the name.

Bill

From guido at python.org  Mon Nov  5 18:54:47 2007
From: guido at python.org (Guido van Rossum)
Date: Mon, 5 Nov 2007 09:54:47 -0800
Subject: [Python-3000] need help fixing broken tests in py3k-pep3137
	branch
In-Reply-To: <6019706871793151324@unknownmsgid>
References: <ca471dc20711021708s7125932ka699abb759e262dd@mail.gmail.com>
	<ca471dc20711031548q3afdaeag2353115d79e797ce@mail.gmail.com>
	<fb6fbf560711031651m66812d0cjce74be84b5a871e@mail.gmail.com>
	<ca471dc20711031700q5b0ef237xc828567bcf4b8cb@mail.gmail.com>
	<472D1C3B.8000107@gmail.com>
	<5d44f72f0711031818t4bcb2e3l432e6cc243c943ba@mail.gmail.com>
	<ca471dc20711040751i3280f7bg299554e20dc25859@mail.gmail.com>
	<472E175C.9040908@cheimes.de>
	<ca471dc20711041231l1a5fd368qc11c3ed2ae9e73fb@mail.gmail.com>
	<6019706871793151324@unknownmsgid>
Message-ID: <ca471dc20711050954t185d2f50x37bf4028becf9579@mail.gmail.com>

On 11/5/07, Bill Janssen <janssen at parc.com> wrote:
> > > > 3. the ABC corresponding to buffer-API objects: MemoryBlock
> > >
> > > What do you think about RawData, RawBlock, RawView or RawSequence? From
> > > my point of view a PyBuffer allows me to access the raw data of a
> > > PyString or PyBytes.
> >
> > "Raw" has lots of different connotations (e.g. raw_input() in 2.x). I
> > like "Memory" best since it indicates directly that it's connected to
> > the computer's (primary) memory.
>
> How about ByteBlock?  I like the "Block" part.

Me too, but the alliteration of ByteBlock somehow rubs me the wrong way.

> Two points:  Every other type of data structure is connected to the the
> "memory" in the same way, strings no less than buffers.  And it (and all
> the other data types) are not really connected to the computer's
> primary memory these days; virtual at best.  It's the bytes which are
> the interesting piece of info here; they should be in the name.

But the *Block type is different because its primary use is to share
that memory / those bytes with code that lives at the C level. In
favor of "memory" is also that Travis Oliphant independently came up
with "memoryview" for the data type that makes the buffer API
accessible from Python.

BTW a separate issue is that there currently is no way for a class
defined in Python to implement PyObject_GetBuffer, other than
inheriting from an object that already implements it. There should be
a possible wrapper so that you can wrap around e.g. a bytes object.
This is really an issue for PEP 3118 though.

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

From guido at python.org  Mon Nov  5 19:39:42 2007
From: guido at python.org (Guido van Rossum)
Date: Mon, 5 Nov 2007 10:39:42 -0800
Subject: [Python-3000] need help fixing broken tests in py3k-pep3137
	branch
In-Reply-To: <bbaeab100711040022y293ffd8en7bab65e9ac4ae45f@mail.gmail.com>
References: <ca471dc20711021708s7125932ka699abb759e262dd@mail.gmail.com>
	<bbaeab100711031627j2d64f6f2wf0e4166f25624e1c@mail.gmail.com>
	<bbaeab100711040022y293ffd8en7bab65e9ac4ae45f@mail.gmail.com>
Message-ID: <ca471dc20711051039n53b8def8m4754ed2e2b25e020@mail.gmail.com>

On 11/3/07, Brett Cannon <brett at python.org> wrote:
> > test_bsddb3
>
> The big failure spewing out all of this stuff about an assert in
> getGenre() failing is because the code in
> Modules/_bsddb.c:_db_associateCallback() uses "y#' to build an
> argument tuple when the test expects a bytes type and not a buffer
> type.  Now I searched in Python/modsupport.c and there is not a single
> PyString_*() call in there.  What format string are we supposed to use
> for PyString/bytes instances?  Should we change 'y' from
> PyBytes/buffer to PyString/bytes, or add yet another format string?

I think we should change 'y' and 'y#' to use PyString. This seems to
fix most of test_bsddb3; I'll have to check how much else it breaks
before I check it in.

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

From greg.ewing at canterbury.ac.nz  Mon Nov  5 22:27:40 2007
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Tue, 06 Nov 2007 10:27:40 +1300
Subject: [Python-3000] need help fixing broken tests in
	py3k-pep3137	branch
In-Reply-To: <5d44f72f0711031818t4bcb2e3l432e6cc243c943ba@mail.gmail.com>
References: <ca471dc20711021708s7125932ka699abb759e262dd@mail.gmail.com>
	<79990c6b0711030637w3ff762ddtae1613d6673efa20@mail.gmail.com>
	<472C7C59.4000602@cheimes.de>
	<79990c6b0711030723v6f611f93w2fdf2bc732912e45@mail.gmail.com>
	<ca471dc20711030825x56be102bv7f50cc2a6ca74d30@mail.gmail.com>
	<472CEA22.508@canterbury.ac.nz>
	<ca471dc20711031548q3afdaeag2353115d79e797ce@mail.gmail.com>
	<fb6fbf560711031651m66812d0cjce74be84b5a871e@mail.gmail.com>
	<ca471dc20711031700q5b0ef237xc828567bcf4b8cb@mail.gmail.com>
	<472D1C3B.8000107@gmail.com>
	<5d44f72f0711031818t4bcb2e3l432e6cc243c943ba@mail.gmail.com>
Message-ID: <472F8ACC.7060704@canterbury.ac.nz>

Jeffrey Yasskin wrote:
> It's a list of
> 'byte's rather than a list of 'bytes'es.

Except maybe in Gollum's version of Python.

--
Greg

From guido at python.org  Tue Nov  6 02:35:57 2007
From: guido at python.org (Guido van Rossum)
Date: Mon, 5 Nov 2007 17:35:57 -0800
Subject: [Python-3000] need help fixing broken tests in py3k-pep3137
	branch
In-Reply-To: <472F51DB.8060204@cheimes.de>
References: <ca471dc20711021708s7125932ka699abb759e262dd@mail.gmail.com>
	<472F51DB.8060204@cheimes.de>
Message-ID: <ca471dc20711051735q4b74edc7u7d7564aab94ed34c@mail.gmail.com>

On 11/5/07, Christian Heimes <lists at cheimes.de> wrote:
> Guido van Rossum wrote:
> > In the py3k-pep3137 branch I've been working on the implementation of PEP 3137.
> > The work is largely done, but I'm stuck with about 20 failing tests,
> > and very little time this weekend to work on these. Here's the list:
>
> Here is an updated list. 4 unit tests are failing on Linux and 7
> (sometimes 8) are failing on Windows:
>
> test_mailbox
> test_old_mailbox

These are the last two failing tests on Linux.

> test_pickle
> test_sqlite

I fixed these today.

> Windows only:
> test_csv
> test_import (fix available at http://bugs.python.org/issue1293)
> test_inspect (only on some occasions, http://bugs.python.org/issue1384)

I'll leave these to Christian.

> test_netrc

Amaury Forgeot d'Arc figured out the cause, it's issue 1395. Patch
would be appreciated.

> One test is leaking reference:
> test_struct (http://bugs.python.org/issue1389)

I spent the better part of today tracking this down; embarrassingly,
it wasn't a real leak, it was slowly filling the cache for (byte)
strings of length 1 based on random input. Maybe regrtest.py should
warm up that cache when -R is used. I found that lots of places can
return a 1-char string that isn't cached, by the way.

> Other open issues:
> * pdb has problems with the "with" statement
> http://bugs.python.org/issue1265

Help!!

> * On Windows Python doesn't start if the path to Python contains non
> ASCII chars. Python can't load modules from paths with non ASCII chars,
> too. http://bugs.python.org/issue1342

Low priority IMO.

> * I like to change str(buffer()) and str(bytes()) to return the
> bytes/buffer decoded with "ascii" instead of returning the
> representation of the bytes/buffer. http://bugs.python.org/issue1392

I rejected that, but am accepting the idea of a command line flag that
causes these calls to issue a warning or error (and ditto for
comparing between str() and bytes()/buffer()).

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

From guido at python.org  Tue Nov  6 06:22:01 2007
From: guido at python.org (Guido van Rossum)
Date: Mon, 5 Nov 2007 21:22:01 -0800
Subject: [Python-3000] need help fixing broken tests in py3k-pep3137
	branch
In-Reply-To: <ca471dc20711051735q4b74edc7u7d7564aab94ed34c@mail.gmail.com>
References: <ca471dc20711021708s7125932ka699abb759e262dd@mail.gmail.com>
	<472F51DB.8060204@cheimes.de>
	<ca471dc20711051735q4b74edc7u7d7564aab94ed34c@mail.gmail.com>
Message-ID: <ca471dc20711052122r7912cf84wa6b553ad62f29a68@mail.gmail.com>

Tests still failing on OSX (besides test_*mailbox, which are failing
everywhere):

test_aepack
test_plistlib
test_scriptpackages

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

From lists at cheimes.de  Tue Nov  6 13:05:13 2007
From: lists at cheimes.de (Christian Heimes)
Date: Tue, 06 Nov 2007 13:05:13 +0100
Subject: [Python-3000] need help fixing broken tests in py3k-pep3137
	branch
In-Reply-To: <ca471dc20711051735q4b74edc7u7d7564aab94ed34c@mail.gmail.com>
References: <ca471dc20711021708s7125932ka699abb759e262dd@mail.gmail.com>	<472F51DB.8060204@cheimes.de>
	<ca471dc20711051735q4b74edc7u7d7564aab94ed34c@mail.gmail.com>
Message-ID: <47305879.5010403@cheimes.de>

Guido van Rossum wrote:
>> test_mailbox
>> test_old_mailbox
> 
> These are the last two failing tests on Linux.

I've a patch that fixes most of the problems in test_mailbox and
test_old_mailbox but I'm unsure about it. It changes get_file() to read
the file in text mode instead of binary mode.
http://bugs.python.org/issue1396

>> Windows only:
>> test_csv
>> test_import (fix available at http://bugs.python.org/issue1293)

I like somebody to review my patch. Brett seems to be too busy to have a
look. It's changing the NullImporter initializer to strip off trailing /
and \ before it applies stat to the path. On Windows stat(c:\\path\\)
yields an error but stat(c:\\path) passes.

>> test_inspect (only on some occasions, http://bugs.python.org/issue1384)

Fixed

> I rejected that, but am accepting the idea of a command line flag that
> causes these calls to issue a warning or error (and ditto for
> comparing between str() and bytes()/buffer()).

Applied
I've altered some tests to filter out the warnings. The test suite
passes even with ./python -bb Lib/test/regrtest.py. Should I make python
-bb the default for make test and rt.bat?

Christian



From guido at python.org  Tue Nov  6 21:15:59 2007
From: guido at python.org (Guido van Rossum)
Date: Tue, 6 Nov 2007 12:15:59 -0800
Subject: [Python-3000] Leaks in py3k-pep3137 branch
Message-ID: <ca471dc20711061215m10b65717t9f341006e5ec006e@mail.gmail.com>

Three tests fail when run with "regrtest.py -R::"

test_frozen
beginning 9 repetitions
123456789
test test_frozen failed -- Traceback (most recent call last):
  File "/usr/local/google/home/guido/python/py3kd/Lib/test/test_frozen.py",
line 36, in test_frozen
    'Hello world...\nHello world...\nHello world...\n')
AssertionError: '' != 'Hello world...\nHello world...\nHello world...\n'

test_pkg
beginning 9 repetitions
123456789
test test_pkg failed -- errors occurred; run in verbose mode for details
test_tcl
beginning 9 repetitions
123456789
test test_tcl failed -- Traceback (most recent call last):
  File "/usr/local/google/home/guido/python/py3kd/Lib/test/test_tcl.py",
line 125, in testLoadTk
    tcl.loadtk()
  File "/usr/local/google/home/guido/python/py3kd/Lib/lib-tk/Tkinter.py",
line 1641, in loadtk
    self.tk.loadtk()
_tkinter.TclError: Calling Tk_Init again after a previous call failed
might deadlock

3 tests failed:
    test_frozen test_pkg test_tcl
[86614 refs]


Three tests (or the set run by default on Linux) have leaks:

test_ctypes
beginning 9 repetitions
123456789
.........
test_pipes
beginning 9 repetitions
123456789
.........
test_pipes leaked [0, 0, 0, 33] references, sum=33
test_sqlite
beginning 9 repetitions
123456789
.........
test_sqlite leaked [325, 325, 325, 325] references, sum=1300
test_urllib2_localnet
beginning 9 repetitions
123456789
.........
test_urllib2_localnet leaked [3, 3, 3, -7] references, sum=2
All 3 tests OK.
[122668 refs]


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

From guido at python.org  Tue Nov  6 21:54:36 2007
From: guido at python.org (Guido van Rossum)
Date: Tue, 6 Nov 2007 12:54:36 -0800
Subject: [Python-3000] Leaks in py3k-pep3137 branch
In-Reply-To: <ca471dc20711061215m10b65717t9f341006e5ec006e@mail.gmail.com>
References: <ca471dc20711061215m10b65717t9f341006e5ec006e@mail.gmail.com>
Message-ID: <ca471dc20711061254u23d6f1e9lf5edf0f3ea5c1e77@mail.gmail.com>

Additional leaks found in tests only run with -uall:

test_bsddb3 leaked [65, 65, 65, 65] references, sum=260


On 11/6/07, Guido van Rossum <guido at python.org> wrote:
> Three tests fail when run with "regrtest.py -R::"
>
> test_frozen
> beginning 9 repetitions
> 123456789
> test test_frozen failed -- Traceback (most recent call last):
>   File "/usr/local/google/home/guido/python/py3kd/Lib/test/test_frozen.py",
> line 36, in test_frozen
>     'Hello world...\nHello world...\nHello world...\n')
> AssertionError: '' != 'Hello world...\nHello world...\nHello world...\n'
>
> test_pkg
> beginning 9 repetitions
> 123456789
> test test_pkg failed -- errors occurred; run in verbose mode for details
> test_tcl
> beginning 9 repetitions
> 123456789
> test test_tcl failed -- Traceback (most recent call last):
>   File "/usr/local/google/home/guido/python/py3kd/Lib/test/test_tcl.py",
> line 125, in testLoadTk
>     tcl.loadtk()
>   File "/usr/local/google/home/guido/python/py3kd/Lib/lib-tk/Tkinter.py",
> line 1641, in loadtk
>     self.tk.loadtk()
> _tkinter.TclError: Calling Tk_Init again after a previous call failed
> might deadlock
>
> 3 tests failed:
>     test_frozen test_pkg test_tcl
> [86614 refs]
>
>
> Three tests (or the set run by default on Linux) have leaks:
>
> test_ctypes
> beginning 9 repetitions
> 123456789
> .........
> test_pipes
> beginning 9 repetitions
> 123456789
> .........
> test_pipes leaked [0, 0, 0, 33] references, sum=33
> test_sqlite
> beginning 9 repetitions
> 123456789
> .........
> test_sqlite leaked [325, 325, 325, 325] references, sum=1300
> test_urllib2_localnet
> beginning 9 repetitions
> 123456789
> .........
> test_urllib2_localnet leaked [3, 3, 3, -7] references, sum=2
> All 3 tests OK.
> [122668 refs]
>
>
> --
> --Guido van Rossum (home page: http://www.python.org/~guido/)
>


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

From guido at python.org  Tue Nov  6 22:06:37 2007
From: guido at python.org (Guido van Rossum)
Date: Tue, 6 Nov 2007 13:06:37 -0800
Subject: [Python-3000] About to merge the py3k-pep3137 branch back into the
	py3k branch
Message-ID: <ca471dc20711061306u1dd8cad5t448ef78a29ba088e@mail.gmail.com>

I'm going to merge the PEP 3137 branch back into Py3k, now that I've
got zero failing tests on Linux and OSX. Please no more checkins to
the py3k branch until I give the green light!

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

From guido at python.org  Tue Nov  6 22:17:19 2007
From: guido at python.org (Guido van Rossum)
Date: Tue, 6 Nov 2007 13:17:19 -0800
Subject: [Python-3000] About to merge the py3k-pep3137 branch back into
	the py3k branch
In-Reply-To: <ca471dc20711061306u1dd8cad5t448ef78a29ba088e@mail.gmail.com>
References: <ca471dc20711061306u1dd8cad5t448ef78a29ba088e@mail.gmail.com>
Message-ID: <ca471dc20711061317y5025a87fwa2e6c35327f56632@mail.gmail.com>

And no checkins to the py3k-pep3137  branch either please!

On 11/6/07, Guido van Rossum <guido at python.org> wrote:
> I'm going to merge the PEP 3137 branch back into Py3k, now that I've
> got zero failing tests on Linux and OSX. Please no more checkins to
> the py3k branch until I give the green light!

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

From guido at python.org  Tue Nov  6 22:39:51 2007
From: guido at python.org (Guido van Rossum)
Date: Tue, 6 Nov 2007 13:39:51 -0800
Subject: [Python-3000] About to merge the py3k-pep3137 branch back into
	the py3k branch
In-Reply-To: <ca471dc20711061317y5025a87fwa2e6c35327f56632@mail.gmail.com>
References: <ca471dc20711061306u1dd8cad5t448ef78a29ba088e@mail.gmail.com>
	<ca471dc20711061317y5025a87fwa2e6c35327f56632@mail.gmail.com>
Message-ID: <ca471dc20711061339h79f66023p9d150b2e91a1d5fc@mail.gmail.com>

All done. The py3k-pep3137 branch is no more. See you all in the py3k branch!

On 11/6/07, Guido van Rossum <guido at python.org> wrote:
> And no checkins to the py3k-pep3137  branch either please!
>
> On 11/6/07, Guido van Rossum <guido at python.org> wrote:
> > I'm going to merge the PEP 3137 branch back into Py3k, now that I've
> > got zero failing tests on Linux and OSX. Please no more checkins to
> > the py3k branch until I give the green light!

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

From wojtek.gminick.walczak at gmail.com  Wed Nov  7 13:59:35 2007
From: wojtek.gminick.walczak at gmail.com (Wojciech Walczak)
Date: Wed, 7 Nov 2007 13:59:35 +0100
Subject: [Python-3000] print() flushing problem.
Message-ID: <2c3c21060711070459s1c1c398y7dae60cc1256ad74@mail.gmail.com>

Hello,

py3k's print() is not flushing when end is set to '' and all it has to
print is one-character-long string:

Python 3.0a1 (py3k, Nov  6 2007, 19:25:33)
[GCC 4.1.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> print('x',end='')
>>> print('')
x
>>> print('',end='x')
>>> print('')
x
>>>


It works OK, when string is longer than 1:
>>> print('xx',end='')
xx>>>
>>> print('',end='xx')
xx>>>

When end is not set at all, it is flushing allright, because print()
prints '\n' at the end:
>>> print('x')
x
>>>

What's even stranger - it's sensitive for spaces (or it's just coincidence)
in the strings:
>>> ret=[print(i,end='') for i in list('print is not flushing')]
print is not flushin>>>
>>> print()
g
>>>ret=[print(i,end='') for i in list('printisnotflushing')]
printisnotflushing>>>

>>> for i in list('print is not flushing'):
...    print(i,end='')
...
print is not flushin[3.0a1]>>> print()
g
>>> for i in list('printisnotflushing'):
...    print(i,end='')
...
printisnotflushing>>>


My proposition of patch is in the attachment, but I think that the
problem lies somewhere deeper.


I was testing both bug and patch on Slack 12 and Debian Etch.


Wojtek Walczak
-------------- next part --------------
A non-text attachment was scrubbed...
Name: py3k-print.patch
Type: application/octet-stream
Size: 805 bytes
Desc: not available
Url : http://mail.python.org/pipermail/python-3000/attachments/20071107/43c5b408/attachment.obj 

From lists at cheimes.de  Wed Nov  7 14:51:43 2007
From: lists at cheimes.de (Christian Heimes)
Date: Wed, 07 Nov 2007 14:51:43 +0100
Subject: [Python-3000] print() flushing problem.
In-Reply-To: <2c3c21060711070459s1c1c398y7dae60cc1256ad74@mail.gmail.com>
References: <2c3c21060711070459s1c1c398y7dae60cc1256ad74@mail.gmail.com>
Message-ID: <fgsftg$nru$1@ger.gmane.org>

Wojciech Walczak wrote:
> Hello,
> 
> py3k's print() is not flushing when end is set to '' and all it has to
> print is one-character-long string:

Good catch! I tried to reproduce the debug in a unit test but it's not
easy. Your patch was a good head start but I didn't like the fact that
it was calling flush() when end is set. It should only call flush when
end is an empty string.

Comments?

	if (end == NULL || end == Py_None) {
		err = PyFile_WriteString("\n", file);
	}
	/* case: end='', the existence of stdout.flush is not mandatory. */
	else if (*PyUnicode_AsString(end) == '\0') {
		tmp = PyObject_CallMethod(file, "flush", "");
		if (tmp == NULL)
			PyErr_Clear();
		else
			Py_DECREF(tmp);
	}
	else {
		err = PyFile_WriteObject(end, file, Py_PRINT_RAW);
	}

Christian


From wojtek.gminick.walczak at gmail.com  Wed Nov  7 15:05:01 2007
From: wojtek.gminick.walczak at gmail.com (Wojciech Walczak)
Date: Wed, 7 Nov 2007 15:05:01 +0100
Subject: [Python-3000] print() flushing problem.
In-Reply-To: <fgsftg$nru$1@ger.gmane.org>
References: <2c3c21060711070459s1c1c398y7dae60cc1256ad74@mail.gmail.com>
	<fgsftg$nru$1@ger.gmane.org>
Message-ID: <2c3c21060711070605o71bcff20xf50a01f98baafcbd@mail.gmail.com>

2007/11/7, Christian Heimes <lists at cheimes.de>:
> Wojciech Walczak wrote:
> > Hello,
> >
> > py3k's print() is not flushing when end is set to '' and all it has to
> > print is one-character-long string:
>
> Good catch! I tried to reproduce the debug in a unit test but it's not
> easy. Your patch was a good head start but I didn't like the fact that
> it was calling flush() when end is set. It should only call flush when
> end is an empty string.
>
> Comments?
>
>         if (end == NULL || end == Py_None) {
>                 err = PyFile_WriteString("\n", file);
>         }
>         /* case: end='', the existence of stdout.flush is not mandatory. */
>         else if (*PyUnicode_AsString(end) == '\0') {
>                 tmp = PyObject_CallMethod(file, "flush", "");
>                 if (tmp == NULL)
>                         PyErr_Clear();
>                 else
>                         Py_DECREF(tmp);
>         }
>         else {
>                 err = PyFile_WriteObject(end, file, Py_PRINT_RAW);
>         }

I was trying that way too, but it won't work in that particular case:

>>> print('x',end='')
x>>> print('',end='x')
>>> print()
x
>>>


Wojtek Walczak

From wojtek.gminick.walczak at gmail.com  Wed Nov  7 15:09:09 2007
From: wojtek.gminick.walczak at gmail.com (Wojciech Walczak)
Date: Wed, 7 Nov 2007 15:09:09 +0100
Subject: [Python-3000] print() flushing problem.
In-Reply-To: <e27efe130711070557p176204e8m71a9f1ba2da48fdd@mail.gmail.com>
References: <2c3c21060711070459s1c1c398y7dae60cc1256ad74@mail.gmail.com>
	<e27efe130711070557p176204e8m71a9f1ba2da48fdd@mail.gmail.com>
Message-ID: <2c3c21060711070609p19252790jabf98e6360401b07@mail.gmail.com>

2007/11/7, Amaury Forgeot d'Arc <amauryfa at gmail.com>:

> > >>> for i in list('print is not flushing'):
> > ...    print(i,end='')
> > ...
> > print is not flushin[3.0a1]>>> print()
> > g
> > >>> for i in list('printisnotflushing'):
> > ...    print(i,end='')
> > ...
> > printisnotflushing>>>
>
> I don't like this [3.0a1] in the output. Does someone know where it
> can come from? (yes, PY_VERSION, but the brakets?)

Sorry, it is just copy-paste mistake. It's my hack of python. I am
running a few interpreters at the same time and I like to know, which
is which. Thus my interpreter prints '[3.0a1]>>>' and '[3.0a1]...'
instead of '>>>' and '...'.



Wojciech Walczak

From daniel at stutzbachenterprises.com  Wed Nov  7 15:10:51 2007
From: daniel at stutzbachenterprises.com (Daniel Stutzbach)
Date: Wed, 7 Nov 2007 08:10:51 -0600
Subject: [Python-3000] print() flushing problem.
In-Reply-To: <2c3c21060711070459s1c1c398y7dae60cc1256ad74@mail.gmail.com>
References: <2c3c21060711070459s1c1c398y7dae60cc1256ad74@mail.gmail.com>
Message-ID: <eae285400711070610h74f5546er2954db07e84360c1@mail.gmail.com>

On Nov 7, 2007 6:59 AM, Wojciech Walczak
<wojtek.gminick.walczak at gmail.com> wrote:
> py3k's print() is not flushing when end is set to '' and all it has to
> print is one-character-long string:

print() shouldn't flush if there isn't a newline, unless the buffer is
full or the user calls flush().  However, in an interactive
interpreter in pre-3.0, Python will automatically add a newline.  Try
this in 2.5:

---------------------------------------
import time
print 'foo',
time.sleep(10)
print
---------------------------------------

You'll see that "foo" appears *after* 10 seconds, not before.
However, in an interactive interpreter, Python will add a newline
after 'foo' ever with the comma there, and the newline causes a flush.
 Observe (2.5):

>>> print 'foo',
foo
>>> print 'foo'
foo
>>>

The same number of newlines are created with the comma and without,
which is different than the script behavior.

It sounds like P3K isn't doing this.

The patch you suggest would cause a flush after *every* write with
print, which would cause a very significant performance hit on
programs that do a lot of writing to standard output (especially if
standard output is a pipe).

Tangent: If standard output is a pipe and not a tty, is P3K smart
enough to switch to fully-buffered mode instead of line-buffered mode?

-- 
Daniel Stutzbach, Ph.D.             President, Stutzbach Enterprises LLC

From guido at python.org  Wed Nov  7 16:32:37 2007
From: guido at python.org (Guido van Rossum)
Date: Wed, 7 Nov 2007 07:32:37 -0800
Subject: [Python-3000] print() flushing problem.
In-Reply-To: <eae285400711070610h74f5546er2954db07e84360c1@mail.gmail.com>
References: <2c3c21060711070459s1c1c398y7dae60cc1256ad74@mail.gmail.com>
	<eae285400711070610h74f5546er2954db07e84360c1@mail.gmail.com>
Message-ID: <ca471dc20711070732i306a3616ia8fbfbaf4f117961@mail.gmail.com>

On Nov 7, 2007 6:10 AM, Daniel Stutzbach
<daniel at stutzbachenterprises.com> wrote:
> On Nov 7, 2007 6:59 AM, Wojciech Walczak
> <wojtek.gminick.walczak at gmail.com> wrote:
> > py3k's print() is not flushing when end is set to '' and all it has to
> > print is one-character-long string:

print() should never flush. The stream can be set to flush when a
newline is seen (set buffer size to 1) though there may currently be
some bugs in that code. Interactive mode should flush before printing
the >>>prompt.

> print() shouldn't flush if there isn't a newline, unless the buffer is
> full or the user calls flush().  However, in an interactive
> interpreter in pre-3.0, Python will automatically add a newline.  Try
> this in 2.5:
>
> ---------------------------------------
> import time
> print 'foo',
> time.sleep(10)
> print
> ---------------------------------------
>
> You'll see that "foo" appears *after* 10 seconds, not before.
> However, in an interactive interpreter, Python will add a newline
> after 'foo' ever with the comma there, and the newline causes a flush.
>  Observe (2.5):
>
> >>> print 'foo',
> foo
> >>> print 'foo'
> foo
> >>>
>
> The same number of newlines are created with the comma and without,
> which is different than the script behavior.

Right. This is because 2.x doesn't only flush, it also adds a newline
when the last character written wasn't a newline.

> It sounds like P3K isn't doing this.

That's because it doesn't have the 'softspace' feature used by 2.x to
implement the automatic appending of a newline as needed. The
softspace feature was intentionally removed because it is a royal pain
to deal with.

Adding the flush back to interactive mode should be easy (flush both
stdout and stderr). Adding the auto-newline back is not; I'm not
convinced that it is necessary to do so since it'll be pretty rare and
usually the user is asking for trouble.

> The patch you suggest would cause a flush after *every* write with
> print, which would cause a very significant performance hit on
> programs that do a lot of writing to standard output (especially if
> standard output is a pipe).

Right, don't do that!

> Tangent: If standard output is a pipe and not a tty, is P3K smart
> enough to switch to fully-buffered mode instead of line-buffered mode?

It checks isatty() when the buffer size is not given explicitly, so it
should be. Worth testing though.

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

From wojtek.gminick.walczak at gmail.com  Wed Nov  7 17:45:42 2007
From: wojtek.gminick.walczak at gmail.com (Wojciech Walczak)
Date: Wed, 7 Nov 2007 17:45:42 +0100
Subject: [Python-3000] print() flushing problem.
In-Reply-To: <eae285400711070610h74f5546er2954db07e84360c1@mail.gmail.com>
References: <2c3c21060711070459s1c1c398y7dae60cc1256ad74@mail.gmail.com>
	<eae285400711070610h74f5546er2954db07e84360c1@mail.gmail.com>
Message-ID: <2c3c21060711070845i58a2d1abq89b6049bea959bcc@mail.gmail.com>

2007/11/7, Daniel Stutzbach <daniel at stutzbachenterprises.com>:

> print() shouldn't flush if there isn't a newline, unless the buffer is
> full or the user calls flush().

So the buffer size in py3k is 1 byte long? Try this as a script in py3k:

-----------------
import time

print('xx',end='')
time.sleep(3)
print('x',end='')
time.sleep(3)
-----------------

First print() will flush immediately even though there is no newline
and flush is not called, while second print() will flush after second
sleep.
What I am saying is that print() is not flushing immediately when
string is 1 byte long, but when it is longer - then print() is
flushing immediately. It works that way both for interpreter and
scripts.

> The patch you suggest would cause a flush after *every* write with
> print, which would cause a very significant performance hit on
> programs that do a lot of writing to standard output (especially if
> standard output is a pipe).

No, it is calling flush only when the 'end' in print() is set.
Otherwise (end==NULL or end==Py_None) it just prints newline as it was
doing before. Anyway - I agree that it is a hit for performance and as
I said before, I think that the problem lies somewhere deeper. Any
clues?


Wojciech Walczak

From guido at python.org  Wed Nov  7 18:17:38 2007
From: guido at python.org (Guido van Rossum)
Date: Wed, 7 Nov 2007 09:17:38 -0800
Subject: [Python-3000] print() flushing problem.
In-Reply-To: <2c3c21060711070845i58a2d1abq89b6049bea959bcc@mail.gmail.com>
References: <2c3c21060711070459s1c1c398y7dae60cc1256ad74@mail.gmail.com>
	<eae285400711070610h74f5546er2954db07e84360c1@mail.gmail.com>
	<2c3c21060711070845i58a2d1abq89b6049bea959bcc@mail.gmail.com>
Message-ID: <ca471dc20711070917m1994a951x7cf35ead0431e6de@mail.gmail.com>

There's clearly a bug somewhere, maybe several. Can you file a bug
report at bugs.python.org, clearly stating the expected behavior and
the observed behavior, preferably with sample code? Studying the
source code and providing a patch would be much appreciated as well!

On 11/7/07, Wojciech Walczak <wojtek.gminick.walczak at gmail.com> wrote:
> 2007/11/7, Daniel Stutzbach <daniel at stutzbachenterprises.com>:
>
> > print() shouldn't flush if there isn't a newline, unless the buffer is
> > full or the user calls flush().
>
> So the buffer size in py3k is 1 byte long? Try this as a script in py3k:
>
> -----------------
> import time
>
> print('xx',end='')
> time.sleep(3)
> print('x',end='')
> time.sleep(3)
> -----------------
>
> First print() will flush immediately even though there is no newline
> and flush is not called, while second print() will flush after second
> sleep.
> What I am saying is that print() is not flushing immediately when
> string is 1 byte long, but when it is longer - then print() is
> flushing immediately. It works that way both for interpreter and
> scripts.
>
> > The patch you suggest would cause a flush after *every* write with
> > print, which would cause a very significant performance hit on
> > programs that do a lot of writing to standard output (especially if
> > standard output is a pipe).
>
> No, it is calling flush only when the 'end' in print() is set.
> Otherwise (end==NULL or end==Py_None) it just prints newline as it was
> doing before. Anyway - I agree that it is a hit for performance and as
> I said before, I think that the problem lies somewhere deeper. Any
> clues?
>
>
> Wojciech Walczak
> _______________________________________________
> 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 wojtek.gminick.walczak at gmail.com  Thu Nov  8 19:16:01 2007
From: wojtek.gminick.walczak at gmail.com (Wojciech Walczak)
Date: Thu, 8 Nov 2007 19:16:01 +0100
Subject: [Python-3000] print() flushing problem.
In-Reply-To: <ca471dc20711070917m1994a951x7cf35ead0431e6de@mail.gmail.com>
References: <2c3c21060711070459s1c1c398y7dae60cc1256ad74@mail.gmail.com>
	<eae285400711070610h74f5546er2954db07e84360c1@mail.gmail.com>
	<2c3c21060711070845i58a2d1abq89b6049bea959bcc@mail.gmail.com>
	<ca471dc20711070917m1994a951x7cf35ead0431e6de@mail.gmail.com>
Message-ID: <2c3c21060711081016m190de56dl14cd5773c2bc8683@mail.gmail.com>

2007/11/7, Guido van Rossum <guido at python.org>:
> There's clearly a bug somewhere, maybe several. Can you file a bug
> report at bugs.python.org, clearly stating the expected behavior and
> the observed behavior, preferably with sample code? Studying the
> source code and providing a patch would be much appreciated as well!

Got it! Please, take a look at my patch. It's in the attachment. I am
still digging in the source, but I think that I have found the core of
the bug.
Without that patch "ret=sys.stdout.write('x')" acts in the same way as
print('x',end=''), which is - it prints nothing. After applying the
patch it is allright for both sys.stdout.write() and for print().

Wojtek Walczak
-------------- next part --------------
A non-text attachment was scrubbed...
Name: py3k-print.patch
Type: application/octet-stream
Size: 1216 bytes
Desc: not available
Url : http://mail.python.org/pipermail/python-3000/attachments/20071108/e0baa715/attachment.obj 

From wojtek.gminick.walczak at gmail.com  Thu Nov  8 19:41:25 2007
From: wojtek.gminick.walczak at gmail.com (Wojciech Walczak)
Date: Thu, 8 Nov 2007 19:41:25 +0100
Subject: [Python-3000] print() flushing problem.
In-Reply-To: <2c3c21060711081016m190de56dl14cd5773c2bc8683@mail.gmail.com>
References: <2c3c21060711070459s1c1c398y7dae60cc1256ad74@mail.gmail.com>
	<eae285400711070610h74f5546er2954db07e84360c1@mail.gmail.com>
	<2c3c21060711070845i58a2d1abq89b6049bea959bcc@mail.gmail.com>
	<ca471dc20711070917m1994a951x7cf35ead0431e6de@mail.gmail.com>
	<2c3c21060711081016m190de56dl14cd5773c2bc8683@mail.gmail.com>
Message-ID: <2c3c21060711081041q38b1aad0oc043f32d0294721f@mail.gmail.com>

> Got it! Please, take a look at my patch. It's in the attachment. I am
> still digging in the source, but I think that I have found the core of
> the bug.
> Without that patch "ret=sys.stdout.write('x')" acts in the same way as
> print('x',end=''), which is - it prints nothing. After applying the
> patch it is allright for both sys.stdout.write() and for print().


The other question is why is self.buffer_size set to 1. But I am
leaving it for tomorrow. Now, a few words about performance. For
debugging reasons I have added a simple line to PyObject_Call()
function in Objects/abstract.c:
printf("%s.%s\n", func->ob_type->tp_name, PyEval_GetFuncName(func));
Now, after compiling python and running interpreter with simple
print() call I receive this:

>>> print('!',end='')
builtin_function_or_method.print
method.write
function.write
function.closed
function.closed
builtin_function_or_method.ascii_encode
function.closed
function.closed
!method.write   # here it goes again for 'end' parameter
function.write
function.closed
function.closed
builtin_function_or_method.ascii_encode
function.closed
builtin_function_or_method.displayhook
>>>

Isn't it checking if stream is closed a bit too often?

Wojtek Walczak

From lists at cheimes.de  Thu Nov  8 20:19:03 2007
From: lists at cheimes.de (Christian Heimes)
Date: Thu, 08 Nov 2007 20:19:03 +0100
Subject: [Python-3000] print() flushing problem.
In-Reply-To: <2c3c21060711081041q38b1aad0oc043f32d0294721f@mail.gmail.com>
References: <2c3c21060711070459s1c1c398y7dae60cc1256ad74@mail.gmail.com>	<eae285400711070610h74f5546er2954db07e84360c1@mail.gmail.com>	<2c3c21060711070845i58a2d1abq89b6049bea959bcc@mail.gmail.com>	<ca471dc20711070917m1994a951x7cf35ead0431e6de@mail.gmail.com>	<2c3c21060711081016m190de56dl14cd5773c2bc8683@mail.gmail.com>
	<2c3c21060711081041q38b1aad0oc043f32d0294721f@mail.gmail.com>
Message-ID: <fgvnf9$2e3$1@ger.gmane.org>

Wojciech Walczak wrote:
> Isn't it checking if stream is closed a bit too often?

You are right. The io system of Python 3000 needs a lot of
optimizations. But speed isn't the main concern for the alpha releases.
It's more important that it works and we get enough debug information to
find problems. As soon as the API has been stabilized and matured we can
start optimizing Python 3.0.

Could you please file yet another bug about the closed calls? Thx :)

Christian


From luke.stebbing at gmail.com  Thu Nov  8 21:34:21 2007
From: luke.stebbing at gmail.com (Luke Stebbing)
Date: Thu, 8 Nov 2007 12:34:21 -0800
Subject: [Python-3000] print() flushing problem.
In-Reply-To: <2c3c21060711081016m190de56dl14cd5773c2bc8683@mail.gmail.com>
References: <2c3c21060711070459s1c1c398y7dae60cc1256ad74@mail.gmail.com>
	<eae285400711070610h74f5546er2954db07e84360c1@mail.gmail.com>
	<2c3c21060711070845i58a2d1abq89b6049bea959bcc@mail.gmail.com>
	<ca471dc20711070917m1994a951x7cf35ead0431e6de@mail.gmail.com>
	<2c3c21060711081016m190de56dl14cd5773c2bc8683@mail.gmail.com>
Message-ID: <dcb1979a0711081234u484cf7d6qa178e2ecf9fba0a8@mail.gmail.com>

On 11/8/07, Wojciech Walczak <wojtek.gminick.walczak at gmail.com> wrote:
> Got it! Please, take a look at my patch. It's in the attachment. I am
> still digging in the source, but I think that I have found the core of
> the bug.
> Without that patch "ret=sys.stdout.write('x')" acts in the same way as
> print('x',end=''), which is - it prints nothing. After applying the
> patch it is allright for both sys.stdout.write() and for print().

If the buffer size is 1, isn't that arguably the correct behavior,
i.e. don't flush until you have _more_ data than you can store?

Luke

From guido at python.org  Fri Nov  9 01:51:51 2007
From: guido at python.org (Guido van Rossum)
Date: Thu, 8 Nov 2007 16:51:51 -0800
Subject: [Python-3000] print() flushing problem.
In-Reply-To: <dcb1979a0711081234u484cf7d6qa178e2ecf9fba0a8@mail.gmail.com>
References: <2c3c21060711070459s1c1c398y7dae60cc1256ad74@mail.gmail.com>
	<eae285400711070610h74f5546er2954db07e84360c1@mail.gmail.com>
	<2c3c21060711070845i58a2d1abq89b6049bea959bcc@mail.gmail.com>
	<ca471dc20711070917m1994a951x7cf35ead0431e6de@mail.gmail.com>
	<2c3c21060711081016m190de56dl14cd5773c2bc8683@mail.gmail.com>
	<dcb1979a0711081234u484cf7d6qa178e2ecf9fba0a8@mail.gmail.com>
Message-ID: <ca471dc20711081651s5d0003b5yd6996923a32c544e@mail.gmail.com>

On Nov 8, 2007 12:34 PM, Luke Stebbing <luke.stebbing at gmail.com> wrote:
> On 11/8/07, Wojciech Walczak <wojtek.gminick.walczak at gmail.com> wrote:
> > Got it! Please, take a look at my patch. It's in the attachment. I am
> > still digging in the source, but I think that I have found the core of
> > the bug.
> > Without that patch "ret=sys.stdout.write('x')" acts in the same way as
> > print('x',end=''), which is - it prints nothing. After applying the
> > patch it is allright for both sys.stdout.write() and for print().
>
> If the buffer size is 1, isn't that arguably the correct behavior,
> i.e. don't flush until you have _more_ data than you can store?

Well, passing '1' as the buffer size to open() is supposed to set the
buffer size to the default value (typically 8K) *and* set a special
flag that forces a flush() whenever a line end is written. But this
isn't implemented; instead, it just flushes after each character...
(Which has the desired effect of not buffering interactive output, but
does it very inefficiently.)

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

From wojtek.gminick.walczak at gmail.com  Fri Nov  9 11:32:16 2007
From: wojtek.gminick.walczak at gmail.com (Wojciech Walczak)
Date: Fri, 9 Nov 2007 11:32:16 +0100
Subject: [Python-3000] print() flushing problem.
In-Reply-To: <ca471dc20711081651s5d0003b5yd6996923a32c544e@mail.gmail.com>
References: <2c3c21060711070459s1c1c398y7dae60cc1256ad74@mail.gmail.com>
	<eae285400711070610h74f5546er2954db07e84360c1@mail.gmail.com>
	<2c3c21060711070845i58a2d1abq89b6049bea959bcc@mail.gmail.com>
	<ca471dc20711070917m1994a951x7cf35ead0431e6de@mail.gmail.com>
	<2c3c21060711081016m190de56dl14cd5773c2bc8683@mail.gmail.com>
	<dcb1979a0711081234u484cf7d6qa178e2ecf9fba0a8@mail.gmail.com>
	<ca471dc20711081651s5d0003b5yd6996923a32c544e@mail.gmail.com>
Message-ID: <2c3c21060711090232h4917c25dh40bd7785aabb2327@mail.gmail.com>

2007/11/9, Guido van Rossum <guido at python.org>:

> Well, passing '1' as the buffer size to open() is supposed to set the
> buffer size to the default value (typically 8K)

OK, my new patch does that. At the momment it is buffering for
interactive mode as well as for scripts instead of buffering only for
the latter.

Python 3.0a1 (py3k, Nov  9 2007, 11:09:49)
[GCC 4.1.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> print('python is flushing when there\' a new line')
python is flushing when there' a new line
>>> print('python is not flushing when new line is gone',end='')
>>> print('')
python is not flushing when new line is gone
>>> ret=sys.stdout.write('python is not flushing when new line is gone')
>>> sys.stdout.flush()
python is not flushing when new line is gone>>><ENTER>
>>> ret=sys.stdout.write('python is flushing when there\s a new line\n')e
python is flushing when there\s a new line
>>>

But, is this really what we want to do? When I run that code:
-----------------------
#include <stdio.h>
#include <string.h>
int main(void)
{
   char *buf="write() is flushing!";
   char *buf2="x";
   write(1,buf,strlen(buf));
   sleep(3);
   write(1,buf2,strlen(buf2));
   sleep(3);
   // printf("printf() requires a new line to flush");
   return 0;
}
--------------------

each write() is writing before sleep() even though there's no flush().
Do we want to ask every programmer to flush everytime there's no new line?
If not, python should flush for every string > 0 bytes, than for
string > 1 byte.

> *and* set a special
> flag that forces a flush() whenever a line end is written. But this
> isn't implemented; instead, it just flushes after each character...

Isn't it rather flushing after each print() or write() call?


Wojtek Walczak
-------------- next part --------------
A non-text attachment was scrubbed...
Name: py3k-print_2nd.patch
Type: application/octet-stream
Size: 420 bytes
Desc: not available
Url : http://mail.python.org/pipermail/python-3000/attachments/20071109/ad557044/attachment.obj 

From lists at cheimes.de  Fri Nov  9 16:22:24 2007
From: lists at cheimes.de (Christian Heimes)
Date: Fri, 09 Nov 2007 16:22:24 +0100
Subject: [Python-3000] Leaks in py3k-pep3137 branch
In-Reply-To: <ca471dc20711061215m10b65717t9f341006e5ec006e@mail.gmail.com>
References: <ca471dc20711061215m10b65717t9f341006e5ec006e@mail.gmail.com>
Message-ID: <47347B30.9070900@cheimes.de>

Guido van Rossum wrote:
> Three tests fail when run with "regrtest.py -R::"
> 
> test_frozen
> test_pkg
> test_tcl

The three tests depend on behavior which isn't compatible with multiple
runs during a test session. The tests could be fixed when Python gains
are reliable way to unload modules and C extensions.


> test_ctypes

I've already talked to Thomas. He thinks it's not a reference leak.

$ ./python Lib/test/regrtest.py -R2:10 test_ctypes
[...]
test_ctypes leaked [9, 6, 2, 0, 0, 0, 0, 0, 0, 0] references, sum=17

$ ./python Lib/test/regrtest.py -R5:5 test_ctypes
[...]
test_ctypes leaked [0, 33, 0, 0, -33] references, sum=0

> test_pipes

test_pipes sometimes leaks 33 references on my system but usually it
recovers the 33 references in the next iteration.

$ ./python Lib/test/regrtest.py -R1:20 test_pipes
test_pipes
beginning 21 repetitions
123456789012345678901
.....................
test_pipes leaked [0, 0, 0, 0, 33, -33, 0, 0, 0, 0, 0, 0, 33, 0, -33, 0,
0, 33, -33, 0] references, sum=0

test_pipes leaked [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
33, -33, 0] references, sum=0

test_pipes leaked [0, 0, 0, 0, 0, 0, 0, 33, -33, 0, 0, 33, -33, 0, 0, 0,
0, 0, 0, 0] references, sum=0

test_pipes leaked [-33, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0] references, sum=-33

test_pipes leaked [0, 0, 0, 0, 0, 33, -33, 0, 0, 0, 0, 0, 0, 0, 33, -33,
0, 0, 0, 0] references, sum=0

> test_urllib2_localnet

The test is leaking WeakSets and references to a function _remove which
seems to be the nested function _remove of WeakSet.

0x82e3034 [1] set()
0x8661494 [1] <weakref.WeakSet object at 0x8661494>
0x884cf4c [1] (<weakref at 0x82e9c34; to 'WeakSet' at 0x86616c4>,)
0x8847a2c [1] <function _remove at 0x8847a2c>
0x82e9c34 [1] <weakref at 0x82e9c34; to 'WeakSet' at 0x86616c4>
0x8648e94 [1] {'_remove': <function _remove at 0x8847a2c>, 'data': set()}

From wojtek.gminick.walczak at gmail.com  Sun Nov 11 18:40:05 2007
From: wojtek.gminick.walczak at gmail.com (Wojciech Walczak)
Date: Sun, 11 Nov 2007 18:40:05 +0100
Subject: [Python-3000] print() flushing problem.
In-Reply-To: <ca471dc20711081651s5d0003b5yd6996923a32c544e@mail.gmail.com>
References: <2c3c21060711070459s1c1c398y7dae60cc1256ad74@mail.gmail.com>
	<eae285400711070610h74f5546er2954db07e84360c1@mail.gmail.com>
	<2c3c21060711070845i58a2d1abq89b6049bea959bcc@mail.gmail.com>
	<ca471dc20711070917m1994a951x7cf35ead0431e6de@mail.gmail.com>
	<2c3c21060711081016m190de56dl14cd5773c2bc8683@mail.gmail.com>
	<dcb1979a0711081234u484cf7d6qa178e2ecf9fba0a8@mail.gmail.com>
	<ca471dc20711081651s5d0003b5yd6996923a32c544e@mail.gmail.com>
Message-ID: <2c3c21060711110940k5e71e9e8pa11e848cac8be001@mail.gmail.com>

2007/11/9, Guido van Rossum <guido at python.org>:

> Well, passing '1' as the buffer size to open() is supposed to set the
> buffer size to the default value (typically 8K) *and* set a special
> flag that forces a flush() whenever a line end is written.

As for now I can't even imagine how to implement the latter in Lib/io.py.
If anyone would like to do that or give me some advice on how to do that - that
would be great.
Anyway, isn't it easier to set the buffer size in Lib/io.py to
DEFAULT_BUFFER_SIZE whenever open() is passing '1' as the buffer size?
I mean changing these lines in Lib/io.py's open():
---[Lib/io.py:145-146]---
if buffering < 0 and raw.isatty():
   buffering = 1
------
into:
------
if buffering < 0 and raw.isatty():
   buffering = DEFAULT_BUFFER_SIZE
-------
...and then we can implement flush() whenever a line end is written (I
mean that print()s end parameter is set and is not empty string) in
builtin_print(). Code below is not a proposition for a patch. It is
rather proof of concept ;-)
---[Python/bltinmodule.c:1225]---
	if (end == NULL || end == Py_None)
		err = PyFile_WriteString("\n", file);
	else {
		err = PyFile_WriteObject(end, file, Py_PRINT_RAW);
                                  if(PyObject_Length(end) > 0) {
		     if(Py_InteractiveFlag) {
                                              err =
PyFile_WriteString("\n", file);
		     }
		     else {
		         tmp = PyObject_CallMethod(file, "flush", "");
		         if (tmp == NULL)
			PyErr_Clear();
		         else
			Py_DECREF(tmp);
		     }
		 }
	}
------------

To make it work I had to change Python/pythonrun.c to make sure that
it sets Py_InteractiveFlag when python works in interactive mode. I
have added that line:

Py_InteractiveFlag = 1;

to PyRun_InteractiveLoopFlags(). I find it arguable if this is the
best place ;-)

Regards,
Wojtek Walczak

From wojtek.gminick.walczak at gmail.com  Mon Nov 12 08:04:03 2007
From: wojtek.gminick.walczak at gmail.com (Wojciech Walczak)
Date: Mon, 12 Nov 2007 08:04:03 +0100
Subject: [Python-3000] print() flushing problem.
In-Reply-To: <ca471dc20711111422o7d1446bej9a6e5b9c4c219425@mail.gmail.com>
References: <2c3c21060711070459s1c1c398y7dae60cc1256ad74@mail.gmail.com>
	<eae285400711070610h74f5546er2954db07e84360c1@mail.gmail.com>
	<2c3c21060711070845i58a2d1abq89b6049bea959bcc@mail.gmail.com>
	<ca471dc20711070917m1994a951x7cf35ead0431e6de@mail.gmail.com>
	<2c3c21060711081016m190de56dl14cd5773c2bc8683@mail.gmail.com>
	<dcb1979a0711081234u484cf7d6qa178e2ecf9fba0a8@mail.gmail.com>
	<ca471dc20711081651s5d0003b5yd6996923a32c544e@mail.gmail.com>
	<2c3c21060711110940k5e71e9e8pa11e848cac8be001@mail.gmail.com>
	<ca471dc20711111422o7d1446bej9a6e5b9c4c219425@mail.gmail.com>
Message-ID: <2c3c21060711112304x1d9a1e75n1dca9cc86ec1436c@mail.gmail.com>

2007/11/11, Guido van Rossum <guido at python.org>:
> Hi Wojtek,
>
> Unfortunately it looks like you just don't understand enough about all
> the issues involved to be able to make useful suggestion for fixing
> the problems you've uncovered. I don't say this with the intention to
> put you down; it just seems fair to let you know that it wouldn't be a
> good use of my time to try and explain the issue in more detail to
> you. I promise you that the issue will be solved, either by me or by
> someone else who knows this area well.

Thanks, now I can sleep peacefully ;)

> I appreciate your interest in Python and hope that you will continue
> to contribute your observations, and will eventually learn enough
> about some parts of Python that you can contribute working code!

Sure I will. It's been more than two years that I haven't been programming
at all. I started again about a week ago and as for now I find new
python's IO handling a bit too complicated. Hope it is just me ;)

Wojtek

From janssen at parc.com  Wed Nov 14 04:05:59 2007
From: janssen at parc.com (Bill Janssen)
Date: Tue, 13 Nov 2007 19:05:59 PST
Subject: [Python-3000] socket GC worries
In-Reply-To: <07Oct30.114923pst."57996"@synergy1.parc.xerox.com> 
References: <07Oct28.111004pst.57996@synergy1.parc.xerox.com>
	<472505A7.108@canterbury.ac.nz> <6186646035112263762@unknownmsgid>
	<ca471dc20710291145w35180095x4893e58560bc1eb7@mail.gmail.com>
	<-5143302779702104898@unknownmsgid>
	<ca471dc20710291332m67019b74kb5d1205b880e790a@mail.gmail.com>
	<07Oct30.093737pst."57996"@synergy1.parc.xerox.com>
	<07Oct30.114923pst."57996"@synergy1.parc.xerox.com>
Message-ID: <07Nov13.190608pst."57996"@synergy1.parc.xerox.com>

> > But if we remove SocketCloser, there's no need for the cyclic GC to be
> > involved.  If the count (of the number of outstanding SocketIO
> > instances pointing to this socket.socket) is just moved into the
> > socket.socket object itself, there's no cyclic reference, and normal
> > refcounting should work just fine.  I don't even think a __del__ method
> > on socket.socket is necessary.
> 
> Here's a patch, for whenever you get back to this.  You can
> ignore/remove the first hunk, which is about SSL.  I've tried all the
> tests, and they work.  I've looked for leaks in test_socket and
> test_ssl, no leaks.

I've posted this patch as issue 1439.

Bill

From janssen at parc.com  Thu Nov 15 18:36:18 2007
From: janssen at parc.com (Bill Janssen)
Date: Thu, 15 Nov 2007 09:36:18 PST
Subject: [Python-3000] SSL patch for Py3K
Message-ID: <07Nov15.093627pst."57996"@synergy1.parc.xerox.com>

is now on issue 1451.

http://bugs.python.org/file8756/ssl.patch

Bill

From lists at cheimes.de  Thu Nov 15 19:27:22 2007
From: lists at cheimes.de (Christian Heimes)
Date: Thu, 15 Nov 2007 19:27:22 +0100
Subject: [Python-3000] SSL patch for Py3K
In-Reply-To: <07Nov15.093627pst."57996"@synergy1.parc.xerox.com>
References: <07Nov15.093627pst."57996"@synergy1.parc.xerox.com>
Message-ID: <473C8F8A.2090800@cheimes.de>

Bill Janssen wrote:
> is now on issue 1451.
> 
> http://bugs.python.org/file8756/ssl.patch

I'm getting two warnings on Ubuntu 7.10, x86

gcc -pthread -fPIC -fno-strict-aliasing -g -Wall -Wstrict-prototypes -I.
-I/home/heimes/dev/python/py3k/./Include -I./Include -IInclude -I.
-I/usr/local/include -I/home/heimes/dev/python/py3k/Include
-I/home/heimes/dev/python/py3k -c
/home/heimes/dev/python/py3k/Modules/_ssl.c -o
build/temp.linux-i686-3.0/home/heimes/dev/python/py3k/Modules/_ssl.o
/home/heimes/dev/python/py3k/Modules/_ssl.c: In function
'_get_peer_alt_names':
/home/heimes/dev/python/py3k/Modules/_ssl.c:680: warning: passing
argument 2 of 'ASN1_item_d2i' from incompatible pointer type
/home/heimes/dev/python/py3k/Modules/_ssl.c:684: warning: passing
argument 2 of 'method->d2i' from incompatible pointer type
gcc -pthread -shared
build/temp.linux-i686-3.0/home/heimes/dev/python/py3k/Modules/_ssl.o
-L/usr/local/lib -lssl -lcrypto -o build/lib.linux-i686-3.0/_ssl.so

Christian

From theller at ctypes.org  Thu Nov 15 20:22:41 2007
From: theller at ctypes.org (Thomas Heller)
Date: Thu, 15 Nov 2007 20:22:41 +0100
Subject: [Python-3000] Win64 buildbot
Message-ID: <fhi6a1$j0n$1@ger.gmane.org>

The Win64 buildbot currently fails to link python30.dll and _testcapi.pyd
because of an unresolved symbol PyObject_Unicode:

http://python.org/dev/buildbot/3.0/amd64%20XP%203.0/builds/242/step-compile/0

Does anyone have an idea why?

Thomas


From guido at python.org  Thu Nov 15 20:29:50 2007
From: guido at python.org (Guido van Rossum)
Date: Thu, 15 Nov 2007 11:29:50 -0800
Subject: [Python-3000] Win64 buildbot
In-Reply-To: <fhi6a1$j0n$1@ger.gmane.org>
References: <fhi6a1$j0n$1@ger.gmane.org>
Message-ID: <ca471dc20711151129s29b10ab5q4c91e0ec3cb6394f@mail.gmail.com>

On Nov 15, 2007 11:22 AM, Thomas Heller <theller at ctypes.org> wrote:
> The Win64 buildbot currently fails to link python30.dll and _testcapi.pyd
> because of an unresolved symbol PyObject_Unicode:
>
> http://python.org/dev/buildbot/3.0/amd64%20XP%203.0/builds/242/step-compile/0
>
> Does anyone have an idea why?

Not directly, but that function no longer exists, and has been
redefined via a macro in object.h to PyObject_Str. I find it hard to
believe that anything isn't including object.h (which is included by
Python.h) but that seems to be happening -- unless it's not properly
recompiling things, and reusing .obj files compiled previously.

Perhaps changing the remaining occurrences to PyObject_Str will fix this?

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

From theller at ctypes.org  Thu Nov 15 20:35:56 2007
From: theller at ctypes.org (Thomas Heller)
Date: Thu, 15 Nov 2007 20:35:56 +0100
Subject: [Python-3000] Win64 buildbot
In-Reply-To: <ca471dc20711151129s29b10ab5q4c91e0ec3cb6394f@mail.gmail.com>
References: <fhi6a1$j0n$1@ger.gmane.org>
	<ca471dc20711151129s29b10ab5q4c91e0ec3cb6394f@mail.gmail.com>
Message-ID: <fhi72s$m1h$1@ger.gmane.org>

Guido van Rossum schrieb:
> On Nov 15, 2007 11:22 AM, Thomas Heller <theller at ctypes.org> wrote:
>> The Win64 buildbot currently fails to link python30.dll and _testcapi.pyd
>> because of an unresolved symbol PyObject_Unicode:
>>
>> http://python.org/dev/buildbot/3.0/amd64%20XP%203.0/builds/242/step-compile/0
>>
>> Does anyone have an idea why?
> 
> Not directly, but that function no longer exists, and has been
> redefined via a macro in object.h to PyObject_Str. I find it hard to
> believe that anything isn't including object.h (which is included by
> Python.h) but that seems to be happening -- unless it's not properly
> recompiling things, and reusing .obj files compiled previously.

Yes, that may be.  The problem on the buildbot may be that the clean step
is not run when the compilation failed.  I'll try to clean up manually.

> Perhaps changing the remaining occurrences to PyObject_Str will fix this?
> 

If PyObject_Unicode is #defined for backwards compatibility then the occurences
should not be changed, imo.  If the #definition is only a hack then it should
be changed.  I have no idea about the C - api compatibility plans for py3k.

Thomas


From guido at python.org  Thu Nov 15 20:51:40 2007
From: guido at python.org (Guido van Rossum)
Date: Thu, 15 Nov 2007 11:51:40 -0800
Subject: [Python-3000] Win64 buildbot
In-Reply-To: <fhi72s$m1h$1@ger.gmane.org>
References: <fhi6a1$j0n$1@ger.gmane.org>
	<ca471dc20711151129s29b10ab5q4c91e0ec3cb6394f@mail.gmail.com>
	<fhi72s$m1h$1@ger.gmane.org>
Message-ID: <ca471dc20711151151rf4cb04ew818da3e87e591b4e@mail.gmail.com>

On Nov 15, 2007 11:35 AM, Thomas Heller <theller at ctypes.org> wrote:
> Guido van Rossum schrieb:
> > Perhaps changing the remaining occurrences to PyObject_Str will fix this?
>
> If PyObject_Unicode is #defined for backwards compatibility then the occurences
> should not be changed, imo.

Even if the #define exists for bw compat then we should still clean up
the sources. It's not going to come back in a different guise.

> If the #definition is only a hack then it should be changed.

Right, it was only a hack so I wouldn't have to fix it in a dozen files.

> I have no idea about the C - api compatibility plans for py3k.

Me neither. We'll have to play this by the seat of our pants, as they
say over here.

From theller at ctypes.org  Thu Nov 15 21:14:05 2007
From: theller at ctypes.org (Thomas Heller)
Date: Thu, 15 Nov 2007 21:14:05 +0100
Subject: [Python-3000] Win64 buildbot
In-Reply-To: <ca471dc20711151151rf4cb04ew818da3e87e591b4e@mail.gmail.com>
References: <fhi6a1$j0n$1@ger.gmane.org>	<ca471dc20711151129s29b10ab5q4c91e0ec3cb6394f@mail.gmail.com>	<fhi72s$m1h$1@ger.gmane.org>
	<ca471dc20711151151rf4cb04ew818da3e87e591b4e@mail.gmail.com>
Message-ID: <fhi9ad$14m$1@ger.gmane.org>

Guido van Rossum schrieb:
> On Nov 15, 2007 11:35 AM, Thomas Heller <theller at ctypes.org> wrote:
>> Guido van Rossum schrieb:
>> > Perhaps changing the remaining occurrences to PyObject_Str will fix this?
>>
>> If PyObject_Unicode is #defined for backwards compatibility then the occurences
>> should not be changed, imo.
> 
> Even if the #define exists for bw compat then we should still clean up
> the sources. It's not going to come back in a different guise.
> 
>> If the #definition is only a hack then it should be changed.
> 
> Right, it was only a hack so I wouldn't have to fix it in a dozen files.

I'll make the change.

And, btw: after a manual clean, the win64 buildbot compiles again.


From guido at python.org  Thu Nov 15 21:52:44 2007
From: guido at python.org (Guido van Rossum)
Date: Thu, 15 Nov 2007 12:52:44 -0800
Subject: [Python-3000] Win64 buildbot
In-Reply-To: <fhi9ad$14m$1@ger.gmane.org>
References: <fhi6a1$j0n$1@ger.gmane.org>
	<ca471dc20711151129s29b10ab5q4c91e0ec3cb6394f@mail.gmail.com>
	<fhi72s$m1h$1@ger.gmane.org>
	<ca471dc20711151151rf4cb04ew818da3e87e591b4e@mail.gmail.com>
	<fhi9ad$14m$1@ger.gmane.org>
Message-ID: <ca471dc20711151252h434caf35wb0778de5fffee0e1@mail.gmail.com>

On Nov 15, 2007 12:14 PM, Thomas Heller <theller at ctypes.org> wrote:
> I'll make the change.

Thanks!

> And, btw: after a manual clean, the win64 buildbot compiles again.

Hm, how about running a cleanup step at the *start* of the build
instead of at the end? (Or at both ends if you want to reclaim the
disk space.)

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

From theller at ctypes.org  Thu Nov 15 22:03:10 2007
From: theller at ctypes.org (Thomas Heller)
Date: Thu, 15 Nov 2007 22:03:10 +0100
Subject: [Python-3000] Win64 buildbot
In-Reply-To: <ca471dc20711151252h434caf35wb0778de5fffee0e1@mail.gmail.com>
References: <fhi6a1$j0n$1@ger.gmane.org>	<ca471dc20711151129s29b10ab5q4c91e0ec3cb6394f@mail.gmail.com>	<fhi72s$m1h$1@ger.gmane.org>	<ca471dc20711151151rf4cb04ew818da3e87e591b4e@mail.gmail.com>	<fhi9ad$14m$1@ger.gmane.org>
	<ca471dc20711151252h434caf35wb0778de5fffee0e1@mail.gmail.com>
Message-ID: <fhic6f$lhu$1@ger.gmane.org>

Guido van Rossum schrieb:
> On Nov 15, 2007 12:14 PM, Thomas Heller <theller at ctypes.org> wrote:
>> I'll make the change.
> 
> Thanks!
> 
>> And, btw: after a manual clean, the win64 buildbot compiles again.
> 
> Hm, how about running a cleanup step at the *start* of the build
> instead of at the end? (Or at both ends if you want to reclaim the
> disk space.)
> 

The *real* problem is that both the build and the clean step require
Python to work.  The former uses it to build _ssl, the latter starts rmpyc.py.
Since the python30.dll was not built, starting python.exe displays a
messagebox complaining that the exe can't find python30.dll,
and the buildbot is stalled.

I guess we just have to live with the fact that the windows
buildbots require manual intervention from time to time.

Thomas


From guido at python.org  Thu Nov 15 22:25:34 2007
From: guido at python.org (Guido van Rossum)
Date: Thu, 15 Nov 2007 13:25:34 -0800
Subject: [Python-3000] Win64 buildbot
In-Reply-To: <fhic6f$lhu$1@ger.gmane.org>
References: <fhi6a1$j0n$1@ger.gmane.org>
	<ca471dc20711151129s29b10ab5q4c91e0ec3cb6394f@mail.gmail.com>
	<fhi72s$m1h$1@ger.gmane.org>
	<ca471dc20711151151rf4cb04ew818da3e87e591b4e@mail.gmail.com>
	<fhi9ad$14m$1@ger.gmane.org>
	<ca471dc20711151252h434caf35wb0778de5fffee0e1@mail.gmail.com>
	<fhic6f$lhu$1@ger.gmane.org>
Message-ID: <ca471dc20711151325p51335100q2cd81dbab64c0dbe@mail.gmail.com>

On Nov 15, 2007 1:03 PM, Thomas Heller <theller at ctypes.org> wrote:
> The *real* problem is that both the build and the clean step require
> Python to work.  The former uses it to build _ssl, the latter starts rmpyc.py.
> Since the python30.dll was not built, starting python.exe displays a
> messagebox complaining that the exe can't find python30.dll,
> and the buildbot is stalled.
>
> I guess we just have to live with the fact that the windows
> buildbots require manual intervention from time to time.

Ideally, the clean step should not depend on Python existing. On Unix
it doesn't need it!

But I don't blame you if you file this as a low priority bug... :-(

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

From amauryfa at gmail.com  Thu Nov 15 23:31:53 2007
From: amauryfa at gmail.com (Amaury Forgeot d'Arc)
Date: Thu, 15 Nov 2007 23:31:53 +0100
Subject: [Python-3000] building _ssl on Windows
Message-ID: <e27efe130711151431p1a067359w67a621061d229f76@mail.gmail.com>

Hello,

I just saw the addition of the _ssl module:
http://svn.python.org/view?rev=58989&view=rev

I modified PCBuild8/pcbuild.sln to add the project to the solution file
(by hand: my version of vc2005 also changes everything in the file)

Now, is it really necessary to install perl in order to compile python?
I managed to avoid it until today :-(

Also note that the openssl distribution proposed in PCBuild8/readme.txt:
svn export http://svn.python.org/projects/external/openssl-0.9.8a
does not compile out of the box with vc2005.
The usual _CRT_NONSTDC_NO_DEPRECATE macro is missing...

-- 
Amaury Forgeot d'Arc

From janssen at parc.com  Thu Nov 15 23:45:58 2007
From: janssen at parc.com (Bill Janssen)
Date: Thu, 15 Nov 2007 14:45:58 PST
Subject: [Python-3000] building _ssl on Windows
In-Reply-To: <e27efe130711151431p1a067359w67a621061d229f76@mail.gmail.com> 
References: <e27efe130711151431p1a067359w67a621061d229f76@mail.gmail.com>
Message-ID: <07Nov15.144607pst."57996"@synergy1.parc.xerox.com>

> Now, is it really necessary to install perl in order to compile python?

This is a Windows thing?  You don't need it on Unix systems, I believe.

Bill

From martin at v.loewis.de  Fri Nov 16 00:07:32 2007
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 16 Nov 2007 00:07:32 +0100
Subject: [Python-3000] building _ssl on Windows
In-Reply-To: <e27efe130711151431p1a067359w67a621061d229f76@mail.gmail.com>
References: <e27efe130711151431p1a067359w67a621061d229f76@mail.gmail.com>
Message-ID: <473CD134.2040907@v.loewis.de>

> Now, is it really necessary to install perl in order to compile python?

Yes, if you want OpenSSL support.

> Also note that the openssl distribution proposed in PCBuild8/readme.txt:
> svn export http://svn.python.org/projects/external/openssl-0.9.8a
> does not compile out of the box with vc2005.
> The usual _CRT_NONSTDC_NO_DEPRECATE macro is missing...

What specific problem does that cause?

In any case, we will recommend a newer OpenSSL library when the release
comes closer. In the meantime, there might be several OpenSSL releases,
so if we update the recommendation now, we would have to do so again
in six months from now, and not just for OpenSSL, but for all the other
libraries.

Regards,
Martin

From p.f.moore at gmail.com  Fri Nov 16 00:32:33 2007
From: p.f.moore at gmail.com (Paul Moore)
Date: Thu, 15 Nov 2007 23:32:33 +0000
Subject: [Python-3000] Win64 buildbot
In-Reply-To: <ca471dc20711151325p51335100q2cd81dbab64c0dbe@mail.gmail.com>
References: <fhi6a1$j0n$1@ger.gmane.org>
	<ca471dc20711151129s29b10ab5q4c91e0ec3cb6394f@mail.gmail.com>
	<fhi72s$m1h$1@ger.gmane.org>
	<ca471dc20711151151rf4cb04ew818da3e87e591b4e@mail.gmail.com>
	<fhi9ad$14m$1@ger.gmane.org>
	<ca471dc20711151252h434caf35wb0778de5fffee0e1@mail.gmail.com>
	<fhic6f$lhu$1@ger.gmane.org>
	<ca471dc20711151325p51335100q2cd81dbab64c0dbe@mail.gmail.com>
Message-ID: <79990c6b0711151532h6c92834g4fed1d065f45a5a3@mail.gmail.com>

On 15/11/2007, Guido van Rossum <guido at python.org> wrote:
> Ideally, the clean step should not depend on Python existing. On Unix
> it doesn't need it!

>From a quick look, rmpyc.py is deleting .pyc and .pyo files in ..\Lib.
This could be done (I believe) using simply

   cd ..\Lib
   del /S *.pyc *.pyo

I haven't tested this (no time right now) but certainly on XP, the del
command accepts a /S flag to delete recursively.

Paul.

From lists at cheimes.de  Fri Nov 16 00:51:55 2007
From: lists at cheimes.de (Christian Heimes)
Date: Fri, 16 Nov 2007 00:51:55 +0100
Subject: [Python-3000] Compiling Python 3.0 with VS 2008 Beta2
Message-ID: <fhim2r$4lq$1@ger.gmane.org>

Today an user named weck has submitted three patches for VS 2005 support
[0]. In one of the replies Martin said that he likes to use the upcoming
VS2008 as new default compiler.

I've downloaded the Beta 2 of VS 2008 from [1] and played with it a bit.
 It comes with most tools required to build Python except of ml.exe
(Microsoft ASM) but I found [2]. Although it looks a bit old it does its
job for OpenSSL.

I had to fix a small problem in socketmodule.c [3] in order to compile
the socket module. The rest is just fine and the unit test suite is
running w/o an error.

The only new warning
C:\Programme\Microsoft SDKs\Windows\v6.0A\include\winnt.h(7127) :
warning C4005: 'WRITE_RESTRICTED' : macro redefinition
        c:\dev\python\py3k\Include\structmember.h(72) : see previous
definition of 'WRITE_RESTRICTED'
could probably be removed with renaming WRITE_RESTRICTED in structmember.h.

Should I check in my PCbuild9 directory? It's based on PCbuild8.

Christian

[0] http://bugs.python.org/issue1447 patch to make msvccompiler.py work
with vs 2005(MSVC8)
http://bugs.python.org/issue1448 Build Python with VS 2005(MSVC8)
http://bugs.python.org/issue1449 make msi  work the vs 2005(MSVC8)
[1] http://msdn2.microsoft.com/en-us/express/future/bb421473.aspx
[2] http://www.masm32.com/masmdl.htm
[3] http://svn.python.org/view?rev=59002&view=rev


From tim.peters at gmail.com  Fri Nov 16 02:22:14 2007
From: tim.peters at gmail.com (Tim Peters)
Date: Thu, 15 Nov 2007 20:22:14 -0500
Subject: [Python-3000] Win64 buildbot
In-Reply-To: <79990c6b0711151532h6c92834g4fed1d065f45a5a3@mail.gmail.com>
References: <fhi6a1$j0n$1@ger.gmane.org>
	<ca471dc20711151129s29b10ab5q4c91e0ec3cb6394f@mail.gmail.com>
	<fhi72s$m1h$1@ger.gmane.org>
	<ca471dc20711151151rf4cb04ew818da3e87e591b4e@mail.gmail.com>
	<fhi9ad$14m$1@ger.gmane.org>
	<ca471dc20711151252h434caf35wb0778de5fffee0e1@mail.gmail.com>
	<fhic6f$lhu$1@ger.gmane.org>
	<ca471dc20711151325p51335100q2cd81dbab64c0dbe@mail.gmail.com>
	<79990c6b0711151532h6c92834g4fed1d065f45a5a3@mail.gmail.com>
Message-ID: <1f7befae0711151722k464b0c03w9633a6458b14672a@mail.gmail.com>

[Paul Moore]
>>From a quick look, rmpyc.py is deleting .pyc and .pyo files in ..\Lib.
> This could be done (I believe) using simply
>
>    cd ..\Lib
>    del /S *.pyc *.pyo
>
> I haven't tested this (no time right now) but certainly on XP, the del
> command accepts a /S flag to delete recursively.

All correct.  "del /s" works under cmd.exe, but not under command.com.
 If Python no longer supports any pre-NT flavor of Windows, then
rmpyc.py is no longer needed.

From guido at python.org  Fri Nov 16 02:28:02 2007
From: guido at python.org (Guido van Rossum)
Date: Thu, 15 Nov 2007 17:28:02 -0800
Subject: [Python-3000] Win64 buildbot
In-Reply-To: <1f7befae0711151722k464b0c03w9633a6458b14672a@mail.gmail.com>
References: <fhi6a1$j0n$1@ger.gmane.org>
	<ca471dc20711151129s29b10ab5q4c91e0ec3cb6394f@mail.gmail.com>
	<fhi72s$m1h$1@ger.gmane.org>
	<ca471dc20711151151rf4cb04ew818da3e87e591b4e@mail.gmail.com>
	<fhi9ad$14m$1@ger.gmane.org>
	<ca471dc20711151252h434caf35wb0778de5fffee0e1@mail.gmail.com>
	<fhic6f$lhu$1@ger.gmane.org>
	<ca471dc20711151325p51335100q2cd81dbab64c0dbe@mail.gmail.com>
	<79990c6b0711151532h6c92834g4fed1d065f45a5a3@mail.gmail.com>
	<1f7befae0711151722k464b0c03w9633a6458b14672a@mail.gmail.com>
Message-ID: <ca471dc20711151728i3084ad05p3c80cde5756e0c17@mail.gmail.com>

Right. Building Win98 or ME is insanity.

[double-takes]

Hey! Tim! Long time no see. Welcome back!!!! Don't be a stranger. :-)
We missed you.

--Guido

On Nov 15, 2007 5:22 PM, Tim Peters <tim.peters at gmail.com> wrote:
> [Paul Moore]
> >>From a quick look, rmpyc.py is deleting .pyc and .pyo files in ..\Lib.
> > This could be done (I believe) using simply
> >
> >    cd ..\Lib
> >    del /S *.pyc *.pyo
> >
> > I haven't tested this (no time right now) but certainly on XP, the del
> > command accepts a /S flag to delete recursively.
>
> All correct.  "del /s" works under cmd.exe, but not under command.com.
>  If Python no longer supports any pre-NT flavor of Windows, then
> rmpyc.py is no longer needed.
>
> _______________________________________________
> 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 mark at qtrac.eu  Fri Nov 16 08:49:34 2007
From: mark at qtrac.eu (Mark Summerfield)
Date: Fri, 16 Nov 2007 07:49:34 +0000
Subject: [Python-3000] Trying to understand Python 3's comparisons
Message-ID: <200711160749.34997.mark@qtrac.eu>

Hi,

I'm trying to understand Python 3's comparisons.

class Eq:
    def __init__(self, x=""):
        self.x = x
    def __str__(self):
        return self.x
    def __eq__(self, other):
        return str(self) == str(other)

class Lt:
    def __init__(self, x=""):
        self.x = x
    def __str__(self):
        return self.x
    def __lt__(self, other):
        return str(self) < str(other)

class LtEq:
    def __init__(self, x=""):
        self.x = x
    def __str__(self):
        return self.x
    def __eq__(self, other):
        return str(self) == str(other)
    def __lt__(self, other):
        return str(self) < str(other)

pairs = ((Eq("a"), Eq("b")), (Lt("a"), Lt("b")), (LtEq("a"), LtEq("b")))
for a, b in pairs:
    print("comparing", type(a))
    try:
        print("a < b", a < b)
    except TypeError as err: # TypeError, err in Python 2
        print(err)
    # etc, for all the other comparisons

For Python 2 I get this output:

comparing <type 'instance'> # Eq
a < b True
a <= b True
a == b False
a != b True
a > b False
a >= b False

comparing <type 'instance'> # Lt
a < b True
a <= b True
a == b False
a != b True
a > b False
a >= b False

comparing <type 'instance'> #LtEq
a < b True
a <= b True
a == b False
a != b True
a > b False
a >= b False

Clearly this is bad since class Eq has no ordering and class Lt has no
notion of equality.

For Python 3 I get this output:

comparing <class '__main__.Eq'>
unorderable types: Eq() < Eq()
unorderable types: Eq() <= Eq()
a == b False
a != b True
unorderable types: Eq() > Eq()
unorderable types: Eq() >= Eq()

comparing <class '__main__.Lt'>
a < b True
unorderable types: Lt() <= Lt()
a == b False
a != b True
a > b False
unorderable types: Lt() >= Lt()

comparing <class '__main__.LtEq'>
a < b True
unorderable types: LtEq() <= LtEq()
a == b False
a != b True
a > b False
unorderable types: LtEq() >= LtEq()

This is much better in the case of classes Eq and Lt. But I don't
understand why class LtEq does not handle <= or =>. Bear in mind that
for class Eq I only defined ==, Python 3 created != for me; similarly
for class Lt I defined < and Python created >. Or is my code for LtEq
wrong?

I know it isn't a problem creating a class decorator or metaclass to
"complete" LtEq; I'm just trying to understand how Python 3 comparisons
work.

Thanks!

-- 
Mark Summerfield, Qtrac Ltd., www.qtrac.eu


From martin at v.loewis.de  Fri Nov 16 09:21:53 2007
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 16 Nov 2007 09:21:53 +0100
Subject: [Python-3000] Compiling Python 3.0 with VS 2008 Beta2
In-Reply-To: <fhim2r$4lq$1@ger.gmane.org>
References: <fhim2r$4lq$1@ger.gmane.org>
Message-ID: <473D5321.3020304@v.loewis.de>

> Should I check in my PCbuild9 directory? It's based on PCbuild8.

Please no. I would much prefer if PCbuild9 was based on PCbuild, not
PCbuild8. In particular, there shouldn't be subdirectories for the
individual projects, and the output files should land directly in
PCbuild9.

Regards,
Martin

From lists at cheimes.de  Fri Nov 16 21:47:50 2007
From: lists at cheimes.de (Christian Heimes)
Date: Fri, 16 Nov 2007 21:47:50 +0100
Subject: [Python-3000] Compiling Python 3.0 with VS 2008 Beta2
In-Reply-To: <473D5321.3020304@v.loewis.de>
References: <fhim2r$4lq$1@ger.gmane.org> <473D5321.3020304@v.loewis.de>
Message-ID: <473E01F6.7050202@cheimes.de>

Martin v. L?wis wrote:
> Please no. I would much prefer if PCbuild9 was based on PCbuild, not
> PCbuild8. In particular, there shouldn't be subdirectories for the
> individual projects, and the output files should land directly in
> PCbuild9.

K!

I'll see if I can take some spare time and port the PCbuild directory to
VS 2008. Do you have any additional suggestions or wishes?

If anybody else is going to test it, please install the standard
edition. I'm having too much trouble with the Beta 2 of the express
edition. You've to install VB and VC#, too, or the cl.exe may not get
installed for x86.

Christian

From martin at v.loewis.de  Fri Nov 16 22:17:45 2007
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 16 Nov 2007 22:17:45 +0100
Subject: [Python-3000] Compiling Python 3.0 with VS 2008 Beta2
In-Reply-To: <473E01F6.7050202@cheimes.de>
References: <fhim2r$4lq$1@ger.gmane.org> <473D5321.3020304@v.loewis.de>
	<473E01F6.7050202@cheimes.de>
Message-ID: <473E08F9.8030308@v.loewis.de>

> I'll see if I can take some spare time and port the PCbuild directory to
> VS 2008. Do you have any additional suggestions or wishes?

If you have time and energy, you can try to eliminate duplicate and
unnecessary settings, using VS defaults wherever possible. For
optimization, it's probably still useful to copy over some of the
PCbuild8 settings (although I'm not sure what the precise constraints
on the feedback optimization are).

Also, we should consider how to manage both the trunk and the 3k branch
- they should definitely use the same compiler, so perhaps a lot of
project files can be shared.

For the multi-architecture thing, there should be build settings for
both x86 and AMD64; Itanium is probably irrelevant. I'm still undecided
on how the directory layout should be; people probably will keep asking
that you can use the same sandbox for both architectures, and other
people will keep asking that the layout should continue to be compatible
with Python 2.5. So perhaps we can put x86 binaries into PCbuild
directly, and AMD64 binaries into PCbuild/amd64.

If you find that you absolutely cannot build some extension module
from the sources that are in external (e.g. openssl), feel free to
import newer releases (provided that they actually work).

Regards,
Martin

From lists at cheimes.de  Sat Nov 17 01:47:48 2007
From: lists at cheimes.de (Christian Heimes)
Date: Sat, 17 Nov 2007 01:47:48 +0100
Subject: [Python-3000] Compiling Python 3.0 with VS 2008 Beta2
In-Reply-To: <473E08F9.8030308@v.loewis.de>
References: <fhim2r$4lq$1@ger.gmane.org> <473D5321.3020304@v.loewis.de>
	<473E01F6.7050202@cheimes.de> <473E08F9.8030308@v.loewis.de>
Message-ID: <473E3A34.6040706@cheimes.de>

Martin v. L?wis wrote:
> If you have time and energy, you can try to eliminate duplicate and
> unnecessary settings, using VS defaults wherever possible. For
> optimization, it's probably still useful to copy over some of the
> PCbuild8 settings (although I'm not sure what the precise constraints
> on the feedback optimization are).

Yes, I like to reuse the vsprops files. They are useful to share common
configuration and macros across multiple projects in a solution. It
should make it easier to share global information like include
directories. I'm not going to add PGO (profile guided optimization) for
now. It's a nice to have feature but it's not crucial.

A project can inherit from multiple vcprops and a vcprop sheet can
inherit from another.  I've given some though to a sensible but small
structure:

pyproject	(base vcprops for all projects in the solution, machine
indepdentend)
    * pyd	(props for Python extensions)
        o pyd_d	(props for Python extensions Debug build)
amd64		(AMD64 related options)
x86		(x86 related options)

> Also, we should consider how to manage both the trunk and the 3k branch
> - they should definitely use the same compiler, so perhaps a lot of
> project files can be shared.

I've planed to work on py3k and port the PCbuild9 stuff back into the
trunk later. The structure of py3k and trunk are almost identical but
the py3k branch has more files. It's easier to remove non existing files
than to add missing files.

> For the multi-architecture thing, there should be build settings for
> both x86 and AMD64; Itanium is probably irrelevant. I'm still undecided
> on how the directory layout should be; people probably will keep asking
> that you can use the same sandbox for both architectures, and other
> people will keep asking that the layout should continue to be compatible
> with Python 2.5. So perhaps we can put x86 binaries into PCbuild
> directly, and AMD64 binaries into PCbuild/amd64.

What combinations of configuration and platform do we need? The migrated
solution has Release, Debug, ReleaseAMD64 and ReleaseItanium as
configurations and Win32 as platform. The platform X64 isn't listed but
I could add it.

Do we need a ReleaseAMD64 when we could use the platform X64?

> If you find that you absolutely cannot build some extension module
> from the sources that are in external (e.g. openssl), feel free to
> import newer releases (provided that they actually work).

I vaguely remember an issue with openssl that is fixed in new versions
of openssl. For now I try to stick to the releases which are already in
the external repository.

I'm not familiar with all settings of VS. While I can make sense of most
settings I don't understand why some projects are setting a base address
in the linker settings.

Christian

From unknown_kev_cat at hotmail.com  Sat Nov 17 02:59:38 2007
From: unknown_kev_cat at hotmail.com (Joe Smith)
Date: Fri, 16 Nov 2007 20:59:38 -0500
Subject: [Python-3000] Compiling Python 3.0 with VS 2008 Beta2
References: <fhim2r$4lq$1@ger.gmane.org>
Message-ID: <fhlirg$m38$1@ger.gmane.org>


"Christian Heimes" <lists at cheimes.de> wrote in message 
news:fhim2r$4lq$1 at ger.gmane.org...
> Today an user named weck has submitted three patches for VS 2005 support
> [0]. In one of the replies Martin said that he likes to use the upcoming
> VS2008 as new default compiler.
>
> I've downloaded the Beta 2 of VS 2008 from [1] and played with it a bit.
> It comes with most tools required to build Python except of ml.exe
> (Microsoft ASM) but I found [2]. Although it looks a bit old it does its
> job for OpenSSL.

While ml.exe is intentionally omitted for the express version of Visual C++, 
the standard versions of Visual Studio are supposed to include ml.exe.
The VS 2008 beta 2 version omitted it by mistake. At the moment there is no 
convenient way to get the latest version. This should be fixed for the final 
release.

(Obviously the older versions still work.) 



From martin at v.loewis.de  Sat Nov 17 10:00:02 2007
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat, 17 Nov 2007 10:00:02 +0100
Subject: [Python-3000] Compiling Python 3.0 with VS 2008 Beta2
In-Reply-To: <473E3A34.6040706@cheimes.de>
References: <fhim2r$4lq$1@ger.gmane.org> <473D5321.3020304@v.loewis.de>
	<473E01F6.7050202@cheimes.de> <473E08F9.8030308@v.loewis.de>
	<473E3A34.6040706@cheimes.de>
Message-ID: <473EAD92.1020706@v.loewis.de>

> What combinations of configuration and platform do we need? The migrated
> solution has Release, Debug, ReleaseAMD64 and ReleaseItanium as
> configurations and Win32 as platform. The platform X64 isn't listed but
> I could add it.
> 
> Do we need a ReleaseAMD64 when we could use the platform X64?

The "platform" feature didn't exist in VS 2003 (atleast you couldn't
define new platforms), hence those projects made new configurations.

In the future, I think we should have only Release and Debug
configurations, and x86 and x64 platforms, and these in all four
combinations.

> I'm not familiar with all settings of VS. While I can make sense of most
> settings I don't understand why some projects are setting a base address
> in the linker settings.

See PC/dllbase_nt.txt. This should be revised to match the current set
of modules, plus it should be updated for AMD64, as some DLLs become
larger on AMD64, so that they need more address space than dllbase_nt
allows for them.

Regards,
Martin

From lists at cheimes.de  Sat Nov 17 12:42:41 2007
From: lists at cheimes.de (Christian Heimes)
Date: Sat, 17 Nov 2007 12:42:41 +0100
Subject: [Python-3000] Compiling Python 3.0 with VS 2008 Beta2
In-Reply-To: <473EAD92.1020706@v.loewis.de>
References: <fhim2r$4lq$1@ger.gmane.org>
	<473D5321.3020304@v.loewis.de>	<473E01F6.7050202@cheimes.de>
	<473E08F9.8030308@v.loewis.de>	<473E3A34.6040706@cheimes.de>
	<473EAD92.1020706@v.loewis.de>
Message-ID: <473ED3B1.40502@cheimes.de>

Martin v. L?wis wrote:
> The "platform" feature didn't exist in VS 2003 (atleast you couldn't
> define new platforms), hence those projects made new configurations.
> 
> In the future, I think we should have only Release and Debug
> configurations, and x86 and x64 platforms, and these in all four
> combinations.

I've tested VS 2008 Beta 2 Express and Standard Edition. I had to
uninstall the Express Edition in order to test the Standard Edition. As
far as I remember the Express Edition does neither ship with the 64bit
compilers nor allows to use the x64 platform.

The standard edition has two platforms: Win32 and x64. I haven't figured
out if its possible to define custom platforms. The x64 platform uses
the amd64 compiler.

> See PC/dllbase_nt.txt. This should be revised to match the current set
> of modules, plus it should be updated for AMD64, as some DLLs become
> larger on AMD64, so that they need more address space than dllbase_nt
> allows for them.

Oh, it's an interesting speed up trick. How was the address table
generated. Lucky guessing and gut feeling? :]

Christian

From lists at cheimes.de  Sat Nov 17 12:49:57 2007
From: lists at cheimes.de (Christian Heimes)
Date: Sat, 17 Nov 2007 12:49:57 +0100
Subject: [Python-3000] Compiling Python 3.0 with VS 2008 Beta2
In-Reply-To: <fhlirg$m38$1@ger.gmane.org>
References: <fhim2r$4lq$1@ger.gmane.org> <fhlirg$m38$1@ger.gmane.org>
Message-ID: <fhmkh5$qj8$1@ger.gmane.org>

Joe Smith wrote:
> While ml.exe is intentionally omitted for the express version of Visual C++, 
> the standard versions of Visual Studio are supposed to include ml.exe.
> The VS 2008 beta 2 version omitted it by mistake. At the moment there is no 
> convenient way to get the latest version. This should be fixed for the final 
> release.
> 
> (Obviously the older versions still work.) 

The older versions don't work with the latest version of openssl. I
guess they don't understand SSE2. I had more luck with the free nasm
assembler from kernel.org.

Christian


From martin at v.loewis.de  Sat Nov 17 13:03:28 2007
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat, 17 Nov 2007 13:03:28 +0100
Subject: [Python-3000] Compiling Python 3.0 with VS 2008 Beta2
In-Reply-To: <473ED3B1.40502@cheimes.de>
References: <fhim2r$4lq$1@ger.gmane.org>
	<473D5321.3020304@v.loewis.de>	<473E01F6.7050202@cheimes.de>
	<473E08F9.8030308@v.loewis.de>	<473E3A34.6040706@cheimes.de>
	<473EAD92.1020706@v.loewis.de> <473ED3B1.40502@cheimes.de>
Message-ID: <473ED890.2070801@v.loewis.de>

>> In the future, I think we should have only Release and Debug
>> configurations, and x86 and x64 platforms, and these in all four
>> combinations.
> 
> I've tested VS 2008 Beta 2 Express and Standard Edition. I had to
> uninstall the Express Edition in order to test the Standard Edition. As
> far as I remember the Express Edition does neither ship with the 64bit
> compilers nor allows to use the x64 platform.
> 
> The standard edition has two platforms: Win32 and x64. I haven't figured
> out if its possible to define custom platforms. The x64 platform uses
> the amd64 compiler.

Microsoft isn't quite consistent in naming things. The "Win32" platform
refers to the x86 architecture, and the x64 platform refers to the AMD64
platform. They couldn't rename "Win32" for backwards compatibility (I
guess), and they couldn't name the new platform "Win64" because that
name might also identify Itanium.

In any case, I will build release versions for both architectures, for
2.6 and 3.0, and will be using the standard edition (or perhaps the
professional edition) for that. I assume that some people would like
to run the debug version on AMD64, so that should also be supported (it
currently isn't - I normally cross-compile for AMD64, so I can't
run it in a debugger, anyway).

>> See PC/dllbase_nt.txt. This should be revised to match the current set
>> of modules, plus it should be updated for AMD64, as some DLLs become
>> larger on AMD64, so that they need more address space than dllbase_nt
>> allows for them.
> 
> Oh, it's an interesting speed up trick. How was the address table
> generated. Lucky guessing and gut feeling? :]

Which aspect of it? There is a documented list (somewhere) of address
ranges that the (MS) Windows DLLs will occupy, so the Python DLLs should
be located elsewhere (there might also be a MS recommendation somewhere
what ranges to use). On the spacing in this table - Mark Hammond did
it, probably by checking the actual sizes and then rounding up. Such
tables need to be revised from time to time, to find out whether the
assumptions on sizes still hold.

Regards,
Martin

From martin at v.loewis.de  Sat Nov 17 14:47:55 2007
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat, 17 Nov 2007 14:47:55 +0100
Subject: [Python-3000] Compiling Python 3.0 with VS 2008 Beta2
In-Reply-To: <473ED3B1.40502@cheimes.de>
References: <fhim2r$4lq$1@ger.gmane.org>
	<473D5321.3020304@v.loewis.de>	<473E01F6.7050202@cheimes.de>
	<473E08F9.8030308@v.loewis.de>	<473E3A34.6040706@cheimes.de>
	<473EAD92.1020706@v.loewis.de> <473ED3B1.40502@cheimes.de>
Message-ID: <473EF10B.8090706@v.loewis.de>

> Oh, it's an interesting speed up trick. How was the address table
> generated. Lucky guessing and gut feeling? :]

There is also rebase.exe (resp. editbin /rebase), which may have been
used to produce the initial version of this table.

Regards,
Martin

From martin at v.loewis.de  Sat Nov 17 18:07:02 2007
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat, 17 Nov 2007 18:07:02 +0100
Subject: [Python-3000] Please re-add __cmp__ to python 3000
In-Reply-To: <aac2c7cb0710291836u28894c1epceb45b3640c794f6@mail.gmail.com>
References: <E1IiBwH-0003sz-04@fenris.runbox.com>	<d11dcfba0710171027tbfeb31dw6f89ff77f6d51fcd@mail.gmail.com>	<47169E6E.7000804@canterbury.ac.nz>	<E1ImZR5-000251-4n@garm.runbox.com>	<aac2c7cb0710291249y31a74c9cw66c5e7fbff818ea@mail.gmail.com>	<47267607.2000806@canterbury.ac.nz>
	<aac2c7cb0710291836u28894c1epceb45b3640c794f6@mail.gmail.com>
Message-ID: <473F1FB6.9010702@v.loewis.de>

> It'd be simpler still if we only had __cmp__ and __eq__.  I just don't
> understand the use cases where that's not sufficient.
> 
> Hrm.  I guess set's subset checking requires more relationships than
> __cmp__ provides.  Abandoning that feature probably isn't an option,
> so nevermind me.
> 
> (Although, if we really wanted we could use -2/+2 to mean
> subset/superset, while -1/+1 mean smaller/larger.)

It's the difference between partial and total order. Some things have
only a partial order, so they can't implement __cmp__; or __cmp__ would
have to be extended to support "unordered" as a result.

Regards,
Martin


From lists at cheimes.de  Sat Nov 17 21:25:39 2007
From: lists at cheimes.de (Christian Heimes)
Date: Sat, 17 Nov 2007 21:25:39 +0100
Subject: [Python-3000] Compiling Python 3.0 with VS 2008 Beta2
In-Reply-To: <fhim2r$4lq$1@ger.gmane.org>
References: <fhim2r$4lq$1@ger.gmane.org>
Message-ID: <fhnio4$i8i$1@ger.gmane.org>

Update
------

The new PCbuild9 directory works for x86. I'm unable to test it for
AMD64. The structure is going to change from a ReleaseAMD64 solution
towards x86 platform in the future.

I've also hacked together a small fix for the msvccompiler module. It's
available at http://bugs.python.org/issue1455 but not yet finished.

In order to test the new build directory you need the STANDARD edition
of VS 2008 Beta 2. The Express Edition doesn't set the necessary bits
and pieces in the registry for msvccompiler.

You also need the new version of openssl from the Python SVN repository
and the nasm Assembler from kernel.org. Beta 2 doesn't ship with ml.exe
and older versions of ml seem to have an issue with SSE2 opcodes.

Once everything is in place and tested I will port the new build dir
back to the trunk.

Christian


From greg.ewing at canterbury.ac.nz  Sat Nov 17 23:53:50 2007
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sun, 18 Nov 2007 11:53:50 +1300
Subject: [Python-3000] Please re-add __cmp__ to python 3000
In-Reply-To: <473F1FB6.9010702@v.loewis.de>
References: <E1IiBwH-0003sz-04@fenris.runbox.com>
	<d11dcfba0710171027tbfeb31dw6f89ff77f6d51fcd@mail.gmail.com>
	<47169E6E.7000804@canterbury.ac.nz> <E1ImZR5-000251-4n@garm.runbox.com>
	<aac2c7cb0710291249y31a74c9cw66c5e7fbff818ea@mail.gmail.com>
	<47267607.2000806@canterbury.ac.nz>
	<aac2c7cb0710291836u28894c1epceb45b3640c794f6@mail.gmail.com>
	<473F1FB6.9010702@v.loewis.de>
Message-ID: <473F70FE.2040605@canterbury.ac.nz>

Martin v. L?wis wrote:
> or __cmp__ would
> have to be extended to support "unordered" as a result.

That's what I think should be done.

--
Greg

From janssen at parc.com  Sun Nov 18 01:10:47 2007
From: janssen at parc.com (Bill Janssen)
Date: Sat, 17 Nov 2007 16:10:47 PST
Subject: [Python-3000] leaking sockets again
Message-ID: <07Nov17.161049pst."57996"@synergy1.parc.xerox.com>

I notice that we are leaking sockets again.  I believe this is due to
the fact that the __del__ methods on socket.socket was removed from the
patch I sent in for socket.py.  I'll poke further.

Bill


From janssen at parc.com  Sun Nov 18 01:27:23 2007
From: janssen at parc.com (Bill Janssen)
Date: Sat, 17 Nov 2007 16:27:23 PST
Subject: [Python-3000] leaking sockets again
In-Reply-To: <07Nov17.161049pst."57996"@synergy1.parc.xerox.com> 
References: <07Nov17.161049pst."57996"@synergy1.parc.xerox.com>
Message-ID: <07Nov17.162729pst."57996"@synergy1.parc.xerox.com>

> I notice that we are leaking sockets again.  I believe this is due to
> the fact that the __del__ methods on socket.socket was removed from the
> patch I sent in for socket.py.  I'll poke further.

Nope, that's not it.  I'll have to poke at it a bit more.

Bill

From unknown_kev_cat at hotmail.com  Mon Nov 19 04:34:55 2007
From: unknown_kev_cat at hotmail.com (Joe Smith)
Date: Sun, 18 Nov 2007 22:34:55 -0500
Subject: [Python-3000] Compiling Python 3.0 with VS 2008 Beta2
References: <fhim2r$4lq$1@ger.gmane.org> <fhlirg$m38$1@ger.gmane.org>
	<fhmkh5$qj8$1@ger.gmane.org>
Message-ID: <fhr27l$hbp$1@ger.gmane.org>


"Christian Heimes" <lists at cheimes.de> wrote in message 
news:fhmkh5$qj8$1 at ger.gmane.org...
> Joe Smith wrote:
>> While ml.exe is intentionally omitted for the express version of Visual 
>> C++,
>> the standard versions of Visual Studio are supposed to include ml.exe.
>> The VS 2008 beta 2 version omitted it by mistake. At the moment there is 
>> no
>> convenient way to get the latest version. This should be fixed for the 
>> final
>> release.
>>
>> (Obviously the older versions still work.)
>
> The older versions don't work with the latest version of openssl. I
> guess they don't understand SSE2. I had more luck with the free nasm
> assembler from kernel.org.
>
> Christian

Ok. Your nasm workaround is fine, but ML.exe is definately intended to ship 
with VS 2008.

For the record:
The ml.exe is apparently included in the team edition of the beta, if you 
wanted it, but microsoft has messed up here. Alternatively, one could 
extract version 8 (a slightly out of date version [from VS 2005] but 
including SSE2 support) from the msi included with 
http://www.microsoft.com/downloads/details.aspx?FamilyID=7a1c9da0-0510-44a2-b042-7ef370530c64&DisplayLang=en 
(or copy it from any VS 2005 cd).



From greg at krypto.org  Mon Nov 19 05:33:59 2007
From: greg at krypto.org (Gregory P. Smith)
Date: Sun, 18 Nov 2007 20:33:59 -0800
Subject: [Python-3000] building _ssl on Windows
In-Reply-To: <473CD134.2040907@v.loewis.de>
References: <e27efe130711151431p1a067359w67a621061d229f76@mail.gmail.com>
	<473CD134.2040907@v.loewis.de>
Message-ID: <52dc1c820711182033p143e564duf0f239de5a2321fa@mail.gmail.com>

On 11/15/07, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>
> > Now, is it really necessary to install perl in order to compile python?
>
> Yes, if you want OpenSSL support.


Yep.  Sadly OpenSSL uses Perl to generate its asm files in one of two or
three different x86 asm syntaxes.  Why is this sad?  A good completely free
x86 assembler is available (http://nasm.sourceforge.net/) so they should
just say screw it to the other syntaxes and write their asm for nasm.  But
its an OpenSSL problem, not python.  If anyone wants to fix this, fix
OpenSSL.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20071118/9843b781/attachment.htm 

From samfeltus at gmail.com  Sun Nov 18 15:34:42 2007
From: samfeltus at gmail.com (SamFeltus)
Date: Sun, 18 Nov 2007 06:34:42 -0800 (PST)
Subject: [Python-3000] Musings and Speculations of Future Python libraries
Message-ID: <1b6bfbfb-ac05-4352-80ec-5fbd58194283@y5g2000hsf.googlegroups.com>

" A team leader exists (Brett Cannon), a seed for a plan exists (PEP
3108) and the mailing list is python-3000 at python.org. Don't be shy!!!
- Guido van Rossum "

I read this, so I'm not being shy, and posted some Python generated
visual thoughts on the sorts of things Python needs in its libraries
one day...

Here's an interesting Podcast musing on the possible future of Python
and computing, illustrated and commentated by SonomaSunshine...

Enjoy...

http://samfeltus.com/kudzu/Nanoprogramming_podcast.html



From jimjjewett at gmail.com  Mon Nov 19 15:41:41 2007
From: jimjjewett at gmail.com (Jim Jewett)
Date: Mon, 19 Nov 2007 09:41:41 -0500
Subject: [Python-3000] Please re-add __cmp__ to python 3000
In-Reply-To: <473F70FE.2040605@canterbury.ac.nz>
References: <E1IiBwH-0003sz-04@fenris.runbox.com>
	<d11dcfba0710171027tbfeb31dw6f89ff77f6d51fcd@mail.gmail.com>
	<47169E6E.7000804@canterbury.ac.nz>
	<E1ImZR5-000251-4n@garm.runbox.com>
	<aac2c7cb0710291249y31a74c9cw66c5e7fbff818ea@mail.gmail.com>
	<47267607.2000806@canterbury.ac.nz>
	<aac2c7cb0710291836u28894c1epceb45b3640c794f6@mail.gmail.com>
	<473F1FB6.9010702@v.loewis.de> <473F70FE.2040605@canterbury.ac.nz>
Message-ID: <fb6fbf560711190641h36e852e4off5450d22c724af2@mail.gmail.com>

On 11/17/07, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Martin v. L?wis wrote:
> > or __cmp__ would
> > have to be extended to support "unordered" as a result.
>
> That's what I think should be done.

Note that this would make it slightly easier to pass a custom sort
function that forced everything to be totally ordered[*], but followed
the standard ordering when one was available.

[*]  yes, it would be possible to trick this function with so that the
end result for a full sequence depended on the order of comparisons.
But that is already true with custom comparisons.

-jJ

From amauryfa at gmail.com  Mon Nov 19 17:05:13 2007
From: amauryfa at gmail.com (Amaury Forgeot d'Arc)
Date: Mon, 19 Nov 2007 17:05:13 +0100
Subject: [Python-3000] Removing windows 95 specific code
Message-ID: <e27efe130711190805i674ca87ep8113e60f35904f3a@mail.gmail.com>

Hello,

Python 3.0 has already dropped support for Windows 9x in several
places, and is now expected to only work with the NT family.

I propose to remove the remaining code specific to windows 9x/ME.

This includes:
- Py_WIN_WIDE_FILENAMES is always defined
- when given a unicode string, try to always use the wide version of
the win32 api.
- w9xpopen will disappear

Are there objections?
Windows CE uses unicode, and is supposed to survive this change.

Another question:
I noticed that open() and other functions accept bytes objects. Is it intended?
There is no test for this in the test suite. I will add some when I
know what is needed.

Another question #2:
on posix platforms, os.path.supports_unicode_filenames is False.
So far, this variable is only used to run test_pep277.py or not. Did
we make some progress on this topic since the unicode-everywhere
rewrite? (see also http://bugs.python.org/issue767645 )

Cheers,

-- 
Amaury Forgeot d'Arc

From guido at python.org  Mon Nov 19 18:23:42 2007
From: guido at python.org (Guido van Rossum)
Date: Mon, 19 Nov 2007 09:23:42 -0800
Subject: [Python-3000] Removing windows 95 specific code
In-Reply-To: <e27efe130711190805i674ca87ep8113e60f35904f3a@mail.gmail.com>
References: <e27efe130711190805i674ca87ep8113e60f35904f3a@mail.gmail.com>
Message-ID: <ca471dc20711190923q48b742fdxf7f755184fa9f39d@mail.gmail.com>

On Nov 19, 2007 8:05 AM, Amaury Forgeot d'Arc <amauryfa at gmail.com> wrote:
> Another question:
> I noticed that open() and other functions accept bytes objects. Is it intended?
> There is no test for this in the test suite. I will add some when I
> know what is needed.

Wasn't intended. We haven't completed fixing all places that still
somehow use the old approach, accepting PyString and PyUnicode both.

> Another question #2:
> on posix platforms, os.path.supports_unicode_filenames is False.
> So far, this variable is only used to run test_pep277.py or not. Did
> we make some progress on this topic since the unicode-everywhere
> rewrite? (see also http://bugs.python.org/issue767645 )

This may well be wrong, since we're supposed to accept Unicode
everywhere. I don't know why that variable was introduced.

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

From lists at cheimes.de  Mon Nov 19 19:40:16 2007
From: lists at cheimes.de (Christian Heimes)
Date: Mon, 19 Nov 2007 19:40:16 +0100
Subject: [Python-3000] Compiling Python 3.0 with VS 2008 Beta2
In-Reply-To: <fhr27l$hbp$1@ger.gmane.org>
References: <fhim2r$4lq$1@ger.gmane.org>
	<fhlirg$m38$1@ger.gmane.org>	<fhmkh5$qj8$1@ger.gmane.org>
	<fhr27l$hbp$1@ger.gmane.org>
Message-ID: <fhslag$n4h$1@ger.gmane.org>

Joe Smith wrote:
> Ok. Your nasm workaround is fine, but ML.exe is definately intended to ship 
> with VS 2008.
> 
> For the record:
> The ml.exe is apparently included in the team edition of the beta, if you 
> wanted it, but microsoft has messed up here. Alternatively, one could 
> extract version 8 (a slightly out of date version [from VS 2005] but 
> including SSE2 support) from the msi included with 
> http://www.microsoft.com/downloads/details.aspx?FamilyID=7a1c9da0-0510-44a2-b042-7ef370530c64&DisplayLang=en 
> (or copy it from any VS 2005 cd).

Thanks for the info! For now I'm going to stick to the opensource
netwide assembler. Somewhere in the future we have to decide if we stick
to the opensource assembler as default or choose to use the Microsoft
assembler when available.

Christian


From lists at cheimes.de  Mon Nov 19 21:02:51 2007
From: lists at cheimes.de (Christian Heimes)
Date: Mon, 19 Nov 2007 21:02:51 +0100
Subject: [Python-3000] Compiling Python 3.0 with VS 2008 Beta2
In-Reply-To: <fhim2r$4lq$1@ger.gmane.org>
References: <fhim2r$4lq$1@ger.gmane.org>
Message-ID: <fhsq5b$aon$1@ger.gmane.org>

Next update:

I've done some more work on the PCbuild9 directory. I've removed the
ReleaseAMD64 solution and replaced it with platform x64. I've also taken
some effort to get the 64bit builds of the dependencies ready and
integrate them in the build process.

The openssl package required some hard kicking. I had to patch the
auto-generated makefile to build the 64bit version in a separate
directory and get the cross compiler x86_amd64 to work.

With the latest commit every dependency except of Tcl TK are build
automatically during the build process. Of course you have to put the
source directories in the right place and for bsddb you have to convert
the solution files of db-4.4 to VS 2008.

TODO:

* I don't own a 64 bit processor. Can somebody please test the 64bit
build? The cross compile seems to work but I'm unsure if it really works.

* The PCbuild9 directory doesn't support PGO builds for now. I've
removed them to simplify the project files.

* The dll base address list may be out of date. Somebody with more
knowledge (Mark, Martin?) have to update the list and the project files
with new base addresses.

* We have to decide if we are going to support older releases of Visual
Studio. I like to remove the support for 6.0 and 7.1 from
distutils.msvccompiler. 7.1 came out around 2003 and 6.0 is far older. I
don't have the means to test the modules with ancient compilers.

Christian


From lists at cheimes.de  Mon Nov 19 21:47:06 2007
From: lists at cheimes.de (Christian Heimes)
Date: Mon, 19 Nov 2007 21:47:06 +0100
Subject: [Python-3000] Python 3.0a2 release
Message-ID: <4741F64A.7050902@cheimes.de>

Hi Guido!

Do you have a schedule for the release of the next alpha? If I recall
correctly the alpha 2 is planed for end of November.

Christian

From martin at v.loewis.de  Mon Nov 19 22:12:26 2007
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 19 Nov 2007 22:12:26 +0100
Subject: [Python-3000] Removing windows 95 specific code
In-Reply-To: <e27efe130711190805i674ca87ep8113e60f35904f3a@mail.gmail.com>
References: <e27efe130711190805i674ca87ep8113e60f35904f3a@mail.gmail.com>
Message-ID: <4741FC3A.8060705@v.loewis.de>

> Python 3.0 has already dropped support for Windows 9x in several
> places, and is now expected to only work with the NT family.
> 
> I propose to remove the remaining code specific to windows 9x/ME.
> 
> This includes:
> - Py_WIN_WIDE_FILENAMES is always defined
> - when given a unicode string, try to always use the wide version of
> the win32 api.
> - w9xpopen will disappear
> 
> Are there objections?

Not in principle. However:
a) changes that apply to 2.6 as well should be done there *first*, and
   then merged to 3.x (although there are few of them), and
b) there is debate whether w9xpopen can disappear on NT (Tim Peters once
   hinted that it should stay if COMSPEC is not cmd.exe).

> on posix platforms, os.path.supports_unicode_filenames is False.
> So far, this variable is only used to run test_pep277.py or not. Did
> we make some progress on this topic since the unicode-everywhere
> rewrite? (see also http://bugs.python.org/issue767645 )

No, and I don't think there can be any progress. POSIX will never ever
support arbitrary Unicode file names, in arbitrary locales.
(of course, no system supports *all* possible Unicode strings as file
names, but some have only a tiny list of characters being excluded, plus
constraints on the maximum length of a file name).

Regards,
Martin

From martin at v.loewis.de  Mon Nov 19 22:17:44 2007
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Mon, 19 Nov 2007 22:17:44 +0100
Subject: [Python-3000] Removing windows 95 specific code
In-Reply-To: <ca471dc20711190923q48b742fdxf7f755184fa9f39d@mail.gmail.com>
References: <e27efe130711190805i674ca87ep8113e60f35904f3a@mail.gmail.com>
	<ca471dc20711190923q48b742fdxf7f755184fa9f39d@mail.gmail.com>
Message-ID: <4741FD78.40904@v.loewis.de>

> This may well be wrong, since we're supposed to accept Unicode
> everywhere. I don't know why that variable was introduced.

To control running test_pep277. The variable should only be set to true,
if the following strings are all valid file names:

filenames = [
    'abc',
    'ascii',
    'Gr\xfc\xdf-Gott',
    '\u0393\u03b5\u03b9\u03ac-\u03c3\u03b1\u03c2',

u'\u0417\u0434\u0440\u0430\u0432\u0441\u0442\u0432\u0443\u0439\u0442\u0435',
    '\u306b\u307d\u3093',
    '\u05d4\u05e9\u05e7\u05e6\u05e5\u05e1',
    '\u66e8\u66e9\u66eb',
    '\u66e8\u05e9\u3093\u0434\u0393\xdf',
    ]

(or, in a non-escaped form:)

filenames = [
  'abc',
  'ascii',
  'Gr??-Gott',
  '????-???',
  '????????????',
  '???',
  '??????',
  '???',
  '??????',
]

On a typical Unix system, several of these aren't valid file names
(unless you happen to use a UTF-8 locale, in which case they are all
valid file names).

Regards,
Martin

From guido at python.org  Mon Nov 19 23:15:32 2007
From: guido at python.org (Guido van Rossum)
Date: Mon, 19 Nov 2007 14:15:32 -0800
Subject: [Python-3000] Python 3.0a2 release
In-Reply-To: <4741F64A.7050902@cheimes.de>
References: <4741F64A.7050902@cheimes.de>
Message-ID: <ca471dc20711191415m11141bb0l22ad57c10310cc57@mail.gmail.com>

On Nov 19, 2007 12:47 PM, Christian Heimes <lists at cheimes.de> wrote:
> Do you have a schedule for the release of the next alpha? If I recall
> correctly the alpha 2 is planed for end of November.

Indeed. I think we can still make that goal; there isn't anything big
that I really want in the release. The only think that I'd like to add
is renaming buffer -> bytearray, and perhaps add ABCs for (bytes,
bytearray) and <bytes, memoryview etc.>. Then there's smaller stuff,
like removing more places that accept both PyString and PyUnicode and
forcing them to either require PyUnicode or anything that supports the
buffer API. (E.g. I noticed socket.send() still accepts strings.)

I doubt that I'll be able to get to much of that this week, as it's a
3-day week in the US, and I'm fairly busy with my day job. But next
week I expect to be able to focus on the release.

Is there anything that you (or anyone else!) would really like to see
added to or fixed in 3.0a2? Now's the time!

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

From ncoghlan at gmail.com  Mon Nov 19 23:52:30 2007
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 20 Nov 2007 08:52:30 +1000
Subject: [Python-3000] Please re-add __cmp__ to python 3000
In-Reply-To: <5d44f72f0710292219h11a28c2dk4c7540bc5bd824e4@mail.gmail.com>
References: <E1IiBwH-0003sz-04@fenris.runbox.com>	<d11dcfba0710171027tbfeb31dw6f89ff77f6d51fcd@mail.gmail.com>	<47169E6E.7000804@canterbury.ac.nz>	<E1ImZR5-000251-4n@garm.runbox.com>	<d11dcfba0710291304qcf5b757m64048d1fc044c42a@mail.gmail.com>
	<5d44f72f0710292219h11a28c2dk4c7540bc5bd824e4@mail.gmail.com>
Message-ID: <474213AE.2060402@gmail.com>

Jeffrey Yasskin wrote:
> For Python, I think I favor reviving __cmp__ for totally ordered
> types, and asking that partially ordered ones return NotImplemented
> from it explicitly.

Returning NotImplemented already means "I don't recognise the other 
type". A fully implemented partial ordering is not the same thing.

None could possibly be coopted for the job of representing 
unequal-but-not-ordered, but has the major downside of evaluating to 
False as a truth value.

A new task-specific singleton as a Greg suggested is a definite 
possibility though.

Cheers,
Nick.

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

From amauryfa at gmail.com  Tue Nov 20 00:06:56 2007
From: amauryfa at gmail.com (Amaury Forgeot d'Arc)
Date: Tue, 20 Nov 2007 00:06:56 +0100
Subject: [Python-3000] Python 3.0a2 release
In-Reply-To: <ca471dc20711191415m11141bb0l22ad57c10310cc57@mail.gmail.com>
References: <4741F64A.7050902@cheimes.de>
	<ca471dc20711191415m11141bb0l22ad57c10310cc57@mail.gmail.com>
Message-ID: <e27efe130711191506o7e56cfb4p75154b4d3dfddd17@mail.gmail.com>

Guido van Rossum wrote:
> Is there anything that you (or anyone else!) would really like to see
> added to or fixed in 3.0a2? Now's the time!

I am currently having a look at http://bugs.python.org/issue1460 .
It's a problem in the utf-7 decoder (there is no such function
PyUnicode_DecodeUTF7Stateful), but I was surprised to see that
codec.StreamReader duplicates a lot of code already present in io.py:
an underlying binary stream, a decoder, a buffer (of 72 chars), some
code to handle \r\n and so on.

I wonder if it is possible to remove this class: are there differences
between codec.StreamReader and io.TextIOWrapper ?

-- 
Amaury Forgeot d'Arc

From guido at python.org  Tue Nov 20 00:44:23 2007
From: guido at python.org (Guido van Rossum)
Date: Mon, 19 Nov 2007 15:44:23 -0800
Subject: [Python-3000] Python 3.0a2 release
In-Reply-To: <e27efe130711191506o7e56cfb4p75154b4d3dfddd17@mail.gmail.com>
References: <4741F64A.7050902@cheimes.de>
	<ca471dc20711191415m11141bb0l22ad57c10310cc57@mail.gmail.com>
	<e27efe130711191506o7e56cfb4p75154b4d3dfddd17@mail.gmail.com>
Message-ID: <ca471dc20711191544s3e83d5a6v98827bee5c0be823@mail.gmail.com>

On Nov 19, 2007 3:06 PM, Amaury Forgeot d'Arc <amauryfa at gmail.com> wrote:
> Guido van Rossum wrote:
> > Is there anything that you (or anyone else!) would really like to see
> > added to or fixed in 3.0a2? Now's the time!
>
> I am currently having a look at http://bugs.python.org/issue1460 .
> It's a problem in the utf-7 decoder (there is no such function
> PyUnicode_DecodeUTF7Stateful), but I was surprised to see that
> codec.StreamReader duplicates a lot of code already present in io.py:
> an underlying binary stream, a decoder, a buffer (of 72 chars), some
> code to handle \r\n and so on.
>
> I wonder if it is possible to remove this class: are there differences
> between codec.StreamReader and io.TextIOWrapper ?

Good point. The redundancy is historic; StreamReader is older, and
performed the same function in 2.x that TextIOWrapper performs in 3.x,
but the latter was written from scratch (and in fact without looking
at the former) to match the API provided by text files in 2.x more
closely. If you see anything in StreamReader that could make
TextIOWrapper faster, I'd love to hear about it. I expect that in 3.0
final, the classes in codecs will probably be implemented using
TextIOWrapper.

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

From lists at cheimes.de  Tue Nov 20 00:58:50 2007
From: lists at cheimes.de (Christian Heimes)
Date: Tue, 20 Nov 2007 00:58:50 +0100
Subject: [Python-3000] Python 3.0a2 release
In-Reply-To: <ca471dc20711191415m11141bb0l22ad57c10310cc57@mail.gmail.com>
References: <4741F64A.7050902@cheimes.de>
	<ca471dc20711191415m11141bb0l22ad57c10310cc57@mail.gmail.com>
Message-ID: <fht7vq$t61$1@ger.gmane.org>

Guido van Rossum wrote:
> Is there anything that you (or anyone else!) would really like to see
> added to or fixed in 3.0a2? Now's the time!

I like to have the bugs w/o priority or high and important priority
reviewed before we release 3.0a2.

http://bugs.python.org/issue?@columns=title,id,activity,status&@sort=-activity&@group=priority&@filter=versions,status&@pagesize=50&@startwith=0&status=1&versions=12&@dispname=py3k%20open

We should also start to discuss how to address some Windows problems.
Amaury has brought up some important points and I like to get some
feedback on the default compiler topic. Are we going to drop VS 2003
after the 3.0a2 release and use VS 2008 as the default compiler?

Christian


From guido at python.org  Tue Nov 20 01:09:07 2007
From: guido at python.org (Guido van Rossum)
Date: Mon, 19 Nov 2007 16:09:07 -0800
Subject: [Python-3000] Python 3.0a2 release
In-Reply-To: <fht7vq$t61$1@ger.gmane.org>
References: <4741F64A.7050902@cheimes.de>
	<ca471dc20711191415m11141bb0l22ad57c10310cc57@mail.gmail.com>
	<fht7vq$t61$1@ger.gmane.org>
Message-ID: <ca471dc20711191609r12d6c21ehd8f495df95c754a8@mail.gmail.com>

On Nov 19, 2007 3:58 PM, Christian Heimes <lists at cheimes.de> wrote:
> Guido van Rossum wrote:
> > Is there anything that you (or anyone else!) would really like to see
> > added to or fixed in 3.0a2? Now's the time!
>
> I like to have the bugs w/o priority or high and important priority
> reviewed before we release 3.0a2.
>
> http://bugs.python.org/issue?@columns=title,id,activity,status&@sort=-activity&@group=priority&@filter=versions,status&@pagesize=50&@startwith=0&status=1&versions=12&@dispname=py3k%20open

Agreed. Feel free to assign anything you don't feel comfortable rating to me.

> We should also start to discuss how to address some Windows problems.
> Amaury has brought up some important points and I like to get some
> feedback on the default compiler topic. Are we going to drop VS 2003
> after the 3.0a2 release and use VS 2008 as the default compiler?

I'd like to stay out of this discussion -- this is not about
stabilizing the language or even the implementation but about the
development environment, and I don't have access to Windows ATM.

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

From amauryfa at gmail.com  Tue Nov 20 01:41:03 2007
From: amauryfa at gmail.com (Amaury Forgeot d'Arc)
Date: Tue, 20 Nov 2007 01:41:03 +0100
Subject: [Python-3000] Removing windows 95 specific code
In-Reply-To: <4741FC3A.8060705@v.loewis.de>
References: <e27efe130711190805i674ca87ep8113e60f35904f3a@mail.gmail.com>
	<4741FC3A.8060705@v.loewis.de>
Message-ID: <e27efe130711191641p32231835la60ab0ddb8b10793@mail.gmail.com>

"Martin v. L?wis" wrote:
> > Python 3.0 has already dropped support for Windows 9x in several
> > places, and is now expected to only work with the NT family.
> >
> > I propose to remove the remaining code specific to windows 9x/ME.
> >
> > This includes:
> > - Py_WIN_WIDE_FILENAMES is always defined
> > - when given a unicode string, try to always use the wide version of
> > the win32 api.
> > - w9xpopen will disappear
> >
> > Are there objections?
>
> Not in principle. However:
> a) changes that apply to 2.6 as well should be done there *first*, and
>    then merged to 3.x (although there are few of them), and

Ah, I've just read PEP11 - and windows9x is indeed officially not
supported since 2.6.
However, python 2 must still compile without Py_USING_UNICODE. So I
don't think we can get rid of the ANSI functions from the win32 api.

> b) there is debate whether w9xpopen can disappear on NT (Tim Peters once
>    hinted that it should stay if COMSPEC is not cmd.exe).

command.com does exists on my windows XP box, but is it really used?
Anyway I will do some tests.

cheers,

-- 
Amaury Forgeot d'Arc

From lists at cheimes.de  Tue Nov 20 02:08:44 2007
From: lists at cheimes.de (Christian Heimes)
Date: Tue, 20 Nov 2007 02:08:44 +0100
Subject: [Python-3000] Removing windows 95 specific code
In-Reply-To: <e27efe130711191641p32231835la60ab0ddb8b10793@mail.gmail.com>
References: <e27efe130711190805i674ca87ep8113e60f35904f3a@mail.gmail.com>	<4741FC3A.8060705@v.loewis.de>
	<e27efe130711191641p32231835la60ab0ddb8b10793@mail.gmail.com>
Message-ID: <fhtc2s$7rt$1@ger.gmane.org>

Amaury Forgeot d'Arc wrote:
> command.com does exists on my windows XP box, but is it really used?
> Anyway I will do some tests.

Are people still using 4Dos? :)

Christian


From martin at v.loewis.de  Tue Nov 20 04:48:31 2007
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 20 Nov 2007 04:48:31 +0100
Subject: [Python-3000] Removing windows 95 specific code
In-Reply-To: <e27efe130711191641p32231835la60ab0ddb8b10793@mail.gmail.com>
References: <e27efe130711190805i674ca87ep8113e60f35904f3a@mail.gmail.com>	<4741FC3A.8060705@v.loewis.de>
	<e27efe130711191641p32231835la60ab0ddb8b10793@mail.gmail.com>
Message-ID: <4742590F.9020405@v.loewis.de>

>> a) changes that apply to 2.6 as well should be done there *first*, and
>>    then merged to 3.x (although there are few of them), and
> 
> Ah, I've just read PEP11 - and windows9x is indeed officially not
> supported since 2.6.
> However, python 2 must still compile without Py_USING_UNICODE. So I
> don't think we can get rid of the ANSI functions from the win32 api.

Correct. What *could* be removed is dynamic linking (i.e. where
LoadLibrary/GetProcAddress is done, instead of relying on an import
library). Of course, the question then is what minimum NT version
to support, since older NTs might not have the functions, either.
(my feeling is that Windows 2000 should still be supported; NT4
 support might not be necessary - but then, NT4 isn't currently
 listed in PEP 11)

In addition, the GetFileAttributesEx emulation in posixmodule can be
removed.

Also, the 9X support in WinSound can be removed.

>> b) there is debate whether w9xpopen can disappear on NT (Tim Peters once
>>    hinted that it should stay if COMSPEC is not cmd.exe).
> 
> command.com does exists on my windows XP box, but is it really used?

I think it does get used if you set COMSPEC, and not only by Python,
but (at least) in all cases where the CRT system() is called. Of course,
nobody really sets this environment variable, but we can't know
(unless we officially stop honoring it).

I think the concern is also about shells other than command.com,
such as 4NT (can you set COMSPEC to the PowerShell?). If you google
for it, you find that people do use 4NT, and apparently also make
COMSPEC point to it.

Regards,
Martin

From martin at v.loewis.de  Tue Nov 20 04:56:03 2007
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 20 Nov 2007 04:56:03 +0100
Subject: [Python-3000] Python 3.0a2 release
In-Reply-To: <fht7vq$t61$1@ger.gmane.org>
References: <4741F64A.7050902@cheimes.de>	<ca471dc20711191415m11141bb0l22ad57c10310cc57@mail.gmail.com>
	<fht7vq$t61$1@ger.gmane.org>
Message-ID: <47425AD3.1050705@v.loewis.de>

> We should also start to discuss how to address some Windows problems.
> Amaury has brought up some important points and I like to get some
> feedback on the default compiler topic. Are we going to drop VS 2003
> after the 3.0a2 release and use VS 2008 as the default compiler?

We cannot use that compiler for binary releases until the compiler
itself is released, as the license agreement for the beta releases
of the compiler forbid such usage.

So if VS 2003 support is dropped, releases would have to be made with
VS 2005, until VS 2008 gets released.

Regards,
Martin

From lists at cheimes.de  Tue Nov 20 07:23:57 2007
From: lists at cheimes.de (Christian Heimes)
Date: Tue, 20 Nov 2007 07:23:57 +0100
Subject: [Python-3000] Python 3.0a2 release
In-Reply-To: <47425AD3.1050705@v.loewis.de>
References: <4741F64A.7050902@cheimes.de>	<ca471dc20711191415m11141bb0l22ad57c10310cc57@mail.gmail.com>
	<fht7vq$t61$1@ger.gmane.org> <47425AD3.1050705@v.loewis.de>
Message-ID: <47427D7D.3020002@cheimes.de>

Martin v. L?wis wrote:
>> We should also start to discuss how to address some Windows problems.
>> Amaury has brought up some important points and I like to get some
>> feedback on the default compiler topic. Are we going to drop VS 2003
>> after the 3.0a2 release and use VS 2008 as the default compiler?
> 
> We cannot use that compiler for binary releases until the compiler
> itself is released, as the license agreement for the beta releases
> of the compiler forbid such usage.
>
> So if VS 2003 support is dropped, releases would have to be made with
> VS 2005, until VS 2008 gets released.

I don't want to drop VS 2003 before VS 2008 is released. Please let me
rephrase the sentence and add some information which didn't find the way
from my brain into the keyboard:

Are we going to drop VS 2003 after the 3.0a2 release and use VS 2008 as
the default compiler once it has been released, too?

In other words: Do we want to support outdated compilers for legacy
reasons or can we stick to 2005 as the minimum version? The directory
and registry layouts of 8.0 and 9.0 are almost identical. My
modifications may work for both compilers.

Christian

From p.f.moore at gmail.com  Tue Nov 20 12:38:30 2007
From: p.f.moore at gmail.com (Paul Moore)
Date: Tue, 20 Nov 2007 11:38:30 +0000
Subject: [Python-3000] Removing windows 95 specific code
In-Reply-To: <4742590F.9020405@v.loewis.de>
References: <e27efe130711190805i674ca87ep8113e60f35904f3a@mail.gmail.com>
	<4741FC3A.8060705@v.loewis.de>
	<e27efe130711191641p32231835la60ab0ddb8b10793@mail.gmail.com>
	<4742590F.9020405@v.loewis.de>
Message-ID: <79990c6b0711200338g2bdc3fa9ra42ffa8f0fd2ed4@mail.gmail.com>

On 20/11/2007, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> I think the concern is also about shells other than command.com,
> such as 4NT (can you set COMSPEC to the PowerShell?). If you google
> for it, you find that people do use 4NT, and apparently also make
> COMSPEC point to it.

I certainly use 4NT, and 4NT itself sets COMSPEC to its own path - so
even if COMSPEC is set globally to CMD (the default) then when running
Python from a 4NT command line, you would see COMSPEC set to 4NT.

Having said that, I believe the point with w9xpopen was to work around
the fact that COMMAND.COM fails to pass the return code of the last
run command back to the calling program - so that os.system didn't
accurately report that a program had failed. I don't believe that this
misfeature has survived into any modern command processor, so it would
seem sensible to remove w9xpopen and simply document that if COMSPEC
is COMMAND.COM, then the return code of os.system (and similar) is
unreliable.

Paul.

From p.f.moore at gmail.com  Tue Nov 20 12:51:04 2007
From: p.f.moore at gmail.com (Paul Moore)
Date: Tue, 20 Nov 2007 11:51:04 +0000
Subject: [Python-3000] Python 3.0a2 release
In-Reply-To: <47427D7D.3020002@cheimes.de>
References: <4741F64A.7050902@cheimes.de>
	<ca471dc20711191415m11141bb0l22ad57c10310cc57@mail.gmail.com>
	<fht7vq$t61$1@ger.gmane.org> <47425AD3.1050705@v.loewis.de>
	<47427D7D.3020002@cheimes.de>
Message-ID: <79990c6b0711200351h4dbe7ed6h93e3df14ba2d4210@mail.gmail.com>

On 20/11/2007, Christian Heimes <lists at cheimes.de> wrote:
> Are we going to drop VS 2003 after the 3.0a2 release and use VS 2008 as
> the default compiler once it has been released, too?
>
> In other words: Do we want to support outdated compilers for legacy
> reasons or can we stick to 2005 as the minimum version? The directory
> and registry layouts of 8.0 and 9.0 are almost identical. My
> modifications may work for both compilers.

One key question which will need to be addressed - at the moment, it
is possible to build Python extensions with mingw, and I believe a lot
of people do this (I certainly do!) If we move to VS 2005 or VS 2008,
then this may not be possible (there is specific mingw support for the
msvcr71 CRT DLL, both in distutils, and in mingw). As things currently
stand, mingw doesn't seem to ship with even msvcr80 libraries.

If allowing non-core developers to build Windows binaries without
needing a paid-for compiler is important, then it will be necessary to
make sure that building extensions works with the free versions of VS
(preferably without the huge pain of "install VS express, install SDK,
grab the following extra bits, etc etc" that seems to be the case now
- at the very least, clear and supported instructions on what needs to
be installed should be included).

I would strongly advise against going back to the days where a paid MS
compiler was the only way to build extensions for Windows.

I will help in addressing this issue, but I am limited in my ability
to do so, as I cannot build Python itself (that *does* need full VS
2005/2008, as I understand it) and so all I have to go with is the
snapshot builds (which use VS 2003, and so don't help...)

Paul.

PS To be honest, I'd like to see Python itself buildable with the free
MS tools, but I don't have time to work on that and so that's more of
a dream than a reasonable request to make :-)

From amauryfa at gmail.com  Tue Nov 20 13:34:05 2007
From: amauryfa at gmail.com (Amaury Forgeot d'Arc)
Date: Tue, 20 Nov 2007 13:34:05 +0100
Subject: [Python-3000] Python 3.0a2 release
In-Reply-To: <79990c6b0711200351h4dbe7ed6h93e3df14ba2d4210@mail.gmail.com>
References: <4741F64A.7050902@cheimes.de>
	<ca471dc20711191415m11141bb0l22ad57c10310cc57@mail.gmail.com>
	<fht7vq$t61$1@ger.gmane.org> <47425AD3.1050705@v.loewis.de>
	<47427D7D.3020002@cheimes.de>
	<79990c6b0711200351h4dbe7ed6h93e3df14ba2d4210@mail.gmail.com>
Message-ID: <e27efe130711200434n1b4c9c89o43e0a719b99dd5f8@mail.gmail.com>

Paul Moore wrote:
> On 20/11/2007, Christian Heimes <lists at cheimes.de> wrote:
> > Are we going to drop VS 2003 after the 3.0a2 release and use VS 2008 as
> > the default compiler once it has been released, too?
> >
> > In other words: Do we want to support outdated compilers for legacy
> > reasons or can we stick to 2005 as the minimum version? The directory
> > and registry layouts of 8.0 and 9.0 are almost identical. My
> > modifications may work for both compilers.
>
> One key question which will need to be addressed - at the moment, it
> is possible to build Python extensions with mingw, and I believe a lot
> of people do this (I certainly do!) If we move to VS 2005 or VS 2008,
> then this may not be possible (there is specific mingw support for the
> msvcr71 CRT DLL, both in distutils, and in mingw). As things currently
> stand, mingw doesn't seem to ship with even msvcr80 libraries.
>
> If allowing non-core developers to build Windows binaries without
> needing a paid-for compiler is important, then it will be necessary to
> make sure that building extensions works with the free versions of VS
> (preferably without the huge pain of "install VS express, install SDK,
> grab the following extra bits, etc etc" that seems to be the case now
> - at the very least, clear and supported instructions on what needs to
> be installed should be included).
>
> I would strongly advise against going back to the days where a paid MS
> compiler was the only way to build extensions for Windows.
>
> I will help in addressing this issue, but I am limited in my ability
> to do so, as I cannot build Python itself (that *does* need full VS
> 2005/2008, as I understand it) and so all I have to go with is the
> snapshot builds (which use VS 2003, and so don't help...)

That is what I thought 10 minutes ago.
But I just did this experiment:
I started from an "official" python25 distribution, with "official"
distribution of third-party packages. They are compiled with VC2003.
Then I copied the wxPython directory into my own workspace, which I
compile with VC2005 (the only compiler I have here)

And it works: the demo application runs just fine, I did not see any
problem so far.
I checked that both C runtime libraries are loaded in memory:
python25.dll uses msvcr80.dll, and _code.pyd uses msvcr71.dll.

It seems that the restriction that forces you to use the same compiler
for core python and extension modules does not stand.

Of course, you cannot do everything: for example, FILE* pointers
cannot be exchanged between different instances of the C runtime.

Off the top of my head, here are the restrictions such a module would face:

- PyMem_MALLOC and PyMem_FREE are macros to the malloc() and free()
functions of the current source being compiled. So an extension module
must free itself the memory it has allocated.
- Same thing for tp_alloc and tp_dealloc, which must match.
- Do not use API functions using the FILE* type. For example,
PyParser_ParseFile, PyObject_Print, the tp_print slot (which is
removed in py3k btw).
- Do not exchange file descriptors (but sockets are OK)
- Be sure to include "python.h" with the correct alignment options
[#pragma pack(8)]
- Do not use stdin, stdout and stderr if you want correct buffering.
- Do not play with signals, or only through the python API functions.
- The locale functions may behave differently.

It seems to me that these conditions are not difficult to respect.
Many extension modules already fulfill them.

Am I missing something? Should we lift the restrictions we impose on
compilers of extension modules? Can we carefully design the Python API
to accept different compilers/runtime?

-- 
Amaury Forgeot d'Arc

From p.f.moore at gmail.com  Tue Nov 20 13:51:23 2007
From: p.f.moore at gmail.com (Paul Moore)
Date: Tue, 20 Nov 2007 12:51:23 +0000
Subject: [Python-3000] Python 3.0a2 release
In-Reply-To: <e27efe130711200434n1b4c9c89o43e0a719b99dd5f8@mail.gmail.com>
References: <4741F64A.7050902@cheimes.de>
	<ca471dc20711191415m11141bb0l22ad57c10310cc57@mail.gmail.com>
	<fht7vq$t61$1@ger.gmane.org> <47425AD3.1050705@v.loewis.de>
	<47427D7D.3020002@cheimes.de>
	<79990c6b0711200351h4dbe7ed6h93e3df14ba2d4210@mail.gmail.com>
	<e27efe130711200434n1b4c9c89o43e0a719b99dd5f8@mail.gmail.com>
Message-ID: <79990c6b0711200451o3939d4b2i41e91279b554a8a7@mail.gmail.com>

On 20/11/2007, Amaury Forgeot d'Arc <amauryfa at gmail.com> wrote:
> Am I missing something? Should we lift the restrictions we impose on
> compilers of extension modules? Can we carefully design the Python API
> to accept different compilers/runtime?

I have done similar experiments in the past. There is no formal
definition of where issues may exist, and I have never encountered a
crash in my experiments. However, the "official position" (to whatever
extent there can be an "official" position in a volunteer open source
project) is that the same CRT must be used.

One thing is needed, regardless - distutils must be taught the
appropriate details for any build tools which are supported (for
Python 2.5, this is MSVC 7.1 and mingw). That, I guess, constitutes
the "official" position.

Personally, I don't have a problem, as long as there is a way to build
with free tools and *not* get told "that's not supported, tough" if
problems should arise.

I believe Martin has always been the strongest advocate of the "CRT
must match exactly" position (apologies, Martin, if I've
misremembered). Maybe he could comment.

Paul.

From ncoghlan at gmail.com  Tue Nov 20 14:37:48 2007
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 20 Nov 2007 23:37:48 +1000
Subject: [Python-3000] Python 3.0a2 release
In-Reply-To: <79990c6b0711200451o3939d4b2i41e91279b554a8a7@mail.gmail.com>
References: <4741F64A.7050902@cheimes.de>	<ca471dc20711191415m11141bb0l22ad57c10310cc57@mail.gmail.com>	<fht7vq$t61$1@ger.gmane.org>
	<47425AD3.1050705@v.loewis.de>	<47427D7D.3020002@cheimes.de>	<79990c6b0711200351h4dbe7ed6h93e3df14ba2d4210@mail.gmail.com>	<e27efe130711200434n1b4c9c89o43e0a719b99dd5f8@mail.gmail.com>
	<79990c6b0711200451o3939d4b2i41e91279b554a8a7@mail.gmail.com>
Message-ID: <4742E32C.2020406@gmail.com>

Paul Moore wrote:
> On 20/11/2007, Amaury Forgeot d'Arc <amauryfa at gmail.com> wrote:
>> Am I missing something? Should we lift the restrictions we impose on
>> compilers of extension modules? Can we carefully design the Python API
>> to accept different compilers/runtime?
> 
> I have done similar experiments in the past. There is no formal
> definition of where issues may exist, and I have never encountered a
> crash in my experiments. However, the "official position" (to whatever
> extent there can be an "official" position in a volunteer open source
> project) is that the same CRT must be used.

I believe the reason that's the consensus python-dev position is because 
even though we acknowledge that it is *possible* to use multiple CRT's 
in a single running program, a Python mailing list isn't really the best 
place to ask for advice on what can safely cross the boundary when you 
do it.

Using two different CRT's in the same program massively multiplies the 
number of things that can go wrong. If a problem occurs while mixing 
CRT's, but not-so-mysteriously vanishes when the program is recompiled 
to use a single CRT, it's a fairly safe bet that one of the unwritten 
rules of safe CRT mixing is being violated.

If someone already understands the rules for mixing CRT's and has a 
reason to do it then more power to them (I do it at work all the time 
due to toolset limitations). On the other hand, if someone doesn't 
understand the restrictions, then it isn't our (or the c.l.p crowd's) 
job to teach them.

Cheers,
Nick.

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

From p.f.moore at gmail.com  Tue Nov 20 15:07:14 2007
From: p.f.moore at gmail.com (Paul Moore)
Date: Tue, 20 Nov 2007 14:07:14 +0000
Subject: [Python-3000] Python 3.0a2 release
In-Reply-To: <4742E32C.2020406@gmail.com>
References: <4741F64A.7050902@cheimes.de>
	<ca471dc20711191415m11141bb0l22ad57c10310cc57@mail.gmail.com>
	<fht7vq$t61$1@ger.gmane.org> <47425AD3.1050705@v.loewis.de>
	<47427D7D.3020002@cheimes.de>
	<79990c6b0711200351h4dbe7ed6h93e3df14ba2d4210@mail.gmail.com>
	<e27efe130711200434n1b4c9c89o43e0a719b99dd5f8@mail.gmail.com>
	<79990c6b0711200451o3939d4b2i41e91279b554a8a7@mail.gmail.com>
	<4742E32C.2020406@gmail.com>
Message-ID: <79990c6b0711200607n1fd43f65l24b1b6384a4ab247@mail.gmail.com>

On 20/11/2007, Nick Coghlan <ncoghlan at gmail.com> wrote:
> If someone already understands the rules for mixing CRT's and has a
> reason to do it then more power to them (I do it at work all the time
> due to toolset limitations). On the other hand, if someone doesn't
> understand the restrictions, then it isn't our (or the c.l.p crowd's)
> job to teach them.

I see this point, but as an end user of Python on Windows, all I want
to do is download a binary, install it and use it. So I rely on
packagers to produce these binaries.

Before distutils supported mingw (something I put a fair bit of effort
into) Windows binaries were relatively rare. Now they are the norm. I
don't want to draw unwarranted conclusions, but I fear that without
some free toolset being an option in distutils, the level of
availability of Windows binaries will drop again.

I'd be happy enough for the diistutils --compiler=mingw option to
remain the "free" route, but if that means using msvcr71 (because
mingw doesn't support msvcr 8 or 9) then it's not entirely fair to
treat that configuration as "unsupported" - by all means, put
qualifications on it (as Amaury did above), but if the code's there,
it needs to be treated as a valid option.

I'm NOT asking for some type of major commitment here - just that
requests for help not be rejected with a comment of "you shouldn't be
doing that" if we add distutils code to enable it.

(Of course, if the consensus is that distutils should not support
anything other than the commercial MSVC, I'll accept that and go and
sulk in the corner, rehearsing my "I told you so" speech :-))

Paul.

PS Just to clarify, the level of "mingw support" in current Python
(2.5) includes:
   - The distutils --compiler=mingw support code
   - Inclusion of libpython25.a in the Windows MSI installer
   - The documentation in "Building Python Extensions"

PPS I *will* see what the current status of msvcr8/9 support in the
Mingw project is, but I'm not too hopeful - mingw is currently
undergoing a change of maintainers and progress has slowed a lot.

From p.f.moore at gmail.com  Tue Nov 20 15:17:34 2007
From: p.f.moore at gmail.com (Paul Moore)
Date: Tue, 20 Nov 2007 14:17:34 +0000
Subject: [Python-3000] Python 3.0a2 release
In-Reply-To: <79990c6b0711200607n1fd43f65l24b1b6384a4ab247@mail.gmail.com>
References: <4741F64A.7050902@cheimes.de>
	<ca471dc20711191415m11141bb0l22ad57c10310cc57@mail.gmail.com>
	<fht7vq$t61$1@ger.gmane.org> <47425AD3.1050705@v.loewis.de>
	<47427D7D.3020002@cheimes.de>
	<79990c6b0711200351h4dbe7ed6h93e3df14ba2d4210@mail.gmail.com>
	<e27efe130711200434n1b4c9c89o43e0a719b99dd5f8@mail.gmail.com>
	<79990c6b0711200451o3939d4b2i41e91279b554a8a7@mail.gmail.com>
	<4742E32C.2020406@gmail.com>
	<79990c6b0711200607n1fd43f65l24b1b6384a4ab247@mail.gmail.com>
Message-ID: <79990c6b0711200617x639e53g5635e829d6a2e0c0@mail.gmail.com>

On 20/11/2007, Paul Moore <p.f.moore at gmail.com> wrote:
> PPS I *will* see what the current status of msvcr8/9 support in the
> Mingw project is, but I'm not too hopeful - mingw is currently
> undergoing a change of maintainers and progress has slowed a lot.

Apologies. I had an out of date mingw runtime. It appears that msvcr80
*is* supported with mingw, but that's the latest.

Whether that counts as an argument for sticking with VS 2005, I don't
know. I doubt it, realistically. But it *may* constitute an argument
for not going to VS 2008 until it's actually released (and mingw have
a chance to ship a runtime with appropriate CRT support).

Feel free to use *your* "I told you so" speech on me :-)

Paul.

From walter at livinglogic.de  Tue Nov 20 19:16:40 2007
From: walter at livinglogic.de (=?UTF-8?B?V2FsdGVyIETDtnJ3YWxk?=)
Date: Tue, 20 Nov 2007 19:16:40 +0100
Subject: [Python-3000] Python 3.0a2 release
In-Reply-To: <ca471dc20711191544s3e83d5a6v98827bee5c0be823@mail.gmail.com>
References: <4741F64A.7050902@cheimes.de>	<ca471dc20711191415m11141bb0l22ad57c10310cc57@mail.gmail.com>	<e27efe130711191506o7e56cfb4p75154b4d3dfddd17@mail.gmail.com>
	<ca471dc20711191544s3e83d5a6v98827bee5c0be823@mail.gmail.com>
Message-ID: <47432488.5090405@livinglogic.de>

Guido van Rossum wrote:
> On Nov 19, 2007 3:06 PM, Amaury Forgeot d'Arc <amauryfa at gmail.com> wrote:
>> Guido van Rossum wrote:
>>> Is there anything that you (or anyone else!) would really like to see
>>> added to or fixed in 3.0a2? Now's the time!
>> I am currently having a look at http://bugs.python.org/issue1460 .
>> It's a problem in the utf-7 decoder (there is no such function
>> PyUnicode_DecodeUTF7Stateful), but I was surprised to see that
>> codec.StreamReader duplicates a lot of code already present in io.py:
>> an underlying binary stream, a decoder, a buffer (of 72 chars), some
>> code to handle \r\n and so on.
>>
>> I wonder if it is possible to remove this class: are there differences
>> between codec.StreamReader and io.TextIOWrapper ?
> 
> Good point. The redundancy is historic; StreamReader is older, and
> performed the same function in 2.x that TextIOWrapper performs in 3.x,
> but the latter was written from scratch (and in fact without looking
> at the former) to match the API provided by text files in 2.x more
> closely. If you see anything in StreamReader that could make
> TextIOWrapper faster, I'd love to hear about it. I expect that in 3.0
> final, the classes in codecs will probably be implemented using
> TextIOWrapper.

Reimplementing the streamreaders via TextIOWrapper basically would make
much of the streamreader code go away. The streamreaders are supposed to
be encoding specific wrappers for streams. TextIOWrapper implements this
in *one* class (which uses the appropriate incremental decoder). A
streamreader is basically just a TextIOWrapper where the encoding
argument is fixed.

The only question remaining is: do we need the streamreader classes at all.

Servus,
   Walter


From tomerfiliba at gmail.com  Tue Nov 20 19:44:50 2007
From: tomerfiliba at gmail.com (tomer filiba)
Date: Tue, 20 Nov 2007 10:44:50 -0800 (PST)
Subject: [Python-3000] async io
Message-ID: <7b50be11-b54d-4860-9a29-addd4ad21bd8@f13g2000hsa.googlegroups.com>

hi

the new i/o pep (3116) says the following:
> In order to put an object in object in non-blocking mode, the user
> must extract the fileno and do it by hand.

i remember the discussions of the subject, but it seems wrong to me.
there are (only?) two common use cases for async IO: sockets and
pipes.
most other file-like-things don't make much sense when async, and that
behavior is not supported on all platforms.

still, pipes and sockets support this behavior almost by definition,
sp
it makes a lot of sense to me to have that be part of the interface,
making
it cross-platform.

i have seen (and had to write) a lot of boilerplate, platform-specific
code
dealing with that... i'd love to have it removed with the new i/o
library.


-tomer

From janssen at parc.com  Tue Nov 20 21:00:11 2007
From: janssen at parc.com (Bill Janssen)
Date: Tue, 20 Nov 2007 12:00:11 PST
Subject: [Python-3000] Python 3.0a2 release
In-Reply-To: <47432488.5090405@livinglogic.de> 
References: <4741F64A.7050902@cheimes.de>
	<ca471dc20711191415m11141bb0l22ad57c10310cc57@mail.gmail.com>
	<e27efe130711191506o7e56cfb4p75154b4d3dfddd17@mail.gmail.com>
	<ca471dc20711191544s3e83d5a6v98827bee5c0be823@mail.gmail.com>
	<47432488.5090405@livinglogic.de>
Message-ID: <07Nov20.120014pst."58696"@synergy1.parc.xerox.com>

> The only question remaining is: do we need the streamreader classes at all.

And if we do, perhaps it simply indicates a limitation of the IO
wrapper classes which should be fixed.

Bill

From jimjjewett at gmail.com  Tue Nov 20 21:01:58 2007
From: jimjjewett at gmail.com (Jim Jewett)
Date: Tue, 20 Nov 2007 15:01:58 -0500
Subject: [Python-3000] Trying to understand Python 3's comparisons
In-Reply-To: <200711160749.34997.mark@qtrac.eu>
References: <200711160749.34997.mark@qtrac.eu>
Message-ID: <fb6fbf560711201201q4eb52224xf228e677300292b2@mail.gmail.com>

(top-posting to shorten the reading time)

Note that in 2.5

    >>> Eq("b") < Eq("a")
    True

Your Eq class didn't define a __lt__, so in 2.5, it inherits the
default method, and ends up (in CPython) looking at the object's
address, so the first-created object will be less.  In this case, it
seemed to do the right thing.  In python 3, that fallback is gone, and
uncomparable things can't be ordered.

More details:

Python treats the comparisons as almost[*] arbitrary binary
operations.  There are even some hacks that take advantage of this to
use funky notation.

This does mean that it doesn't fall back on logical equivalences.  It
is entirely possible (though pathological) for two objects to be both
equal and unequal, or for one to be both less-than the other but not
less-than-or-equal.

[*]There are two exceptions to the "arbitrary functions" rule.  If an
operation is not defined by the left operand, python will try to the
reversed operation from the right operand.  So when you asked for
"a>b" you got forwarded to "b<a".  There is also a shortcut so that "a
is b" ==> (a ==b and not a != b)

So why is python 3 different from python 2?  Because in python 2, your
custom object inherited default behavior that let anything be ordered
(unless it took steps to avoid that).  That default ends up looking at
object address, which is why the first-created object is less.  In
python 3, there is no such default.


-jJ

On 11/16/07, Mark Summerfield <mark at qtrac.eu> wrote:
> Hi,
>
> I'm trying to understand Python 3's comparisons.
>
> class Eq:
>     def __init__(self, x=""):
>         self.x = x
>     def __str__(self):
>         return self.x
>     def __eq__(self, other):
>         return str(self) == str(other)
>
> class Lt:
>     def __init__(self, x=""):
>         self.x = x
>     def __str__(self):
>         return self.x
>     def __lt__(self, other):
>         return str(self) < str(other)
>
> class LtEq:
>     def __init__(self, x=""):
>         self.x = x
>     def __str__(self):
>         return self.x
>     def __eq__(self, other):
>         return str(self) == str(other)
>     def __lt__(self, other):
>         return str(self) < str(other)
>
> pairs = ((Eq("a"), Eq("b")), (Lt("a"), Lt("b")), (LtEq("a"), LtEq("b")))
> for a, b in pairs:
>     print("comparing", type(a))
>     try:
>         print("a < b", a < b)
>     except TypeError as err: # TypeError, err in Python 2
>         print(err)
>     # etc, for all the other comparisons
>
> For Python 2 I get this output:
>
> comparing <type 'instance'> # Eq
> a < b True
> a <= b True
> a == b False
> a != b True
> a > b False
> a >= b False
>
> comparing <type 'instance'> # Lt
> a < b True
> a <= b True
> a == b False
> a != b True
> a > b False
> a >= b False
>
> comparing <type 'instance'> #LtEq
> a < b True
> a <= b True
> a == b False
> a != b True
> a > b False
> a >= b False
>
> Clearly this is bad since class Eq has no ordering and class Lt has no
> notion of equality.
>
> For Python 3 I get this output:
>
> comparing <class '__main__.Eq'>
> unorderable types: Eq() < Eq()
> unorderable types: Eq() <= Eq()
> a == b False
> a != b True
> unorderable types: Eq() > Eq()
> unorderable types: Eq() >= Eq()
>
> comparing <class '__main__.Lt'>
> a < b True
> unorderable types: Lt() <= Lt()
> a == b False
> a != b True
> a > b False
> unorderable types: Lt() >= Lt()
>
> comparing <class '__main__.LtEq'>
> a < b True
> unorderable types: LtEq() <= LtEq()
> a == b False
> a != b True
> a > b False
> unorderable types: LtEq() >= LtEq()
>
> This is much better in the case of classes Eq and Lt. But I don't
> understand why class LtEq does not handle <= or =>. Bear in mind that
> for class Eq I only defined ==, Python 3 created != for me; similarly
> for class Lt I defined < and Python created >. Or is my code for LtEq
> wrong?
>
> I know it isn't a problem creating a class decorator or metaclass to
> "complete" LtEq; I'm just trying to understand how Python 3 comparisons
> work.
>
> Thanks!

From lists at cheimes.de  Tue Nov 20 21:55:09 2007
From: lists at cheimes.de (Christian Heimes)
Date: Tue, 20 Nov 2007 21:55:09 +0100
Subject: [Python-3000] Python 3.0a2 release
In-Reply-To: <79990c6b0711200351h4dbe7ed6h93e3df14ba2d4210@mail.gmail.com>
References: <4741F64A.7050902@cheimes.de>	<ca471dc20711191415m11141bb0l22ad57c10310cc57@mail.gmail.com>	<fht7vq$t61$1@ger.gmane.org>
	<47425AD3.1050705@v.loewis.de>	<47427D7D.3020002@cheimes.de>
	<79990c6b0711200351h4dbe7ed6h93e3df14ba2d4210@mail.gmail.com>
Message-ID: <fhvhjd$439$1@ger.gmane.org>

Paul Moore wrote:
[snip]
> I will help in addressing this issue, but I am limited in my ability
> to do so, as I cannot build Python itself (that *does* need full VS
> 2005/2008, as I understand it) and so all I have to go with is the
> snapshot builds (which use VS 2003, and so don't help...)
> 
> Paul.

Have you tried to compile py3k with the express edition of VS 2008 Beta
2? I used the free express edition for my first experiments and it
compiled Python 3.0 just fine. I moved to the standard edition to test
some additional features like PGO and 64bit builds.

I'm not sure but I strongly believe that the express edition is able to
build 32bit builds of Python. As far as I know the express edition can't
build PGO and 64bit builds. Please correct me if I'm wrong.

> PS To be honest, I'd like to see Python itself buildable with the free
> MS tools, but I don't have time to work on that and so that's more of
> a dream than a reasonable request to make :-)

Isn't the express edition the successor of the free MS compiler suite?
I've installed the free command line compiler in the past. It took quite
some effort and I had to collect the pieces all over the internet
because MS doesn't offer the old 7.1 compiler suite any more.

Christian


From martin at v.loewis.de  Tue Nov 20 22:02:35 2007
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 20 Nov 2007 22:02:35 +0100
Subject: [Python-3000] Python 3.0a2 release
In-Reply-To: <47427D7D.3020002@cheimes.de>
References: <4741F64A.7050902@cheimes.de>	<ca471dc20711191415m11141bb0l22ad57c10310cc57@mail.gmail.com>
	<fht7vq$t61$1@ger.gmane.org> <47425AD3.1050705@v.loewis.de>
	<47427D7D.3020002@cheimes.de>
Message-ID: <47434B6B.5050805@v.loewis.de>

> Are we going to drop VS 2003 after the 3.0a2 release and use VS 2008 as
> the default compiler once it has been released, too?

Ah, that. I would certainly hope so - although we may see 3.0a3 first,
as VS 2008 is planned for February.

> In other words: Do we want to support outdated compilers for legacy
> reasons or can we stick to 2005 as the minimum version?

We keep the build files around for a while in the PC subdirectory.
Sometimes, people contribute patches to keep them working, and as
long as there are users, I see no reason to drop the build files.

Python should *definitely* continue to compile with older compilers
(although breaking them is fine if they don't provide header files
for functionality that we would like to use).

> The directory
> and registry layouts of 8.0 and 9.0 are almost identical. My
> modifications may work for both compilers.

I doubt that. VisualStudioProject::Version indicates what compiler
version a project file is good for, so I think the PCbuild9 directory
can only work with VS 2008.

Regards,
Martin

From martin at v.loewis.de  Tue Nov 20 22:11:52 2007
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 20 Nov 2007 22:11:52 +0100
Subject: [Python-3000] Python 3.0a2 release
In-Reply-To: <79990c6b0711200351h4dbe7ed6h93e3df14ba2d4210@mail.gmail.com>
References: <4741F64A.7050902@cheimes.de>	
	<ca471dc20711191415m11141bb0l22ad57c10310cc57@mail.gmail.com>	
	<fht7vq$t61$1@ger.gmane.org> <47425AD3.1050705@v.loewis.de>	
	<47427D7D.3020002@cheimes.de>
	<79990c6b0711200351h4dbe7ed6h93e3df14ba2d4210@mail.gmail.com>
Message-ID: <47434D98.2060508@v.loewis.de>

> I would strongly advise against going back to the days where a paid MS
> compiler was the only way to build extensions for Windows.

Certainly. If Microsoft follows its recent tradition, they will continue
to publish an "express" version of VS 2008 (and then take the "express"
version of VS 2005 offline); these versions have become more functional
in that last years, so you may not need an SDK installation anymore
(and Christian's reports seem to indicate that you can indeed build
with his project files with just the Express version, and no SDK installed).

> I will help in addressing this issue, but I am limited in my ability
> to do so, as I cannot build Python itself (that *does* need full VS
> 2005/2008, as I understand it)

Not with the PCbuild9 directory (and probably not with the PCbuild8
directory, either).

Regards,
Martin

From martin at v.loewis.de  Tue Nov 20 22:27:13 2007
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 20 Nov 2007 22:27:13 +0100
Subject: [Python-3000] Python 3.0a2 release
In-Reply-To: <e27efe130711200434n1b4c9c89o43e0a719b99dd5f8@mail.gmail.com>
References: <4741F64A.7050902@cheimes.de>	<ca471dc20711191415m11141bb0l22ad57c10310cc57@mail.gmail.com>	<fht7vq$t61$1@ger.gmane.org>
	<47425AD3.1050705@v.loewis.de>	<47427D7D.3020002@cheimes.de>	<79990c6b0711200351h4dbe7ed6h93e3df14ba2d4210@mail.gmail.com>
	<e27efe130711200434n1b4c9c89o43e0a719b99dd5f8@mail.gmail.com>
Message-ID: <47435131.7070809@v.loewis.de>

> It seems that the restriction that forces you to use the same compiler
> for core python and extension modules does not stand.
>
> Of course, you cannot do everything: for example, FILE* pointers
> cannot be exchanged between different instances of the C runtime.

I wouldn't call that "it works", if it can actually crash.

The real constraint, of course, is "it works if you don't do any
of the things that don't work, but we can't give an exhaustive,
easy-to-verify list of the things that don't work".

> Off the top of my head, here are the restrictions such a module would face:
> 
> - PyMem_MALLOC and PyMem_FREE are macros to the malloc() and free()
> functions of the current source being compiled. So an extension module
> must free itself the memory it has allocated.
> - Same thing for tp_alloc and tp_dealloc, which must match.
> - Do not use API functions using the FILE* type. For example,
> PyParser_ParseFile, PyObject_Print, the tp_print slot (which is
> removed in py3k btw).
> - Do not exchange file descriptors (but sockets are OK)
> - Be sure to include "python.h" with the correct alignment options
> [#pragma pack(8)]
> - Do not use stdin, stdout and stderr if you want correct buffering.
> - Do not play with signals, or only through the python API functions.
> - The locale functions may behave differently.
> 
> It seems to me that these conditions are not difficult to respect.
> Many extension modules already fulfill them.

Right. Many modules also would crash, and have crashed in the past.

People who understand the rules may break them (or bend them), of
course.

> Am I missing something? Should we lift the restrictions we impose on
> compilers of extension modules? Can we carefully design the Python API
> to accept different compilers/runtime?

What you are missing is that your above list
a) may not be complete, and
b) is difficult to verify for somebody building an extension module
   (whose code he might never look at)

Not sure what you mean by "lift the restrictions" - they have
never really existed, and have been lifted in Python 2.5.
(More precisely - you could always build extensions with
any compiler of your choice that is capable of creating DLLs,
and if you use distutils, you can use any compiler in 2.5 with
proper setup)

Regards,
Martin


From martin at v.loewis.de  Tue Nov 20 22:30:19 2007
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 20 Nov 2007 22:30:19 +0100
Subject: [Python-3000] Python 3.0a2 release
In-Reply-To: <79990c6b0711200451o3939d4b2i41e91279b554a8a7@mail.gmail.com>
References: <4741F64A.7050902@cheimes.de>	<ca471dc20711191415m11141bb0l22ad57c10310cc57@mail.gmail.com>	<fht7vq$t61$1@ger.gmane.org>
	<47425AD3.1050705@v.loewis.de>	<47427D7D.3020002@cheimes.de>	<79990c6b0711200351h4dbe7ed6h93e3df14ba2d4210@mail.gmail.com>	<e27efe130711200434n1b4c9c89o43e0a719b99dd5f8@mail.gmail.com>
	<79990c6b0711200451o3939d4b2i41e91279b554a8a7@mail.gmail.com>
Message-ID: <474351EB.9070903@v.loewis.de>

> I believe Martin has always been the strongest advocate of the "CRT
> must match exactly" position (apologies, Martin, if I've
> misremembered). Maybe he could comment.

See my other comment. For the "unwashed masses", this statement (CRT
must absolutely match), is certainly my recommendation. For some
people, this can be extended to "unless you know precisely what you
are doing".

Python 2.5 distutils supports the mode "I know what I'm doing",
so distutils only imposes the restriction on people who fail to
read and understand the documentation.

Regards,
Martin

From martin at v.loewis.de  Tue Nov 20 22:31:11 2007
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 20 Nov 2007 22:31:11 +0100
Subject: [Python-3000] Python 3.0a2 release
In-Reply-To: <4742E32C.2020406@gmail.com>
References: <4741F64A.7050902@cheimes.de>	<ca471dc20711191415m11141bb0l22ad57c10310cc57@mail.gmail.com>	<fht7vq$t61$1@ger.gmane.org>	<47425AD3.1050705@v.loewis.de>	<47427D7D.3020002@cheimes.de>	<79990c6b0711200351h4dbe7ed6h93e3df14ba2d4210@mail.gmail.com>	<e27efe130711200434n1b4c9c89o43e0a719b99dd5f8@mail.gmail.com>	<79990c6b0711200451o3939d4b2i41e91279b554a8a7@mail.gmail.com>
	<4742E32C.2020406@gmail.com>
Message-ID: <4743521F.8020007@v.loewis.de>

> If someone already understands the rules for mixing CRT's and has a 
> reason to do it then more power to them (I do it at work all the time 
> due to toolset limitations). On the other hand, if someone doesn't 
> understand the restrictions, then it isn't our (or the c.l.p crowd's) 
> job to teach them.

Exactly my view.

Martin

From martin at v.loewis.de  Tue Nov 20 22:33:34 2007
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 20 Nov 2007 22:33:34 +0100
Subject: [Python-3000] Python 3.0a2 release
In-Reply-To: <79990c6b0711200607n1fd43f65l24b1b6384a4ab247@mail.gmail.com>
References: <4741F64A.7050902@cheimes.de>	<ca471dc20711191415m11141bb0l22ad57c10310cc57@mail.gmail.com>	<fht7vq$t61$1@ger.gmane.org>
	<47425AD3.1050705@v.loewis.de>	<47427D7D.3020002@cheimes.de>	<79990c6b0711200351h4dbe7ed6h93e3df14ba2d4210@mail.gmail.com>	<e27efe130711200434n1b4c9c89o43e0a719b99dd5f8@mail.gmail.com>	<79990c6b0711200451o3939d4b2i41e91279b554a8a7@mail.gmail.com>	<4742E32C.2020406@gmail.com>
	<79990c6b0711200607n1fd43f65l24b1b6384a4ab247@mail.gmail.com>
Message-ID: <474352AE.6050306@v.loewis.de>

> I'd be happy enough for the diistutils --compiler=mingw option to
> remain the "free" route, but if that means using msvcr71 (because
> mingw doesn't support msvcr 8 or 9)

I think it's a bit to early to claim that mingw doesn't support
mvcr 9 - that library hasn't even been released yet. When it is
released, it will be supported, I'm sure.

> PPS I *will* see what the current status of msvcr8/9 support in the
> Mingw project is, but I'm not too hopeful - mingw is currently
> undergoing a change of maintainers and progress has slowed a lot.

Do they still accept patches?

Regards,
Martin

From martin at v.loewis.de  Tue Nov 20 22:35:09 2007
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 20 Nov 2007 22:35:09 +0100
Subject: [Python-3000] Python 3.0a2 release
In-Reply-To: <79990c6b0711200617x639e53g5635e829d6a2e0c0@mail.gmail.com>
References: <4741F64A.7050902@cheimes.de>	<ca471dc20711191415m11141bb0l22ad57c10310cc57@mail.gmail.com>	<fht7vq$t61$1@ger.gmane.org>
	<47425AD3.1050705@v.loewis.de>	<47427D7D.3020002@cheimes.de>	<79990c6b0711200351h4dbe7ed6h93e3df14ba2d4210@mail.gmail.com>	<e27efe130711200434n1b4c9c89o43e0a719b99dd5f8@mail.gmail.com>	<79990c6b0711200451o3939d4b2i41e91279b554a8a7@mail.gmail.com>	<4742E32C.2020406@gmail.com>	<79990c6b0711200607n1fd43f65l24b1b6384a4ab247@mail.gmail.com>
	<79990c6b0711200617x639e53g5635e829d6a2e0c0@mail.gmail.com>
Message-ID: <4743530D.8090008@v.loewis.de>

> Whether that counts as an argument for sticking with VS 2005, I don't
> know. I doubt it, realistically. But it *may* constitute an argument
> for not going to VS 2008 until it's actually released

Of course, I won't ship any VS 2008 binaries until VS 2008 is released -
not just because of MingW, but also because the license agreement on
the VS 2008 betas disallows such releases.

Regards,
Martin


From martin at v.loewis.de  Tue Nov 20 22:37:49 2007
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 20 Nov 2007 22:37:49 +0100
Subject: [Python-3000] Python 3.0a2 release
In-Reply-To: <fhvhjd$439$1@ger.gmane.org>
References: <4741F64A.7050902@cheimes.de>	<ca471dc20711191415m11141bb0l22ad57c10310cc57@mail.gmail.com>	<fht7vq$t61$1@ger.gmane.org>	<47425AD3.1050705@v.loewis.de>	<47427D7D.3020002@cheimes.de>	<79990c6b0711200351h4dbe7ed6h93e3df14ba2d4210@mail.gmail.com>
	<fhvhjd$439$1@ger.gmane.org>
Message-ID: <474353AD.3010200@v.loewis.de>

> I'm not sure but I strongly believe that the express edition is able to
> build 32bit builds of Python. As far as I know the express edition can't
> build PGO and 64bit builds. Please correct me if I'm wrong.

I haven't actually tried, but it may be that you can build 64-bit
binaries if you also install the platform SDK - it comes with an amd64
compiler (at least the Vista SDK does). Whether that enables the express
edition to invoke that compiler, I don't know.

>> PS To be honest, I'd like to see Python itself buildable with the free
>> MS tools, but I don't have time to work on that and so that's more of
>> a dream than a reasonable request to make :-)
> 
> Isn't the express edition the successor of the free MS compiler suite?

Correct - or, perhaps, one successor. They also ship free compilers with
the platform SDK (but still not so for x86, IIUC).

Regards,
Martin

From lists at cheimes.de  Tue Nov 20 23:45:30 2007
From: lists at cheimes.de (Christian Heimes)
Date: Tue, 20 Nov 2007 23:45:30 +0100
Subject: [Python-3000] Python 3.0a2 release
In-Reply-To: <47434B6B.5050805@v.loewis.de>
References: <4741F64A.7050902@cheimes.de>	<ca471dc20711191415m11141bb0l22ad57c10310cc57@mail.gmail.com>
	<fht7vq$t61$1@ger.gmane.org> <47425AD3.1050705@v.loewis.de>
	<47427D7D.3020002@cheimes.de> <47434B6B.5050805@v.loewis.de>
Message-ID: <4743638A.4010003@cheimes.de>

Martin v. L?wis wrote:
> We keep the build files around for a while in the PC subdirectory.
> Sometimes, people contribute patches to keep them working, and as
> long as there are users, I see no reason to drop the build files.
> 
> Python should *definitely* continue to compile with older compilers
> (although breaking them is fine if they don't provide header files
> for functionality that we would like to use).

I'm fine with the status quo as long as the community steps in and
helps. I can't test every flavor of VS everytime a file has changed. I'm
having trouble to test VS 2003 since I installed VS 2008. The
installation is somehow conflicting with Nant.

> I doubt that. VisualStudioProject::Version indicates what compiler
> version a project file is good for, so I think the PCbuild9 directory
> can only work with VS 2008.

I see. Perhaps we can backport the PCbuild9 files to PCbuild8 somehow. I
leave the task to somebody else. At least my patch for
distutils.msvccompiler should work for VS 8.0 and VS 9.0.

Christian

From p.f.moore at gmail.com  Wed Nov 21 00:47:15 2007
From: p.f.moore at gmail.com (Paul Moore)
Date: Tue, 20 Nov 2007 23:47:15 +0000
Subject: [Python-3000] Python 3.0a2 release
In-Reply-To: <fhvhjd$439$1@ger.gmane.org>
References: <4741F64A.7050902@cheimes.de>
	<ca471dc20711191415m11141bb0l22ad57c10310cc57@mail.gmail.com>
	<fht7vq$t61$1@ger.gmane.org> <47425AD3.1050705@v.loewis.de>
	<47427D7D.3020002@cheimes.de>
	<79990c6b0711200351h4dbe7ed6h93e3df14ba2d4210@mail.gmail.com>
	<fhvhjd$439$1@ger.gmane.org>
Message-ID: <79990c6b0711201547h6258866dj5e33c9a4f9a22481@mail.gmail.com>

On 20/11/2007, Christian Heimes <lists at cheimes.de> wrote:
> Paul Moore wrote:
> [snip]
> > I will help in addressing this issue, but I am limited in my ability
> > to do so, as I cannot build Python itself (that *does* need full VS
> > 2005/2008, as I understand it) and so all I have to go with is the
> > snapshot builds (which use VS 2003, and so don't help...)
> >
> > Paul.
>
> Have you tried to compile py3k with the express edition of VS 2008 Beta
> 2? I used the free express edition for my first experiments and it
> compiled Python 3.0 just fine. I moved to the standard edition to test
> some additional features like PGO and 64bit builds.
>
> I'm not sure but I strongly believe that the express edition is able to
> build 32bit builds of Python. As far as I know the express edition can't
> build PGO and 64bit builds. Please correct me if I'm wrong.

I will try (at some point). I believe I tried compiling Python 2.x
with VS 2005 Express at some point, and it failed. However, that was
some time ago, and I may be misremembering. I will see if I can try
again, and report back.

Clearly, if VS Express *does* compile Python - particularly if the
"official" build matches an Express version (not true for 2.x at the
moment, it will be for 3.0) - then my concerns go away.

> > PS To be honest, I'd like to see Python itself buildable with the free
> > MS tools, but I don't have time to work on that and so that's more of
> > a dream than a reasonable request to make :-)
>
> Isn't the express edition the successor of the free MS compiler suite?
> I've installed the free command line compiler in the past. It took quite
> some effort and I had to collect the pieces all over the internet
> because MS doesn't offer the old 7.1 compiler suite any more.

The biggest problem with 7.1 was that the free version (built from all
the pieces, as you say) doesn't support the project files used by the
commercial product. If the solution files in PCBuild8 and PCBuild9
work with the Express compilers, then that's the biggest hurdle I
encountered previously resolved.

Paul.

From greg.ewing at canterbury.ac.nz  Wed Nov 21 01:26:30 2007
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Wed, 21 Nov 2007 13:26:30 +1300
Subject: [Python-3000] Python 3.0a2 release
In-Reply-To: <79990c6b0711200607n1fd43f65l24b1b6384a4ab247@mail.gmail.com>
References: <4741F64A.7050902@cheimes.de>
	<ca471dc20711191415m11141bb0l22ad57c10310cc57@mail.gmail.com>
	<fht7vq$t61$1@ger.gmane.org> <47425AD3.1050705@v.loewis.de>
	<47427D7D.3020002@cheimes.de>
	<79990c6b0711200351h4dbe7ed6h93e3df14ba2d4210@mail.gmail.com>
	<e27efe130711200434n1b4c9c89o43e0a719b99dd5f8@mail.gmail.com>
	<79990c6b0711200451o3939d4b2i41e91279b554a8a7@mail.gmail.com>
	<4742E32C.2020406@gmail.com>
	<79990c6b0711200607n1fd43f65l24b1b6384a4ab247@mail.gmail.com>
Message-ID: <47437B36.8070502@canterbury.ac.nz>

Paul Moore wrote:
> I fear that without
> some free toolset being an option in distutils, the level of
> availability of Windows binaries will drop again.

I think it's important that some truly free toolset such as
mingw remains an option. In fact I think it's even more important
than the free MS compilers. The trouble with their so-called
free compilers is that they don't *stay* free -- any given
version is dangled tantalizingly in front of us for a year or
two and then whisked away.

--
Greg

From sergey at optimaltec.com  Wed Nov 21 04:37:23 2007
From: sergey at optimaltec.com (Sergey A. Lipnevich)
Date: Tue, 20 Nov 2007 22:37:23 -0500
Subject: [Python-3000] Python 3.0a2 release
In-Reply-To: <4743530D.8090008@v.loewis.de>
References: <4741F64A.7050902@cheimes.de>	<ca471dc20711191415m11141bb0l22ad57c10310cc57@mail.gmail.com>	<fht7vq$t61$1@ger.gmane.org>	<47425AD3.1050705@v.loewis.de>	<47427D7D.3020002@cheimes.de>	<79990c6b0711200351h4dbe7ed6h93e3df14ba2d4210@mail.gmail.com>	<e27efe130711200434n1b4c9c89o43e0a719b99dd5f8@mail.gmail.com>	<79990c6b0711200451o3939d4b2i41e91279b554a8a7@mail.gmail.com>	<4742E32C.2020406@gmail.com>	<79990c6b0711200607n1fd43f65l24b1b6384a4ab247@mail.gmail.com>	<79990c6b0711200617x639e53g5635e829d6a2e0c0@mail.gmail.com>
	<4743530D.8090008@v.loewis.de>
Message-ID: <fi095h$7fm$1@ger.gmane.org>

Martin v. L?wis wrote:
> Of course, I won't ship any VS 2008 binaries until VS 2008 is released -
> not just because of MingW, but also because the license agreement on
> the VS 2008 betas disallows such releases.

Martin,

Not that it changes anything, but VS 2008 it was released today.
Cheers,

Sergey.


From lists at cheimes.de  Wed Nov 21 05:08:29 2007
From: lists at cheimes.de (Christian Heimes)
Date: Wed, 21 Nov 2007 05:08:29 +0100
Subject: [Python-3000] Python 3.0a2 release
In-Reply-To: <fi095h$7fm$1@ger.gmane.org>
References: <4741F64A.7050902@cheimes.de>	<ca471dc20711191415m11141bb0l22ad57c10310cc57@mail.gmail.com>	<fht7vq$t61$1@ger.gmane.org>	<47425AD3.1050705@v.loewis.de>	<47427D7D.3020002@cheimes.de>	<79990c6b0711200351h4dbe7ed6h93e3df14ba2d4210@mail.gmail.com>	<e27efe130711200434n1b4c9c89o43e0a719b99dd5f8@mail.gmail.com>	<79990c6b0711200451o3939d4b2i41e91279b554a8a7@mail.gmail.com>	<4742E32C.2020406@gmail.com>	<79990c6b0711200607n1fd43f65l24b1b6384a4ab247@mail.gmail.com>	<79990c6b0711200617x639e53g5635e829d6a2e0c0@mail.gmail.com>	<4743530D.8090008@v.loewis.de>
	<fi095h$7fm$1@ger.gmane.org>
Message-ID: <4743AF3D.8090105@cheimes.de>

> Not that it changes anything, but VS 2008 it was released today.
> Cheers,

Nice :)

You can get more information at
http://msdn2.microsoft.com/en-us/vstudio/products/default.aspx

The express edition is available at
http://www.microsoft.com/express/download/

Christian

From mark at qtrac.eu  Wed Nov 21 09:19:50 2007
From: mark at qtrac.eu (Mark Summerfield)
Date: Wed, 21 Nov 2007 08:19:50 +0000
Subject: [Python-3000] Trying to understand Python 3's comparisons
In-Reply-To: <fb6fbf560711201201q4eb52224xf228e677300292b2@mail.gmail.com>
References: <200711160749.34997.mark@qtrac.eu>
	<fb6fbf560711201201q4eb52224xf228e677300292b2@mail.gmail.com>
Message-ID: <200711210819.51018.mark@qtrac.eu>

On 2007-11-20, you wrote:
> (top-posting to shorten the reading time)
>
[snip]
> This does mean that it doesn't fall back on logical equivalences.  It
> is entirely possible (though pathological) for two objects to be both
> equal and unequal, or for one to be both less-than the other but not
> less-than-or-equal.

Ah, this was the point I was missing. If you have < then you can define
all the other comparison in terms of it. Yet when you define < and ==
Python gives you > and != by reversing arguments, but doesn't give you
<= or >= even though it is possible to do so.

I'll write myself a class decorator that can create the "missing"
comparisons using logical equivalences.

Thanks!

> -jJ
>
> On 11/16/07, Mark Summerfield <mark at qtrac.eu> wrote:
> > Hi,
> >
> > I'm trying to understand Python 3's comparisons.
> >
> > class Eq:
> >     def __init__(self, x=""):
> >         self.x = x
> >     def __str__(self):
> >         return self.x
> >     def __eq__(self, other):
> >         return str(self) == str(other)
> >
> > class Lt:
> >     def __init__(self, x=""):
> >         self.x = x
> >     def __str__(self):
> >         return self.x
> >     def __lt__(self, other):
> >         return str(self) < str(other)
> >
> > class LtEq:
> >     def __init__(self, x=""):
> >         self.x = x
> >     def __str__(self):
> >         return self.x
> >     def __eq__(self, other):
> >         return str(self) == str(other)
> >     def __lt__(self, other):
> >         return str(self) < str(other)
> >
> > pairs = ((Eq("a"), Eq("b")), (Lt("a"), Lt("b")), (LtEq("a"), LtEq("b")))
> > for a, b in pairs:
> >     print("comparing", type(a))
> >     try:
> >         print("a < b", a < b)
> >     except TypeError as err: # TypeError, err in Python 2
> >         print(err)
> >     # etc, for all the other comparisons
> >
> > For Python 2 I get this output:
> >
> > comparing <type 'instance'> # Eq
> > a < b True
> > a <= b True
> > a == b False
> > a != b True
> > a > b False
> > a >= b False
> >
> > comparing <type 'instance'> # Lt
> > a < b True
> > a <= b True
> > a == b False
> > a != b True
> > a > b False
> > a >= b False
> >
> > comparing <type 'instance'> #LtEq
> > a < b True
> > a <= b True
> > a == b False
> > a != b True
> > a > b False
> > a >= b False
> >
> > Clearly this is bad since class Eq has no ordering and class Lt has no
> > notion of equality.
> >
> > For Python 3 I get this output:
> >
> > comparing <class '__main__.Eq'>
> > unorderable types: Eq() < Eq()
> > unorderable types: Eq() <= Eq()
> > a == b False
> > a != b True
> > unorderable types: Eq() > Eq()
> > unorderable types: Eq() >= Eq()
> >
> > comparing <class '__main__.Lt'>
> > a < b True
> > unorderable types: Lt() <= Lt()
> > a == b False
> > a != b True
> > a > b False
> > unorderable types: Lt() >= Lt()
> >
> > comparing <class '__main__.LtEq'>
> > a < b True
> > unorderable types: LtEq() <= LtEq()
> > a == b False
> > a != b True
> > a > b False
> > unorderable types: LtEq() >= LtEq()
> >
> > This is much better in the case of classes Eq and Lt. But I don't
> > understand why class LtEq does not handle <= or =>. Bear in mind that
> > for class Eq I only defined ==, Python 3 created != for me; similarly
> > for class Lt I defined < and Python created >. Or is my code for LtEq
> > wrong?
> >
> > I know it isn't a problem creating a class decorator or metaclass to
> > "complete" LtEq; I'm just trying to understand how Python 3 comparisons
> > work.
> >
> > Thanks!



-- 
Mark Summerfield, Qtrac Ltd., www.qtrac.eu


From p.f.moore at gmail.com  Wed Nov 21 10:53:34 2007
From: p.f.moore at gmail.com (Paul Moore)
Date: Wed, 21 Nov 2007 09:53:34 +0000
Subject: [Python-3000] Python 3.0a2 release
In-Reply-To: <4743AF3D.8090105@cheimes.de>
References: <4741F64A.7050902@cheimes.de>
	<79990c6b0711200351h4dbe7ed6h93e3df14ba2d4210@mail.gmail.com>
	<e27efe130711200434n1b4c9c89o43e0a719b99dd5f8@mail.gmail.com>
	<79990c6b0711200451o3939d4b2i41e91279b554a8a7@mail.gmail.com>
	<4742E32C.2020406@gmail.com>
	<79990c6b0711200607n1fd43f65l24b1b6384a4ab247@mail.gmail.com>
	<79990c6b0711200617x639e53g5635e829d6a2e0c0@mail.gmail.com>
	<4743530D.8090008@v.loewis.de> <fi095h$7fm$1@ger.gmane.org>
	<4743AF3D.8090105@cheimes.de>
Message-ID: <79990c6b0711210153j42ed5a4ch4abf7c314a0baf42@mail.gmail.com>

On 21/11/2007, Christian Heimes <lists at cheimes.de> wrote:
> > Not that it changes anything, but VS 2008 it was released today.
> > Cheers,
>
> Nice :)
>
> You can get more information at
> http://msdn2.microsoft.com/en-us/vstudio/products/default.aspx
>
> The express edition is available at
> http://www.microsoft.com/express/download/

Cool. I'm downloading now, and will report back.

Paul.

From lists at cheimes.de  Wed Nov 21 18:07:05 2007
From: lists at cheimes.de (Christian Heimes)
Date: Wed, 21 Nov 2007 18:07:05 +0100
Subject: [Python-3000] Python 3.0a2 release
In-Reply-To: <79990c6b0711210153j42ed5a4ch4abf7c314a0baf42@mail.gmail.com>
References: <4741F64A.7050902@cheimes.de>	<79990c6b0711200351h4dbe7ed6h93e3df14ba2d4210@mail.gmail.com>	<e27efe130711200434n1b4c9c89o43e0a719b99dd5f8@mail.gmail.com>	<79990c6b0711200451o3939d4b2i41e91279b554a8a7@mail.gmail.com>	<4742E32C.2020406@gmail.com>	<79990c6b0711200607n1fd43f65l24b1b6384a4ab247@mail.gmail.com>	<79990c6b0711200617x639e53g5635e829d6a2e0c0@mail.gmail.com>	<4743530D.8090008@v.loewis.de>
	<fi095h$7fm$1@ger.gmane.org>	<4743AF3D.8090105@cheimes.de>
	<79990c6b0711210153j42ed5a4ch4abf7c314a0baf42@mail.gmail.com>
Message-ID: <474465B9.6020900@cheimes.de>

Paul Moore wrote:
> Cool. I'm downloading now, and will report back.

How is it going? Does the PCbuild9 directory work with the final version
of VS C++ Express?

Christian

From p.f.moore at gmail.com  Wed Nov 21 19:00:15 2007
From: p.f.moore at gmail.com (Paul Moore)
Date: Wed, 21 Nov 2007 18:00:15 +0000
Subject: [Python-3000] Python 3.0a2 release
In-Reply-To: <474465B9.6020900@cheimes.de>
References: <4741F64A.7050902@cheimes.de>
	<79990c6b0711200451o3939d4b2i41e91279b554a8a7@mail.gmail.com>
	<4742E32C.2020406@gmail.com>
	<79990c6b0711200607n1fd43f65l24b1b6384a4ab247@mail.gmail.com>
	<79990c6b0711200617x639e53g5635e829d6a2e0c0@mail.gmail.com>
	<4743530D.8090008@v.loewis.de> <fi095h$7fm$1@ger.gmane.org>
	<4743AF3D.8090105@cheimes.de>
	<79990c6b0711210153j42ed5a4ch4abf7c314a0baf42@mail.gmail.com>
	<474465B9.6020900@cheimes.de>
Message-ID: <79990c6b0711211000y4a0692bhbfb5e0874525f87d@mail.gmail.com>

On 21/11/2007, Christian Heimes <lists at cheimes.de> wrote:
> Paul Moore wrote:
> > Cool. I'm downloading now, and will report back.
>
> How is it going? Does the PCbuild9 directory work with the final version
> of VS C++ Express?

I couldn't install at work (don't ask :-() so I'll have to do it at
home. Not tonight, as I'm busy with real life, but I'll report back in
a day or two.

Paul.

From martin at v.loewis.de  Wed Nov 21 20:59:59 2007
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 21 Nov 2007 20:59:59 +0100
Subject: [Python-3000] Python 3.0a2 release
In-Reply-To: <fi095h$7fm$1@ger.gmane.org>
References: <4741F64A.7050902@cheimes.de>	<ca471dc20711191415m11141bb0l22ad57c10310cc57@mail.gmail.com>	<fht7vq$t61$1@ger.gmane.org>	<47425AD3.1050705@v.loewis.de>	<47427D7D.3020002@cheimes.de>	<79990c6b0711200351h4dbe7ed6h93e3df14ba2d4210@mail.gmail.com>	<e27efe130711200434n1b4c9c89o43e0a719b99dd5f8@mail.gmail.com>	<79990c6b0711200451o3939d4b2i41e91279b554a8a7@mail.gmail.com>	<4742E32C.2020406@gmail.com>	<79990c6b0711200607n1fd43f65l24b1b6384a4ab247@mail.gmail.com>	<79990c6b0711200617x639e53g5635e829d6a2e0c0@mail.gmail.com>	<4743530D.8090008@v.loewis.de>
	<fi095h$7fm$1@ger.gmane.org>
Message-ID: <47448E3F.7080604@v.loewis.de>

> Not that it changes anything, but VS 2008 it was released today.

Actually, it may. I'll see whether I can release 3.0a2 with VS 2008.
(which depends on whether I can get it through our MSDN subscription,
and on whether Christian's project files work well enough)

Regards,
Martin

From greg at krypto.org  Wed Nov 21 21:09:36 2007
From: greg at krypto.org (Gregory P. Smith)
Date: Wed, 21 Nov 2007 12:09:36 -0800
Subject: [Python-3000] Python 3.0a2 release
In-Reply-To: <79990c6b0711200617x639e53g5635e829d6a2e0c0@mail.gmail.com>
References: <4741F64A.7050902@cheimes.de> <fht7vq$t61$1@ger.gmane.org>
	<47425AD3.1050705@v.loewis.de> <47427D7D.3020002@cheimes.de>
	<79990c6b0711200351h4dbe7ed6h93e3df14ba2d4210@mail.gmail.com>
	<e27efe130711200434n1b4c9c89o43e0a719b99dd5f8@mail.gmail.com>
	<79990c6b0711200451o3939d4b2i41e91279b554a8a7@mail.gmail.com>
	<4742E32C.2020406@gmail.com>
	<79990c6b0711200607n1fd43f65l24b1b6384a4ab247@mail.gmail.com>
	<79990c6b0711200617x639e53g5635e829d6a2e0c0@mail.gmail.com>
Message-ID: <52dc1c820711211209t7d536d71yffc441e0b9067940@mail.gmail.com>

On 11/20/07, Paul Moore <p.f.moore at gmail.com> wrote:
>
> On 20/11/2007, Paul Moore <p.f.moore at gmail.com> wrote:
> > PPS I *will* see what the current status of msvcr8/9 support in the
> > Mingw project is, but I'm not too hopeful - mingw is currently
> > undergoing a change of maintainers and progress has slowed a lot.
>
> Apologies. I had an out of date mingw runtime. It appears that msvcr80
> *is* supported with mingw, but that's the latest.
>
> Whether that counts as an argument for sticking with VS 2005, I don't
> know. I doubt it, realistically. But it *may* constitute an argument
> for not going to VS 2008 until it's actually released (and mingw have
> a chance to ship a runtime with appropriate CRT support).


I would not hold up a compiler decision based on the mingw project.  Always
use the latest MS compiler released at the time for a x.0 build of any
python.  Doing otherwise costs the world a fortune in lost performance
(higher power consumption via lower efficiency code).  mingw will
undoubtedly catch up on its own.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20071121/a4c3af7f/attachment.htm 

From guido at python.org  Wed Nov 21 21:23:55 2007
From: guido at python.org (Guido van Rossum)
Date: Wed, 21 Nov 2007 12:23:55 -0800
Subject: [Python-3000] Need help with menial tasks
Message-ID: <ca471dc20711211223h3b48633bu3241caf71184411b@mail.gmail.com>

I just changed PEP 3137 to rename the mutable bytes type 'bytearray'
instead of 'buffer', and implemented this change in the py3k branch.

A lot of code in the Py3k branch still returns PyBytes instances
(i.e., bytearray) where it should really return PyString instances
(i.e., bytes). I'm not going to be able to make all these changes
myself; they require a certain amount of care (e.g. the signature for
PyBytes_Resize() is different from that of _PyString_Resize())
although in most cases the unittests don't need to be adjusted
(because PyBytes() and PyString() compare equal and interoperate in
almost all circumstances).

If you have submit privileges, please consider helping out by
submitting changes for this. If you don't have submit privileges,
please help out by submitting patches. Check bugs.python.org
frequently to avoid duplicate work. (Posting names of modules fixed
here would also be welcome.)

The rest of this week is a 4-day holiday weekend in the US, to be
spent strictly eating, shopping and watching sports on tv; I expect I
won't be doing much Py3k work even though I'm unlikely to do much
shopping or watching tv... :-)

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

From theller at ctypes.org  Wed Nov 21 22:12:34 2007
From: theller at ctypes.org (Thomas Heller)
Date: Wed, 21 Nov 2007 22:12:34 +0100
Subject: [Python-3000] Python 3.0a2 release
In-Reply-To: <47448E3F.7080604@v.loewis.de>
References: <4741F64A.7050902@cheimes.de>	<ca471dc20711191415m11141bb0l22ad57c10310cc57@mail.gmail.com>	<fht7vq$t61$1@ger.gmane.org>	<47425AD3.1050705@v.loewis.de>	<47427D7D.3020002@cheimes.de>	<79990c6b0711200351h4dbe7ed6h93e3df14ba2d4210@mail.gmail.com>	<e27efe130711200434n1b4c9c89o43e0a719b99dd5f8@mail.gmail.com>	<79990c6b0711200451o3939d4b2i41e91279b554a8a7@mail.gmail.com>	<4742E32C.2020406@gmail.com>	<79990c6b0711200607n1fd43f65l24b1b6384a4ab247@mail.gmail.com>	<79990c6b0711200617x639e53g5635e829d6a2e0c0@mail.gmail.com>	<4743530D.8090008@v.loewis.de>	<fi095h$7fm$1@ger.gmane.org>
	<47448E3F.7080604@v.loewis.de>
Message-ID: <fi2703$dvm$1@ger.gmane.org>

Martin v. L?wis schrieb:
>> Not that it changes anything, but VS 2008 it was released today.
> 
> Actually, it may. I'll see whether I can release 3.0a2 with VS 2008.
> (which depends on whether I can get it through our MSDN subscription,
> and on whether Christian's project files work well enough)

Download link for MSDN subscribers:

http://msdn2.microsoft.com/de-de/subscriptions/bb608344.aspx

Thomas


From amauryfa at gmail.com  Wed Nov 21 23:35:11 2007
From: amauryfa at gmail.com (Amaury Forgeot d'Arc)
Date: Wed, 21 Nov 2007 23:35:11 +0100
Subject: [Python-3000] Python 3.0a2 release
In-Reply-To: <474465B9.6020900@cheimes.de>
References: <4741F64A.7050902@cheimes.de>
	<79990c6b0711200451o3939d4b2i41e91279b554a8a7@mail.gmail.com>
	<4742E32C.2020406@gmail.com>
	<79990c6b0711200607n1fd43f65l24b1b6384a4ab247@mail.gmail.com>
	<79990c6b0711200617x639e53g5635e829d6a2e0c0@mail.gmail.com>
	<4743530D.8090008@v.loewis.de> <fi095h$7fm$1@ger.gmane.org>
	<4743AF3D.8090105@cheimes.de>
	<79990c6b0711210153j42ed5a4ch4abf7c314a0baf42@mail.gmail.com>
	<474465B9.6020900@cheimes.de>
Message-ID: <e27efe130711211435h660c594bv951f8cc7209f04fc@mail.gmail.com>

2007/11/21, Christian Heimes <lists at cheimes.de>:
> Paul Moore wrote:
> > Cool. I'm downloading now, and will report back.
>
> How is it going? Does the PCbuild9 directory work with the final version
> of VS C++ Express?

Yes, it seems to work. I am currently running the test suite, with
good results so far.
So far, I have just a problem when importing bz2 in debug builds.

-- 
Amaury Forgeot d'Arc

From dalcinl at gmail.com  Thu Nov 22 00:48:15 2007
From: dalcinl at gmail.com (Lisandro Dalcin)
Date: Wed, 21 Nov 2007 20:48:15 -0300
Subject: [Python-3000] Need help with menial tasks
In-Reply-To: <ca471dc20711211223h3b48633bu3241caf71184411b@mail.gmail.com>
References: <ca471dc20711211223h3b48633bu3241caf71184411b@mail.gmail.com>
Message-ID: <e7ba66e40711211548u163e7abeg6ed4055dd0f30373@mail.gmail.com>

On 11/21/07, Guido van Rossum <guido at python.org> wrote:
> I just changed PEP 3137 to rename the mutable bytes type 'bytearray'
> instead of 'buffer', and implemented this change in the py3k branch.

Have you ever consider using 'bytes' for the mutable and 'frozenbytes'
for the inmutable?


-- 
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  Thu Nov 22 01:09:08 2007
From: guido at python.org (Guido van Rossum)
Date: Wed, 21 Nov 2007 16:09:08 -0800
Subject: [Python-3000] Need help with menial tasks
In-Reply-To: <e7ba66e40711211548u163e7abeg6ed4055dd0f30373@mail.gmail.com>
References: <ca471dc20711211223h3b48633bu3241caf71184411b@mail.gmail.com>
	<e7ba66e40711211548u163e7abeg6ed4055dd0f30373@mail.gmail.com>
Message-ID: <ca471dc20711211609o4c8e6702xce1b872ec48aa9fc@mail.gmail.com>

On Nov 21, 2007 3:48 PM, Lisandro Dalcin <dalcinl at gmail.com> wrote:
> On 11/21/07, Guido van Rossum <guido at python.org> wrote:
> > I just changed PEP 3137 to rename the mutable bytes type 'bytearray'
> > instead of 'buffer', and implemented this change in the py3k branch.
>
> Have you ever consider using 'bytes' for the mutable and 'frozenbytes'
> for the inmutable?

Not until you brought it up just now, but I already don't like it.
Unlike set/frozenset, for bytes, the common use case is the immutable
type, so that should have the shorter name.

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

From amauryfa at gmail.com  Thu Nov 22 02:19:13 2007
From: amauryfa at gmail.com (Amaury Forgeot d'Arc)
Date: Thu, 22 Nov 2007 02:19:13 +0100
Subject: [Python-3000] Need help with menial tasks
In-Reply-To: <ca471dc20711211223h3b48633bu3241caf71184411b@mail.gmail.com>
References: <ca471dc20711211223h3b48633bu3241caf71184411b@mail.gmail.com>
Message-ID: <e27efe130711211719m1efa9f5cj3cb684842a58125@mail.gmail.com>

Guido van Rossum:
> I just changed PEP 3137 to rename the mutable bytes type 'bytearray'
> instead of 'buffer', and implemented this change in the py3k branch.
>
> A lot of code in the Py3k branch still returns PyBytes instances
> (i.e., bytearray) where it should really return PyString instances
> (i.e., bytes). I'm not going to be able to make all these changes
> myself; they require a certain amount of care (e.g. the signature for
> PyBytes_Resize() is different from that of _PyString_Resize())
> although in most cases the unittests don't need to be adjusted
> (because PyBytes() and PyString() compare equal and interoperate in
> almost all circumstances).
>
> If you have submit privileges, please consider helping out by
> submitting changes for this. If you don't have submit privileges,
> please help out by submitting patches. Check bugs.python.org
> frequently to avoid duplicate work. (Posting names of modules fixed
> here would also be welcome.)

audioop: done.


I noticed that PyString_AsString also accepts PyUnicode objects.
Should we try to remove this?

-- 
Amaury Forgeot d'Arc

From lists at cheimes.de  Thu Nov 22 05:39:22 2007
From: lists at cheimes.de (Christian Heimes)
Date: Thu, 22 Nov 2007 05:39:22 +0100
Subject: [Python-3000] Python 3.0a2 release
In-Reply-To: <52dc1c820711211209t7d536d71yffc441e0b9067940@mail.gmail.com>
References: <4741F64A.7050902@cheimes.de>
	<fht7vq$t61$1@ger.gmane.org>	<47425AD3.1050705@v.loewis.de>
	<47427D7D.3020002@cheimes.de>	<79990c6b0711200351h4dbe7ed6h93e3df14ba2d4210@mail.gmail.com>	<e27efe130711200434n1b4c9c89o43e0a719b99dd5f8@mail.gmail.com>	<79990c6b0711200451o3939d4b2i41e91279b554a8a7@mail.gmail.com>	<4742E32C.2020406@gmail.com>	<79990c6b0711200607n1fd43f65l24b1b6384a4ab247@mail.gmail.com>	<79990c6b0711200617x639e53g5635e829d6a2e0c0@mail.gmail.com>
	<52dc1c820711211209t7d536d71yffc441e0b9067940@mail.gmail.com>
Message-ID: <474507FA.7070608@cheimes.de>

Gregory P. Smith wrote:
> I would not hold up a compiler decision based on the mingw project.  Always
> use the latest MS compiler released at the time for a x.0 build of any
> python.  Doing otherwise costs the world a fortune in lost performance
> (higher power consumption via lower efficiency code).  mingw will
> undoubtedly catch up on its own.

That raises another question. Should the official releases use PGO
(profile guided optimization) and how should the profiles be created?

PGO is an optimization system which works in two steps. At first a PGO
instrument build is compiled. The instrument build is linked against an
additional library. Next one or several typical applications are run to
gather profiling information. Finally the project is compiled against
using the profiles to optimize the new build.

Christian

From greg at krypto.org  Thu Nov 22 07:32:11 2007
From: greg at krypto.org (Gregory P. Smith)
Date: Wed, 21 Nov 2007 22:32:11 -0800
Subject: [Python-3000] Python 3.0a2 release
In-Reply-To: <474507FA.7070608@cheimes.de>
References: <4741F64A.7050902@cheimes.de> <47427D7D.3020002@cheimes.de>
	<79990c6b0711200351h4dbe7ed6h93e3df14ba2d4210@mail.gmail.com>
	<e27efe130711200434n1b4c9c89o43e0a719b99dd5f8@mail.gmail.com>
	<79990c6b0711200451o3939d4b2i41e91279b554a8a7@mail.gmail.com>
	<4742E32C.2020406@gmail.com>
	<79990c6b0711200607n1fd43f65l24b1b6384a4ab247@mail.gmail.com>
	<79990c6b0711200617x639e53g5635e829d6a2e0c0@mail.gmail.com>
	<52dc1c820711211209t7d536d71yffc441e0b9067940@mail.gmail.com>
	<474507FA.7070608@cheimes.de>
Message-ID: <52dc1c820711212232t7a971bcat45b5929af746915@mail.gmail.com>

On 11/21/07, Christian Heimes <lists at cheimes.de> wrote:
> Gregory P. Smith wrote:
> > I would not hold up a compiler decision based on the mingw project.  Always
> > use the latest MS compiler released at the time for a x.0 build of any
> > python.  Doing otherwise costs the world a fortune in lost performance
> > (higher power consumption via lower efficiency code).  mingw will
> > undoubtedly catch up on its own.
>
> That raises another question. Should the official releases use PGO
> (profile guided optimization) and how should the profiles be created?
>
> PGO is an optimization system which works in two steps. At first a PGO
> instrument build is compiled. The instrument build is linked against an
> additional library. Next one or several typical applications are run to
> gather profiling information. Finally the project is compiled against
> using the profiles to optimize the new build.
>
> Christian
>

I'd say yes, it should demonstrably produce faster code (easy to test
that).  I don't know what workload to suggest, pystone could be one
place to start.  Possibly even just a small subset of the test suite
would be enough.  The idea is to exercise the basics so it can
optimize with knowledge of actual common control flow paths and hot
spots in mind, it may not require much.

-gps

From lists at cheimes.de  Thu Nov 22 07:49:42 2007
From: lists at cheimes.de (Christian Heimes)
Date: Thu, 22 Nov 2007 07:49:42 +0100
Subject: [Python-3000] PyObject_AsString()
Message-ID: <fi38q6$1ka$1@ger.gmane.org>

A lot of functions in Python 3.x have blocks like

	if (PyString_Check(sub_obj)) {
		sub = PyString_AS_STRING(sub_obj);
		sub_len = PyString_GET_SIZE(sub_obj);
	}
	else if (PyObject_AsCharBuffer(sub_obj, &sub, &sub_len))
		return NULL;

The functions check for PyString first to gain a little speed up. I like
to add a new function to the abstract object protocol
(Objects/abstract.c) to make code more readable while keeping the speed up.

int inline
PyObject_AsString(PyObject *obj,
		  const char **buffer,
		  Py_ssize_t *buffer_len)
{
	if (PyString_Check(obj)) {
		*buffer = PyString_AS_STRING(obj);
		*buffer_len = PyString_GET_SIZE(obj);
		return 1;
	}
	return (PyObject_AsCharBuffer(obj, buffer, buffer_len));
}

Maybe somebody can come up with a clever macro instead of this short
inline function?

Christian


From martin at v.loewis.de  Thu Nov 22 07:57:09 2007
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 22 Nov 2007 07:57:09 +0100
Subject: [Python-3000] Python 3.0a2 release
In-Reply-To: <52dc1c820711212232t7a971bcat45b5929af746915@mail.gmail.com>
References: <4741F64A.7050902@cheimes.de>
	<47427D7D.3020002@cheimes.de>	<79990c6b0711200351h4dbe7ed6h93e3df14ba2d4210@mail.gmail.com>	<e27efe130711200434n1b4c9c89o43e0a719b99dd5f8@mail.gmail.com>	<79990c6b0711200451o3939d4b2i41e91279b554a8a7@mail.gmail.com>	<4742E32C.2020406@gmail.com>	<79990c6b0711200607n1fd43f65l24b1b6384a4ab247@mail.gmail.com>	<79990c6b0711200617x639e53g5635e829d6a2e0c0@mail.gmail.com>	<52dc1c820711211209t7d536d71yffc441e0b9067940@mail.gmail.com>	<474507FA.7070608@cheimes.de>
	<52dc1c820711212232t7a971bcat45b5929af746915@mail.gmail.com>
Message-ID: <47452845.3050707@v.loewis.de>

> I'd say yes, it should demonstrably produce faster code (easy to test
> that).  

I would be opposed unless a complete automation of that is possible and
can be contributed. For AMD64, I see little hope for that, as I build
the releases in a cross-compilation environment, so I can't run them
on the build machine.

Regards,
Martin

From walter at livinglogic.de  Thu Nov 22 10:39:39 2007
From: walter at livinglogic.de (=?UTF-8?B?V2FsdGVyIETDtnJ3YWxk?=)
Date: Thu, 22 Nov 2007 10:39:39 +0100
Subject: [Python-3000] Need help with menial tasks
In-Reply-To: <e27efe130711211719m1efa9f5cj3cb684842a58125@mail.gmail.com>
References: <ca471dc20711211223h3b48633bu3241caf71184411b@mail.gmail.com>
	<e27efe130711211719m1efa9f5cj3cb684842a58125@mail.gmail.com>
Message-ID: <47454E5B.5030907@livinglogic.de>

Amaury Forgeot d'Arc wrote:
> Guido van Rossum:
>> I just changed PEP 3137 to rename the mutable bytes type 'bytearray'
>> instead of 'buffer', and implemented this change in the py3k branch.
>>
>> A lot of code in the Py3k branch still returns PyBytes instances
>> (i.e., bytearray) where it should really return PyString instances
>> (i.e., bytes). I'm not going to be able to make all these changes
>> myself; they require a certain amount of care (e.g. the signature for
>> PyBytes_Resize() is different from that of _PyString_Resize())
>> although in most cases the unittests don't need to be adjusted
>> (because PyBytes() and PyString() compare equal and interoperate in
>> almost all circumstances).
>>
>> If you have submit privileges, please consider helping out by
>> submitting changes for this. If you don't have submit privileges,
>> please help out by submitting patches. Check bugs.python.org
>> frequently to avoid duplicate work. (Posting names of modules fixed
>> here would also be welcome.)
> 
> audioop: done.

datetime: done.

Servus,
   Walter

From amauryfa at gmail.com  Thu Nov 22 11:03:06 2007
From: amauryfa at gmail.com (Amaury Forgeot d'Arc)
Date: Thu, 22 Nov 2007 11:03:06 +0100
Subject: [Python-3000] PyObject_AsString()
In-Reply-To: <fi38q6$1ka$1@ger.gmane.org>
References: <fi38q6$1ka$1@ger.gmane.org>
Message-ID: <e27efe130711220203yf71d215rc3b1fa450eb4b36f@mail.gmail.com>

Christian Heimes wrote:
> A lot of functions in Python 3.x have blocks like
>
>         if (PyString_Check(sub_obj)) {
>                 sub = PyString_AS_STRING(sub_obj);
>                 sub_len = PyString_GET_SIZE(sub_obj);
>         }
>         else if (PyObject_AsCharBuffer(sub_obj, &sub, &sub_len))
>                 return NULL;
>
> The functions check for PyString first to gain a little speed up. I like
> to add a new function to the abstract object protocol
> (Objects/abstract.c) to make code more readable while keeping the speed up.
>
> int inline
> PyObject_AsString(PyObject *obj,
>                   const char **buffer,
>                   Py_ssize_t *buffer_len)
> {
>         if (PyString_Check(obj)) {
>                 *buffer = PyString_AS_STRING(obj);
>                 *buffer_len = PyString_GET_SIZE(obj);
>                 return 1;
>         }
>         return (PyObject_AsCharBuffer(obj, buffer, buffer_len));
> }

Could this code replace the current PyString_AsStringAndSize, instead
of creating a new function?

-- 
Amaury Forgeot d'Arc

From lists at cheimes.de  Thu Nov 22 11:27:23 2007
From: lists at cheimes.de (Christian Heimes)
Date: Thu, 22 Nov 2007 11:27:23 +0100
Subject: [Python-3000] PyBench results of PGO build
Message-ID: <4745598B.8090609@cheimes.de>

This morning I've fixed the PGO builds of PCbuild9 and compared a PGO
build with a vanilla build. The PGO builds is about 10% faster. I've
used a PyBench and an unit test run as profiling data.

Christian

-------------------------------------------------------------------------------
PYBENCH 2.0 (vanilla build)
-------------------------------------------------------------------------------
* using CPython 3.0a1+ (py3k:59110, Nov 22 2007, 05:42:09) [MSC v.1500
32 bit (Intel)]
* system check interval set to maximum: 2147483647
* using timer: time.clock

Calibrating tests. Please wait... done.

Running 3 round(s) of the suite at warp factor 10:

* Round 1 done in 12.366 seconds.
* Round 2 done in 12.358 seconds.
* Round 3 done in 12.320 seconds.

-------------------------------------------------------------------------------
Benchmark: 2007-11-22 11:18:46
-------------------------------------------------------------------------------

    Rounds: 3
    Warp:   10
    Timer:  time.clock

    Machine Details:
       Platform ID:    Windows-XP-5.1.2600
       Processor:

    Python:
       Implementation: CPython
       Executable:     c:\dev\python\py3k\PCbuild9\python.exe
       Version:        3.0.0
       Compiler:       MSC v.1500 32 bit (Intel)
       Bits:           32bit
       Build:          Nov 22 2007 05:42:09 (#py3k:59110)
       Unicode:        None


Test                             minimum  average  operation  overhead
-------------------------------------------------------------------------------
          BuiltinFunctionCalls:    159ms    163ms    0.32us    0.579ms
           BuiltinMethodLookup:    190ms    199ms    0.19us    0.593ms
                 CompareFloats:    146ms    149ms    0.12us    0.680ms
         CompareFloatsIntegers:    514ms    522ms    0.58us    0.053ms
               CompareIntegers:    227ms    232ms    0.13us    0.915ms
        CompareInternedStrings:    295ms    301ms    0.20us    2.643ms
                  CompareLongs:    156ms    160ms    0.15us    0.589ms
                CompareStrings:    200ms    204ms    0.20us    2.052ms
                 ConcatStrings:    403ms    411ms    0.82us    0.985ms
               CreateInstances:    274ms    312ms    2.78us    0.849ms
            CreateNewInstances:    203ms    204ms    2.42us    0.647ms
       CreateStringsWithConcat:    519ms    594ms    0.59us    1.213ms
                  DictCreation:    139ms    151ms    0.38us    1.011ms
             DictWithFloatKeys:    360ms    366ms    0.41us    1.263ms
           DictWithIntegerKeys:    120ms    135ms    0.11us    1.755ms
            DictWithStringKeys:    147ms    154ms    0.13us    1.711ms
                      ForLoops:    150ms    156ms    6.23us    0.072ms
                    IfThenElse:    157ms    162ms    0.12us    1.271ms
                   ListSlicing:    214ms    241ms   17.24us    0.140ms
                NestedForLoops:    197ms    200ms    0.13us   -0.002ms
          NormalClassAttribute:    362ms    365ms    0.30us    0.832ms
       NormalInstanceAttribute:    282ms    284ms    0.24us    1.046ms
           PythonFunctionCalls:    199ms    201ms    0.61us    0.503ms
             PythonMethodCalls:    271ms    275ms    1.22us    0.301ms
                     Recursion:    336ms    364ms    7.28us    0.860ms
                  SecondImport:    286ms    288ms    2.88us    0.340ms
           SecondPackageImport:    290ms    294ms    2.94us    0.339ms
         SecondSubmoduleImport:    399ms    408ms    4.08us    0.343ms
       SimpleComplexArithmetic:    205ms    209ms    0.24us    0.678ms
        SimpleDictManipulation:    293ms    332ms    0.28us    0.850ms
         SimpleFloatArithmetic:    181ms    183ms    0.14us    1.056ms
      SimpleIntFloatArithmetic:    271ms    275ms    0.21us    0.419ms
       SimpleIntegerArithmetic:    260ms    269ms    0.20us    1.013ms
        SimpleListManipulation:    144ms    170ms    0.15us    1.081ms
          SimpleLongArithmetic:    170ms    177ms    0.27us    0.532ms
                    SmallLists:    287ms    316ms    0.46us    0.625ms
                   SmallTuples:    257ms    261ms    0.48us    0.760ms
         SpecialClassAttribute:    368ms    382ms    0.32us    0.892ms
      SpecialInstanceAttribute:    292ms    295ms    0.25us    0.925ms
                StringMappings:    571ms    578ms    2.29us    0.893ms
              StringPredicates:    243ms    250ms    0.36us    4.530ms
                 StringSlicing:    474ms    487ms    0.87us    1.607ms
                     TryExcept:     84ms     85ms    0.04us    1.256ms
                TryRaiseExcept:    272ms    280ms    4.37us    0.710ms
                  TupleSlicing:    257ms    306ms    1.17us    0.088ms
-------------------------------------------------------------------------------
Totals:                          11824ms  12348ms



-------------------------------------------------------------------------------
PYBENCH 2.0 (PGO build)
-------------------------------------------------------------------------------
* using CPython 3.0a1+ (py3k:59110M, Nov 22 2007, 11:04:21) [MSC v.1500
32 bit (Intel)]
* system check interval set to maximum: 2147483647
* using timer: time.clock

Calibrating tests. Please wait... done.

Running 3 round(s) of the suite at warp factor 10:

* Round 1 done in 10.833 seconds.
* Round 2 done in 11.230 seconds.
* Round 3 done in 11.058 seconds.

-------------------------------------------------------------------------------
Benchmark: 2007-11-22 11:17:59
-------------------------------------------------------------------------------

    Rounds: 3
    Warp:   10
    Timer:  time.clock

    Machine Details:
       Platform ID:    Windows-XP-5.1.2600
       Processor:

    Python:
       Implementation: CPython
       Executable:     c:\dev\python\py3k\PCbuild9\Win32-pgo\python.exe
       Version:        3.0.0
       Compiler:       MSC v.1500 32 bit (Intel)
       Bits:           32bit
       Build:          Nov 22 2007 11:04:21 (#py3k:59110M)
       Unicode:        None


Test                             minimum  average  operation  overhead
-------------------------------------------------------------------------------
          BuiltinFunctionCalls:    139ms    142ms    0.28us    0.414ms
           BuiltinMethodLookup:    188ms    196ms    0.19us    0.479ms
                 CompareFloats:    147ms    148ms    0.12us    0.566ms
         CompareFloatsIntegers:    408ms    414ms    0.46us    0.389ms
               CompareIntegers:    127ms    141ms    0.08us    0.413ms
        CompareInternedStrings:    224ms    226ms    0.15us    2.195ms
                  CompareLongs:    120ms    121ms    0.12us    0.397ms
                CompareStrings:    163ms    169ms    0.17us    1.543ms
                 ConcatStrings:    406ms    434ms    0.87us    1.382ms
               CreateInstances:    237ms    239ms    2.13us    0.739ms
            CreateNewInstances:    179ms    181ms    2.15us    0.549ms
       CreateStringsWithConcat:    483ms    573ms    0.57us    1.413ms
                  DictCreation:    160ms    163ms    0.41us    0.542ms
             DictWithFloatKeys:    351ms    360ms    0.40us    1.014ms
           DictWithIntegerKeys:    117ms    120ms    0.10us    1.399ms
            DictWithStringKeys:    145ms    165ms    0.14us    0.637ms
                      ForLoops:    134ms    153ms    6.11us    0.059ms
                    IfThenElse:    124ms    130ms    0.10us    1.133ms
                   ListSlicing:    237ms    253ms   18.04us    0.118ms
                NestedForLoops:    150ms    179ms    0.12us   -0.002ms
          NormalClassAttribute:    376ms    391ms    0.33us    0.900ms
       NormalInstanceAttribute:    257ms    283ms    0.24us    0.743ms
           PythonFunctionCalls:    201ms    203ms    0.62us    0.437ms
             PythonMethodCalls:    247ms    247ms    1.10us    0.245ms
                     Recursion:    310ms    314ms    6.27us    0.844ms
                  SecondImport:    262ms    284ms    2.84us    0.274ms
           SecondPackageImport:    275ms    297ms    2.97us    0.262ms
         SecondSubmoduleImport:    396ms    404ms    4.04us    0.280ms
       SimpleComplexArithmetic:    157ms    166ms    0.19us    0.525ms
        SimpleDictManipulation:    283ms    286ms    0.24us    0.751ms
         SimpleFloatArithmetic:    124ms    134ms    0.10us    0.830ms
      SimpleIntFloatArithmetic:    219ms    227ms    0.17us    0.877ms
       SimpleIntegerArithmetic:    220ms    250ms    0.19us    0.401ms
        SimpleListManipulation:    141ms    144ms    0.12us    0.868ms
          SimpleLongArithmetic:    151ms    154ms    0.23us    0.408ms
                    SmallLists:    266ms    290ms    0.43us    0.955ms
                   SmallTuples:    220ms    225ms    0.42us    0.642ms
         SpecialClassAttribute:    359ms    408ms    0.34us    0.749ms
      SpecialInstanceAttribute:    257ms    261ms    0.22us    0.782ms
                StringMappings:    348ms    351ms    1.39us    0.740ms
              StringPredicates:    194ms    205ms    0.29us    4.242ms
                 StringSlicing:    430ms    438ms    0.78us    1.398ms
                     TryExcept:     69ms     72ms    0.03us    1.067ms
                TryRaiseExcept:    256ms    267ms    4.18us    0.544ms
                  TupleSlicing:    224ms    230ms    0.88us    0.084ms
-------------------------------------------------------------------------------
Totals:                          10485ms  11041ms




From lists at cheimes.de  Thu Nov 22 11:30:04 2007
From: lists at cheimes.de (Christian Heimes)
Date: Thu, 22 Nov 2007 11:30:04 +0100
Subject: [Python-3000] PyObject_AsString()
In-Reply-To: <e27efe130711220203yf71d215rc3b1fa450eb4b36f@mail.gmail.com>
References: <fi38q6$1ka$1@ger.gmane.org>
	<e27efe130711220203yf71d215rc3b1fa450eb4b36f@mail.gmail.com>
Message-ID: <47455A2C.70403@cheimes.de>

Amaury Forgeot d'Arc wrote:
> Could this code replace the current PyString_AsStringAndSize, instead
> of creating a new function?

I guess it could. But it's a naming question. The method is more general
and takes more than just instances of PyString and its subclasses.
Therefor I think it should be part of the abstract protocol. Guido? :)

Christian



From lists at cheimes.de  Thu Nov 22 11:34:36 2007
From: lists at cheimes.de (Christian Heimes)
Date: Thu, 22 Nov 2007 11:34:36 +0100
Subject: [Python-3000] Python 3.0a2 release
In-Reply-To: <47452845.3050707@v.loewis.de>
References: <4741F64A.7050902@cheimes.de>	<47427D7D.3020002@cheimes.de>	<79990c6b0711200351h4dbe7ed6h93e3df14ba2d4210@mail.gmail.com>	<e27efe130711200434n1b4c9c89o43e0a719b99dd5f8@mail.gmail.com>	<79990c6b0711200451o3939d4b2i41e91279b554a8a7@mail.gmail.com>	<4742E32C.2020406@gmail.com>	<79990c6b0711200607n1fd43f65l24b1b6384a4ab247@mail.gmail.com>	<79990c6b0711200617x639e53g5635e829d6a2e0c0@mail.gmail.com>	<52dc1c820711211209t7d536d71yffc441e0b9067940@mail.gmail.com>	<474507FA.7070608@cheimes.de>	<52dc1c820711212232t7a971bcat45b5929af746915@mail.gmail.com>
	<47452845.3050707@v.loewis.de>
Message-ID: <47455B3C.80704@cheimes.de>

Martin v. L?wis wrote:
> I would be opposed unless a complete automation of that is possible and
> can be contributed. For AMD64, I see little hope for that, as I build
> the releases in a cross-compilation environment, so I can't run them
> on the build machine.

Done ;)
I've modified the PGO builds and the build_pgo batch file I copied from
the PCbuild8 directory. For AMD64 builds we either have to buy you an
AMD64 processor or somebody else has to run the PGI and PGO builds.

Christian

From theller at ctypes.org  Thu Nov 22 12:48:28 2007
From: theller at ctypes.org (Thomas Heller)
Date: Thu, 22 Nov 2007 12:48:28 +0100
Subject: [Python-3000] Python 3.0a2 release
In-Reply-To: <47455B3C.80704@cheimes.de>
References: <4741F64A.7050902@cheimes.de>	<47427D7D.3020002@cheimes.de>	<79990c6b0711200351h4dbe7ed6h93e3df14ba2d4210@mail.gmail.com>	<e27efe130711200434n1b4c9c89o43e0a719b99dd5f8@mail.gmail.com>	<79990c6b0711200451o3939d4b2i41e91279b554a8a7@mail.gmail.com>	<4742E32C.2020406@gmail.com>	<79990c6b0711200607n1fd43f65l24b1b6384a4ab247@mail.gmail.com>	<79990c6b0711200617x639e53g5635e829d6a2e0c0@mail.gmail.com>	<52dc1c820711211209t7d536d71yffc441e0b9067940@mail.gmail.com>	<474507FA.7070608@cheimes.de>	<52dc1c820711212232t7a971bcat45b5929af746915@mail.gmail.com>	<47452845.3050707@v.loewis.de>
	<47455B3C.80704@cheimes.de>
Message-ID: <fi3qac$jcf$1@ger.gmane.org>

Christian Heimes schrieb:
> Martin v. L?wis wrote:
>> I would be opposed unless a complete automation of that is possible and
>> can be contributed. For AMD64, I see little hope for that, as I build
>> the releases in a cross-compilation environment, so I can't run them
>> on the build machine.
> 
> Done ;)
> I've modified the PGO builds and the build_pgo batch file I copied from
> the PCbuild8 directory. For AMD64 builds we either have to buy you an
> AMD64 processor or somebody else has to run the PGI and PGO builds.

Job for the win64 buildbot, maybe?

Thomas


From bborcic at gmail.com  Thu Nov 22 16:45:37 2007
From: bborcic at gmail.com (Boris Borcic)
Date: Thu, 22 Nov 2007 16:45:37 +0100
Subject: [Python-3000] Python 3.0a2 release
In-Reply-To: <52dc1c820711211209t7d536d71yffc441e0b9067940@mail.gmail.com>
References: <4741F64A.7050902@cheimes.de>
	<fht7vq$t61$1@ger.gmane.org>	<47425AD3.1050705@v.loewis.de>
	<47427D7D.3020002@cheimes.de>	<79990c6b0711200351h4dbe7ed6h93e3df14ba2d4210@mail.gmail.com>	<e27efe130711200434n1b4c9c89o43e0a719b99dd5f8@mail.gmail.com>	<79990c6b0711200451o3939d4b2i41e91279b554a8a7@mail.gmail.com>	<4742E32C.2020406@gmail.com>	<79990c6b0711200607n1fd43f65l24b1b6384a4ab247@mail.gmail.com>	<79990c6b0711200617x639e53g5635e829d6a2e0c0@mail.gmail.com>
	<52dc1c820711211209t7d536d71yffc441e0b9067940@mail.gmail.com>
Message-ID: <fi489b$65u$1@ger.gmane.org>

Gregory P. Smith wrote:
> I would not hold up a compiler decision based on the mingw project.  
> Always use the latest MS compiler released at the time for a x.0 build 
> of any python.  Doing otherwise costs the world a fortune in lost 
> performance (higher power consumption via lower efficiency code).  mingw 
> will undoubtedly catch up on its own.

FWIW back in march Giovanni Bajo said on mingw-users that GCC-4.x optimized his 
code base better than MSVC; that was in

http://article.gmane.org/gmane.comp.gnu.mingw.user/21964/

Now there has been an official "technology preview" release of MingW gcc-4.2.1 
sitting on MingW sourceforge download page since mid-summer.

Regards, BB


From lists at cheimes.de  Thu Nov 22 16:58:49 2007
From: lists at cheimes.de (Christian Heimes)
Date: Thu, 22 Nov 2007 16:58:49 +0100
Subject: [Python-3000] Python 3.0a2 release
In-Reply-To: <fi489b$65u$1@ger.gmane.org>
References: <4741F64A.7050902@cheimes.de>	<fht7vq$t61$1@ger.gmane.org>	<47425AD3.1050705@v.loewis.de>	<47427D7D.3020002@cheimes.de>	<79990c6b0711200351h4dbe7ed6h93e3df14ba2d4210@mail.gmail.com>	<e27efe130711200434n1b4c9c89o43e0a719b99dd5f8@mail.gmail.com>	<79990c6b0711200451o3939d4b2i41e91279b554a8a7@mail.gmail.com>	<4742E32C.2020406@gmail.com>	<79990c6b0711200607n1fd43f65l24b1b6384a4ab247@mail.gmail.com>	<79990c6b0711200617x639e53g5635e829d6a2e0c0@mail.gmail.com>	<52dc1c820711211209t7d536d71yffc441e0b9067940@mail.gmail.com>
	<fi489b$65u$1@ger.gmane.org>
Message-ID: <4745A739.9040607@cheimes.de>

Boris Borcic wrote:
> FWIW back in march Giovanni Bajo said on mingw-users that GCC-4.x optimized his 
> code base better than MSVC; that was in
> 
> http://article.gmane.org/gmane.comp.gnu.mingw.user/21964/
> 
> Now there has been an official "technology preview" release of MingW gcc-4.2.1 
> sitting on MingW sourceforge download page since mid-summer.

He is speaking about C++ code and compares it to MSVC 7.1. I'm not a big
MS fan and I certainly don't want to advertise them. MSVC is the
standard compiler for most Windows users. The Windows build should be as
convenient as possible. If our main goal would be speed I'd probably
settle down with the Intel Compiler. ;)

Christian

From martin at v.loewis.de  Thu Nov 22 19:43:30 2007
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 22 Nov 2007 19:43:30 +0100
Subject: [Python-3000] Python 3.0a2 release
In-Reply-To: <47455B3C.80704@cheimes.de>
References: <4741F64A.7050902@cheimes.de>	<47427D7D.3020002@cheimes.de>	<79990c6b0711200351h4dbe7ed6h93e3df14ba2d4210@mail.gmail.com>	<e27efe130711200434n1b4c9c89o43e0a719b99dd5f8@mail.gmail.com>	<79990c6b0711200451o3939d4b2i41e91279b554a8a7@mail.gmail.com>	<4742E32C.2020406@gmail.com>	<79990c6b0711200607n1fd43f65l24b1b6384a4ab247@mail.gmail.com>	<79990c6b0711200617x639e53g5635e829d6a2e0c0@mail.gmail.com>	<52dc1c820711211209t7d536d71yffc441e0b9067940@mail.gmail.com>	<474507FA.7070608@cheimes.de>	<52dc1c820711212232t7a971bcat45b5929af746915@mail.gmail.com>
	<47452845.3050707@v.loewis.de> <47455B3C.80704@cheimes.de>
Message-ID: <4745CDD2.2080308@v.loewis.de>

> I've modified the PGO builds and the build_pgo batch file I copied from
> the PCbuild8 directory. For AMD64 builds we either have to buy you an
> AMD64 processor or somebody else has to run the PGI and PGO builds.

So what's the build process? Is it

1. start a VS build environment shell
2. cd to PCbuild9
3. run "build_pgo"

Any additional steps? Should I pass arguments? Can you kindly document
it in readme.txt?

Regards,
Martin


From lists at cheimes.de  Thu Nov 22 19:52:49 2007
From: lists at cheimes.de (Christian Heimes)
Date: Thu, 22 Nov 2007 19:52:49 +0100
Subject: [Python-3000] Python 3.0a2 release
In-Reply-To: <4745CDD2.2080308@v.loewis.de>
References: <4741F64A.7050902@cheimes.de>	<47427D7D.3020002@cheimes.de>	<79990c6b0711200351h4dbe7ed6h93e3df14ba2d4210@mail.gmail.com>	<e27efe130711200434n1b4c9c89o43e0a719b99dd5f8@mail.gmail.com>	<79990c6b0711200451o3939d4b2i41e91279b554a8a7@mail.gmail.com>	<4742E32C.2020406@gmail.com>	<79990c6b0711200607n1fd43f65l24b1b6384a4ab247@mail.gmail.com>	<79990c6b0711200617x639e53g5635e829d6a2e0c0@mail.gmail.com>	<52dc1c820711211209t7d536d71yffc441e0b9067940@mail.gmail.com>	<474507FA.7070608@cheimes.de>	<52dc1c820711212232t7a971bcat45b5929af746915@mail.gmail.com>
	<47452845.3050707@v.loewis.de> <47455B3C.80704@cheimes.de>
	<4745CDD2.2080308@v.loewis.de>
Message-ID: <4745D001.7080802@cheimes.de>

Martin v. L?wis wrote:
> So what's the build process? Is it
> 
> 1. start a VS build environment shell
> 2. cd to PCbuild9
> 3. run "build_pgo"
> 
> Any additional steps? Should I pass arguments? Can you kindly document
> it in readme.txt?

Yes, you can either use the build_pgo.bat in the PCbuild9 directory or
you can use the GUI. The process is always the same. At first you have
to build a PGInstrument configuration, then you run the output in
$platform-pgi to gather profiling data and finally you have to build a
PGUpdate build. The optimized binaries end up in $platform-pgo.

A word of warning. The PGInstrument builds are *very* slow compared to
normal builds. The bench mark and test suite need about *TEN* times the
time to run.

I promise to update the docs as soon as the new build process has been
tested and approved.

Christian

From martin at v.loewis.de  Thu Nov 22 20:37:15 2007
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 22 Nov 2007 20:37:15 +0100
Subject: [Python-3000] Python 3.0a2 release
In-Reply-To: <4745D001.7080802@cheimes.de>
References: <4741F64A.7050902@cheimes.de>	<47427D7D.3020002@cheimes.de>	<79990c6b0711200351h4dbe7ed6h93e3df14ba2d4210@mail.gmail.com>	<e27efe130711200434n1b4c9c89o43e0a719b99dd5f8@mail.gmail.com>	<79990c6b0711200451o3939d4b2i41e91279b554a8a7@mail.gmail.com>	<4742E32C.2020406@gmail.com>	<79990c6b0711200607n1fd43f65l24b1b6384a4ab247@mail.gmail.com>	<79990c6b0711200617x639e53g5635e829d6a2e0c0@mail.gmail.com>	<52dc1c820711211209t7d536d71yffc441e0b9067940@mail.gmail.com>	<474507FA.7070608@cheimes.de>	<52dc1c820711212232t7a971bcat45b5929af746915@mail.gmail.com>
	<47452845.3050707@v.loewis.de> <47455B3C.80704@cheimes.de>
	<4745CDD2.2080308@v.loewis.de> <4745D001.7080802@cheimes.de>
Message-ID: <4745DA6B.4010002@v.loewis.de>

> A word of warning. The PGInstrument builds are *very* slow compared to
> normal builds. The bench mark and test suite need about *TEN* times the
> time to run.

That's also an issue - releases typically occur under time pressure,
trying to get everything done in a single day. If I prepare the
instrument build in advance, how long can I continue to use the data
before they get outdated?

Regards,
Martin

From martin at v.loewis.de  Thu Nov 22 20:42:44 2007
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 22 Nov 2007 20:42:44 +0100
Subject: [Python-3000] Python 3.0a2 release
In-Reply-To: <fi3qac$jcf$1@ger.gmane.org>
References: <4741F64A.7050902@cheimes.de>	<47427D7D.3020002@cheimes.de>	<79990c6b0711200351h4dbe7ed6h93e3df14ba2d4210@mail.gmail.com>	<e27efe130711200434n1b4c9c89o43e0a719b99dd5f8@mail.gmail.com>	<79990c6b0711200451o3939d4b2i41e91279b554a8a7@mail.gmail.com>	<4742E32C.2020406@gmail.com>	<79990c6b0711200607n1fd43f65l24b1b6384a4ab247@mail.gmail.com>	<79990c6b0711200617x639e53g5635e829d6a2e0c0@mail.gmail.com>	<52dc1c820711211209t7d536d71yffc441e0b9067940@mail.gmail.com>	<474507FA.7070608@cheimes.de>	<52dc1c820711212232t7a971bcat45b5929af746915@mail.gmail.com>	<47452845.3050707@v.loewis.de>	<47455B3C.80704@cheimes.de>
	<fi3qac$jcf$1@ger.gmane.org>
Message-ID: <4745DBB4.5010100@v.loewis.de>

> Job for the win64 buildbot, maybe?

Is it possible to share the profile data across machines?
I would certainly want to build and test the releases on
my own machines, rather than having to rely on a buildbot.
I then rather do a multi-reboot thing where I build the AMD64
profiling binaries, reboot to AMD64 mode, run the binaries,
reboot back to 32-bit mode, build the release, and reboot
again to test the release.

Regards,
Martin

From lists at cheimes.de  Thu Nov 22 21:11:04 2007
From: lists at cheimes.de (Christian Heimes)
Date: Thu, 22 Nov 2007 21:11:04 +0100
Subject: [Python-3000] Python 3.0a2 release
In-Reply-To: <4745DA6B.4010002@v.loewis.de>
References: <4741F64A.7050902@cheimes.de>	<47427D7D.3020002@cheimes.de>	<79990c6b0711200351h4dbe7ed6h93e3df14ba2d4210@mail.gmail.com>	<e27efe130711200434n1b4c9c89o43e0a719b99dd5f8@mail.gmail.com>	<79990c6b0711200451o3939d4b2i41e91279b554a8a7@mail.gmail.com>	<4742E32C.2020406@gmail.com>	<79990c6b0711200607n1fd43f65l24b1b6384a4ab247@mail.gmail.com>	<79990c6b0711200617x639e53g5635e829d6a2e0c0@mail.gmail.com>	<52dc1c820711211209t7d536d71yffc441e0b9067940@mail.gmail.com>	<474507FA.7070608@cheimes.de>	<52dc1c820711212232t7a971bcat45b5929af746915@mail.gmail.com>
	<47452845.3050707@v.loewis.de> <47455B3C.80704@cheimes.de>
	<4745CDD2.2080308@v.loewis.de> <4745D001.7080802@cheimes.de>
	<4745DA6B.4010002@v.loewis.de>
Message-ID: <4745E258.1010206@cheimes.de>

Martin v. L?wis wrote:
> That's also an issue - releases typically occur under time pressure,
> trying to get everything done in a single day. If I prepare the
> instrument build in advance, how long can I continue to use the data
> before they get outdated?

Good point! I've chosen PGUpdate over PGOptimize. The update builds can
reuse profiling data even when some of the C code has changed. The
optimizer simple ignores profiling information of function that have
changed.

As long as the flow of the code doesn't change dramatically between the
last PGI run and the build of the PGO version it should be fine. I'm
using the word "should" here because I really don't know it. I don't
have much experience with PGO.

Christian

From p.f.moore at gmail.com  Thu Nov 22 22:41:12 2007
From: p.f.moore at gmail.com (Paul Moore)
Date: Thu, 22 Nov 2007 21:41:12 +0000
Subject: [Python-3000] Python 3.0a2 release
In-Reply-To: <79990c6b0711211000y4a0692bhbfb5e0874525f87d@mail.gmail.com>
References: <4741F64A.7050902@cheimes.de> <4742E32C.2020406@gmail.com>
	<79990c6b0711200607n1fd43f65l24b1b6384a4ab247@mail.gmail.com>
	<79990c6b0711200617x639e53g5635e829d6a2e0c0@mail.gmail.com>
	<4743530D.8090008@v.loewis.de> <fi095h$7fm$1@ger.gmane.org>
	<4743AF3D.8090105@cheimes.de>
	<79990c6b0711210153j42ed5a4ch4abf7c314a0baf42@mail.gmail.com>
	<474465B9.6020900@cheimes.de>
	<79990c6b0711211000y4a0692bhbfb5e0874525f87d@mail.gmail.com>
Message-ID: <79990c6b0711221341h2180cb09yad4c3e49d34a2ba8@mail.gmail.com>

On 21/11/2007, Paul Moore <p.f.moore at gmail.com> wrote:
> On 21/11/2007, Christian Heimes <lists at cheimes.de> wrote:
> > Paul Moore wrote:
> > > Cool. I'm downloading now, and will report back.
> >
> > How is it going? Does the PCbuild9 directory work with the final version
> > of VS C++ Express?
>
> I couldn't install at work (don't ask :-() so I'll have to do it at
> home. Not tonight, as I'm busy with real life, but I'll report back in
> a day or two.

Python itself seems to build with no problems at all (there was a
mention of "Solution folders" not being supported in Express Edition,
but that doesn't seem to stop anything I need to do to build.

Most of the extensions built fine, and the test suite went through
with no issues. I couldn't get TCL/Tk or SSL to build, but I didn't
try very hard, I have to admit. SSL needs perl, which I don't have
installed (I could install it and try, but no time right now). For
TCL, though, it doesn't seem to build cleanly with VS 2008. Lots of
errors. I'm not sure how useful it would be for me to attempt to get
this resolved, as it's more of a TCL issue at some level. At some
stage, building TCL/Tk needs to be addressed, but as I've never
managed to do so in the past, I may not be the best person to start
right now :-)

But I'm certainly happy to help if that would be useful.

Thanks for the work you've put into PCBuild9, and for porting it back
to 2.6, as well. It looks really good. I may actually be able to go
back to doing some C hacking on the Python core :-)

Paul.

From lists at cheimes.de  Thu Nov 22 22:49:15 2007
From: lists at cheimes.de (Christian Heimes)
Date: Thu, 22 Nov 2007 22:49:15 +0100
Subject: [Python-3000] Python 3.0a2 release
In-Reply-To: <79990c6b0711221341h2180cb09yad4c3e49d34a2ba8@mail.gmail.com>
References: <4741F64A.7050902@cheimes.de> <4742E32C.2020406@gmail.com>	
	<79990c6b0711200607n1fd43f65l24b1b6384a4ab247@mail.gmail.com>	
	<79990c6b0711200617x639e53g5635e829d6a2e0c0@mail.gmail.com>	
	<4743530D.8090008@v.loewis.de> <fi095h$7fm$1@ger.gmane.org>	
	<4743AF3D.8090105@cheimes.de>	
	<79990c6b0711210153j42ed5a4ch4abf7c314a0baf42@mail.gmail.com>	
	<474465B9.6020900@cheimes.de>	
	<79990c6b0711211000y4a0692bhbfb5e0874525f87d@mail.gmail.com>
	<79990c6b0711221341h2180cb09yad4c3e49d34a2ba8@mail.gmail.com>
Message-ID: <4745F95B.70309@cheimes.de>

Paul Moore wrote:
> Python itself seems to build with no problems at all (there was a
> mention of "Solution folders" not being supported in Express Edition,
> but that doesn't seem to stop anything I need to do to build.
> 
> Most of the extensions built fine, and the test suite went through
> with no issues. I couldn't get TCL/Tk or SSL to build, but I didn't
> try very hard, I have to admit. SSL needs perl, which I don't have
> installed (I could install it and try, but no time right now). For
> TCL, though, it doesn't seem to build cleanly with VS 2008. Lots of
> errors. I'm not sure how useful it would be for me to attempt to get
> this resolved, as it's more of a TCL issue at some level. At some
> stage, building TCL/Tk needs to be addressed, but as I've never
> managed to do so in the past, I may not be the best person to start
> right now :-)

That's great news! Thanks for testing VS 2008 Express. Amaury has also
told me that the express edition reorders the content of the project and
solution files. Let's not commit changes made with the express edition.

The SSL port still needs Perl and an assembler. I've chosen nasm for the
x86 builds because it's freely available. ml (MS asm) also works. You
have to change one line in the build_ssl.py file. It may be possible to
put slightly modified openssl sources with pre-generated make files into
the svn repository. As far as I've studied the sources Perl is only
required to build the makefiles and for MKDIR and COPY.

I haven't addressed TCL/TK yet. I'm still using the binaries - which
I've compiled with VS 2003 - for testing. The sources of tcl, tk and tix
need an update as well.

Christian

From lists at cheimes.de  Fri Nov 23 08:09:20 2007
From: lists at cheimes.de (Christian Heimes)
Date: Fri, 23 Nov 2007 08:09:20 +0100
Subject: [Python-3000] building _ssl on Windows
In-Reply-To: <e27efe130711151431p1a067359w67a621061d229f76@mail.gmail.com>
References: <e27efe130711151431p1a067359w67a621061d229f76@mail.gmail.com>
Message-ID: <47467CA0.5040302@cheimes.de>

Amaury Forgeot d'Arc wrote:
> Now, is it really necessary to install perl in order to compile python?
> I managed to avoid it until today :-(

*snip*
I've modified the build_ssl.py script and added pre-generated makefiles
and assembly files to openssl today. From now on you can build Python
w/o Perl. Perl is only required when somebody needs to update openssl.

Christian

From amauryfa at gmail.com  Fri Nov 23 10:34:04 2007
From: amauryfa at gmail.com (Amaury Forgeot d'Arc)
Date: Fri, 23 Nov 2007 10:34:04 +0100
Subject: [Python-3000] building _ssl on Windows
In-Reply-To: <47467CA0.5040302@cheimes.de>
References: <e27efe130711151431p1a067359w67a621061d229f76@mail.gmail.com>
	<47467CA0.5040302@cheimes.de>
Message-ID: <e27efe130711230134y6990854bh53653212f9eca057@mail.gmail.com>

Christian Heimes wrote:
> I've modified the build_ssl.py script and added pre-generated makefiles
> and assembly files to openssl today. From now on you can build Python
> w/o Perl. Perl is only required when somebody needs to update openssl.

Nice! I will try this this afternoon.

However, I am surprised by this comment:
> # Run build_ssl in this order:
> # python.exe build_ssl.py Release x64
> # python.exe build_ssl.py Release Win32
Why so? does the Win32 build rely on some file generated by x64?

I fear that with VC2008 express, x64 compilation is not available, and
that _ssl will not build at all.

-- 
Amaury Forgeot d'Arc

From lists at cheimes.de  Fri Nov 23 10:39:22 2007
From: lists at cheimes.de (Christian Heimes)
Date: Fri, 23 Nov 2007 10:39:22 +0100
Subject: [Python-3000] building _ssl on Windows
In-Reply-To: <e27efe130711230134y6990854bh53653212f9eca057@mail.gmail.com>
References: <e27efe130711151431p1a067359w67a621061d229f76@mail.gmail.com>	
	<47467CA0.5040302@cheimes.de>
	<e27efe130711230134y6990854bh53653212f9eca057@mail.gmail.com>
Message-ID: <47469FCA.7030506@cheimes.de>

Amaury Forgeot d'Arc wrote:
> However, I am surprised by this comment:
>> # Run build_ssl in this order:
>> # python.exe build_ssl.py Release x64
>> # python.exe build_ssl.py Release Win32
> Why so? does the Win32 build rely on some file generated by x64?

openssl doesn't support separate makefiles and build directories for
64bit builds. I'm creating the files in the build_ssl.py script.
"python.exe build_ssl.py Release x64" has to run first because it
creates the 64bit makefile from the 32bit makefile.

The other way around the build process would overwrite the 32bit
makefile with the settings from the 64bit makefile before it is moved over.

Christian

From amauryfa at gmail.com  Fri Nov 23 10:56:28 2007
From: amauryfa at gmail.com (Amaury Forgeot d'Arc)
Date: Fri, 23 Nov 2007 10:56:28 +0100
Subject: [Python-3000] building _ssl on Windows
In-Reply-To: <47469FCA.7030506@cheimes.de>
References: <e27efe130711151431p1a067359w67a621061d229f76@mail.gmail.com>
	<47467CA0.5040302@cheimes.de>
	<e27efe130711230134y6990854bh53653212f9eca057@mail.gmail.com>
	<47469FCA.7030506@cheimes.de>
Message-ID: <e27efe130711230156i479203c2l8119ff33f75d250c@mail.gmail.com>

Christian Heimes wrote:
> Amaury Forgeot d'Arc wrote:
> > However, I am surprised by this comment:
> >> # Run build_ssl in this order:
> >> # python.exe build_ssl.py Release x64
> >> # python.exe build_ssl.py Release Win32
> > Why so? does the Win32 build rely on some file generated by x64?
>
> openssl doesn't support separate makefiles and build directories for
> 64bit builds. I'm creating the files in the build_ssl.py script.
> "python.exe build_ssl.py Release x64" has to run first because it
> creates the 64bit makefile from the 32bit makefile.
>
> The other way around the build process would overwrite the 32bit
> makefile with the settings from the 64bit makefile before it is moved over.

Well, since we control the creation of the makefiles, we could
unconditionally create all makefiles in all builds, and even give them
other names.

Anyway, this is only relevant when updating opensll.
As long as I can click the "build" button in the IDE, the rest is not
worth the trouble.

-- 
Amaury Forgeot d'Arc

From g.brandl at gmx.net  Sun Nov 25 10:08:35 2007
From: g.brandl at gmx.net (Georg Brandl)
Date: Sun, 25 Nov 2007 10:08:35 +0100
Subject: [Python-3000] Unbound methods -- keep creating API?
Message-ID: <fibhjs$jol$1@ger.gmane.org>

We've made class.function return a function, but the unbound method machinery
is still alive. For example, you can still create unbound methods with
new.instancemethod and PyMethod_New, and there's bits of code in classobject.c
that refers to unbound methods.

Should this go too?

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 lists at cheimes.de  Sun Nov 25 11:39:20 2007
From: lists at cheimes.de (Christian Heimes)
Date: Sun, 25 Nov 2007 11:39:20 +0100
Subject: [Python-3000] Unbound methods -- keep creating API?
In-Reply-To: <fibhjs$jol$1@ger.gmane.org>
References: <fibhjs$jol$1@ger.gmane.org>
Message-ID: <fibjco$nb7$1@ger.gmane.org>

Georg Brandl wrote:
> We've made class.function return a function, but the unbound method machinery
> is still alive. For example, you can still create unbound methods with
> new.instancemethod and PyMethod_New, and there's bits of code in classobject.c
> that refers to unbound methods.
> 
> Should this go too?

I'm +1 in removing the code, too. I haven't touched the code yet in the
case we might need it in the interim period.

Christian


From lists at cheimes.de  Sun Nov 25 12:01:17 2007
From: lists at cheimes.de (Christian Heimes)
Date: Sun, 25 Nov 2007 12:01:17 +0100
Subject: [Python-3000] Unbound methods -- keep creating API?
In-Reply-To: <fibjco$nb7$1@ger.gmane.org>
References: <fibhjs$jol$1@ger.gmane.org> <fibjco$nb7$1@ger.gmane.org>
Message-ID: <474955FD.6020200@cheimes.de>

Christian Heimes wrote:
> I'm +1 in removing the code, too. I haven't touched the code yet in the
> case we might need it in the interim period.

I've created a patch and I'm running the test suite now.

Christian

From lists at cheimes.de  Sun Nov 25 12:29:41 2007
From: lists at cheimes.de (Christian Heimes)
Date: Sun, 25 Nov 2007 12:29:41 +0100
Subject: [Python-3000] Unbound methods -- keep creating API?
In-Reply-To: <fibhjs$jol$1@ger.gmane.org>
References: <fibhjs$jol$1@ger.gmane.org>
Message-ID: <fibmb5$tva$1@ger.gmane.org>

Georg Brandl wrote:
> We've made class.function return a function, but the unbound method machinery
> is still alive. For example, you can still create unbound methods with
> new.instancemethod and PyMethod_New, and there's bits of code in classobject.c
> that refers to unbound methods.

Removing unbound methods also removes an obscure way to rebind internal
C functions to classes:

class Example:
   pass

Example.id = new.instancemethod(id, None, Example)

Now Example().id() has the same effect as:

class Example:
   def id(self):
       return id(self)

Do we need this feature?

Christian


From greg.ewing at canterbury.ac.nz  Sun Nov 25 22:43:27 2007
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Mon, 26 Nov 2007 10:43:27 +1300
Subject: [Python-3000] Unbound methods -- keep creating API?
In-Reply-To: <fibmb5$tva$1@ger.gmane.org>
References: <fibhjs$jol$1@ger.gmane.org> <fibmb5$tva$1@ger.gmane.org>
Message-ID: <4749EC7F.80603@canterbury.ac.nz>

Christian Heimes wrote:
> class Example:
>    pass
> 
> Example.id = new.instancemethod(id, None, Example)

This needs consideration. Pyrex currently makes use of
this behaviour when defining a Python class having Pyrex
functions as methods.

However, a better solution for Pyrex would be to add
method-binding behaviour to the C function object, so
that C functions can be used directly as methods. The
above example would then work simply by doing

   Example.id = id

--
Greg

From skip at pobox.com  Sun Nov 25 23:10:54 2007
From: skip at pobox.com (skip at pobox.com)
Date: Sun, 25 Nov 2007 16:10:54 -0600
Subject: [Python-3000] test_asynchat hanging
Message-ID: <18249.62190.496669.797140@montanaro.dyndns.org>

Am I the only person for whom test_asynchat is hanging?  If it's not already
a known issue let me know and I'll try and characterize it a bit better than
"it hangs".

Skip

From lists at cheimes.de  Sun Nov 25 23:26:51 2007
From: lists at cheimes.de (Christian Heimes)
Date: Sun, 25 Nov 2007 23:26:51 +0100
Subject: [Python-3000] test_asynchat hanging
In-Reply-To: <18249.62190.496669.797140@montanaro.dyndns.org>
References: <18249.62190.496669.797140@montanaro.dyndns.org>
Message-ID: <ficsrb$ish$1@ger.gmane.org>

skip at pobox.com wrote:
> Am I the only person for whom test_asynchat is hanging?  If it's not already
> a known issue let me know and I'll try and characterize it a bit better than
> "it hangs".

No, you are not alone although I've never seen a hanging async test on
my systems. But other developers share the problem:
http://bugs.python.org/issue1067

Christian


From lists at cheimes.de  Sun Nov 25 23:39:06 2007
From: lists at cheimes.de (Christian Heimes)
Date: Sun, 25 Nov 2007 23:39:06 +0100
Subject: [Python-3000] Unbound methods -- keep creating API?
In-Reply-To: <4749EC7F.80603@canterbury.ac.nz>
References: <fibhjs$jol$1@ger.gmane.org> <fibmb5$tva$1@ger.gmane.org>
	<4749EC7F.80603@canterbury.ac.nz>
Message-ID: <4749F98A.5070407@cheimes.de>

Greg Ewing wrote:
> This needs consideration. Pyrex currently makes use of
> this behaviour when defining a Python class having Pyrex
> functions as methods.
> 
> However, a better solution for Pyrex would be to add
> method-binding behaviour to the C function object, so
> that C functions can be used directly as methods. The
> above example would then work simply by doing

Why was the builtin_function_or_method type introduced and what's the
rational of the different behavior? Maybe we could add an API to wrap a
CFunction in an ordinary function?

Christian

From lists at cheimes.de  Sun Nov 25 23:39:06 2007
From: lists at cheimes.de (Christian Heimes)
Date: Sun, 25 Nov 2007 23:39:06 +0100
Subject: [Python-3000] Unbound methods -- keep creating API?
In-Reply-To: <4749EC7F.80603@canterbury.ac.nz>
References: <fibhjs$jol$1@ger.gmane.org> <fibmb5$tva$1@ger.gmane.org>
	<4749EC7F.80603@canterbury.ac.nz>
Message-ID: <4749F98A.5070407@cheimes.de>

Greg Ewing wrote:
> This needs consideration. Pyrex currently makes use of
> this behaviour when defining a Python class having Pyrex
> functions as methods.
> 
> However, a better solution for Pyrex would be to add
> method-binding behaviour to the C function object, so
> that C functions can be used directly as methods. The
> above example would then work simply by doing

Why was the builtin_function_or_method type introduced and what's the
rational of the different behavior? Maybe we could add an API to wrap a
CFunction in an ordinary function?

Christian


From guido at python.org  Mon Nov 26 03:54:55 2007
From: guido at python.org (Guido van Rossum)
Date: Sun, 25 Nov 2007 18:54:55 -0800
Subject: [Python-3000] Unbound methods -- keep creating API?
In-Reply-To: <4749F98A.5070407@cheimes.de>
References: <fibhjs$jol$1@ger.gmane.org> <fibmb5$tva$1@ger.gmane.org>
	<4749EC7F.80603@canterbury.ac.nz> <4749F98A.5070407@cheimes.de>
Message-ID: <ca471dc20711251854v993a882g89b4d8a368e13f6d@mail.gmail.com>

On Nov 25, 2007 2:39 PM, Christian Heimes <lists at cheimes.de> wrote:
> Greg Ewing wrote:
> > This needs consideration. Pyrex currently makes use of
> > this behaviour when defining a Python class having Pyrex
> > functions as methods.
> >
> > However, a better solution for Pyrex would be to add
> > method-binding behaviour to the C function object, so
> > that C functions can be used directly as methods. The
> > above example would then work simply by doing
>
> Why was the builtin_function_or_method type introduced and what's the
> rational of the different behavior? Maybe we could add an API to wrap a
> CFunction in an ordinary function?

And how would that work? Ultimately, a CFunction wraps a C function
pointer, while a Python function wraps a (byte)code object. Totally
different functionality inside. Anyway, even if you have a way around
that, this answers your "why" question. I see no reason why all
functions should be instances of the same type -- after all, we do
duck typing, right? :-)

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

From facundobatista at gmail.com  Mon Nov 26 16:13:39 2007
From: facundobatista at gmail.com (Facundo Batista)
Date: Mon, 26 Nov 2007 12:13:39 -0300
Subject: [Python-3000] test_asynchat hanging
In-Reply-To: <18249.62190.496669.797140@montanaro.dyndns.org>
References: <18249.62190.496669.797140@montanaro.dyndns.org>
Message-ID: <e04bdf310711260713y7084b494m400b6b0ea1431d2d@mail.gmail.com>

2007/11/25, skip at pobox.com <skip at pobox.com>:

> Am I the only person for whom test_asynchat is hanging?  If it's not already
> a known issue let me know and I'll try and characterize it a bit better than
> "it hangs".

As this not happens in all the systems, it'd be great if you could
debug it and try to be more specific with the problem. The solution
would be fantastic, btw, ;)

Thanks!

-- 
.    Facundo

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

From lists at cheimes.de  Mon Nov 26 17:19:37 2007
From: lists at cheimes.de (Christian Heimes)
Date: Mon, 26 Nov 2007 17:19:37 +0100
Subject: [Python-3000] Unbound methods -- keep creating API?
In-Reply-To: <4749EC7F.80603@canterbury.ac.nz>
References: <fibhjs$jol$1@ger.gmane.org> <fibmb5$tva$1@ger.gmane.org>
	<4749EC7F.80603@canterbury.ac.nz>
Message-ID: <474AF219.6080907@cheimes.de>

Greg Ewing wrote:
> This needs consideration. Pyrex currently makes use of
> this behaviour when defining a Python class having Pyrex
> functions as methods.
> 
> However, a better solution for Pyrex would be to add
> method-binding behaviour to the C function object, so
> that C functions can be used directly as methods. The
> above example would then work simply by doing
> 
>    Example.id = id

A C function binder is very easy to implement. Here is a rough
implementation:

class binder:
    def __init__(self, func):
        self._func = func
    def __get__(self, obj, type):
        if obj:
            return wrapper(self._func, obj)
        else:
            return self._func

def wrapper(func, obj):
    def wrapped(*args, **kwargs):
        return func(obj, *args, **kwargs)
    return wrapped

class Example:
    id = binder(id)

>>> Example.id
<built-in function id>
>>> Example().id()
138076828
>>> Example().id
<function wrapped at 0x83ac714>


From lists at cheimes.de  Mon Nov 26 17:19:37 2007
From: lists at cheimes.de (Christian Heimes)
Date: Mon, 26 Nov 2007 17:19:37 +0100
Subject: [Python-3000] Unbound methods -- keep creating API?
In-Reply-To: <4749EC7F.80603@canterbury.ac.nz>
References: <fibhjs$jol$1@ger.gmane.org> <fibmb5$tva$1@ger.gmane.org>
	<4749EC7F.80603@canterbury.ac.nz>
Message-ID: <474AF219.6080907@cheimes.de>

Greg Ewing wrote:
> This needs consideration. Pyrex currently makes use of
> this behaviour when defining a Python class having Pyrex
> functions as methods.
> 
> However, a better solution for Pyrex would be to add
> method-binding behaviour to the C function object, so
> that C functions can be used directly as methods. The
> above example would then work simply by doing
> 
>    Example.id = id

A C function binder is very easy to implement. Here is a rough
implementation:

class binder:
    def __init__(self, func):
        self._func = func
    def __get__(self, obj, type):
        if obj:
            return wrapper(self._func, obj)
        else:
            return self._func

def wrapper(func, obj):
    def wrapped(*args, **kwargs):
        return func(obj, *args, **kwargs)
    return wrapped

class Example:
    id = binder(id)

>>> Example.id
<built-in function id>
>>> Example().id()
138076828
>>> Example().id
<function wrapped at 0x83ac714>


From janssen at parc.com  Mon Nov 26 19:28:38 2007
From: janssen at parc.com (Bill Janssen)
Date: Mon, 26 Nov 2007 10:28:38 PST
Subject: [Python-3000] test_asynchat hanging
In-Reply-To: <ficsrb$ish$1@ger.gmane.org> 
References: <18249.62190.496669.797140@montanaro.dyndns.org>
	<ficsrb$ish$1@ger.gmane.org>
Message-ID: <07Nov26.102839pst."58696"@synergy1.parc.xerox.com>

> skip at pobox.com wrote:
> > Am I the only person for whom test_asynchat is hanging?  If it's not already
> > a known issue let me know and I'll try and characterize it a bit better than
> > "it hangs".
> 
> No, you are not alone although I've never seen a hanging async test on
> my systems. But other developers share the problem:
> http://bugs.python.org/issue1067

You might want to check to make sure that the socket on the other end
of the connection is being closed.  That not happening caused a number
of the SSL tests to hang.

Bill

From ncoghlan at gmail.com  Mon Nov 26 23:53:23 2007
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 27 Nov 2007 08:53:23 +1000
Subject: [Python-3000] Unbound methods -- keep creating API?
In-Reply-To: <474AF219.6080907@cheimes.de>
References: <fibhjs$jol$1@ger.gmane.org>
	<fibmb5$tva$1@ger.gmane.org>	<4749EC7F.80603@canterbury.ac.nz>
	<474AF219.6080907@cheimes.de>
Message-ID: <474B4E63.9010803@gmail.com>

Christian Heimes wrote:
> Greg Ewing wrote:
>> This needs consideration. Pyrex currently makes use of
>> this behaviour when defining a Python class having Pyrex
>> functions as methods.
>>
>> However, a better solution for Pyrex would be to add
>> method-binding behaviour to the C function object, so
>> that C functions can be used directly as methods. The
>> above example would then work simply by doing
>>
>>    Example.id = id
> 
> A C function binder is very easy to implement.

True, but it would probably make more sense to find a way to let Pyrex 
re-use the method descriptor already used for builtin types:

 >>> type(str.lower)
<type 'method_descriptor'>

Interestly, I just discovered that method descriptors for builtins don't 
define im_class, im_self or im_func. I never knew that - I thought they 
had the same interface as instance methods.

Cheers,
Nick.

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

From guido at python.org  Tue Nov 27 00:00:06 2007
From: guido at python.org (Guido van Rossum)
Date: Mon, 26 Nov 2007 15:00:06 -0800
Subject: [Python-3000] Unbound methods -- keep creating API?
In-Reply-To: <474B4E63.9010803@gmail.com>
References: <fibhjs$jol$1@ger.gmane.org> <fibmb5$tva$1@ger.gmane.org>
	<4749EC7F.80603@canterbury.ac.nz> <474AF219.6080907@cheimes.de>
	<474B4E63.9010803@gmail.com>
Message-ID: <ca471dc20711261500j6f54d71s37b40a800113456e@mail.gmail.com>

On Nov 26, 2007 2:53 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> Christian Heimes wrote:
> > Greg Ewing wrote:
> >> This needs consideration. Pyrex currently makes use of
> >> this behaviour when defining a Python class having Pyrex
> >> functions as methods.
> >>
> >> However, a better solution for Pyrex would be to add
> >> method-binding behaviour to the C function object, so
> >> that C functions can be used directly as methods. The
> >> above example would then work simply by doing
> >>
> >>    Example.id = id
> >
> > A C function binder is very easy to implement.
>
> True, but it would probably make more sense to find a way to let Pyrex
> re-use the method descriptor already used for builtin types:
>
>  >>> type(str.lower)
> <type 'method_descriptor'>
>
> Interestly, I just discovered that method descriptors for builtins don't
> define im_class, im_self or im_func. I never knew that - I thought they
> had the same interface as instance methods.

They have, if you only consider the *important* operations. For method
descriptors the only thing you can count on is __call__. The rest are
internal implementation details -- and besides, what would you expect
im_func to be for a C function? :-)

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

From greg.ewing at canterbury.ac.nz  Tue Nov 27 00:49:22 2007
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Tue, 27 Nov 2007 12:49:22 +1300
Subject: [Python-3000] Unbound methods -- keep creating API?
In-Reply-To: <474B4E63.9010803@gmail.com>
References: <fibhjs$jol$1@ger.gmane.org> <fibmb5$tva$1@ger.gmane.org>
	<4749EC7F.80603@canterbury.ac.nz> <474AF219.6080907@cheimes.de>
	<474B4E63.9010803@gmail.com>
Message-ID: <474B5B82.6070106@canterbury.ac.nz>

Nick Coghlan wrote:
> Interestly, I just discovered that method descriptors for builtins don't 
> define im_class, im_self or im_func. I never knew that - I thought they 
> had the same interface as instance methods.

A builtin method descriptor is the C equivalent of a
function object, not an instancemethod.

The desired behaviour would be for builtin method
descriptors to have a __get__ method that creates
an instancemethod object, like functions do.

--
Greg

From guido at python.org  Tue Nov 27 05:28:11 2007
From: guido at python.org (Guido van Rossum)
Date: Mon, 26 Nov 2007 20:28:11 -0800
Subject: [Python-3000] Unbound methods -- keep creating API?
In-Reply-To: <474B5B82.6070106@canterbury.ac.nz>
References: <fibhjs$jol$1@ger.gmane.org> <fibmb5$tva$1@ger.gmane.org>
	<4749EC7F.80603@canterbury.ac.nz> <474AF219.6080907@cheimes.de>
	<474B4E63.9010803@gmail.com> <474B5B82.6070106@canterbury.ac.nz>
Message-ID: <ca471dc20711262028s5b9a83c0i868a723bc252f035@mail.gmail.com>

On Nov 26, 2007 3:49 PM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Nick Coghlan wrote:
> > Interestly, I just discovered that method descriptors for builtins don't
> > define im_class, im_self or im_func. I never knew that - I thought they
> > had the same interface as instance methods.
>
> A builtin method descriptor is the C equivalent of a
> function object, not an instancemethod.

Not quite -- it holds a reference to an object too.

> The desired behaviour would be for builtin method
> descriptors to have a __get__ method that creates
> an instancemethod object, like functions do.

They have that too. See:

Python 2.4.4 (#1, Oct 18 2006, 10:34:39)
[GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> a = []
>>> f = list.append
>>> f
<method 'append' of 'list' objects>
>>> g = f.__get__(a)
>>> g
<built-in method append of list object at 0x590f8>
>>> a.append
<built-in method append of list object at 0x590f8>
>>> g(42)
>>> a
[42]
>>>

What am I missing?

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

From greg.ewing at canterbury.ac.nz  Tue Nov 27 07:43:16 2007
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Tue, 27 Nov 2007 19:43:16 +1300
Subject: [Python-3000] Unbound methods -- keep creating API?
In-Reply-To: <ca471dc20711262028s5b9a83c0i868a723bc252f035@mail.gmail.com>
References: <fibhjs$jol$1@ger.gmane.org> <fibmb5$tva$1@ger.gmane.org>
	<4749EC7F.80603@canterbury.ac.nz> <474AF219.6080907@cheimes.de>
	<474B4E63.9010803@gmail.com> <474B5B82.6070106@canterbury.ac.nz>
	<ca471dc20711262028s5b9a83c0i868a723bc252f035@mail.gmail.com>
Message-ID: <474BBC84.6030902@canterbury.ac.nz>

Guido van Rossum wrote:
> They have that too. See:
> 
>>>>f = list.append
>>>>g = f.__get__(a)
>>>>g
> 
> <built-in method append of list object at 0x590f8>

Hmmm. It seems that C method objects are more
like an unbound method object that's pre-bound to a
particular class.

I'm concerned with built-in function objects that
are *not* methods of anything. I'm suggesting they
should behave the same way as a Python function when
you put one in a class, i.e. accessing it through an
instance creates a bound method.

If that were the case, then Pyrex wouldn't have
to do anything special to create a Python class
containing a method implemented in Pyrex, and
unbound method objects could cease to exist without
causing Pyrex any problem.

--
Greg

From ncoghlan at gmail.com  Tue Nov 27 11:16:59 2007
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 27 Nov 2007 20:16:59 +1000
Subject: [Python-3000] Unbound methods -- keep creating API?
In-Reply-To: <474BBC84.6030902@canterbury.ac.nz>
References: <fibhjs$jol$1@ger.gmane.org>
	<fibmb5$tva$1@ger.gmane.org>	<4749EC7F.80603@canterbury.ac.nz>
	<474AF219.6080907@cheimes.de>	<474B4E63.9010803@gmail.com>
	<474B5B82.6070106@canterbury.ac.nz>	<ca471dc20711262028s5b9a83c0i868a723bc252f035@mail.gmail.com>
	<474BBC84.6030902@canterbury.ac.nz>
Message-ID: <474BEE9B.8060505@gmail.com>

Greg Ewing wrote:
> Guido van Rossum wrote:
>> They have that too. See:
>>
>>>>> f = list.append
>>>>> g = f.__get__(a)
>>>>> g
>> <built-in method append of list object at 0x590f8>
> 
> Hmmm. It seems that C method objects are more
> like an unbound method object that's pre-bound to a
> particular class.
> 
> I'm concerned with built-in function objects that
> are *not* methods of anything. I'm suggesting they
> should behave the same way as a Python function when
> you put one in a class, i.e. accessing it through an
> instance creates a bound method.

I think I see what you're getting at now - adding a '__get__' method to 
the basic C function wrapper that returns self when retrieved from the 
class, and a bound instancemethod when retrieved from an instance.

To illustrate the difference between builtin functions and methods:

 >>> type(str.lower)
<type 'method_descriptor'>
 >>> '__get__' in dir(str.lower)
True

 >>> type(map)
<type 'builtin_function_or_method'>
 >>> '__get__' in dir(map)
False

This seems like an eminently sensible idea to me, and not really 
something that can be done in the 2.x series.

Cheers,
Nick.

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

From ncoghlan at gmail.com  Tue Nov 27 11:25:03 2007
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 27 Nov 2007 20:25:03 +1000
Subject: [Python-3000] Unbound methods -- keep creating API?
In-Reply-To: <ca471dc20711261500j6f54d71s37b40a800113456e@mail.gmail.com>
References: <fibhjs$jol$1@ger.gmane.org> <fibmb5$tva$1@ger.gmane.org>	
	<4749EC7F.80603@canterbury.ac.nz>
	<474AF219.6080907@cheimes.de>	 <474B4E63.9010803@gmail.com>
	<ca471dc20711261500j6f54d71s37b40a800113456e@mail.gmail.com>
Message-ID: <474BF07F.1000206@gmail.com>

Guido van Rossum wrote:
> They have, if you only consider the *important* operations. For method
> descriptors the only thing you can count on is __call__. The rest are
> internal implementation details -- and besides, what would you expect
> im_func to be for a C function? :-)

I'd just never thought about it until this discussion. I realise now 
that there is no particular reason for them to be the same (beyond 
implementing __call__).

Cheers,
Nick.

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

From guido at python.org  Tue Nov 27 19:15:56 2007
From: guido at python.org (Guido van Rossum)
Date: Tue, 27 Nov 2007 10:15:56 -0800
Subject: [Python-3000] Unbound methods -- keep creating API?
In-Reply-To: <474BBC84.6030902@canterbury.ac.nz>
References: <fibhjs$jol$1@ger.gmane.org> <fibmb5$tva$1@ger.gmane.org>
	<4749EC7F.80603@canterbury.ac.nz> <474AF219.6080907@cheimes.de>
	<474B4E63.9010803@gmail.com> <474B5B82.6070106@canterbury.ac.nz>
	<ca471dc20711262028s5b9a83c0i868a723bc252f035@mail.gmail.com>
	<474BBC84.6030902@canterbury.ac.nz>
Message-ID: <ca471dc20711271015q5af166e6g98909482271a439f@mail.gmail.com>

On Nov 26, 2007 10:43 PM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Guido van Rossum wrote:
> > They have that too. See:
> >
> >>>>f = list.append
> >>>>g = f.__get__(a)
> >>>>g
> >
> > <built-in method append of list object at 0x590f8>
>
> Hmmm. It seems that C method objects are more
> like an unbound method object that's pre-bound to a
> particular class.

Yes, that's exactly what an unbound method was. While for Python
functions there's no compelling reason (from the VM's POV anyway) why
they should only be called on instances of a particular class, for
built-in functions there is a very big reason -- the C code is written
assuming a specific instance lay-out.

> I'm concerned with built-in function objects that
> are *not* methods of anything.

Like 'len', right?

> I'm suggesting they
> should behave the same way as a Python function when
> you put one in a class, i.e. accessing it through an
> instance creates a bound method.
>
> If that were the case, then Pyrex wouldn't have
> to do anything special to create a Python class
> containing a method implemented in Pyrex, and
> unbound method objects could cease to exist without
> causing Pyrex any problem.

Couldn't PyRex define its own type for its functions that has a
__get__ descriptor with the appropriate semantics?

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

From guido at python.org  Tue Nov 27 19:29:19 2007
From: guido at python.org (Guido van Rossum)
Date: Tue, 27 Nov 2007 10:29:19 -0800
Subject: [Python-3000] Unbound methods -- keep creating API?
In-Reply-To: <474BEE9B.8060505@gmail.com>
References: <fibhjs$jol$1@ger.gmane.org> <fibmb5$tva$1@ger.gmane.org>
	<4749EC7F.80603@canterbury.ac.nz> <474AF219.6080907@cheimes.de>
	<474B4E63.9010803@gmail.com> <474B5B82.6070106@canterbury.ac.nz>
	<ca471dc20711262028s5b9a83c0i868a723bc252f035@mail.gmail.com>
	<474BBC84.6030902@canterbury.ac.nz> <474BEE9B.8060505@gmail.com>
Message-ID: <ca471dc20711271029m7b8c332bv6124565610bb2284@mail.gmail.com>

On Nov 27, 2007 2:16 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> Greg Ewing wrote:
> > Guido van Rossum wrote:
> >> They have that too. See:
> >>
> >>>>> f = list.append
> >>>>> g = f.__get__(a)
> >>>>> g
> >> <built-in method append of list object at 0x590f8>
> >
> > Hmmm. It seems that C method objects are more
> > like an unbound method object that's pre-bound to a
> > particular class.
> >
> > I'm concerned with built-in function objects that
> > are *not* methods of anything. I'm suggesting they
> > should behave the same way as a Python function when
> > you put one in a class, i.e. accessing it through an
> > instance creates a bound method.
>
> I think I see what you're getting at now - adding a '__get__' method to
> the basic C function wrapper that returns self when retrieved from the
> class, and a bound instancemethod when retrieved from an instance.
>
> To illustrate the difference between builtin functions and methods:
>
>  >>> type(str.lower)
> <type 'method_descriptor'>
>  >>> '__get__' in dir(str.lower)
> True
>
>  >>> type(map)
> <type 'builtin_function_or_method'>
>  >>> '__get__' in dir(map)
> False
>
> This seems like an eminently sensible idea to me, and not really
> something that can be done in the 2.x series.

On second thought (after responding to Greg), I agree that it is
sensible. But why can't it be done in 2.6?

The attached implementation is simple enough...

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: meth.diff
Type: text/x-patch
Size: 831 bytes
Desc: not available
Url : http://mail.python.org/pipermail/python-3000/attachments/20071127/ef3ca9b7/attachment.bin 

From guido at python.org  Tue Nov 27 19:48:15 2007
From: guido at python.org (Guido van Rossum)
Date: Tue, 27 Nov 2007 10:48:15 -0800
Subject: [Python-3000] Unbound methods -- keep creating API?
In-Reply-To: <ca471dc20711271029m7b8c332bv6124565610bb2284@mail.gmail.com>
References: <fibhjs$jol$1@ger.gmane.org> <fibmb5$tva$1@ger.gmane.org>
	<4749EC7F.80603@canterbury.ac.nz> <474AF219.6080907@cheimes.de>
	<474B4E63.9010803@gmail.com> <474B5B82.6070106@canterbury.ac.nz>
	<ca471dc20711262028s5b9a83c0i868a723bc252f035@mail.gmail.com>
	<474BBC84.6030902@canterbury.ac.nz> <474BEE9B.8060505@gmail.com>
	<ca471dc20711271029m7b8c332bv6124565610bb2284@mail.gmail.com>
Message-ID: <ca471dc20711271048u305fc9dep8fe702048620ed73@mail.gmail.com>

On Nov 27, 2007 10:29 AM, Guido van Rossum <guido at python.org> wrote:
> The attached implementation is simple enough...

Do note that this breaks quite a bit of code that was storing built-in
functions as class variables and accessing them via self.xxx...

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

From greg.ewing at canterbury.ac.nz  Wed Nov 28 01:35:33 2007
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Wed, 28 Nov 2007 13:35:33 +1300
Subject: [Python-3000] Unbound methods -- keep creating API?
In-Reply-To: <ca471dc20711271015q5af166e6g98909482271a439f@mail.gmail.com>
References: <fibhjs$jol$1@ger.gmane.org> <fibmb5$tva$1@ger.gmane.org>
	<4749EC7F.80603@canterbury.ac.nz> <474AF219.6080907@cheimes.de>
	<474B4E63.9010803@gmail.com> <474B5B82.6070106@canterbury.ac.nz>
	<ca471dc20711262028s5b9a83c0i868a723bc252f035@mail.gmail.com>
	<474BBC84.6030902@canterbury.ac.nz>
	<ca471dc20711271015q5af166e6g98909482271a439f@mail.gmail.com>
Message-ID: <474CB7D5.7040408@canterbury.ac.nz>

Guido van Rossum wrote:
> Like 'len', right?

Yes, anything that's a stand-alone function rather than
a method of some C type.

> Couldn't PyRex define its own type for its functions that has a
> __get__ descriptor with the appropriate semantics?

Yes, it could, but it would be more run-time support
baggage to carry around in every Pyrex module that used
it (there's currently no mechanism for different Pyrex
modules to share runtime support code). It would be
tidier if the existing builtin function type had the
desired behaviour, that's all.

I can't imagine there would be much in the way of
existing code that would be affected by this. It would
have to be putting a builtin function into a class,
and then retrieving it via an instance and expecting
it to come back as a plain function.

But in any case, the impact on existing code could be
reduced to zero by having a flag in the method descriptor
to enable this behaviour. It would only be turned on
for functions that really need it.

--
Greg

From guido at python.org  Wed Nov 28 02:12:59 2007
From: guido at python.org (Guido van Rossum)
Date: Tue, 27 Nov 2007 17:12:59 -0800
Subject: [Python-3000] Unbound methods -- keep creating API?
In-Reply-To: <474CB7D5.7040408@canterbury.ac.nz>
References: <fibhjs$jol$1@ger.gmane.org> <fibmb5$tva$1@ger.gmane.org>
	<4749EC7F.80603@canterbury.ac.nz> <474AF219.6080907@cheimes.de>
	<474B4E63.9010803@gmail.com> <474B5B82.6070106@canterbury.ac.nz>
	<ca471dc20711262028s5b9a83c0i868a723bc252f035@mail.gmail.com>
	<474BBC84.6030902@canterbury.ac.nz>
	<ca471dc20711271015q5af166e6g98909482271a439f@mail.gmail.com>
	<474CB7D5.7040408@canterbury.ac.nz>
Message-ID: <ca471dc20711271712v2667492j97826446fa3ed296@mail.gmail.com>

On Nov 27, 2007 4:35 PM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Guido van Rossum wrote:
> > Like 'len', right?
>
> Yes, anything that's a stand-alone function rather than
> a method of some C type.
>
> > Couldn't PyRex define its own type for its functions that has a
> > __get__ descriptor with the appropriate semantics?
>
> Yes, it could, but it would be more run-time support
> baggage to carry around in every Pyrex module that used
> it (there's currently no mechanism for different Pyrex
> modules to share runtime support code). It would be
> tidier if the existing builtin function type had the
> desired behaviour, that's all.

Or if there were another builtin type (wrapped around a C function
obviously) with the desired behavior.

> I can't imagine there would be much in the way of
> existing code that would be affected by this. It would
> have to be putting a builtin function into a class,
> and then retrieving it via an instance and expecting
> it to come back as a plain function.

Funny, that. I tried my patch (see previous message) and 50 unittests
had at least one failure.

> But in any case, the impact on existing code could be
> reduced to zero by having a flag in the method descriptor
> to enable this behaviour. It would only be turned on
> for functions that really need it.

OK. I know you're not going to like this, but I'm asking that you
provide a patch yourself.

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

From greg.ewing at canterbury.ac.nz  Wed Nov 28 02:36:05 2007
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Wed, 28 Nov 2007 14:36:05 +1300
Subject: [Python-3000] Unbound methods -- keep creating API?
In-Reply-To: <ca471dc20711271712v2667492j97826446fa3ed296@mail.gmail.com>
References: <fibhjs$jol$1@ger.gmane.org> <fibmb5$tva$1@ger.gmane.org>
	<4749EC7F.80603@canterbury.ac.nz> <474AF219.6080907@cheimes.de>
	<474B4E63.9010803@gmail.com> <474B5B82.6070106@canterbury.ac.nz>
	<ca471dc20711262028s5b9a83c0i868a723bc252f035@mail.gmail.com>
	<474BBC84.6030902@canterbury.ac.nz>
	<ca471dc20711271015q5af166e6g98909482271a439f@mail.gmail.com>
	<474CB7D5.7040408@canterbury.ac.nz>
	<ca471dc20711271712v2667492j97826446fa3ed296@mail.gmail.com>
Message-ID: <474CC605.2010005@canterbury.ac.nz>

Guido van Rossum wrote:
> Funny, that. I tried my patch (see previous message) and 50 unittests
> had at least one failure.

That's quite surprising!

> I know you're not going to like this, but I'm asking that you
> provide a patch yourself.

Fair enough. I'll file this idea away for when I get
around to working on Pyrex3k.

--
Greg

From lists at cheimes.de  Thu Nov 29 17:33:22 2007
From: lists at cheimes.de (Christian Heimes)
Date: Thu, 29 Nov 2007 17:33:22 +0100
Subject: [Python-3000] pyvm module - low level interface to Python's VM
Message-ID: <fimpkk$405$1@ger.gmane.org>

Shorah!

I've started to work on a pyvm module patch today. The new
module is going to contain low level interfaces to Python's VM and some
low level types, too. So far my first version contains only a bunch of
types.

What methods do you like to move to the new module? I was thinking about
sys.get/setcheckinterval, sys.get/setrecursionlimit, sys.getrefcount,
sys.gettotalrefcount. Maybe sys._current_frames, sys._getframe and
sys.builtin_module_names, too.

http://bugs.python.org/issue1522

Christian


From foom at fuhm.net  Thu Nov 29 17:55:49 2007
From: foom at fuhm.net (James Y Knight)
Date: Thu, 29 Nov 2007 11:55:49 -0500
Subject: [Python-3000] pyvm module - low level interface to Python's VM
In-Reply-To: <fimpkk$405$1@ger.gmane.org>
References: <fimpkk$405$1@ger.gmane.org>
Message-ID: <64749112-E25C-4466-8648-4CC667E7A8ED@fuhm.net>


On Nov 29, 2007, at 11:33 AM, Christian Heimes wrote:

> Shorah!
>
> I've started to work on a pyvm module patch today. The new
> module is going to contain low level interfaces to Python's VM and  
> some
> low level types, too. So far my first version contains only a bunch of
> types.


I'd like to quote some of a thread I started in Aug 2004, subject  
"Classes that claim to be defined in __builtin__ but aren't". I  
haven't rerun the script that generated this list (I have to find it  
again, first, or rewrite it...), but assuming these types are still  
lying about their location, most seem likely candidates for putting in  
a pyvm module.

It might also be a nice idea to require types to have an explicit  
module defined (that is: require tp_name to have a '.' in it) so that  
types can't accidently claim to be defined in the __builtin__ module.

I wrote:
> There's a fair number of classes that claim they are defined in  
> __builtin__, but do not actually appear there.
>


> Okay, so, I don't have a patch, but I have made a script to examine  
> the situation. It seems the problem is a little more widespread than  
> I had realized. I grepped through the python C source to find all  
> the type objects, and then verified their existence. Just looking at  
> Objects/*.c, there are 31 classes without appropriate bindings.  
> Additionally, some aren't even valid identifier names. It seems like  
> there's 4 categories here: iterators, descrobject stuffs, list  
> comparison wrappers, and other. I'm not sure it's a good idea to add  
> all these names to the builtins -- perhaps only the ones in the  
> 'other' group?
>
> For {Modules,Mac,PC,RISCOS,Python}/*.c, most seem like they could  
> relatively straightforwardly be added to their module, but I haven't  
> examined them too closely. Some likely ought to have constructors  
> added (e.g. the dl.dl('file') could be equivalent to dl.open('file')).
>
> __builtin__.dictionary-keyiterator   not found (./Objects/ 
> dictobject.c)
> __builtin__.dictionary-valueiterator   not found (./Objects/ 
> dictobject.c)
> __builtin__.dictionary-itemiterator   not found (./Objects/ 
> dictobject.c)
> __builtin__.tupleiterator   not found (./Objects/tupleobject.c)
> __builtin__.rangeiterator   not found (./Objects/rangeobject.c)
> __builtin__.iterator   not found (./Objects/iterobject.c)
> __builtin__.callable-iterator   not found (./Objects/iterobject.c)
> __builtin__.listiterator   not found (./Objects/listobject.c)
> __builtin__.listreverseiterator   not found (./Objects/listobject.c)
>
> __builtin__.method_descriptor   not found (./Objects/descrobject.c)
> __builtin__.classmethod_descriptor   not found (./Objects/ 
> descrobject.c)
> __builtin__.member_descriptor   not found (./Objects/descrobject.c)
> __builtin__.getset_descriptor   not found (./Objects/descrobject.c)
> __builtin__.wrapper_descriptor   not found (./Objects/descrobject.c)
> __builtin__.method-wrapper   not found (./Objects/descrobject.c)
>
> __builtin__.sortwrapper   not found (./Objects/listobject.c)
> __builtin__.cmpwrapper   not found (./Objects/listobject.c)
>
> __builtin__.ellipsis   not found (./Objects/sliceobject.c)    
> types.EllipsisType
> __builtin__.builtin_function_or_method   not found (./Objects/ 
> methodobject.c)   types.BuiltinFunctionType types.BuiltinMethodType
> __builtin__.dictproxy   not found (./Objects/descrobject.c)    
> types.DictProxyType
> __builtin__.generator   not found (./Objects/genobject.c)    
> types.GeneratorType
> __builtin__.PyCObject   not found (./Objects/cobject.c)
> __builtin__.classobj   not found (./Objects/classobject.c)    
> types.ClassType
> __builtin__.instance   not found (./Objects/classobject.c)    
> types.InstanceType
> __builtin__.instancemethod   not found (./Objects/classobject.c)    
> types.MethodType types.UnboundMethodType
> __builtin__.cell   not found (./Objects/cellobject.c)
> __builtin__.NoneType   not found (./Objects/object.c)   types.NoneType
> __builtin__.NotImplementedType   not found (./Objects/object.c)    
> types.NotImplementedType
> __builtin__.frame   not found (./Objects/frameobject.c)    
> types.FrameType
> __builtin__.function   not found (./Objects/funcobject.c)    
> types.FunctionType types.LambdaType
> __builtin__.module   not found (./Objects/moduleobject.c)    
> types.ModuleType
>
>
> (the Mac ones I checked on my mac w/ python 2.3.0)
> _Qt.IdleManager   not found (./Mac/Modules/qt/_Qtmodule.c)
> _Qt.SGOutput   not found (./Mac/Modules/qt/_Qtmodule.c)
> module _OSA not installed (./Mac/Modules/osa/_OSAmodule.c)
> Nav.NavReplyRecord   not found (./Mac/Modules/Nav.c)
> _Scrap.Scrap   not found (./Mac/Modules/scrap/_Scrapmodule.c)
> module waste not installed (./Mac/Modules/waste/wastemodule.c)
> MacOS.ResourceFork   not found (./Mac/Modules/macosmodule.c)
> icglue.ic_instance   not found (./Mac/Modules/icgluemodule.c)
>
>
> __builtin__.PyHKEY   not found (./PC/_winreg.c)
> __builtin__.drawf   not found (./RISCOS/Modules/drawfmodule.c)
> __builtin__.block   not found (./RISCOS/Modules/swimodule.c)
> __builtin__.traceback   not found (./Python/traceback.c)    
> types.TracebackType
> __builtin__.code   not found (./Python/compile.c)   types.CodeType
> __builtin__.symtable entry   not found (./Python/symtable.c)
> __builtin__.tktimertoken   not found (./Modules/_tkinter.c)
> __builtin__.tkapp   not found (./Modules/_tkinter.c)
> __builtin__.arrayiterator   not found (./Modules/arraymodule.c)
> _curses_panel.curses panel   not found (./Modules/_curses_panel.c)
> linuxaudiodev.linux_audio_device   not found (./Modules/ 
> linuxaudiodev.c)
> module fl not installed (./Modules/flmodule.c)
> __builtin__.DB   not found (./Modules/_bsddb.c)
> __builtin__.DBCursor   not found (./Modules/_bsddb.c)
> __builtin__.DBEnv   not found (./Modules/_bsddb.c)
> __builtin__.DBTxn   not found (./Modules/_bsddb.c)
> __builtin__.DBLock   not found (./Modules/_bsddb.c)
> sha.SHA   not found (./Modules/shamodule.c)
> module sv not installed (./Modules/svmodule.c)
> itertools._grouper   not found (./Modules/itertoolsmodule.c)
> itertools.tee_dataobject   not found (./Modules/itertoolsmodule.c)
> rotor.rotor   not found (./Modules/rotormodule.c)
> module cl not installed (./Modules/clmodule.c)
> _sre.SRE_Pattern   not found (./Modules/_sre.c)
> _sre.SRE_Match   not found (./Modules/_sre.c)
> _sre.SRE_Scanner   not found (./Modules/_sre.c)
> socket.SSL   not found (./Modules/_ssl.c)
> _curses.curses window   not found (./Modules/_cursesmodule.c)
> parser.st   not found (./Modules/parsermodule.c)
> cStringIO.StringO   not found (./Modules/cStringIO.c)
> cStringIO.StringI   not found (./Modules/cStringIO.c)
> module sunaudiodev not installed (./Modules/sunaudiodev.c)
> module dbm not installed (./Modules/dbmmodule.c)
> dl.dl   not found (./Modules/dlmodule.c)
> module fm not installed (./Modules/fmmodule.c)
> regex.regex   not found (./Modules/regexmodule.c)
> pyexpat.xmlparser   not found (./Modules/pyexpat.c)
> __builtin__.MultibyteCodec   not found (./Modules/cjkcodecs/ 
> multibytecodec.c)
> __builtin__.MultibyteStreamReader   not found (./Modules/cjkcodecs/ 
> multibytecodec.c)
> __builtin__.MultibyteStreamWriter   not found (./Modules/cjkcodecs/ 
> multibytecodec.c)
> bsddb.bsddb   not found (./Modules/bsddbmodule.c)
> module cd not installed (./Modules/cdmodule.c)
> cPickle.Pdata   not found (./Modules/cPickle.c)
> module al not installed (./Modules/almodule.c)
> __builtin__.deque_iterator   not found (./Modules/collectionsmodule.c)
> __builtin__.deque_reverse_iterator   not found (./Modules/ 
> collectionsmodule.c)
> thread.lock   not found (./Modules/threadmodule.c)
> zlib.Compress   not found (./Modules/zlibmodule.c)
> zlib.Decompress   not found (./Modules/zlibmodule.c)
> gdbm.gdbm   not found (./Modules/gdbmmodule.c)
> ossaudiodev.oss_audio_device   not found (./Modules/ossaudiodev.c)
> ossaudiodev.oss_mixer_device   not found (./Modules/ossaudiodev.c)

From lists at cheimes.de  Thu Nov 29 20:21:50 2007
From: lists at cheimes.de (Christian Heimes)
Date: Thu, 29 Nov 2007 20:21:50 +0100
Subject: [Python-3000] pyvm module - low level interface to Python's VM
In-Reply-To: <64749112-E25C-4466-8648-4CC667E7A8ED@fuhm.net>
References: <fimpkk$405$1@ger.gmane.org>
	<64749112-E25C-4466-8648-4CC667E7A8ED@fuhm.net>
Message-ID: <fin3gf$cf6$1@ger.gmane.org>

James Y Knight wrote:
> I'd like to quote some of a thread I started in Aug 2004, subject  
> "Classes that claim to be defined in __builtin__ but aren't". I  
> haven't rerun the script that generated this list (I have to find it  
> again, first, or rewrite it...), but assuming these types are still  
> lying about their location, most seem likely candidates for putting in  
> a pyvm module.

Thanks for the list! It's going to help me very much.

> It might also be a nice idea to require types to have an explicit  
> module defined (that is: require tp_name to have a '.' in it) so that  
> types can't accidently claim to be defined in the __builtin__ module.

I don't think that it's important. Most of the types can't be
instantiated in Python code because they are hard wired to
implementation details in C code. A valid dotted name is only required
when the types are pickle-able and can be instantiated in Python code.

Christian


From tjreedy at udel.edu  Fri Nov 30 01:44:03 2007
From: tjreedy at udel.edu (Terry Reedy)
Date: Thu, 29 Nov 2007 19:44:03 -0500
Subject: [Python-3000] pyvm module - low level interface to Python's VM
References: <fimpkk$405$1@ger.gmane.org>
Message-ID: <finmfi$e50$1@ger.gmane.org>


"Christian Heimes" <lists at cheimes.de> wrote in message 
news:fimpkk$405$1 at ger.gmane.org...
| Shorah!
|
| I've started to work on a pyvm module patch today. The new
| module is going to contain low level interfaces to Python's VM and some
| low level types, too. So far my first version contains only a bunch of
| types.
|
| What methods do you like to move to the new module? I was thinking about
| sys.get/setcheckinterval, sys.get/setrecursionlimit, sys.getrefcount,
| sys.gettotalrefcount.

These are seem vm related to me too.

|Maybe sys._current_frames, sys._getframe and

Hmm.  The idea of execution frames strikes me as somewhat independent of 
vm.  In practice, they are associated with exceptions and tracebacks.  If 
these were also split off from sys in another separate module, I would look 
there for the frame functions.

| sys.builtin_module_names, too.

This strikes me as a packaging issue rather than vm issue.

tjr




From dirkjan at ochtman.nl  Fri Nov 30 10:58:07 2007
From: dirkjan at ochtman.nl (Dirkjan Ochtman)
Date: Fri, 30 Nov 2007 10:58:07 +0100
Subject: [Python-3000] pyvm module - low level interface to Python's VM
In-Reply-To: <finmfi$e50$1@ger.gmane.org>
References: <fimpkk$405$1@ger.gmane.org> <finmfi$e50$1@ger.gmane.org>
Message-ID: <fiomri$o5v$1@ger.gmane.org>

Terry Reedy wrote:
> |Maybe sys._current_frames, sys._getframe and
> 
> Hmm.  The idea of execution frames strikes me as somewhat independent of 
> vm.  In practice, they are associated with exceptions and tracebacks.  If 
> these were also split off from sys in another separate module, I would look 
> there for the frame functions.

I was talking to the guys in #pypy (and I think some people from twisted 
were agreeing), who said that the whole _frame thing is not really an 
implementation detail, but a rather important interface. As such, I was 
thinking that maybe their underscore prefix should go...

I don't know how hard it would be for Jython, IronPython et al. to 
support this kind of interface, but seeing as how something like 
zope.interface relies on it (and therefore all of Twisted, too, I 
think), it's kind of mandatory anyway.

Cheers,

Dirkjan


From lists at cheimes.de  Fri Nov 30 11:35:18 2007
From: lists at cheimes.de (Christian Heimes)
Date: Fri, 30 Nov 2007 11:35:18 +0100
Subject: [Python-3000] pyvm module - low level interface to Python's VM
In-Reply-To: <fiomri$o5v$1@ger.gmane.org>
References: <fimpkk$405$1@ger.gmane.org> <finmfi$e50$1@ger.gmane.org>
	<fiomri$o5v$1@ger.gmane.org>
Message-ID: <fiop16$vnn$1@ger.gmane.org>

Dirkjan Ochtman wrote:
> I don't know how hard it would be for Jython, IronPython et al. to 
> support this kind of interface, but seeing as how something like 
> zope.interface relies on it (and therefore all of Twisted, too, I 
> think), it's kind of mandatory anyway.

zope.interface could work without sys._getframe(). It's not mandatory
for its API. getframe is used for a clever hack which makes declaring
interfaces more convenient and readable.

class Example:
    implements(IExample)

The implements() function uses frame inspection to find and modify the
local namespace of the class. The code looks like:

def implements(...):
    frame = sys._getframe(...)
    locals = frame.f_locals
    locals['someinterfacedata'] = ...

The same class and interface definition could be written as:

class Example:
    pass

implements(Example, IExample)

but it's not as readable as the version of implements() with stack
inspection.

Christian


From mark at qtrac.eu  Fri Nov 30 12:20:12 2007
From: mark at qtrac.eu (Mark Summerfield)
Date: Fri, 30 Nov 2007 11:20:12 +0000
Subject: [Python-3000] str.format() -- poss. code or doc bug?
Message-ID: <200711301120.12630.mark@qtrac.eu>

Hi,

I'm using Python 30a.

The docs for str.format()'s 'g' format say
    "General format. This prints the number as a fixed-point number,
    unless the number is too large, in which case it switches to 'e'
    exponent notation."
The fixed-point format uses the 'f' character.

But this does not seem to happen in practice:

>>> "[{0:12.4e}] [{0:12.4f}] [{0:12.4g}]".format(10**4 * math.pi)
'[  3.1416e+04] [  31415.9265] [   3.142e+04]'
>>> "[{0:12.4e}] [{0:12.4f}] [{0:12.4g}]".format(10**3 * math.pi)
'[  3.1416e+03] [   3141.5927] [        3142]'

I thought this was a bug in Python 3, but Python 2 does the same thing:

>>> n = 10**4 * math.pi
>>> m = 10**3 * math.pi
>>> "[%12.4e] [%12.4f] [%12.4g]" % (n, n, n)
'[  3.1416e+04] [  31415.9265] [   3.142e+04]'
>>> "[%12.4e] [%12.4f] [%12.4g]" % (m, m, m)
'[  3.1416e+03] [   3141.5927] [        3142]'

Python 2's docs are different from Python 3's regarding 'g' format:
    "Floating point format. Uses exponential format if exponent is
    greater than -4 or less than precision, decimal format otherwise."
There is no "decimal format", but there is "Signed integer decimal"
format which is what seems to being used.

So is this a doc bug?

BTW I notice that decimal.Decimal() numbers can't be used with the 'e',
'f', or 'g' formats. I know that these numbers aren't floating-point
under the hood, but this still seems a bit counter-intuitive to me.

-- 
Mark Summerfield, Qtrac Ltd., www.qtrac.eu


From facundobatista at gmail.com  Fri Nov 30 15:02:40 2007
From: facundobatista at gmail.com (Facundo Batista)
Date: Fri, 30 Nov 2007 11:02:40 -0300
Subject: [Python-3000] str.format() -- poss. code or doc bug?
In-Reply-To: <200711301120.12630.mark@qtrac.eu>
References: <200711301120.12630.mark@qtrac.eu>
Message-ID: <e04bdf310711300602u43a15795j18572ea864f12ec1@mail.gmail.com>

2007/11/30, Mark Summerfield <mark at qtrac.eu>:

> BTW I notice that decimal.Decimal() numbers can't be used with the 'e',
> 'f', or 'g' formats. I know that these numbers aren't floating-point
> under the hood, but this still seems a bit counter-intuitive to me.

Adding __format__ to the Decimal data type is on my queue of pendings...

Regards,

-- 
.    Facundo

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

From exarkun at divmod.com  Fri Nov 30 15:31:22 2007
From: exarkun at divmod.com (Jean-Paul Calderone)
Date: Fri, 30 Nov 2007 09:31:22 -0500
Subject: [Python-3000] pyvm module - low level interface to Python's VM
In-Reply-To: <fiop16$vnn$1@ger.gmane.org>
Message-ID: <20071130143122.8162.1740258355.divmod.quotient.41604@ohm>

On Fri, 30 Nov 2007 11:35:18 +0100, Christian Heimes <lists at cheimes.de> wrote:
>Dirkjan Ochtman wrote:
>> I don't know how hard it would be for Jython, IronPython et al. to
>> support this kind of interface, but seeing as how something like
>> zope.interface relies on it (and therefore all of Twisted, too, I
>> think), it's kind of mandatory anyway.
>
>zope.interface could work without sys._getframe(). It's not mandatory
>for its API. getframe is used for a clever hack which makes declaring
>interfaces more convenient and readable.
>
>class Example:
>    implements(IExample)
>

This is a current feature of zope.interface.  Therefore, zope.interface
requires it, unless you can show an implementation of this API which does
not depend on it.

It is certainly true that this API could be removed from zope.interface.
At that time, zope.interface would not depend on these frame APIs.  It
would also break almost every user of zope.interface and require them to
change to the new API.

Don't try to mix "could work" with "does work" together.

Jean-Paul

From barry at python.org  Fri Nov 30 16:21:16 2007
From: barry at python.org (Barry Warsaw)
Date: Fri, 30 Nov 2007 10:21:16 -0500
Subject: [Python-3000] pyvm module - low level interface to Python's VM
In-Reply-To: <20071130143122.8162.1740258355.divmod.quotient.41604@ohm>
References: <20071130143122.8162.1740258355.divmod.quotient.41604@ohm>
Message-ID: <2A47ED28-8018-4A1C-A1D8-DBCB5265B340@python.org>

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

On Nov 30, 2007, at 9:31 AM, Jean-Paul Calderone wrote:

> On Fri, 30 Nov 2007 11:35:18 +0100, Christian Heimes  
> <lists at cheimes.de> wrote:
>> Dirkjan Ochtman wrote:
>>> I don't know how hard it would be for Jython, IronPython et al. to
>>> support this kind of interface, but seeing as how something like
>>> zope.interface relies on it (and therefore all of Twisted, too, I
>>> think), it's kind of mandatory anyway.
>>
>> zope.interface could work without sys._getframe(). It's not mandatory
>> for its API. getframe is used for a clever hack which makes declaring
>> interfaces more convenient and readable.
>>
>> class Example:
>>    implements(IExample)
>>
>
> This is a current feature of zope.interface.  Therefore,  
> zope.interface
> requires it, unless you can show an implementation of this API  
> which does
> not depend on it.
>
> It is certainly true that this API could be removed from  
> zope.interface.
> At that time, zope.interface would not depend on these frame APIs.  It
> would also break almost every user of zope.interface and require  
> them to
> change to the new API.
>
> Don't try to mix "could work" with "does work" together.

This frame hacking is also a pretty common feature of other types of  
systems, such as ORMs.  It can make certain Python code much more  
readable, so "frame hacking" is clearly a useful feature, at least it  
seems, in the context of a class definition.  Is there a way to  
promote this to an API that's more principled than the sys._getframe 
() hack, and thus more acceptable to Guido and more portable to other  
implementations?

(Or is something like this already in Py3K, and I just haven't  
noticed it yet? ;).

- -Barry

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

iQCVAwUBR1AqbXEjvBPtnXfVAQIfUQQAnKd4ThlGtsUKcdoSj+lXa/4kHxZ5Znju
sOKEWM77pTZZorQuIJjib9UI9GfaZq+HR9lcRb00ztUspNZcX7x/cSMOKFKVQT+B
XiPGJvHpVttYc8Qb1bd/drcPJpK+cvXDBva10ivL8PnSzziMgV86gI1HzSoCxg4i
51X0uzuhLfE=
=Hvxa
-----END PGP SIGNATURE-----

From eric+python-dev at trueblade.com  Fri Nov 30 16:52:43 2007
From: eric+python-dev at trueblade.com (Eric Smith)
Date: Fri, 30 Nov 2007 10:52:43 -0500
Subject: [Python-3000] str.format() -- poss. code or doc bug?
In-Reply-To: <e04bdf310711300602u43a15795j18572ea864f12ec1@mail.gmail.com>
References: <200711301120.12630.mark@qtrac.eu>
	<e04bdf310711300602u43a15795j18572ea864f12ec1@mail.gmail.com>
Message-ID: <475031CB.6090109@trueblade.com>

Facundo Batista wrote:
> 2007/11/30, Mark Summerfield <mark at qtrac.eu>:
> 
>> BTW I notice that decimal.Decimal() numbers can't be used with the 'e',
>> 'f', or 'g' formats. I know that these numbers aren't floating-point
>> under the hood, but this still seems a bit counter-intuitive to me.
> 
> Adding __format__ to the Decimal data type is on my queue of pendings...

That's great to hear!

And backporting __format__ and friends back to trunk is on my pending 
list.  The fact that upgrading to Leopard broke my compilation 
environment isn't helping me out, unfortunately.



From mark at qtrac.eu  Fri Nov 30 17:08:16 2007
From: mark at qtrac.eu (Mark Summerfield)
Date: Fri, 30 Nov 2007 16:08:16 +0000
Subject: [Python-3000] str.format() -- poss. code or doc bug?
In-Reply-To: <47502FD4.6010702@trueblade.com>
References: <200711301120.12630.mark@qtrac.eu> <47502FD4.6010702@trueblade.com>
Message-ID: <200711301608.16444.mark@qtrac.eu>

On 2007-11-30, Eric Smith wrote:
> Mark Summerfield wrote:
> > Hi,
> >
> > I'm using Python 30a.
> >
> > The docs for str.format()'s 'g' format say
> >     "General format. This prints the number as a fixed-point number,
> >     unless the number is too large, in which case it switches to 'e'
> >     exponent notation."
> > The fixed-point format uses the 'f' character.
> >
> > But this does not seem to happen in practice:
> >>>> "[{0:12.4e}] [{0:12.4f}] [{0:12.4g}]".format(10**4 * math.pi)
> >
> > '[  3.1416e+04] [  31415.9265] [   3.142e+04]'
> >
> >>>> "[{0:12.4e}] [{0:12.4f}] [{0:12.4g}]".format(10**3 * math.pi)
> >
> > '[  3.1416e+03] [   3141.5927] [        3142]'
> >
> > I thought this was a bug in Python 3, but Python 2 does the same thing:
> >>>> n = 10**4 * math.pi
> >>>> m = 10**3 * math.pi
> >>>> "[%12.4e] [%12.4f] [%12.4g]" % (n, n, n)
> >
> > '[  3.1416e+04] [  31415.9265] [   3.142e+04]'
> >
> >>>> "[%12.4e] [%12.4f] [%12.4g]" % (m, m, m)
> >
> > '[  3.1416e+03] [   3141.5927] [        3142]'
>
> They're the same because I copied the '%' code when I created the
> __format__ code.  I copied, instead of refactoring and using the same
> code, because at the time I did it I thought the direction was going to
> be to remove '%' formatting.  Plus, the string/unicode work was making
> it more complex at the time.  If I had it to do over, I might spend some
> more time refactoring, or maybe even modifying '%' to call str.format()
> internally.
>
> As to whether the documentation or the code is correct, I can't say
> which is correct or more desirable.  Changing how this works would no
> doubt break all sorts of code.

I have no opinion, I just wanted to know which was right.

Your reply seems to imply that Python 3 will have 3 different and
overlapping ways of formatting strings: %, str.format(), and
string.Template. If that is the case, it seems like overkill to me:-)

> > Python 2's docs are different from Python 3's regarding 'g' format:
> >     "Floating point format. Uses exponential format if exponent is
> >     greater than -4 or less than precision, decimal format otherwise."
> > There is no "decimal format", but there is "Signed integer decimal"
> > format which is what seems to being used.
> >
> > So is this a doc bug?
> >
> > BTW I notice that decimal.Decimal() numbers can't be used with the 'e',
> > 'f', or 'g' formats. I know that these numbers aren't floating-point
> > under the hood, but this still seems a bit counter-intuitive to me.

-- 
Mark Summerfield, Qtrac Ltd., www.qtrac.eu


From eric+python-dev at trueblade.com  Fri Nov 30 16:44:20 2007
From: eric+python-dev at trueblade.com (Eric Smith)
Date: Fri, 30 Nov 2007 10:44:20 -0500
Subject: [Python-3000] str.format() -- poss. code or doc bug?
In-Reply-To: <200711301120.12630.mark@qtrac.eu>
References: <200711301120.12630.mark@qtrac.eu>
Message-ID: <47502FD4.6010702@trueblade.com>

Mark Summerfield wrote:
> Hi,
> 
> I'm using Python 30a.
> 
> The docs for str.format()'s 'g' format say
>     "General format. This prints the number as a fixed-point number,
>     unless the number is too large, in which case it switches to 'e'
>     exponent notation."
> The fixed-point format uses the 'f' character.
> 
> But this does not seem to happen in practice:
> 
>>>> "[{0:12.4e}] [{0:12.4f}] [{0:12.4g}]".format(10**4 * math.pi)
> '[  3.1416e+04] [  31415.9265] [   3.142e+04]'
>>>> "[{0:12.4e}] [{0:12.4f}] [{0:12.4g}]".format(10**3 * math.pi)
> '[  3.1416e+03] [   3141.5927] [        3142]'
> 
> I thought this was a bug in Python 3, but Python 2 does the same thing:
> 
>>>> n = 10**4 * math.pi
>>>> m = 10**3 * math.pi
>>>> "[%12.4e] [%12.4f] [%12.4g]" % (n, n, n)
> '[  3.1416e+04] [  31415.9265] [   3.142e+04]'
>>>> "[%12.4e] [%12.4f] [%12.4g]" % (m, m, m)
> '[  3.1416e+03] [   3141.5927] [        3142]'

They're the same because I copied the '%' code when I created the 
__format__ code.  I copied, instead of refactoring and using the same 
code, because at the time I did it I thought the direction was going to 
be to remove '%' formatting.  Plus, the string/unicode work was making 
it more complex at the time.  If I had it to do over, I might spend some 
more time refactoring, or maybe even modifying '%' to call str.format() 
internally.

As to whether the documentation or the code is correct, I can't say 
which is correct or more desirable.  Changing how this works would no 
doubt break all sorts of code.

> Python 2's docs are different from Python 3's regarding 'g' format:
>     "Floating point format. Uses exponential format if exponent is
>     greater than -4 or less than precision, decimal format otherwise."
> There is no "decimal format", but there is "Signed integer decimal"
> format which is what seems to being used.
> 
> So is this a doc bug?
> 
> BTW I notice that decimal.Decimal() numbers can't be used with the 'e',
> 'f', or 'g' formats. I know that these numbers aren't floating-point
> under the hood, but this still seems a bit counter-intuitive to me.
> 


From lists at cheimes.de  Fri Nov 30 17:51:18 2007
From: lists at cheimes.de (Christian Heimes)
Date: Fri, 30 Nov 2007 17:51:18 +0100
Subject: [Python-3000] str.format() -- poss. code or doc bug?
In-Reply-To: <475031CB.6090109@trueblade.com>
References: <200711301120.12630.mark@qtrac.eu>	<e04bdf310711300602u43a15795j18572ea864f12ec1@mail.gmail.com>
	<475031CB.6090109@trueblade.com>
Message-ID: <fipf27$db7$1@ger.gmane.org>

Eric Smith wrote:
> And backporting __format__ and friends back to trunk is on my pending 
> list.  The fact that upgrading to Leopard broke my compilation 
> environment isn't helping me out, unfortunately.

I've seen several bugs related to Mac OS X 10.5 in the bug tracker.
Could you test some patches for us when you get your build env working
again?

Christian


From p.f.moore at gmail.com  Fri Nov 30 17:52:05 2007
From: p.f.moore at gmail.com (Paul Moore)
Date: Fri, 30 Nov 2007 16:52:05 +0000
Subject: [Python-3000] pyvm module - low level interface to Python's VM
In-Reply-To: <2A47ED28-8018-4A1C-A1D8-DBCB5265B340@python.org>
References: <20071130143122.8162.1740258355.divmod.quotient.41604@ohm>
	<2A47ED28-8018-4A1C-A1D8-DBCB5265B340@python.org>
Message-ID: <79990c6b0711300852y6b1555c8tbae50821a5cf46f7@mail.gmail.com>

On 30/11/2007, Barry Warsaw <barry at python.org> wrote:
> >> class Example:
> >>    implements(IExample)
>
> This frame hacking is also a pretty common feature of other types of
> systems, such as ORMs.  It can make certain Python code much more
> readable, so "frame hacking" is clearly a useful feature, at least it
> seems, in the context of a class definition.  Is there a way to
> promote this to an API that's more principled than the sys._getframe
> () hack, and thus more acceptable to Guido and more portable to other
> implementations?
>
> (Or is something like this already in Py3K, and I just haven't
> noticed it yet? ;).

There's class decorators:

    @implements(IExample)
    class Example:
        pass

which could provide the same result in effect, but (as J-P points out)
it's still an API change and so not a direct replacement. IIRC, one of
the arguments for class decorators was that they are a way to avoid
the need for some of this getframe hacking, though.

Paul.

From guido at python.org  Fri Nov 30 18:29:26 2007
From: guido at python.org (Guido van Rossum)
Date: Fri, 30 Nov 2007 09:29:26 -0800
Subject: [Python-3000] pyvm module - low level interface to Python's VM
In-Reply-To: <fiomri$o5v$1@ger.gmane.org>
References: <fimpkk$405$1@ger.gmane.org> <finmfi$e50$1@ger.gmane.org>
	<fiomri$o5v$1@ger.gmane.org>
Message-ID: <ca471dc20711300929o3d21bf24w1d00f68fd33050bd@mail.gmail.com>

On Nov 30, 2007 1:58 AM, Dirkjan Ochtman <dirkjan at ochtman.nl> wrote:
> I was talking to the guys in #pypy (and I think some people from twisted
> were agreeing), who said that the whole _frame thing is not really an
> implementation detail, but a rather important interface. As such, I was
> thinking that maybe their underscore prefix should go...
>
> I don't know how hard it would be for Jython, IronPython et al. to
> support this kind of interface, but seeing as how something like
> zope.interface relies on it (and therefore all of Twisted, too, I
> think), it's kind of mandatory anyway.

Well I hate to say it again (over and over), but the hacks used by
those systems are all disgusting and they should not be encouraged by
giving the _getframe() API a higher status.

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

From krstic at solarsail.hcs.harvard.edu  Fri Nov 30 18:02:13 2007
From: krstic at solarsail.hcs.harvard.edu (=?UTF-8?Q?Ivan_Krsti=C4=87?=)
Date: Fri, 30 Nov 2007 15:02:13 -0200
Subject: [Python-3000] pyvm module - low level interface to Python's VM
In-Reply-To: <79990c6b0711300852y6b1555c8tbae50821a5cf46f7@mail.gmail.com>
References: <20071130143122.8162.1740258355.divmod.quotient.41604@ohm>
	<2A47ED28-8018-4A1C-A1D8-DBCB5265B340@python.org>
	<79990c6b0711300852y6b1555c8tbae50821a5cf46f7@mail.gmail.com>
Message-ID: <913FE3C0-45F2-41BD-85D2-92D5F0CBE6E0@solarsail.hcs.harvard.edu>

On Nov 30, 2007, at 2:52 PM, Paul Moore wrote:
> one of the arguments for class decorators was that they are a way to  
> avoid the need for some of this getframe hacking, though.


IIRC, the zope.interface clusterfrack was _the_ argument that got  
Guido to give thought to class decorators, after it was brought to his  
attention by, I think, PJE.

--
Ivan Krsti? <krstic at solarsail.hcs.harvard.edu> | http://radian.org


From guido at python.org  Fri Nov 30 18:37:12 2007
From: guido at python.org (Guido van Rossum)
Date: Fri, 30 Nov 2007 09:37:12 -0800
Subject: [Python-3000] str.format() -- poss. code or doc bug?
In-Reply-To: <200711301608.16444.mark@qtrac.eu>
References: <200711301120.12630.mark@qtrac.eu> <47502FD4.6010702@trueblade.com>
	<200711301608.16444.mark@qtrac.eu>
Message-ID: <ca471dc20711300937x3c5546cbn3be6ef0ae8dc25f1@mail.gmail.com>

On Nov 30, 2007 8:08 AM, Mark Summerfield <mark at qtrac.eu> wrote:
> Your reply seems to imply that Python 3 will have 3 different and
> overlapping ways of formatting strings: %, str.format(), and
> string.Template. If that is the case, it seems like overkill to me:-)

IMO string.Template is a dead experiment.

My original plan was to get rid of % in favor of str.format(). This
seems to have run into objections from folks who don't want to have to
change their code. They have a point: when the string is not a
literal, it's not possible for 2to3 to automatically convert x%y to a
.format() call. So perhaps we should deprecate % formatting and get
rid of it at some later time.

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

From pje at telecommunity.com  Fri Nov 30 18:37:58 2007
From: pje at telecommunity.com (Phillip J. Eby)
Date: Fri, 30 Nov 2007 12:37:58 -0500
Subject: [Python-3000] pyvm module - low level interface to Python's VM
In-Reply-To: <79990c6b0711300852y6b1555c8tbae50821a5cf46f7@mail.gmail.co
 m>
References: <20071130143122.8162.1740258355.divmod.quotient.41604@ohm>
	<2A47ED28-8018-4A1C-A1D8-DBCB5265B340@python.org>
	<79990c6b0711300852y6b1555c8tbae50821a5cf46f7@mail.gmail.com>
Message-ID: <20071130173806.9D12E3A408C@sparrow.telecommunity.com>

At 04:52 PM 11/30/2007 +0000, Paul Moore wrote:
>On 30/11/2007, Barry Warsaw <barry at python.org> wrote:
> > >> class Example:
> > >>    implements(IExample)
> >
> > This frame hacking is also a pretty common feature of other types of
> > systems, such as ORMs.  It can make certain Python code much more
> > readable, so "frame hacking" is clearly a useful feature, at least it
> > seems, in the context of a class definition.  Is there a way to
> > promote this to an API that's more principled than the sys._getframe
> > () hack, and thus more acceptable to Guido and more portable to other
> > implementations?
> >
> > (Or is something like this already in Py3K, and I just haven't
> > noticed it yet? ;).
>
>There's class decorators:
>
>     @implements(IExample)
>     class Example:
>         pass
>
>which could provide the same result in effect, but (as J-P points out)
>it's still an API change and so not a direct replacement. IIRC, one of
>the arguments for class decorators was that they are a way to avoid
>the need for some of this getframe hacking, though.

Well, for what class-level frame hacking is typically used for, it 
would suffice to have a convenient way to refer to the local 
namespace, e.g. if you could do something like:

     implements(@, IExample)

where @ was a shortcut for locals().  The most-used frame hacks (in 
zope.interface and most PEAK tools) just want to access the namespace 
of the current class definition, and maybe decorate the class in some way.


From mark at qtrac.eu  Fri Nov 30 18:45:20 2007
From: mark at qtrac.eu (Mark Summerfield)
Date: Fri, 30 Nov 2007 17:45:20 +0000
Subject: [Python-3000] str.format() -- poss. code or doc bug?
In-Reply-To: <ca471dc20711300937x3c5546cbn3be6ef0ae8dc25f1@mail.gmail.com>
References: <200711301120.12630.mark@qtrac.eu>
	<200711301608.16444.mark@qtrac.eu>
	<ca471dc20711300937x3c5546cbn3be6ef0ae8dc25f1@mail.gmail.com>
Message-ID: <200711301745.21256.mark@qtrac.eu>

On 2007-11-30, Guido van Rossum wrote:
> On Nov 30, 2007 8:08 AM, Mark Summerfield <mark at qtrac.eu> wrote:
> > Your reply seems to imply that Python 3 will have 3 different and
> > overlapping ways of formatting strings: %, str.format(), and
> > string.Template. If that is the case, it seems like overkill to me:-)
>
> IMO string.Template is a dead experiment.

Does that mean it should be deprecated in the docs?

> My original plan was to get rid of % in favor of str.format(). This
> seems to have run into objections from folks who don't want to have to
> change their code. They have a point: when the string is not a
> literal, it's not possible for 2to3 to automatically convert x%y to a
> .format() call. So perhaps we should deprecate % formatting and get
> rid of it at some later time.

I just downloaded the most recent docs and they describe % under "Old
String Formatting Operations" and say "The formatting operations
described here are obsolete and may go away in future versions of
Python. Use the new String Formatting in new code."

So for new users, str.format() will be _the_ way.

Thanks!

-- 
Mark Summerfield, Qtrac Ltd., www.qtrac.eu




From fdrake at acm.org  Fri Nov 30 18:42:19 2007
From: fdrake at acm.org (Fred Drake)
Date: Fri, 30 Nov 2007 12:42:19 -0500
Subject: [Python-3000] str.format() -- poss. code or doc bug?
In-Reply-To: <ca471dc20711300937x3c5546cbn3be6ef0ae8dc25f1@mail.gmail.com>
References: <200711301120.12630.mark@qtrac.eu> <47502FD4.6010702@trueblade.com>
	<200711301608.16444.mark@qtrac.eu>
	<ca471dc20711300937x3c5546cbn3be6ef0ae8dc25f1@mail.gmail.com>
Message-ID: <0D97916A-D8FA-4D7F-A8E9-317AF0150929@acm.org>

On Nov 30, 2007, at 12:37 PM, Guido van Rossum wrote:
> IMO string.Template is a dead experiment.

Ouch.  I like it.  I use it.  I hope it doesn't disappear.

I'd be fine if it moved, and it should be easy enough to separate into  
a separate package distribution (which would be fine for my purposes).

If it moves out of the standard library, I'll volunteer to create a  
separate distribution for it (assuming no one beats me to it).


   -Fred

-- 
Fred Drake   <fdrake at acm.org>





From eric+python-dev at trueblade.com  Fri Nov 30 19:22:30 2007
From: eric+python-dev at trueblade.com (Eric Smith)
Date: Fri, 30 Nov 2007 13:22:30 -0500
Subject: [Python-3000] str.format() -- poss. code or doc bug?
In-Reply-To: <fipf27$db7$1@ger.gmane.org>
References: <200711301120.12630.mark@qtrac.eu>	<e04bdf310711300602u43a15795j18572ea864f12ec1@mail.gmail.com>	<475031CB.6090109@trueblade.com>
	<fipf27$db7$1@ger.gmane.org>
Message-ID: <475054E6.5000500@trueblade.com>

Christian Heimes wrote:
> Eric Smith wrote:
>> And backporting __format__ and friends back to trunk is on my pending 
>> list.  The fact that upgrading to Leopard broke my compilation 
>> environment isn't helping me out, unfortunately.
> 
> I've seen several bugs related to Mac OS X 10.5 in the bug tracker.
> Could you test some patches for us when you get your build env working
> again?
> 
> Christian

Sure.  I'm planning on repaving the machine this weekend.  I originally 
updated it from 10.4, hopefully a fresh 10.5 install will deal with my 
problems.

Eric.


From brett at python.org  Fri Nov 30 20:38:32 2007
From: brett at python.org (Brett Cannon)
Date: Fri, 30 Nov 2007 11:38:32 -0800
Subject: [Python-3000] str.format() -- poss. code or doc bug?
In-Reply-To: <ca471dc20711300937x3c5546cbn3be6ef0ae8dc25f1@mail.gmail.com>
References: <200711301120.12630.mark@qtrac.eu> <47502FD4.6010702@trueblade.com>
	<200711301608.16444.mark@qtrac.eu>
	<ca471dc20711300937x3c5546cbn3be6ef0ae8dc25f1@mail.gmail.com>
Message-ID: <bbaeab100711301138l28c041c5y4a9f8205ad43b16b@mail.gmail.com>

On Nov 30, 2007 9:37 AM, Guido van Rossum <guido at python.org> wrote:
> On Nov 30, 2007 8:08 AM, Mark Summerfield <mark at qtrac.eu> wrote:
> > Your reply seems to imply that Python 3 will have 3 different and
> > overlapping ways of formatting strings: %, str.format(), and
> > string.Template. If that is the case, it seems like overkill to me:-)
>
> IMO string.Template is a dead experiment.
>
> My original plan was to get rid of % in favor of str.format(). This
> seems to have run into objections from folks who don't want to have to
> change their code. They have a point: when the string is not a
> literal, it's not possible for 2to3 to automatically convert x%y to a
> .format() call. So perhaps we should deprecate % formatting and get
> rid of it at some later time.

+1 from me on starting a PendingDeprecationWarning in 3.0 and a
DeprecationWarning move on % formatting once Python 3 has stabilized
(I know you have said 3.1 or 3.2 would most likely be that version).

-Brett