Mailman 3 June 2006 - Python-Dev

string inconsistency
by Neal Norwitz June 1, 2006

June 1, 2006

This is still in Lib/test/string_tests.py: #EQ("A", "", "replace", "", "A") # That was the correct result; this is the result we actually get # now (for str, but not for unicode): #EQ("", "", "replace", "", "A") Is this going to be fixed? n

2 1

test_struct failure on 64 bit platforms
by Neal Norwitz June 1, 2006

June 1, 2006

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

4 5

Possible bug in complexobject.c (still in Python 2.5)
by Travis E. Oliphant June 1, 2006

June 1, 2006

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

1 1

A can of worms... (does Python C code have a new C style?)
by Martin Blais June 1, 2006

June 1, 2006

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,

6 6

Search for empty substrings (was Re: Let's stop eating exceptions in dict lookup)
by Tim Peters June 1, 2006

June 1, 2006

[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.

2 1

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
by Bob Ippolito June 1, 2006

June 1, 2006

On May 26, 2006, at 4:56 PM, Guido van Rossum wrote: > On 5/26/06, martin.blais <python-checkins(a)python.org> wrote: >> Log: >> Support for buffer protocol for socket and struct. >> >> * 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(). > > 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? (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. 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. Grammatically it only works if it's implemented on all buffer objects, but in this case it's implemented on the Struct type. -bob

3 4