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.
htt
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/)
___
Python-3000 mailing list
Python-3000@python.org
http://
On 11/5/07, Christian Heimes <[EMAIL PROTECTED]> 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.
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
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
On 11/3/07, Brett Cannon <[EMAIL PROTECTED]> 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 a
On 11/5/07, Bill Janssen <[EMAIL PROTECTED]> 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 PyByt
> > > 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_in
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 faili
On 11/4/07, Christian Heimes <[EMAIL PROTECTED]> 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 buffe
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
On 11/4/07, Guido van Rossum <[EMAIL PROTECTED]> 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 fi
Paul Moore schrieb:
> On 04/11/2007, Guido van Rossum <[EMAIL PROTECTED]> 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"
On 04/11/2007, Guido van Rossum <[EMAIL PROTECTED]> 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)
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 <[EMAIL PROTECTED]> wrote:
> Those look c
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
On Sat, Nov 03, 2007, Brett Cannon wrote:
> On 11/3/07, Christian Heimes <[EMAIL PROTECTED]> 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
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 loc
On 11/3/07, Brett Cannon <[EMAIL PROTECTED]> wrote:
> On 11/2/07, Guido van Rossum <[EMAIL PROTECTED]> 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 th
On 11/3/07, Brett Cannon <[EMAIL PROTECTED]> wrote:
> On 11/2/07, Guido van Rossum <[EMAIL PROTECTED]> 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 th
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 t
Guido van Rossum wrote:
> On 11/3/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
>> On 11/3/07, Guido van Rossum <[EMAIL PROTECTED]> 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-i
On 11/3/07, Larry Hastings <[EMAIL PROTECTED]> 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 th
On 11/3/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> On 11/3/07, Guido van Rossum <[EMAIL PROTECTED]> 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 n
On 11/3/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 11/3/07, Greg Ewing <[EMAIL PROTECTED]> 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 parti
On 11/2/07, Guido van Rossum <[EMAIL PROTECTED]> 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
On 11/3/07, Christian Heimes <[EMAIL PROTECTED]> 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
> veri
On 11/3/07, Adam Hupp <[EMAIL PROTECTED]> 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 prob
On 11/3/07, Greg Ewing <[EMAIL PROTECTED]> 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.
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
___
Python
On 11/3/07, Christian Heimes <[EMAIL PROTECTED]> 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 pre
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. Th
On 11/2/07, Guido van Rossum <[EMAIL PROTECTED]> 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 presen
On 11/3/07, Brett Cannon <[EMAIL PROTECTED]> 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
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.
Christia
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 b
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
On 03/11/2007, Christian Heimes <[EMAIL PROTECTED]> 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 a
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
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 "stri
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 e
On 03/11/2007, Paul Moore <[EMAIL PROTECTED]> wrote:
> On 03/11/2007, Christian Heimes <[EMAIL PROTECTED]> 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 s
On 03/11/2007, Christian Heimes <[EMAIL PROTECTED]> 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.
___
Python-3000 mailing list
Python
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
>
On 03/11/2007, Guido van Rossum <[EMAIL PROTECTED]> 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_arra
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
w
On 11/2/07, Guido van Rossum <[EMAIL PROTECTED]> 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
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_e
47 matches
Mail list logo
