Phillip J. Eby wrote:
> At 12:54 PM 7/24/2007 +1200, Greg Ewing wrote:
>> > binary operators depend on multiple argument values (and you
>>> have to know *both* types in order to work out the result)
>> Yes, that can be a bit more complex, but at least the method
>> that gets called has to belong
On 7/20/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I definitely *don't* want to continue the old habit of having a slow
> and a fast module with different names; the experience with especially
> cPickle and cStringIO is that everyone believes their code is
> performance critical and hence us
I am not sure if an official naming scheme is really necessary. For
StringIO and BytesIO, I simply added a leading underscore the Python
implementations and rename them if the C implementations aren't
available. So, the Python versions remain available for testing, or if
someone needs them.
-- Ale
Taking the recent threads here, and Guido's comments off-list, I've
attempted to put together a coherent response as a new section for
the PEP, which I've checked in and included a copy of here. If I
have misrepresented anyone's argument, or if you spot something where
you have a question or n
I'm confused why you spend so much time refuting the argument, given
that you've already agreed to implement explicit decoration. Did I
misread that? As I tried to indicate with my "gut feelings" argument
this is not something that's up to rational argument. Also, the
paragraph starting with "As a
Yeah, that particular test is not yet working. (Fixes are welcome --
see http://wiki.python.org/moin/Py3kStrUniTests for how to help.)
I believe I rigged "make install" to continue after this error -- did
the rest of the install complete?
FWIW, a better place to discuss Py3k bleeding edge stuff i
At 03:16 PM 7/24/2007 -0700, Guido van Rossum wrote:
>I'm confused why you spend so much time refuting the argument,
The purpose was to capture the arguments on both sides for posterity
as part of the PEP.
> Also, the
>paragraph starting with "As a result, the vast majority of overloads
>can b
On 7/24/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I believe I rigged "make install" to continue after this error -- did
> the rest of the install complete?
Yes, it continued fine. BTW, are you interested in sending the output
of python testsuite? I'm on a Fedora Core 6 box.
I could build
Guido van Rossum wrote:
> On 7/24/07, Lisandro Dalcin <[EMAIL PROTECTED]> wrote:
>> Afther checking out the py3k-struni branch, 'make install' issued this:
>>
>> Compiling /usr/local/python/3.0/lib/python3.0/test/test_tarfile.py ...
>> *** SyntaxError: ('expected string, bytes found',
>> ('/usr/loc
Lisandro Dalcin wrote:
> However, I am having trouble with 'pickle', but perhaps this is only
> my fault, i just imported pickle instead of cPickle (and all this in a
> C extension module). I am using that because cPickle seems to be not
> available in the py3k-struni.
The pickle module is broken
Phillip J. Eby wrote:
> ...and may be subclassed in an unlimited number of places.
>
> A generic function is defined in just one place, with a limited number
> of "generic" methods typically adjoining it, and may be extended in an
> unlimited number of places.
>
> Where's the difference?
With
Phillip J. Eby wrote:
> At 12:54 PM 7/24/2007 +1200, Greg Ewing wrote:
>> When adding an overload to a GF, what methodology can I
>> follow to ensure that my overload doesn't interact in an
>> unfortunate way with another one somewhere else, perhaps
>> one not written by me?
>
> What methodology c
Phillip J. Eby wrote:
> At 03:16 PM 7/24/2007 -0700, Guido van Rossum wrote:
>
>>I'm confused why you spend so much time refuting the argument,
>
> The purpose was to capture the arguments on both sides for posterity
> as part of the PEP.
I don't think you need to spend so many words on the
arg
What's broken about pickle on the struni branch? It passes all its tests.
On 7/24/07, Christian Heimes <[EMAIL PROTECTED]> wrote:
> Lisandro Dalcin wrote:
> > However, I am having trouble with 'pickle', but perhaps this is only
> > my fault, i just imported pickle instead of cPickle (and all this
You can find it in the usual place:
http://www.python.org/dev/peps/pep-3101/
There are no changes to public APIs, the only changes are to the
extension mechanism for custom formatting classes. Also, I've edited a
lot of the text in order to improve the clarity of explanations and cut
out
Tarfile is not from the 1.x days. But you're right, it's hairy. It
also changes too much (e.g. between 2.4.1 and 2.4.3 a refactoring
happened that also caused a new bug. The code has evolved quite a bit
since then and is still evolving... ;-( )
On 7/24/07, Christian Heimes <[EMAIL PROTECTED]> wrot
I'm looking through a couple of the OS X tests and have run into the
question of what to do with four-character codes. (For those of you
who are unfamiliar with these, Apple, around the dawn of time, decided
that C constants like 'TEXT' (yes, those are single quotes) would
compile to the uint32_t 0
Jeffrey Yasskin wrote:
> I'm looking through a couple of the OS X tests and have run into the
> question of what to do with four-character codes. (For those of you
> who are unfamiliar with these, Apple, around the dawn of time, decided
> that C constants like 'TEXT' (yes, those are single quotes)
Make them bytes literals (some code already does this), and convert
them to integers when they're needed to be used as hash keys. (Does
this happen a lot? I haven't seen it yet.)
I would endorse an API to create an int from a bytes array (or
arbitrary length) and vice versa -- that would be a usef
19 matches
Mail list logo
