Christian Heimes wrote:
> I found a bug in the str type that may affect a lot of tests.
>
> In the py3k-struni branch the str() constructor doesn't use __str__ when
> the argument is an instance of a subclass of str. A user defined string
> can't change __str__(). The __repr__ method isn't affect
Yeah, I'm looking in to this right now. What a mess! But I'm close to a fix.
There's more that causes test_descr to fail however. Bleh, what a
terrible unit test -- it doesn't use the unittest module, and a single
failure aborts the rest of the test.
--Guido
On 7/11/07, Walter Dörwald <[EMAIL PR
Fixed in subversion. Please do review r56252 to see that I did the right thing.
On 7/11/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Yeah, I'm looking in to this right now. What a mess! But I'm close to a fix.
>
> There's more that causes test_descr to fail however. Bleh, what a
> terrible un
Which joker tried to unsub me?
-- Forwarded message --
From: [EMAIL PROTECTED]
<[EMAIL PROTECTED]>
Date: Jul 11, 2007 12:43 PM
Subject: Your confirmation is required to leave the Python-3000 mailing list
To: [EMAIL PROTECTED]
Mailing list removal confirmation notice for mailing l
On 7/11/07, Thomas Heller <[EMAIL PROTECTED]> wrote:
> Christian Heimes schrieb:
> >
> > By the way the ctypes unit tests are causing a segfault on my machine:
> > test_ctypes
> > Warning: could not import ctypes.test.test_numbers: unpack requires a
> > string argument of length 1
> > Segmentation
Thomas Heller wrote:
> I would love to look into these, but I prefer debugging on Windows.
> However, the windows build does not work because the _fileio builtin
> module is missing from config.c. Again, this is not so easy to fix,
> because the ftruncate function does not exist on Windows.
In fi
That would be great! Assign it to theller who can test it much better
than I can.
On 7/11/07, Amaury Forgeot d'Arc <[EMAIL PROTECTED]> wrote:
> Thomas Heller wrote:
> > I would love to look into these, but I prefer debugging on Windows.
> > However, the windows build does not work because the _fil
Guido van Rossum schrieb:
> That would be great! Assign it to theller who can test it much better
> than I can.
>
> On 7/11/07, Amaury Forgeot d'Arc <[EMAIL PROTECTED]> wrote:
>> Thomas Heller wrote:
>> > I would love to look into these, but I prefer debugging on Windows.
>> > However, the windows
There are currently three "string" types, here shown with there repr styles:
- str = 'same as unicode in 2.x'
- bytes = b'new, mutable list of small ints'
- str8 = s'same as str in 2.x'
The s'...' notation means it's an 8-bit string (not a bytes array).
This is not supported in the syntax; it's j
Guido van Rossum schrieb:
> There are currently three "string" types, here shown with there repr styles:
>
> - str = 'same as unicode in 2.x'
> - bytes = b'new, mutable list of small ints'
> - str8 = s'same as str in 2.x'
>
> The s'...' notation means it's an 8-bit string (not a bytes array).
> T
On 7/11/07, Thomas Heller <[EMAIL PROTECTED]> wrote:
> Let me explain it in other words. This code creates a new type:
>
> >>> ht = type("name", (object,), {})
> [47054 refs]
> >>> ht
>
> [47093 refs]
>
> The '__name__' attribute is a (unicode) string:
>
> >>> ht.__name__
> 'name'
> [47121 refs]
I can't find the message you forwarded in mail.python.org's logs (although I
may be looking wrong; its hard to do such a search without the full headers
of the original) -- but it looks to me like it was a hoax, and not an actual
unsubscription request from mail.python.org.
On 7/11/07, Guido van
ctypes creates heaptypes with this call, in _ctypes.c, line 3986 (slightly
simplified):
result = PyObject_CallFunction((PyObject *)&ArrayType_Type,
"s(O){s:n,s:O}",
name,
&
Guido van Rossum wrote:
> Fixed in subversion. Please do review r56252 to see that I did the right
> thing.
I haven't looked at test_descr.py but the rest looks good to me.
I guess for the final version of Py3000 type_set_name() in typeobject.c
will not downgrade unicode strings to str8, but ins
Walter Dörwald schrieb:
>
> I guess for the final version of Py3000 type_set_name() in typeobject.c
> will not downgrade unicode strings to str8, but instead upgrade str8
> objects to unicode.
I'm currently working on type_set_name, see the other message with subject
'Heaptypes'.
Thomas
__
Hello,
Thomas Wouters wrote:
>
> I can't find the message you forwarded in mail.python.org's logs (although I
> may be looking wrong; its hard to do such a search without the full headers
> of the original) -- but it looks to me like it was a hoax, and not an actual
> unsubscription request from m
I have a very remedial question about how to fix test failures due to
the side effects of string-unicode integration.
The xmlrpc library uses explicit encoding to encode XML tag payloads
to (almost always) utf8. Tag literals are not encoded.
What would be the best way to mimic this behavior
Hi,
Thomas Heller wrote:
The most important problem, IMO, is now that wide filenames on Windows are not
implemented, see the code starting at line 148 in _fileio.c. This prevents
most unittests to run because test_support cannot be imported:
C:\svn\py3k-struni\PCbuild>python -E -tt ../lib/tes
Re-hello,
Thomas Heller wrote:
> On 7/11/07, Amaury Forgeot d'Arc wrote:
>> Thomas Heller wrote:
>> > I would love to look into these, but I prefer debugging on Windows.
>> > However, the windows build does not work because the _fileio builtin
>> > module is missing from config.c. Again, this i
Amaury Forgeot d'Arc schrieb:
> Re-hello,
>
> Thomas Heller wrote:
>> > On 7/11/07, Amaury Forgeot d'Arc wrote:
>> >> Thomas Heller wrote:
>> >> > I would love to look into these, but I prefer debugging on Windows.
>> >> > However, the windows build does not work because the _fileio builtin
>> >>
On 7/11/07, Walter Dörwald <[EMAIL PROTECTED]> wrote:
> I guess for the final version of Py3000 type_set_name() in typeobject.c
> will not downgrade unicode strings to str8, but instead upgrade str8
> objects to unicode.
Right, Thomas is working on this (but I have some feedback on his fix).
> Al
On 7/11/07, Chris McDonough <[EMAIL PROTECTED]> wrote:
> I have a very remedial question about how to fix test failures due to
> the side effects of string-unicode integration.
>
> The xmlrpc library uses explicit encoding to encode XML tag payloads
> to (almost always) utf8. Tag literals are not
On 7/11/07, Amaury Forgeot d'Arc <[EMAIL PROTECTED]> wrote:
> BTW, what is the status of this fileobject? open() doesn't seem to use
> it anymore. Will file() be removed at some point?
The 'file' builtin is already gone. (You did use the py3k-struni
branch, didn't you?) Some parts of the fileobjec
It's a small detail but I wonder if it's time to stop using a
leading underscore for internal APIs. I'm not sure what would be a
good replacement, perhaps a trailing underscore. In case people
don't remember, the _Py prefix could, theoretically, be invalid C on
some platforms.
Regards,
Neil
Someone asked if Py3 would get a "real" or "pure" bool type (one not
subclassing int). [The usual complaints and rehash about current bool
ensured.] I believe (and said so) that this is a settled question. If so,
please add a line under Standard types
* bool will continue to subclass int.
tj
I decided to try to tackle the unit tests failing on the py3k-struni
branch for mmap. It now passes all the unit tests but one, and
the problem is that I don't know what should be 'fixed'. The
code in the unit test is:
finally:
try:
f.close()
except
Joe Gregorio wrote:
> flush() raises
> ValueError() if the file is already closed,
>
> Should io.py raise OSError instead of ValueError?
Is it really necessary to raise anything at all?
An already-closed file is as flushed as it can
get, so why not just let it be a no-op?
--
Greg Ewing, Compute
27 matches
Mail list logo
