Re: [Python-Dev] optparse and unicode
On 30-mei-2006, at 22:32, Tom Cato Amundsen wrote: optparse Using unicode strings with non-ascii chars.[1] I'm working around this by subclassing OptionParser. Below is a workaround I use in GNU Solfege. Should something like this be included in python 2.5? Could you please file a bug or feature request for this on SF? Your report might get lost otherwise. Ronald ___ 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-3000] stdlib reorganization
A.M. Kuchling wrote: On Tue, May 30, 2006 at 03:36:02PM -0600, Steven Bethard wrote: That sounds about reasonable. One possible grouping: Note that 2.5's library reference has a different chapter organization from 2.4's. See http://docs.python.org/dev/lib/lib.html. I like it. Its a much cleaner organization than the 2.4 libs. I would like to see it used as a starting point for a reorg of the standard lib namespace. One question that is raised is whether the categories should map directly to package names in all cases. For example, I can envision a desire that 'sys' would stay a top-level name, rather than 'rt.sys'. Certain modules are so fundamental that they deserve IMHO to live in the root namespace. -- Talin ___ 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] test_struct failure on 64 bit platforms
Bob,
There are a couple of things I don't understand about the new struct.
Below is a test that fails.
$ ./python ./Lib/test/regrtest.py test_tarfile test_struct
test_tarfile
/home/pybot/test-trunk/build/Lib/struct.py:63: DeprecationWarning: 'l'
format requires -2147483648 = number = 2147483647
return o.pack(*args)
test_struct
test test_struct failed -- pack('l', -2147483649) did not raise error
1 test OK.
1 test failed:
test_struct
I fixed the error message (the min value was off by one before). I
think I fixed a few ssize_t issues too.
The remaining issues I know of are:
* The warning only appears on 64-bit platforms.
* The warning doesn't seem correct for 64-bit platforms (l is 8 bytes, not 4).
* test_struct only fails if run after test_tarfile.
* The msg from test_struct doesn't seem correct for 64-bit platforms.
I tracked the problem down to trying to write the gzip tar file. Can
you fix this?
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
Re: [Python-Dev] test_struct failure on 64 bit platforms
On May 31, 2006, at 12:49 AM, Neal Norwitz wrote:
Bob,
There are a couple of things I don't understand about the new struct.
Below is a test that fails.
$ ./python ./Lib/test/regrtest.py test_tarfile test_struct
test_tarfile
/home/pybot/test-trunk/build/Lib/struct.py:63: DeprecationWarning: 'l'
format requires -2147483648 = number = 2147483647
return o.pack(*args)
test_struct
test test_struct failed -- pack('l', -2147483649) did not raise error
1 test OK.
1 test failed:
test_struct
I fixed the error message (the min value was off by one before). I
think I fixed a few ssize_t issues too.
The remaining issues I know of are:
* The warning only appears on 64-bit platforms.
* The warning doesn't seem correct for 64-bit platforms (l is 8
bytes, not 4).
* test_struct only fails if run after test_tarfile.
* The msg from test_struct doesn't seem correct for 64-bit platforms.
I tracked the problem down to trying to write the gzip tar file. Can
you fix this?
The warning is correct, and so is the size. Only native formats have
native sizes; l and i are exactly 4 bytes on all platforms when using
=, , , or !. That's what std size and alignment means.
It looks like the only thing that's broken here is the test. The
behavior changed to consistently allow any integer whatsoever to be
passed to struct for all formats (except q and Q which have always
done proper range checking). Previously, the range checking was
inconsistent across platforms (32-bit and 64-bit anyway) and when
using int vs. long.
Unfortunately I don't have a 64-bit platform easily accessible and I
have no idea which test it is that's raising the warning. Could you
isolate it?
-bob
___
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] fixing buildbots
On 5/30/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Zitat von Neal Norwitz [EMAIL PROTECTED]:
I've been starting to get some of the buildbots working again. There
was some massive problem on May 25 where a ton of extra files were
left around. I can't remember if I saw something about that at the
NFS sprint or not.
You can clean each buildbot remotely by forcing a build on a
(non-existing) branch. That removes the build tree, and then
tries to build the branch (which fails if the branch doesn't
exist). The next build will then start with a fresh checkout
of the trunk.
That's good to know. Thanks. In this case there were also bogus
files/directories created that were siblings of the build area, so I
don't think that those could have been cleaned up. I'm pretty sure it
would have fixed the problem though.
There is a lingering problem that I can't fix on all the boxes. Namely:
cp Modules/Setup{.dist,}
Should we always do that step before we build on the buildbots?
If so, the easiest way to do it would be to make distclean in
the clean step: that removes Modules/Setup as well.
I agree this is best. I updated Makefile.pre.in and master.cfg. I
didn't restart the buildbot yet though. I wanted to wait for a quiet
period.
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
Re: [Python-Dev] test_struct failure on 64 bit platforms
On 5/31/06, Bob Ippolito [EMAIL PROTECTED] wrote:
On May 31, 2006, at 12:49 AM, Neal Norwitz wrote:
Bob,
There are a couple of things I don't understand about the new struct.
Below is a test that fails.
$ ./python ./Lib/test/regrtest.py test_tarfile test_struct
test_tarfile
/home/pybot/test-trunk/build/Lib/struct.py:63: DeprecationWarning: 'l'
format requires -2147483648 = number = 2147483647
return o.pack(*args)
test_struct
test test_struct failed -- pack('l', -2147483649) did not raise error
1 test OK.
1 test failed:
test_struct
I fixed the error message (the min value was off by one before). I
think I fixed a few ssize_t issues too.
The remaining issues I know of are:
* The warning only appears on 64-bit platforms.
* The warning doesn't seem correct for 64-bit platforms (l is 8
bytes, not 4).
* test_struct only fails if run after test_tarfile.
* The msg from test_struct doesn't seem correct for 64-bit platforms.
I tracked the problem down to trying to write the gzip tar file. Can
you fix this?
The warning is correct, and so is the size. Only native formats have
native sizes; l and i are exactly 4 bytes on all platforms when using
=, , , or !. That's what std size and alignment means.
Ah, you are correct. I see this is the behaviour in 2.4. Though I
wouldn't call 4 bytes a standard size on a 64-bit platform.
Unfortunately I don't have a 64-bit platform easily accessible and I
have no idea which test it is that's raising the warning. Could you
isolate it?
I wasted sleep for that? Damn and I gotta get up early again tomorrow
too. See the checkin for answer. Would someone augment the warnings
module to make testing more reasonable?
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
Re: [Python-Dev] [Python-checkins] r46300 - in python/trunk: Lib/socket.py Lib/test/test_socket.py Lib/test/test_struct.py Modules/_struct.c Modules/arraymodule.c Modules/socketmodule.c
On 5/29/06, Guido van Rossum [EMAIL PROTECTED] wrote: [python-checkins] * Added socket.recv_buf() and socket.recvfrom_buf() methods, that use the buffer protocol (send and sendto already did). * Added struct.pack_to(), that is the corresponding buffer compatible method to unpack_from(). [Guido] Hm... The file object has a similar method readinto(). Perhaps the methods introduced here could follow that lead instead of using two different new naming conventions? On 5/27/06, Bob Ippolito [EMAIL PROTECTED] wrote: (speaking specifically about struct and not socket) pack_to and unpack_from are named as such because they work with objects that support the buffer API (not file-like-objects). I couldn't find any existing convention for objects that manipulate buffers in such a way. Actually, fileobject.readinto(bufferobject) is the convention I started long ago (at the time the buffer was introduced. If there is an existing convention then I'd be happy to rename these. readinto seems to imply that some kind of position is being incremented. No -- it's like read() but instead of returning a new object it reads into an object you pass. Grammatically it only works if it's implemented on all buffer objects, but in this case it's implemented on the Struct type. It looks like structobject.pack_to(bufferobject, other args) is similar to fileobject.readinto(bufferobject) in that the buffer object receives the result of packing / reading. So I assume you're suggesting the following renames: pack_to - packinto recv_buf - recvinto recvfrom_buf - recvfrominto (I don't like that last one very much. I'll go ahead and make those renames once I return.) ___ 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] Reporting unexpected import failures as test failures in regrtest.py
Some background for those not watching python-checkins: I neglected to do svn add for the new functools Python module when converting functional-functools. The buildbots stayed green because the ImportError triggered by the line import functools in test_functools was treated as a TestSkipped by regrtest.py. Georg noticed the file missing from the checkin message, but this is the second time I (and the buildbots) have missed a regression due to this behaviour. (As I recall, last time I checked in some broken code because I didn't notice the additional entry appearing in the list of unexpected skips in my local testing) Tim Peters wrote: [Nick Coghlan] ... (we should probably do something about that misleading ImportError - TestSkipped - green buildbot behaviour. . . ) I looked at that briefly a few weeks back and gave up. Seemed the sanest thing was to entirely stop treating ImportError as test skipped, and rewrite tests that legimately _may_ get skipped to catch expected ImportErrors and change them to TestSkipped themselves. A bit of framework might help; e.g., a test that expects to get skipped due to failing imports on some platforms could define a module-level list bound to a conventional name containing the names of the modules whose import failure should be treated as TestSkipped, and then regrtest.py could be taught to check import errors against the test module's list (if any). In the case du jour, test_functools.py presumably wouldn't define that list, so that any ImportError it raised would be correctly treated as test failure. What if we appended unexpected skips to the list of bad tests so that they get rerun in verbose mode and the return value becomes non-zero? print count(len(surprise), skip), \ unexpected on, plat + : printlist(surprise) # Add the next line after the previous two in regrtest.py bad.extend(surprise) (This happens after the count of failed tests has been printed, so we don't affect that output) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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] A can of worms... (does Python C code have a new C style?)
Hi all I'd like to know what the policy is on the source code indentation for C code in the interpreter. At the Need-for-Speed sprints, there was consensus that there is a new indentation for style for the Python C source files, with * indentation (emacs: c-basic-offset): 4 chars * no tabs (so tab-width does not matter) * 79 chars max for lines (I think) (Correct me if any of this is wrong.) I cannot find where this discussion comes from, PEP 7 seems to imply that the new style only applies to Python 3k. Is this correct? However, people were maintaining the existing styles when they were editing part of existing files (I setup emacs users with two c-styles, python and python-new, so they could switch per-file), but using the new guidelines for new files. I look at the source code, and there is a bit of a mix of the two styles in some places. Is there a grand plan to convert all the code at once at some point? If not, how is it that these new guidelines are supposed to take effect? I could easily contribute to the vaccuuming here, by writing a script that will run emacs in batch mode on all the C code with the appropriate new style to do the following for each C file present: * re-indent the entire file according to the new guidelines * convert all the tabs to whitespace * delete trailing whitespace on all lines * remove those pesky CR if there are any * (anything else you'd like that's easily done from emacs?) The problem is that if someone was to check-in the result of this automation there would be a huge wave of complaints from merge conflicts for people who have a checkouts with lots of uncommitted changes. I don't see any painless way to do this. To ease the pain, however, it could be done at a fixed time, giving everyone a wide margin of chance to commit beforehand. In addition, should this be applied, we should probably create a Subversion hook that will automatically convert tabs to spaces, or fails the commit if the files don't comply. I realize this is potentially opening a can of worms, but on the one hand I'd like to know what's the low-down on the indentation, and on the other hand I won't spend a second on this if this is only going to lead to trouble. Then again, maybe I misunderstood and the new rules apply only to Python 3k, in which case, well, press delete and move on. cheers, ___ 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] A can of worms... (does Python C code have a new C style?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 31 May 2006 07:02:02 -0400 Martin Blais [EMAIL PROTECTED] wrote: I'd like to know what the policy is on the source code indentation for C code in the interpreter. At the Need-for-Speed sprints, there was consensus that there is a new indentation for style for the Python C source files, with * indentation (emacs: c-basic-offset): 4 chars * no tabs (so tab-width does not matter) * 79 chars max for lines (I think) (Correct me if any of this is wrong.) I cannot find where this discussion comes from, PEP 7 seems to imply that the new style only applies to Python 3k. Is this correct? AFAIK, yes it only applies to Py3K. There are no plans to re-indent the Python 2.x C code. Or maybe, there have been plans to do so for 10 years and in Py3K those plans might finally come to fruition. :) BTW, A while back I think I posted a py3k cc-mode style for you X/Emacs hackers out there. It's based on the standard python style but changes c-basic-offset and indent-tabs-mode. Let me know if you can't find it in the archives. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iQCVAwUBRH2HvnEjvBPtnXfVAQJv/wQAhKBvh49xW59JgKv6tq9O/QvU/jvZJSPw qHMjOi55IGdFUG4zrSOH08U0VSkkM/mhoBgAqggNnsWMsFjtEu0NeOcroKIPBmLK RU1B4sw78RQFj/phEBpCvgObYRoI8lEVJYnXKFAp6yY9qGdJRGIRGhVX5nnBz/as 4BLr5tADpHo= =IFzC -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
Re: [Python-Dev] [Python-3000] stdlib reorganization
On Tue, May 30, 2006 at 11:46:06PM -0700, Talin wrote: I like it. Its a much cleaner organization than the 2.4 libs. I would like to see it used as a starting point for a reorg of the standard lib namespace. I'm not convinced that the chapter organization of a book is necessarily the best choice for the actual package layout of the standard library. A grouping that's useful for reference may not be ideal for staying in one's memory. --amk ___ 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_struct failure on 64 bit platforms
[Bob] The warning is correct, and so is the size. Only native formats have native sizes; l and i are exactly 4 bytes on all platforms when using =, , , or !. That's what std size and alignment means. [Neal] Ah, you are correct. I see this is the behaviour in 2.4. Though I wouldn't call 4 bytes a standard size on a 64-bit platform. standard is a technical word with precise meaning here, and is defined by the struct module docs, in contrast to native. It means whatever they say it means :-) Portable may have been a more intuitive word than standard here -- read standard in the struct context in the sense of standardized, regardless of native platform size or alignment or endian quirks. Would someone augment the warnings module to make testing more reasonable? What's required? I know of two things: 1. There's no advertised way to save+restore the internal filter list, or to remove a filter entry, so tests that want to make a temporary change have to break into the internals. 2. There's no advertised way to disable only gripe once per source line behavior. This gets in the way of testing that warnings get raised when running tests more than once, or using a common function to raise warnings from multiple call sites. These get in the way of Zope and ZODB testing too, BTW. Unfortunately, looks like the new test_struct code bumped into both of them at once. ___ 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] Reporting unexpected import failures as test failures in regrtest.py
[Nick Coghlan] What if we appended unexpected skips to the list of bad tests so that they get rerun in verbose mode and the return value becomes non-zero? print count(len(surprise), skip), \ unexpected on, plat + : printlist(surprise) # Add the next line after the previous two in regrtest.py bad.extend(surprise) (This happens after the count of failed tests has been printed, so we don't affect that output) While expected skips is reliable on Windows, it's just a guess everywhere else. That's because the Windows build is unique in supplying and compiling all the external packages Python ships with on Windows. On non-Windows boxes, which skips are expected also depends on which external packages happen to be installed on the box, and how Python was configured, and regrtest.py has no knowledge about those. For example, on the sparc solaris10 gcc trunk buildbot, 6 tests show up as unexpected skips, and there's just no way for a non-platform-expert to guess which of those are and aren't pointing at problems. It's easy enough to guess that test_zipfile is skipped because the box doesn't have an external zlib installed, but why is test_ioctl skipped? I have no idea (and neither does regrtest.py), but it's presumably obvious to a Sun expert. In any case, if unexpected skips got appended to `bad`, the non-zero exit code would cause that buildbot slave to fail every time. It's not unique, either; e.g., the x86 gentoo trunk slave always skips test_tcl, presumably because Tcl isn't installed on that box. In short, there's simply no way to _guess_ which import errors are and aren't expected. Improving that requires adding more knowledge to the testing machinery. The most important thing is to add knowledge about which import errors are _never_ expected (perhaps by adding knowledge about which imports _may_ legitimately fail), since we can know that for sure about x-platform modules, and that's exactly the problem that keeps burning us. Confusing ImportError with TestSkipped is an admirably lazy idea that unfortunately didn't turn out to work very well. ___ 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_struct failure on 64 bit platforms
On Wednesday, May 31, 2006, at 03:06PM, Tim Peters [EMAIL PROTECTED] wrote: Would someone augment the warnings module to make testing more reasonable? What's required? I know of two things: 1. There's no advertised way to save+restore the internal filter list, or to remove a filter entry, so tests that want to make a temporary change have to break into the internals. 2. There's no advertised way to disable only gripe once per source line behavior. This gets in the way of testing that warnings get raised when running tests more than once, or using a common function to raise warnings from multiple call sites. These get in the way of Zope and ZODB testing too, BTW. Unfortunately, looks like the new test_struct code bumped into both of them at once. The really annoying part of the new struct warnings is that the warning line mentions a line in struct.py instead the caller of struct.pack. That makes it hard to find the source of the warning without telling the warnings module to raise an exception for DeprecationWarnings. Ronald ___ 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] r46300 - in python/trunk: Lib/socket.py Lib/test/test_socket.py Lib/test/test_struct.py Modules/_struct.c Modules/arraymodule.c Modules/socketmodule.c
On 5/31/06, Martin Blais [EMAIL PROTECTED] wrote: So I assume you're suggesting the following renames: pack_to - packinto recv_buf - recvinto recvfrom_buf - recvfrominto (I don't like that last one very much. I'll go ahead and make those renames once I return.) You could add an underscore before _into. -- --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
Re: [Python-Dev] A can of worms... (does Python C code have a new C style?)
Martin Blais wrote: Hi all I'd like to know what the policy is on the source code indentation for C code in the interpreter. At the Need-for-Speed sprints, there was consensus that there is a new indentation for style for the Python C source files, with * indentation (emacs: c-basic-offset): 4 chars * no tabs (so tab-width does not matter) * 79 chars max for lines (I think) (Correct me if any of this is wrong.) I cannot find where this discussion comes from, PEP 7 seems to imply that the new style only applies to Python 3k. Is this correct? The consensus at NFS was that it also applies to newly written C files. I did update the PEP, but that doesn't seem to have propagated to the web site yet. However, people were maintaining the existing styles when they were editing part of existing files (I setup emacs users with two c-styles, python and python-new, so they could switch per-file), but using the new guidelines for new files. I look at the source code, and there is a bit of a mix of the two styles in some places. That's bad, but is the way the code was written and should not be changed for the sake of changing. Is there a grand plan to convert all the code at once at some point? If not, how is it that these new guidelines are supposed to take effect? AFAIK not before Python 3.0 since it would unnecessarily break, for instance, svn blame and make merging more difficult. [...] In addition, should this be applied, we should probably create a Subversion hook that will automatically convert tabs to spaces, or fails the commit if the files don't comply. For the future (=Py3k), I think this would be nice. Georg ___ 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] Iterating generator from C (PostgreSQL's pl/python RETUN SETOF/RECORD iterator support broken on RedHat buggy libs)
Ühel kenal päeval, P, 2006-05-28 kell 14:18, kirjutas Thomas Wouters: On 5/20/06, Hannu Krosing [EMAIL PROTECTED] wrote: I try to move this to -dev as I hope there more people reading it who are competent in internal working :). So please replay to -dev only. I'm not sure if you have found the problem on another mailinglist then, but I saw no answers on python-dev. - The question is about use of generators in embedde v2.4 with asserts enabled. Can somebody explain, why the code in try2.c works with wrappers 2 and 3 but crashes on buggy exception for all others, that is pure generator and wrappers 1,4,5 ? Your example code does not crash for me, not for any of the 'wrapper_source' variants, linking against Python 2.4 (debian's python 2.4.3 on amd64, both in 64-bit and 32-bit mode) or Python 2.5 (current trunk, same hardware.) I don't know what kind of crash you were expecting, but I do see unchecked return values, which can cause crashes for the simplest of reasons ;-) Fedora Core distributes its python libs with asserts on, and this code triggers an assert, both without a wrapper and with most wrappers [EMAIL PROTECTED] plpython]$ ./try2 one try2: Objects/genobject.c:53: gen_iternext: Assertion `f-f_back != ((void *)0)' failed. Aborted This is reported to be fixed for 2.5 (they changed the assert), but I'd like to have a workaround which would not trigger the old buggy assert. -- Thomas Wouters [EMAIL PROTECTED] Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ 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] Add new PyErr_WarnEx() to 2.5?
[Ronald Oussoren, hijacking the test_struct failure on 64 bit platforms thread] The really annoying part of the new struct warnings is that the warning line mentions a line in struct.py instead the caller of struct.pack. That makes it hard to find the source of the warning without telling the warnings module to raise an exception for DeprecationWarnings. The problem seems to be that Python's C API apparently gives no simple way to supply a value for warning.warn's optional `stacklevel` argument. The C-level signature is: int PyErr_Warn(PyObject *category, char *message); and that's what _struct.c calls. I think it would be good to add a new int PyErr_WarnEx(PyObject *category, char *message, long stacklevel); C API function, change PyErr_Warn to call that forcing stacklevel to 1, and change _struct.c to call PyErr_WarnEx with stacklevel=2. Then it would point at struct.pack()'s caller. ___ 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_gzip/test_tarfile failure om AMD64
I'm afraid a sabbatical year isn't long enough to understand what the struct module did or intends to do by way of range checking 0.7 wink. Is this intended? This is on a 32-bit Windows box with current trunk: from struct import pack as p p(I, 2**32 + 2343) C:\Code\python\lib\struct.py:63: DeprecationWarning: 'I' format requires 0 = number = 4294967295 return o.pack(*args) '\x00\x00\x00\x00' The warning makes sense, but the result doesn't make sense to me. In Python 2.4.3, that example raised OverflowError, which seems better than throwing away all the bits without an exception. ___ 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] Python Benchmarks
Hello, After reading through recent Python mail regarding dictionaries and exceptions, I wondered, what is the current state of the art in Python benchmarks? I've tried before to find a definite set of Python benchmarks but failed. There doesn't seem to be an up to date reference, though if there is one and I didn't find it I would be very happy to be proven wrong. In any case, I would appreciate advice from the experts regarding what's available and what it tests. thank you, Niko Matsakis ___ 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_gzip/test_tarfile failure om AMD64
On May 31, 2006, at 8:31 AM, Tim Peters wrote: I'm afraid a sabbatical year isn't long enough to understand what the struct module did or intends to do by way of range checking 0.7 wink. Is this intended? This is on a 32-bit Windows box with current trunk: from struct import pack as p p(I, 2**32 + 2343) C:\Code\python\lib\struct.py:63: DeprecationWarning: 'I' format requires 0 = number = 4294967295 return o.pack(*args) '\x00\x00\x00\x00' The warning makes sense, but the result doesn't make sense to me. In Python 2.4.3, that example raised OverflowError, which seems better than throwing away all the bits without an exception. Throwing away all the bits is a bug, it's supposed to mask with 0xL -bob ___ 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 Benchmarks
(This is more appropriate for comp.lang.python/[EMAIL PROTECTED]) Niko After reading through recent Python mail regarding dictionaries Niko and exceptions, I wondered, what is the current state of the art Niko in Python benchmarks? Pybench was recently added to the repository and will be in 2.5. It works with Python as far back as 1.5.2 though. As a result of last week's NeedForSpeed sprint some questions were raised about the efficacy of its string/unicode tests, however, it seems to be the best available tool at the moment. Skip ___ 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 Benchmarks
[EMAIL PROTECTED] wrote: (This is more appropriate for comp.lang.python/[EMAIL PROTECTED]) Niko After reading through recent Python mail regarding dictionaries Niko and exceptions, I wondered, what is the current state of the art Niko in Python benchmarks? Pybench was recently added to the repository and will be in 2.5. It works with Python as far back as 1.5.2 though. As a result of last week's NeedForSpeed sprint some questions were raised about the efficacy of its string/unicode tests, however, it seems to be the best available tool at the moment. Could you please forward such questions to me ? Steve Holden has added lots of good features to pybench during the sprint and I'm working on having it use more accurate timers (see pybench/systimes.py). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, May 31 2006) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ 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 Benchmarks
MAL Could you please forward such questions to me ? I suppose, though what question were you referring to? I was referring to Fredrik's thread about stringbench vs pybench for string/unicode tests, which I thought was posted to python-dev. I assumed you were aware of the issue. Skip ___ 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] Arguments and PyInt_AsLong
Looking at #1153226, I found this: We introduced emitting a DeprecationWarning for PyArg_ParseTuple integer arguments if a float was given. This doesn't affect functions like file.seek which use PyInt_AsLong to parse their argument. PyInt_AsLong calls the nb_int slot which silently converts floats to ints. Is that acceptable, should PyInt_AsLong not accept other numbers or should the functions be changed? Georg ___ 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 Benchmarks
[EMAIL PROTECTED] wrote: MAL Could you please forward such questions to me ? I suppose, though what question were you referring to? Not sure - I thought you knew ;-) I was referring to Fredrik's thread about stringbench vs pybench for string/unicode tests, which I thought was posted to python-dev. I assumed you were aware of the issue. I'm aware of that thread, but Fredrik only posted some vague comment to the checkins list, saying that they couldn't use pybench. I asked for some more details, but he didn't get back to me. AFAIK, there were no real issues with pybench, only with the fact that time.clock() (the timer used by pybench) is wall-time on Windows and thus an MP3-player running in the background will cause some serious noise in the measurements ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, May 31 2006) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ 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 Benchmarks
MAL I'm aware of that thread, but Fredrik only posted some vague MAL comment to the checkins list, saying that they couldn't use MAL pybench. I asked for some more details, but he didn't get back to MAL me. I'm pretty sure I saw him (or maybe Andrew Dalke) post some timing comparisons between pybench and stringbench. Something about a change not impacting performance showing a 60% slowdown on pybench but no change using stringbench. Maybe Fredrik had his iTunes volume cranked up too high... ;-) Skip ___ 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 Benchmarks
M.-A. Lemburg wrote: AFAIK, there were no real issues with pybench, only with the fact that time.clock() (the timer used by pybench) is wall-time on Windows and thus an MP3-player running in the background will cause some serious noise in the measurements oh, please; as I mentioned back then, PyBench reported massive slowdowns and huge speedups in code that wasn't touched, gave unrepeatable results on most platforms, and caused us to waste quite some time investigating potential regressions from 2.4 that simply didn't exist. of about a dozen claimed slowdowns when comparing 2.4 to 2.5a2 on several platforms, only *one* slowdown could be independently confirmed with other tools. and when we fixed that, and ended up with an implementation that was *faster* than in 2.4, PyBench didn't even notice the speedup. the fact is that the results for individual tests in PyBench are 100% unreliable. I have no idea why. the accumulated result may be somewhat useful (at least after the use minimum time instead of average changes), but I wouldn't use it for any serious purpose. at least PyStone is unusable in a well-defined way ;-) /F ___ 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 Benchmarks
[EMAIL PROTECTED] wrote: MAL I'm aware of that thread, but Fredrik only posted some vague MAL comment to the checkins list, saying that they couldn't use MAL pybench. I asked for some more details, but he didn't get back to MAL me. I'm pretty sure I saw him (or maybe Andrew Dalke) post some timing comparisons between pybench and stringbench. Something about a change not impacting performance showing a 60% slowdown on pybench but no change using stringbench. Maybe Fredrik had his iTunes volume cranked up too high... ;-) This is possible since pybench uses a long run strategy, whereas stringbench uses the timeit.py short run method. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, May 31 2006) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ 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] Arguments and PyInt_AsLong
Guido ... PyNumber_AsIndex or whatever it's called. Maybe the API is getting a little fat if it doesn't fit comfortably in the BDFL's brain... Does that suggest it might need some streamlining for Py3k? Skip ___ 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] Segmentation fault of Python if build on Solaris 9 or10 with Sun Studio 11
Zitat von Andreas Flöter [EMAIL PROTECTED]: Help would be appreciated This strictly doesn't belong to python-dev: this is the list where you say I want to help, not so much I need your help. If you want to resolve this yourself, we can guide you through that. I would start running the binary in a debugger to find out where it crashes. Maybe the bug in Python is easy to see from that. But then, maybe the bug is in the compiler, and not in Python... Regards, 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] Segmentation fault of Python if build on Solaris 9 or10 with Sun Studio 11
2006/5/31, [EMAIL PROTECTED] [EMAIL PROTECTED]: This strictly doesn't belong to python-dev: this is the list where you say I want to help, not so much I need your help. QOTW! I love it! -- .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ 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] Segmentation fault of Python if build on Solaris 9 or10 with Sun Studio 11
[MvL, to Andreas Flöter] This strictly doesn't belong to python-dev: this is the list where you say I want to help, not so much I need your help. LOL! How true. If you want to resolve this yourself, we can guide you through that. I would start running the binary in a debugger to find out where it crashes. Maybe the bug in Python is easy to see from that. But then, maybe the bug is in the compiler, and not in Python... The first or second thing to try is to recompile Python with C optimization disabled, and especially in this case where compiling with gcc instead works fine (that certainly _suggests_ C compiler optimization bug). ___ 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] Possible bug in complexobject.c (still in Python 2.5)
I'm curious about the difference between float_subtype_new in floatobject.c complex_subtype_from_c_complex in complexobject.c The former uses type-tp_alloc(type, 0) to create memory for the object while the latter uses PyType_GenericAlloc(type, 0) to create memory for the sub-type (thereby by-passing the sub-type's own memory allocator). It seems like this is a bug. Shouldn't type-tp_alloc(type, 0) also be used in the case of allocating complex subtypes? This is causing problems in NumPy because we have a complex type that is a sub-type of the Python complex scalar. It sometimes uses the complex_new code to generate instances (so that the __new__ interface is the same), but because complex_subtype_from_c_complex is using PyType_GenericAlloc this is causing errors. I can work around this by not calling the __new__ method for the base type but this is not consistent. Thanks for any feedback, -Travis ___ 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] Possible bug in complexobject.c (still in Python 2.5)
I'm curious about the difference between float_subtype_new in floatobject.c complex_subtype_from_c_complex in complexobject.c The former uses type-tp_alloc(type, 0) to create memory for the object while the latter uses PyType_GenericAlloc(type, 0) to create memory for the sub-type (thereby by-passing the sub-type's own memory allocator). It seems like this is a bug. Shouldn't type-tp_alloc(type, 0) also be used in the case of allocating complex subtypes? This is causing problems in NumPy because we have a complex type that is a sub-type of the Python complex scalar. It sometimes uses the complex_new code to generate instances (so that the __new__ interface is the same), but because complex_subtype_from_c_complex is using PyType_GenericAlloc this is causing errors. I can work around this by not calling the __new__ method for the base type but this is not consistent. Thanks for any feedback, P.S. Sorry about the cross-posting to another thread. I must have hit reply instead of compose. Please forgive the noise. -Travis ___ 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] Possible bug in complexobject.c (still in Python 2.5)
I wouldn't be surprised if this is a genuine bug; the complex type doesn't get a lot of love from core developers. Could you come up with a proposed fix, and a unit test showing that it works (and that the old version doesn't)? (Maybe a good unit test would require writing a custome C extension; in that case just show some sample code.) --Guido On 5/31/06, Travis E. Oliphant [EMAIL PROTECTED] wrote: I'm curious about the difference between float_subtype_new in floatobject.c complex_subtype_from_c_complex in complexobject.c The former uses type-tp_alloc(type, 0) to create memory for the object while the latter uses PyType_GenericAlloc(type, 0) to create memory for the sub-type (thereby by-passing the sub-type's own memory allocator). It seems like this is a bug. Shouldn't type-tp_alloc(type, 0) also be used in the case of allocating complex subtypes? This is causing problems in NumPy because we have a complex type that is a sub-type of the Python complex scalar. It sometimes uses the complex_new code to generate instances (so that the __new__ interface is the same), but because complex_subtype_from_c_complex is using PyType_GenericAlloc this is causing errors. I can work around this by not calling the __new__ method for the base type but this is not consistent. Thanks for any feedback, -Travis ___ 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
Re: [Python-Dev] Let's stop eating exceptions in dict lookup
[Martin Blais] I'm still looking for a benchmark that is not amazingly uninformative and crappy. I've been looking around all day, I even looked under the bed, I cannot find it. I've also been looking around all day as well, even looked for it shooting out of the Iceland geysirs, of all places--it's always all day out here it seems, day and day-- and I still can't find it. (In the process however, I found Thule beer and strangely dressed vikings, which makes it all worthwhile.) For those who don't know, Martin stayed on in Iceland after the NFS sprint. He shows clear signs above of developing photon madness. http://www.timeanddate.com/worldclock/astronomy.html?n=211 Where that says sunset, don't read dark -- it just means the top of the sun dips a bit below the horizon for a few hours. It never gets dark this time of year. If you haven't experienced this, no explanation can convey the other-worldly sense of it. Combined with Iceland's astonishing and beautiful geography, a North American boy (like Martin or me) could swear they were transported to a different planet. It's one I'd love to visit again, but back home for a few days now I still turn the lights off for about half an hour each night and just sit here cherishing darkness :-) ___ 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] Search for empty substrings (was Re: Let's stop eating exceptions in dict lookup)
[Fredrik Lundh] would abc.find(, 100) == 3 be okay? or should we switch to treating the optional start and end positions as return value boundaries (used to filter the result) rather than slice directives (used to process the source string before the operation)? it's all trivial to implement, and has no performance implications, but I'm not sure what the consensus really is... FWIW, I like what you eventually did: ab.find() 0 ab.find(, 1) 1 ab.find(, 2) 2 ab.find(, 3) -1 ab.rfind() 2 ab.rfind(, 1) 2 ab.rfind(, 2) 2 ab.rfind(, 3) -1 I don't know that a compelling argument can be made for such a seemingly senseless operation, but the behavior above is at least consistent with the rule that a string of length n has exactly n+1 empty substrings, at 0:0, 1:1, ..., and n: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
Re: [Python-Dev] [Python-checkins] r46300 - in python/trunk: Lib/socket.py Lib/test/test_socket.py Lib/test/test_struct.py Modules/_struct.c Modules/arraymodule.c Modules/socketmodule.c
On 5/31/06, Guido van Rossum [EMAIL PROTECTED] wrote: On 5/31/06, Martin Blais [EMAIL PROTECTED] wrote: So I assume you're suggesting the following renames: pack_to - packinto recv_buf - recvinto recvfrom_buf - recvfrominto (I don't like that last one very much. I'll go ahead and make those renames once I return.) You could add an underscore before _into. Will do! cheers, ___ 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] Search for empty substrings (was Re: Let's stop eating exceptions in dict lookup)
On 5/31/06, Tim Peters [EMAIL PROTECTED] wrote: [Fredrik Lundh] would abc.find(, 100) == 3 be okay? or should we switch to treating the optional start and end positions as return value boundaries (used to filter the result) rather than slice directives (used to process the source string before the operation)? it's all trivial to implement, and has no performance implications, but I'm not sure what the consensus really is... FWIW, I like what you eventually did: ab.find() 0 ab.find(, 1) 1 ab.find(, 2) 2 ab.find(, 3) -1 ab.rfind() 2 ab.rfind(, 1) 2 ab.rfind(, 2) 2 ab.rfind(, 3) -1 I don't know that a compelling argument can be made for such a seemingly senseless operation, but the behavior above is at least consistent with the rule that a string of length n has exactly n+1 empty substrings, at 0:0, 1:1, ..., and n:n. Yes. Bravo! -- --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
Re: [Python-Dev] Possible bug in complexobject.c (still in Python 2.5)
Guido (Maybe a good unit test would require writing a custome C Guido extension; in that case just show some sample code.) Isn't that what Module/_testcapimodule.c is for? Skip ___ 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] Possible bug in complexobject.c (still in Python 2.5)
Guido van Rossum wrote:
I wouldn't be surprised if this is a genuine bug; the complex type
doesn't get a lot of love from core developers.
Could you come up with a proposed fix, and a unit test showing that it
works (and that the old version doesn't)? (Maybe a good unit test
would require writing a custome C extension; in that case just show
some sample code.)
Attached is a sample module that exposes the problem. The problem goes
away by replacing
op = PyType_GenericAlloc(type, 0);
with
op = type-tp_alloc(type, 0);
in the function
complex_subtype_from_c_complex
in the file complexobject.c (about line #191).
The problem with a unit test is that it might not fail. On my Linux
system, it doesn't complain about the problem unless I first use strict
pointer checking with
export MALLOC_CHECK_=2
Then the code
import bugtest
a = bugtest.newcomplex(3.0)
del a
Aborts
Valgrind also shows the error when running the simple code. It seems
pretty clear to me that the subtype code should be calling the sub-types
tp_alloc code instead of the generic one.
Best regards,
-Travis
#include Python.h
typedef struct {
PyObject_HEAD
double real;
double imag;
} PyNewComplexObject;
static PyTypeObject PyComplex_SubType = {
PyObject_HEAD_INIT(NULL)
0, /*ob_size*/
newcomplex, /*tp_name*/
sizeof(PyNewComplexObject),/*tp_basicsize*/
};
static PyObject *
_complex_alloc(PyTypeObject *type, int nitems)
{
PyObject *obj;
obj = (PyObject *)malloc(_PyObject_SIZE(type));
memset(obj, 0, _PyObject_SIZE(type));
PyObject_INIT(obj, type);
return obj;
}
PyMODINIT_FUNC initbugtest(void) {
PyObject *m, *d;
m = Py_InitModule(bugtest, NULL);
d = PyModule_GetDict(m);
PyComplex_SubType.tp_free = free;
PyComplex_SubType.tp_alloc = _complex_alloc;
PyComplex_SubType.tp_base = PyComplex_Type;
PyComplex_SubType.tp_flags = Py_TPFLAGS_DEFAULT | Py_TPFLAGS_CHECKTYPES;
PyType_Ready(PyComplex_SubType);
Py_INCREF(PyComplex_SubType);
PyDict_SetItemString(d, newcomplex,
(PyObject *)PyComplex_SubType);
return;
}
___
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] Possible bug in complexobject.c (still in Python 2.5)
Travis E. Oliphant wrote: I'm curious about the difference between float_subtype_new in floatobject.c complex_subtype_from_c_complex in complexobject.c The former uses type-tp_alloc(type, 0) to create memory for the object while the latter uses PyType_GenericAlloc(type, 0) to create memory for the sub-type (thereby by-passing the sub-type's own memory allocator). It seems like this is a bug. Shouldn't type-tp_alloc(type, 0) also be used in the case of allocating complex subtypes? I submitted an entry and a patch for this on SourceForge Tracker (#1498638) http://sourceforge.net/tracker/index.php?func=detailaid=1498638group_id=5470atid=105470 -Travis ___ 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_struct failure on 64 bit platforms
On 5/31/06, Tim Peters [EMAIL PROTECTED] wrote: standard is a technical word with precise meaning here, and is defined by the struct module docs, in contrast to native. It means whatever they say it means :-) Portable may have been a more intuitive word than standard here -- read standard in the struct context in the sense of standardized, regardless of native platform size or alignment or endian quirks. :-) Would someone augment the warnings module to make testing more reasonable? What's required? I know of two things: 1. There's no advertised way to save+restore the internal filter list, or to remove a filter entry, so tests that want to make a temporary change have to break into the internals. 2. There's no advertised way to disable only gripe once per source line behavior. This gets in the way of testing that warnings get raised when running tests more than once, or using a common function to raise warnings from multiple call sites. These get in the way of Zope and ZODB testing too, BTW. Unfortunately, looks like the new test_struct code bumped into both of them at once. Right. The 2 you list above are the only one's I know of. You fixed one of them. I find the __warningregistry__ fix extremely obscure. I remember working on wrt test_warnings (and -R maybe?). I don't think I fixed, someone else eventually figured it out, probably you. :-) 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
