Re: [Python-Dev] PEP 3118: Extended buffer protocol (new version)
Carl Banks wrote: > Py_BUF_REQUIRE_READONLY - Raise excpetion if the buffer is writable. Is there a use case for this? -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3118: Extended buffer protocol (new version)
Travis Oliphant wrote:
> Carl Banks wrote:
>> My recommendation is, any flag should turn on some circle in the Venn
>> diagram (it could be a circle I didn't draw--shaped arrays, for
>> example--but it should be *some* circle).
> I don't think your Venn diagram is broad enough and it un-necessarily
> limits the use of flags to communicate between consumer and exporter.
> We don't have to ram these flags down that point-of-view for them to be
> productive.If you have a specific alternative proposal, or specific
> criticisms, then I'm very willing to hear them.
Ok, I've thought quite a bit about this, and I have an idea that I think
will be ok with you, and I'll be able to drop my main objection. It's
not a big change, either. The key is to explicitly say whether the flag
allows or requires. But I made a few other changes as well.
First of all, let me define how I'm using the word "contiguous": it's a
single buffer with no gaps. So, if you were to do this:
"memset(bufinfo->buf,0,bufinfo->len)", you would not touch any data that
isn't being exported.
Without further ado, here is my proposal:
--
With no flags, the PyObject_GetBuffer will raise an exception if the
buffer is not direct, contiguous, and one-dimensional. Here are the
flags and how they affect that:
Py_BUF_REQUIRE_WRITABLE - Raise exception if the buffer isn't writable.
Py_BUF_REQUIRE_READONLY - Raise excpetion if the buffer is writable.
Py_BUF_ALLOW_NONCONTIGUOUS - Allow noncontiguous buffers. (This turns
on "shape" and "strides".)
Py_BUF_ALLOW_MULTIDIMENSIONAL - Allow multidimensional buffers. (Also
turns on "shape" and "strides".)
(Neither of the above two flags implies the other.)
Py_BUF_ALLOW_INDIRECT - Allow indirect buffers. Implies
Py_BUF_ALLOW_NONCONTIGUOUS and Py_BUF_ALLOW_MULTIDIMENSIONAL. (Turns on
"shape", "strides", and "suboffsets".)
Py_BUF_REQUIRE_CONTIGUOUS_C_ARRAY or Py_BUF_REQUIRE_ROW_MAJOR - Raise an
exception if the array isn't a contiguous array with in C (row-major)
format.
Py_BUF_REQUIRE_CONTIGUOUS_FORTRAN_ARRAY or Py_BUF_REQUIRE_COLUMN_MAJOR -
Raise an exception if the array isn't a contiguous array with in Fortran
(column-major) format.
Py_BUF_ALLOW_NONCONTIGUOUS, Py_BUF_REQUIRE_CONTIGUOUS_C_ARRAY, and
Py_BUF_REQUIRE_CONTIGUOUS_FORTRAN_ARRAY all conflict with each other,
and an exception should be raised if more than one are set.
(I would go with ROW_MAJOR and COLUMN_MAJOR: even though the terms only
make sense for 2D arrays, I believe the terms are commonly generalized
to other dimensions.)
Possible pseudo-flags:
Py_BUF_SIMPLE = 0;
Py_BUF_ALLOW_STRIDED = Py_BUF_ALLOW_NONCONTIGUOUS
| Py_BUF_ALLOW_MULTIDIMENSIONAL;
--
Now, for each flag, there should be an associated function to test the
condition, given a bufferinfo struct. (Though I suppose they don't
necessarily have to map one-to-one, I'll do that here.)
int PyBufferInfo_IsReadonly(struct bufferinfo*);
int PyBufferInfo_IsWritable(struct bufferinfo*);
int PyBufferInfo_IsContiguous(struct bufferinfo*);
int PyBufferInfo_IsMultidimensional(struct bufferinfo*);
int PyBufferInfo_IsIndirect(struct bufferinfo*);
int PyBufferInfo_IsRowMajor(struct bufferinfo*);
int PyBufferInfo_IsColumnMajor(struct bufferinfo*);
The function PyObject_GetBuffer then has a pretty obvious
implementation. Here is an except:
if ((flags & Py_BUF_REQUIRE_READONLY) &&
!PyBufferInfo_IsReadonly(&bufinfo)) {
PyExc_SetString(PyErr_BufferError,"buffer not read-only");
return 0;
}
Pretty straightforward, no?
Now, here is a key point: for these functions to work (indeed, for
PyObject_GetBuffer to work at all), you need enough information in
bufinfo to figure it out. The bufferinfo struct should be
self-contained; you should not need to know what flags were passed to
PyObject_GetBuffer in order to know exactly what data you're looking at.
Therefore, format must always be supplied by getbuffer. You cannot tell
if an array is contiguous without the format string. (But see below.)
And even if the consumer isn't asking for a contiguous buffer, it has to
know the item size so it knows what data not to step on.
(This is true even in your own proposal, BTW. If a consumer asks for a
non-strided array in your proposal, PyObject_GetBuffer would have to
know the item size to determine if the array is contiguous.)
--
FAQ:
Q. Why ALLOW_NONCONTIGUOUS and ALLOW_MULTIDIMENSIONAL instead of
ALLOW_STRIDED and ALLOW_SHAPED?
A. It's more useful to the consumer that way. With ALLOW_STRIDED and
ALLOW_SHAPED, there's no way for a consumer to request a general
one-dimensional array (it can only request a non-strided one-dimensional
array), and requesting a SHAPED array but not a STRIDED one can only
return a C-like (row-major) array, although a consumer might reasonably
want a Fortran-like (column-major) array. This approach maps more
directly to the consumer's n
Re: [Python-Dev] Access to Python SVN
Travis E. Oliphant schrieb: > I'd like to ask for access to Python SVN so that I can keep the PEP 3118 > up to date as well as to eventually make the changes needed for > implementing the extended buffer protocol. > > I will email my public SSH key to the appropriate place. Please send it to me. Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] test_normalization failures across communitybuildbots
[Collin Winter] > This should be fixed in r54844. The problem was that the availability > of the urlfetch resource wasn't being checked early enough and so > test_support.run_suite() was converting the ResourceDenied exception > into a TestError instance. This wasn't showing up on other machines > since the urlfetch'd files weren't being cleaned out between test > runs. Can you add code to clean them out between runs? Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Access to Python SVN
+1 On 4/16/07, Travis E. Oliphant <[EMAIL PROTECTED]> wrote: > I'd like to ask for access to Python SVN so that I can keep the PEP 3118 > up to date as well as to eventually make the changes needed for > implementing the extended buffer protocol. > > I have quite a bit of experience with the Python C-API and understand > many parts of the code base fairly well (though I would not claim to be > an expert on all of it). > > I promise to only adjust the PEP until such time as patches to implement > the extended buffer protocol are approved. > > I will email my public SSH key to the appropriate place. > > Thank you very much, > > -Travis Oliphant > > > > > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Access to Python SVN
I'd like to ask for access to Python SVN so that I can keep the PEP 3118 up to date as well as to eventually make the changes needed for implementing the extended buffer protocol. I have quite a bit of experience with the Python C-API and understand many parts of the code base fairly well (though I would not claim to be an expert on all of it). I promise to only adjust the PEP until such time as patches to implement the extended buffer protocol are approved. I will email my public SSH key to the appropriate place. Thank you very much, -Travis Oliphant ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] new metaclass error condition checks
I just noticed r53997 (from some unit tests it broke), which disallowed things like this: class X(object): def __repr__(self): return "blah" class Y(X, type): pass class Z: __metaclass__ = Y Making X classic eliminates the TypeError, and is probably an acceptable fix in a lot of cases (at least as long as classic classes are available). I wonder if the ability to override type special methods like this was considered when the change was made, though? Jean-Paul ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] test_normalization failures across community buildbots
On 4/16/07, Brett Cannon <[EMAIL PROTECTED]> wrote: > On 4/16/07, Grig Gheorghiu <[EMAIL PROTECTED]> wrote: > > On 4/16/07, Brett Cannon <[EMAIL PROTECTED]> wrote: > > > Don't know what suddenly triggered this (nothing I did), but the code > > > basically looks correct. What should be happening is regrtest should be > > > catching that exception and just saying the test was skipped. > > > > > > The last commit on regrtest was March 12, test_support was touched April > 3, > > > and test_normalization on April 5 according to ``svn log -r COMMITTED``. > > > > > > > There's a check-in related to test_normalization.py on April 5th that > > seems to have triggered the failures: > > > > > http://www.python.org/dev/buildbot/community/trunk/changes/1292 > > > > Sorry I haven't reported this sooner, I've been swamped the last couple > weeks. > > > That's Collin's checkin when he updated the test to use unittest. Any > ideas, Collin? This should be fixed in r54844. The problem was that the availability of the urlfetch resource wasn't being checked early enough and so test_support.run_suite() was converting the ResourceDenied exception into a TestError instance. This wasn't showing up on other machines since the urlfetch'd files weren't being cleaned out between test runs. Collin Winter ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] test_normalization failures across community buildbots
On 4/16/07, Grig Gheorghiu <[EMAIL PROTECTED]> wrote: On 4/16/07, Brett Cannon <[EMAIL PROTECTED]> wrote: > Don't know what suddenly triggered this (nothing I did), but the code > basically looks correct. What should be happening is regrtest should be > catching that exception and just saying the test was skipped. > > The last commit on regrtest was March 12, test_support was touched April 3, > and test_normalization on April 5 according to ``svn log -r COMMITTED``. > There's a check-in related to test_normalization.py on April 5th that seems to have triggered the failures: http://www.python.org/dev/buildbot/community/trunk/changes/1292 Sorry I haven't reported this sooner, I've been swamped the last couple weeks. That's Collin's checkin when he updated the test to use unittest. Any ideas, Collin? -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] test_normalization failures across community buildbots
On 4/16/07, Brett Cannon <[EMAIL PROTECTED]> wrote: > Don't know what suddenly triggered this (nothing I did), but the code > basically looks correct. What should be happening is regrtest should be > catching that exception and just saying the test was skipped. > > The last commit on regrtest was March 12, test_support was touched April 3, > and test_normalization on April 5 according to ``svn log -r COMMITTED``. > There's a check-in related to test_normalization.py on April 5th that seems to have triggered the failures: http://www.python.org/dev/buildbot/community/trunk/changes/1292 Sorry I haven't reported this sooner, I've been swamped the last couple weeks. Grig ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] SystemErrors in generator (just happened in 2.5)
[Neal Norwitz]
> There were some SystemErrors on one of the Windows build slaves.
Not always, though -- looks to be rare.
> Does anyone have any ideas what might be the cause? I looked through about
> 5 previous logs on the same slave and didn't see the same problem.
I'm home today and fired up my slave, and no problem there either.
> I haven't seen this myself and I don't know if it's WIndows specific. I
> don't know if this has happened on the trunk or just 2.5.
Me neither.
> For the full log see:
> http://python.org/dev/buildbot/2.5/x86%20XP%202.5/builds/197/step-test/0
>
> n
> --
>
> *** Previous context (I don't think this really matters):
>
> Re-running test 'test_profilehooks' in verbose mode
> test_caught_exception (test.test_profilehooks.ProfileHookTestCase) ... ok
> test_caught_nested_exception (test.test_profilehooks.ProfileHookTestCase) ...
> ok
> test_distant_exception (test.test_profilehooks.ProfileHookTestCase) ... ok
> test_exception (test.test_profilehooks.ProfileHookTestCase) ... ok
> test_exception_in_except_clause
> (test.test_profilehooks.ProfileHookTestCase) ... ok
> test_exception_propogation (test.test_profilehooks.ProfileHookTestCase) ... ok
> test_generator (test.test_profilehooks.ProfileHookTestCase) ... ok
> test_nested_exception (test.test_profilehooks.ProfileHookTestCase) ... ok
> test_raise (test.test_profilehooks.ProfileHookTestCase) ... ok
> test_raise_reraise (test.test_profilehooks.ProfileHookTestCase) ... ok
> test_raise_twice (test.test_profilehooks.ProfileHookTestCase) ... ok
> test_simple (test.test_profilehooks.ProfileHookTestCase) ... ok
> test_stop_iteration (test.test_profilehooks.ProfileHookTestCase) ... ok
> test_basic_exception (test.test_profilehooks.ProfileSimulatorTestCase) ... ok
> test_caught_exception (test.test_profilehooks.ProfileSimulatorTestCase) ... ok
> test_distant_exception (test.test_profilehooks.ProfileSimulatorTestCase) ...
> ok
> test_simple (test.test_profilehooks.ProfileSimulatorTestCase) ... ok
>
> --
> Ran 17 tests in 0.016s
>
> OK
>
> *** Here is the problem:
>
> Exception exceptions.SystemError: 'error return without exception set' in
> ignored
> Exception exceptions.SystemError: 'error return without exception set' in
> ignored
> Exception exceptions.SystemError: 'error return without exception set' in
> ignored
> Exception exceptions.SystemError: 'error return without exception set' in
> ignored
> Exception exceptions.SystemError: 'error return without exception set' in
> ignored
> *** The following messages occur in other successful tests too:
> a DOS box should flash briefly ...
Always happens in test_subprocess, during the Windows-specific
test_creationflags. This is expected. When you /watch/ the tests
running on Windows, it's intended to prevent panic when a mysterious
DOS box appears ;-)
> find_library('c') -> None
> find_library('m') -> None
Mysterious. Looks like debug/trace(!) output while running
Lib/ctypes/test/test_loading.py's test_find().
> C:\buildbot_py25\2.5.mcintyre-windows\build\lib\test\test_unicode_file.py:103:
> UnicodeWarning: Unicode equal comparison failed to convert both
> arguments to Unicode - interpreting them as being unequal
> filename1==filename2
> C:\buildbot_py25\2.5.mcintyre-windows\build\lib\shutil.py:36:
> UnicodeWarning: Unicode equal comparison failed to convert both
> arguments to Unicode - interpreting them as being unequal
> os.path.normcase(os.path.abspath(dst)))
Those started showing up months ago.
> warning: DBTxn aborted in destructor. No prior commit() or abort().
Likewise, from the bsddb test, and we've been seeing this one on
Unixish boxes too.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] test_normalization failures across community buildbots
On 4/16/07, Grig Gheorghiu <[EMAIL PROTECTED]> wrote:
Almost all community buildbots have failed the test step due to a
failure in test_normalization. Here's a link to the community farm for
the trunk:
http://www.python.org/dev/buildbot/community/trunk/
And here's an example of a failure:
http://www.python.org/dev/buildbot/community/trunk/x86%20OSX%20trunk/builds/567/step-test/0
test test_normalization failed -- Traceback (most recent call last):
File
"/Users/builder/pybots/pybot/trunk.osaf-x86/build/Lib/test/test_normalization.py",
line 36, in test_main
for line in open_urlresource(TESTDATAURL):
File
"/Users/builder/pybots/pybot/trunk.osaf-x86/build/Lib/test/test_support.py",
line 271, in open_urlresource
requires('urlfetch')
File
"/Users/builder/pybots/pybot/trunk.osaf-x86/build/Lib/test/test_support.py",
line 94, in requires
raise ResourceDenied(msg)
ResourceDenied: Use of the `urlfetch' resource not enabled
Don't know what suddenly triggered this (nothing I did), but the code
basically looks correct. What should be happening is regrtest should be
catching that exception and just saying the test was skipped.
The last commit on regrtest was March 12, test_support was touched April 3,
and test_normalization on April 5 according to ``svn log -r COMMITTED``.
-Brett
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 3118: Extended buffer protocol (new version)
Reading this message without the entire PEP in front of me showed some confusing usage. (Details below) Most (but not all) I could resolve from the PEP itself, but they could be clarified with different constant names. Counter Proposal at bottom, and specific questions in between. Travis Oliphant wrote: > Carl Banks wrote: >> Some of the flags RESTRICT the kind of buffers that can be >> exported (Py_BUF_WRITABLE); other flags EXPAND the >> kind of buffers that can be exported (Py_BUF_INDIRECT). >> That is highly confusing and I'm -1 >> on any proposal that includes both behaviors. > Basically, every flag corresponds to a different property of > the buffer that the consumer is requesting: I had trouble seeing it like that. Could you at least rename them something like SHAPE_VALID? But I would prefer the change suggested at the bottom. > Py_BUF_SIMPLE --- you are requesting the simplest possible (0x00) ??? Does this automatically assume a readable buffer? (No hardware write buffers?) (This one I couldn't tell from the PEP) > Py_BUF_WRITEABLE -- get a writeable buffer (0x01) > Py_BUF_READONLY -- get a read-only buffer(0x02) Do Py_BUF_READONLY promise that *this* consumer won't try to change it, or request that it be immutable (and no one else will change it either)? (From the PEP itself, I think you wanted IMMUTABLE.) When it comes back, does it mean "you, the consumer, promised not to change this", or "I, the exporter, won't authorize anyone to change it, including myself." If it is really a request for immutability, and the exporter can't make that promise, then should the buffer protocol itself make and return an immutable copy? For this grouping to make sense, I have to assume that you really mean Py_BUF_READABLE (0 - no way to mark it write-only) Py_BUF_WRITABLE (1 - meaning *this* consumer can write) Py_BUF_IMMUTABLE (2 - meaning no one can change it.) so 3 => compile-time error but that still doesn't mesh with your later statement that: > ... most people request read-or-write buffers > i.e. Py_BUF_SIMPLE. > Py_BUF_FORMAT -- get a "formatted" buffer. (0x04) Is this saying "I the consumer will respect your formatting" or "I the consumer will fail if you don't tell me the formatting"? If this flag comes back, does that mean that understanding the formatting is mandatory, or is it just informational? ??? To make this concrete, there are libraries that sniff and guess a format. Should they pass this flag or not? > Py_BUF_SHAPE -- get a buffer with shape information (0x08) Wait -- what is the difference between these two again? Is "format" the internal format of a single element, and shape the dimensions of an array? Should Py_BUF_FORMAT be Py_BUF_ELT_FORMAT? Do you pass Py_BUF_SHAPE to indicate that you'll accept N-Dim arrays, or to say that you prefer them or somehow need them? ??? If Py_BUF_SHAPE was requested, but the buffer really is 1-dimensional, should this still be set on the way back? (Presumably setting the "shape" variable to point to a (one-element) array containing len/itemsize? > Py_BUF_STRIDES -- get a buffer with stride information (and shape) (0x18) > Py_BUF_OFFSET -- get a buffer with suboffsets (and strides and shape) (0x38) I assume that Py_BUF_OFFSET doesn't make sense without Py_BUF_STRIDES, and Py_BUF_STRIDES doesn't make sense without Py_BUF_SHAPE. What happens if someone *does* pass 0x20? If you want to avoid that, it might make sense to treat this as 4 enumerated values (1-D, n-D, n-D with strides, n-D with strides and offsets) instead of 3 flags. If Py_BUF_OFFSET was requested, but the return value is a single continuous 1D array, should Py_BUF_OFFSET still come back but have the zeros filled in? Also, why are all negative offsets invalid? It seems like they might be useful for some re-orderings, and using an offset of 0 has the same effect as marking the offset unused. > For me, the most restrictive requests are > PY_BUF_WRITEABLE | Py_BUF_FORMAT and > Py_BUF_READONLY | Py_BUF_FORMAT > The most un-restrictive request (the largest circle in my mental Venn > diagram) is > Py_BUF_OFFSETS followed by Py_BUF_STRIDES followed by Py_BUF_SHAPE I think this is what he meant when he said that the flags had opposite meanings. Ideally, 0 and 0xFF should be shortcuts to either the most restrictive or the least restrictive. > Think of them as turning "on" members of the bufferinfo structure. If the senses can't be reversed, could you at least rename them to indicate this? Something like Py_BUF_VALID_SUBOFFSETS? Counter Proposal: 0x00: Py_BUF_RWLOCK: "Consumer is a new owner. It can read and write; no other code can." (most restrictive) 0x01: Py_BUF_READONLY: "Consumer doesn't need to (cannot) write." 0x02: Py_BUF_MUTABLE: "Other code can write" (implies) 0x03 = PY_BUF_UR: Py_BUF_READONLY | Py_BUF_MUTABLE : "Unconfirmed Read: Consumer won't write,
[Python-Dev] test_normalization failures across community buildbots
Almost all community buildbots have failed the test step due to a
failure in test_normalization. Here's a link to the community farm for
the trunk:
http://www.python.org/dev/buildbot/community/trunk/
And here's an example of a failure:
http://www.python.org/dev/buildbot/community/trunk/x86%20OSX%20trunk/builds/567/step-test/0
test test_normalization failed -- Traceback (most recent call last):
File
"/Users/builder/pybots/pybot/trunk.osaf-x86/build/Lib/test/test_normalization.py",
line 36, in test_main
for line in open_urlresource(TESTDATAURL):
File
"/Users/builder/pybots/pybot/trunk.osaf-x86/build/Lib/test/test_support.py",
line 271, in open_urlresource
requires('urlfetch')
File
"/Users/builder/pybots/pybot/trunk.osaf-x86/build/Lib/test/test_support.py",
line 94, in requires
raise ResourceDenied(msg)
ResourceDenied: Use of the `urlfetch' resource not enabled
Grig
--
http://agiletesting.blogspot.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r54805 - python/branches/release25-maint/Lib/test/test_pty.py
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Apr 13, 2007, at 4:58 PM, Martin v. Löwis wrote: >> I don't know, maybe it is. This one's extremely low risk as it only >> affects certain platforms when test_pty is run verbosely. But if it >> ain't cool, I'll back it out and re-apply after 2.5.1 final. > > Please back it out. If there are changes to the branch, we would have > to create another release candidate (IMO). I see Neal did already... thanks Neal. I was away for most of the weekend. Cheers, - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRiNj3XEjvBPtnXfVAQLgfQP+KVKtGkEzZpo8Bjhlo6w7zII5oQdo9pDy L18n2OjcJyAsz+Hgo4hkel6W+O39o/lR0EtjohCUlfG92DTgyoUxGXc2g88LyT83 G4Gob2UBoqiWnsHpYjWFP6/HlAcr6nUXa6CGJqkyhzud6+c9ZsdfOIhDpZfyxh2x ZzH/D5f8D7M= =aI0k -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] SystemErrors in generator (just happened in 2.5)
There were some SystemErrors on one of the Windows build slaves. Does
anyone have any ideas what might be the cause? I looked through about
5 previous logs on the same slave and didn't see the same problem. I
haven't seen this myself and I don't know if it's WIndows specific. I
don't know if this has happened on the trunk or just 2.5.
For the full log see:
http://python.org/dev/buildbot/2.5/x86%20XP%202.5/builds/197/step-test/0
n
--
*** Previous context (I don't think this really matters):
Re-running test 'test_profilehooks' in verbose mode
test_caught_exception (test.test_profilehooks.ProfileHookTestCase) ... ok
test_caught_nested_exception (test.test_profilehooks.ProfileHookTestCase) ... ok
test_distant_exception (test.test_profilehooks.ProfileHookTestCase) ... ok
test_exception (test.test_profilehooks.ProfileHookTestCase) ... ok
test_exception_in_except_clause
(test.test_profilehooks.ProfileHookTestCase) ... ok
test_exception_propogation (test.test_profilehooks.ProfileHookTestCase) ... ok
test_generator (test.test_profilehooks.ProfileHookTestCase) ... ok
test_nested_exception (test.test_profilehooks.ProfileHookTestCase) ... ok
test_raise (test.test_profilehooks.ProfileHookTestCase) ... ok
test_raise_reraise (test.test_profilehooks.ProfileHookTestCase) ... ok
test_raise_twice (test.test_profilehooks.ProfileHookTestCase) ... ok
test_simple (test.test_profilehooks.ProfileHookTestCase) ... ok
test_stop_iteration (test.test_profilehooks.ProfileHookTestCase) ... ok
test_basic_exception (test.test_profilehooks.ProfileSimulatorTestCase) ... ok
test_caught_exception (test.test_profilehooks.ProfileSimulatorTestCase) ... ok
test_distant_exception (test.test_profilehooks.ProfileSimulatorTestCase) ... ok
test_simple (test.test_profilehooks.ProfileSimulatorTestCase) ... ok
--
Ran 17 tests in 0.016s
OK
*** Here is the problem:
Exception exceptions.SystemError: 'error return without exception set'
in ignored
Exception exceptions.SystemError: 'error return without exception set'
in ignored
Exception exceptions.SystemError: 'error return without exception set'
in ignored
Exception exceptions.SystemError: 'error return without exception set'
in ignored
Exception exceptions.SystemError: 'error return without exception set'
in ignored
*** The following messages occur in other successful tests too:
a DOS box should flash briefly ...
find_library('c') -> None
find_library('m') -> None
C:\buildbot_py25\2.5.mcintyre-windows\build\lib\test\test_unicode_file.py:103:
UnicodeWarning: Unicode equal comparison failed to convert both
arguments to Unicode - interpreting them as being unequal
filename1==filename2
C:\buildbot_py25\2.5.mcintyre-windows\build\lib\shutil.py:36:
UnicodeWarning: Unicode equal comparison failed to convert both
arguments to Unicode - interpreting them as being unequal
os.path.normcase(os.path.abspath(dst)))
warning: DBTxn aborted in destructor. No prior commit() or abort().
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.5.1c1 pickle problem
On 4/12/07, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > Ralf, your issue is arising because of revision 53655 which fixes SF 1615701. I have backed out this change for 2.5.1. > Am leaving this open for others to discuss and decide. The old behavior was > surprising to some, but the revised behavior also appears to have some > unforeseen consequences. Anthony and I talked about this a bit. The current behavior seems less than optimal. However, changing it in a bug fix release seems particularly risky. > P.S. In addition to rev 53655, a number of similar changes were made to sets. Raymond, can you revert the changes? I looked in Objects/setobject.c and saw 53667. Is that the revision you are referring to? Are there any other revs? Thanks, n ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
