Phillip J. Eby wrote:
> At 07:49 AM 7/20/2007 -0700, Guido van Rossum wrote:
>> On 7/19/07, Joe Smith <[EMAIL PROTECTED]> wrote:
>>> So the state of the PEP? From the rest of the posts so far,
>>> it sounds like there is no real objection to the basic end user API as
>>> described in the PEP,
>> Ac
On Saturday 21 July 2007, Joe Gregorio wrote:
> Should xml.parsers.expat.XMLParser.ParseFile(file) operate on
> both text and binary streams?
No. XML is a serialization of a markup language containing Unicode character
into an encoded stream.
-Fred
--
Fred L. Drake, Jr.
__
Should xml.parsers.expat.XMLParser.ParseFile(file) operate on
both text and binary streams?
If it should operate on text streams then an
issue arises from "read(n)" meaning different
things for text and binary streams. If the stream passed in
is "text" then read(n) will read
'n' unicode characters
Josiah Carlson wrote:
> What made it really annoying is that there was no way to tell the heapq
> module not to load the C version so that I could use a generic container.
I would say that all such dual-implementation modules should
make the specific implementations available under different
name
Joe Smith wrote:
> If the maintainers of most of the large packages that do imaging are willing
> to support this,
> and your code is good, I see absolutely no reason why this PEP would not be
> accepted.
Something that bothers me about it a little is that
the core Python/C API seems like the wr
Thanks to all who helped fixing tests in the str/unicode branch! We're
down to about 35 failing tests. I still need help -- especially since
we're now getting into territory that I don't know all that well, for
example the email package or XML support.
The list of unit tests that need help is stil
On 7/20/07, Blake Winton <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> >> While the pickle/cPickle, StringIO/cStringIO, etc., naming can be
> >> a bit annoying, it does give me the choice whether I want it to be
> >> fast or flexible.
> > I definitely *don't* want to continue the old hab
Guido van Rossum wrote:
>> While the pickle/cPickle, StringIO/cStringIO, etc., naming can be
>> a bit annoying, it does give me the choice whether I want it to be
>> fast or flexible.
> I definitely *don't* want to continue the old habit of having a slow
> and a fast module with different names;
I discovered what appears to be a thread-unsafety in uuid.py. This is
in the trunk as well as in 3.x; I'm using the trunk here for easy
reference. There's some code around like 395:
import ctypes, ctypes.util
_buffer = ctypes.create_string_buffer(16)
This creates a *global* buffer which i
At 07:49 AM 7/20/2007 -0700, Guido van Rossum wrote:
>On 7/19/07, Joe Smith <[EMAIL PROTECTED]> wrote:
> > So the state of the PEP? From the rest of the posts so far,
> > it sounds like there is no real objection to the basic end user API as
> > described in the PEP,
>
>Actually I want to reserve j
On 7/20/07, Joe Smith <[EMAIL PROTECTED]> wrote:
> "Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> > On 7/19/07, Joe Smith <[EMAIL PROTECTED]> wrote:
> >> So the state of the PEP? From the rest of the posts so far,
> >> it sounds like there is no real objection to
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> On 7/19/07, Joe Smith <[EMAIL PROTECTED]> wrote:
>> So the state of the PEP? From the rest of the posts so far,
>> it sounds like there is no real objection to the basic end user API as
>> described in the PEP,
>
> A
They shouldn't, really, and I don't care too much about what happens
in that case. It may depend on whether the I/O device honors seeks
beyond EOF or not.
On 7/20/07, Alexandre Vassalotti <[EMAIL PROTECTED]> wrote:
> How this different from setting the position to the new size? What
> should happe
How this different from setting the position to the new size? What
should happen when someone call truncate() with an argument greater
than the current size? Should it do a seek, or nothing?
Thanks,
-- Alexandre
On 7/18/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Unless anyone cares, it sho
On 7/19/07, Joe Smith <[EMAIL PROTECTED]> wrote:
> So the state of the PEP? From the rest of the posts so far,
> it sounds like there is no real objection to the basic end user API as
> described in the PEP,
Actually I want to reserve judgment on that until the PEP is rewritten
to explain and docu
On 7/20/07, Josiah Carlson <[EMAIL PROTECTED]> wrote:
>
> "Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> > On 7/19/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > > How about instead you help with fixing pickling of datetime objects?
> > > This broke when I fixed test_pickle. Rolling back your
"Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> On 7/19/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > How about instead you help with fixing pickling of datetime objects?
> > This broke when I fixed test_pickle. Rolling back your changes to
> > datetime pickling didn't seem to help.
>
> Nev
17 matches
Mail list logo
