Mailman 3 May 2002 - Python-Dev

Re: [Python-Dev] Problems with Python's default dlopen flags
by Ralf W. Grosse-Kunstleve 06 May '02

06 May '02

The discussion in this thread is going in a direction that makes it seem more suitable for the Python C++ SIG. Therefore I have just posted my new findings here: http://mail.python.org/pipermail/c++-sig/2002-May/001021.html Thanks for all the feedback, Ralf

1 0

buffer objects
by Scott Gilbert 05 May '02

05 May '02

I recently submitted a (really tiny) patch to allow the buffer() builtin to return a read/write PyBufferObject when possible. Mostly this was just to get my feet wet on the patch submission process, but I also think it is the correct behavior (am I wrong about this?). Being new at this, I don't know: Am I supposed to find a committer to champion my patch? Also... Several weeks ago, I brought up the suggestion that arraymodule.c arrays should be able to pickle directly and efficiently. I've since found out that the topic of arrays is a complicated one, and now I'm wondering if anyone else thinks that buffer objects should pickle. I look at buffers as mutable byte-strings. Having buffers pickle/unpickle (without a temporary copy) would avoid most of the questions about data types/sizes, endian-ness, ..., while allowing things which built on top of buffers (array modules for instance) to pickle efficiently. Just curious if a patch along these lines would be received well (assuming it's a good patch). Cheers, -Scott __________________________________________________ Do You Yahoo!? Yahoo! Health - your guide to health and wellness http://health.yahoo.com

7 12

slice notation and RDF
by Damien Morton 04 May '02

04 May '02

I was reading TBLs presentation of webizing Python, and specifically his ideas about incorporating RDF into the syntax of Python. The recent thread on slice notation, and some of my experiences playing around implementing syntax for TBLs RDF-in-Python proposal got me thinking. Could the notation a:b:c:d:... be generalised, with slices becoming a kind of tuple. For backwards compatability, the first three elements of the tuple could be accessed using the start, stop, step attributes. Could the dictionary notation be related to slice notation, such that a dictionary is defined as being an object initialised by a list of slices. { 1:2, 3:4 } <--> dict([slice(1,2), slice(3,4)]) For RDF notation, you could then happily write: {1:2:3, 4:5:6, 7:8:9} --> dict([slice(1,2,3), slice(4,5,6), slice(7,8,9)]) For sets, you would write: {1, 2, 3} -> dict([slice(1), slice(2), slice(3)]} A slice on its own would be writen: (1:2:3) -> slice(1,2,3) A 1-element slice might be written similarily to a 1-element tuple: (1:) -> slice(1)

3 5

Unicode objects more space efficient than plain strings? can that be?
by Skip Montanaro 02 May '02

02 May '02

I'm busy absorbing all the great feedback I got on the Unicode how-to. Thanks to all who've responded. As Aahz has said, the best way to learn something isn't to ask questions, it's to post an incorrect program (or in this case, text). After reading Simon's Perl/Unicode course notes and Marc-André's Python/Unicode EuroPython slides, I formed a simple, seemingly obvious, hypothesis: When considering just ASCII data, plain Python strings should be more space efficient than Unicode strings. I compared ps output for two interactive sessions. In the first, I executed this statement at the interpreter prompt: l = [u"abc%d"%i for i in xrange(1000000)] In the second I executed this similar statement: l = ["abc%d"%i for i in xrange(1000000)] Ps showed that the interpreter consumed 57MB or so of virtual memory for the list of Unicode strings case, and a whopping 152MB for the list of plain strings case. Just to be sure I wasn't dreaming, I repeated the crude experiment. Same result. I then looked at the typedefs for Unicode and string objects. The sizes of the two structs are approximately the same. There's certainly not a factor of three difference in the per-object overhead. I expect the raw Unicode buffer to refer to a chunk of memory that is roughly two times the size of the plain string version of the bytes because the internal representation is (I seem to recall from MAL's notes) UCS2. It seemed the only thing that might be a problem was string interning, so based on the comment in stringobject.h about interning strings that "look like" Python identifiers, I tried one more time with strings that didn't look like identifers (the automatic string interning would only happen for string literals anyway, right?): l = ["-bc%d"%i for i in xrange(1000000)] Same result. I ran these tests with a two-week old build from CVS. I just tried it with a build from today using xrange(100000) and got similar, though obviously smaller virtual memory sizes. I must be missing something obvious, but what is it? Something about pymalloc? Skip

3 5

RE: [Python-checkins] python/dist/src/Modules arraymodule.c,2.70,2.71
by Tim Peters 02 May '02

02 May '02

> Update of /cvsroot/python/python/dist/src/Modules > In directory usw-pr-cvs1:/tmp/cvs-serv16518 > > Modified Files: > arraymodule.c > Log Message: > Patch #551009: Initialize array type dynamically. I like these a lot better if a do-nothing macro is plugged into the "0" slots, like #define DELAYED(X) DELAYED(PyObject_Del), /* tp_free */ instead of 0, /* tp_free */ It's confusing and error-prone to need to search all over the source code to find out what's really in a type object.

1 0

Why was Misc/Makefile.pre.in removed?
by Lance Sloan 02 May '02

02 May '02

I'm wondering why Makefile.pre.in was removed from Python 2.2. I understand that is was due to a "BDFL pronouncement" (whatever that is), but unlike other such pronouncements, I cannot find an explanation of why this was done. Thanks! -- Lance E Sloan Web Services, Univ. of Michigan: Full-service Web and database design, development, and hosting. Specializing in Python & Perl CGIs. http://websvcs.itd.umich.edu/ - "Putting U on the Web"

3 2

Re: [bug?] UserLong.py - pow(5, UserLong(3), 26) fails
by Luke Kenneth Casson Leighton 02 May '02

02 May '02

michael, thanks for the int.__mru tip. i confirm: pow(5, UserLong(3), 26) - gets the same error that you report. i also confirmed: pow(5, UserLong(3)) - calls UserLong.__rpow__. it works! errrr :) :) so it looks like it's _almost_ there, but not quite. i _believe_ i can get away with this, for DSA.py, at this time, if i correctly implement UserLong.__rpow__ (which was previously a stub). later tonight i'll raise a proper bug report. thanks for the tips, michael. l.

1 0

Re: [Python-Dev] Re: [bug?] UserLong.py - pow(5, UserLong(3), 26) fails
by Michael Hudson 02 May '02

02 May '02

Luke Kenneth Casson Leighton <lkcl(a)samba-tng.org> writes: > class UserLong(object): > ... > > which i presume is the means by which new-style classes are specified > (search google "new style python class" jumped into a tutorial: > couldn't find an explicit place straight away). > > i get a segmentation fault at line 1217 of Objects/typeobject.c, > because mro - type->tp_mro - is NULL. You can make the segfault go away by putting "int.__mro__" at the top of the file. mro's are lazily calculated and here we manage to go through the code in an order that gets this wrong. Shouldn't be too hard to fix, but it's probably easier if you're Guido. Unfortunately, the situation overall is not improved: $ ./python lkcl.py Adding parser accelerators ... Done. int 3 long 3 5**int(y) 125 5**y rpow: (5,) 3 x^y%26 (3L, 26) 21L 5^y%26 Traceback (most recent call last): File "lkcl.py", line 172, in ? test() File "lkcl.py", line 156, in test print "5^y%26", pow(5, y, 26) TypeError: unsupported operand type(s) for pow(): 'int', 'UserLong', 'int' [6613 refs] I'm out of my depth in this area... Cheers, M. -- ARTHUR: Why are there three of you? LINTILLAS: Why is there only one of you? ARTHUR: Er... Could I have notice of that question? -- The Hitch-Hikers Guide to the Galaxy, Episode 11

1 0

Re: [bug?] UserLong.py - pow(5, UserLong(3), 26) fails
by Luke Kenneth Casson Leighton 02 May '02

02 May '02

dear michael, i tried this: class UserLong(object): ... which i presume is the means by which new-style classes are specified (search google "new style python class" jumped into a tutorial: couldn't find an explicit place straight away). i get a segmentation fault at line 1217 of Objects/typeobject.c, because mro - type->tp_mro - is NULL. uhm... :) -- This email and any files transmitted with it, including replies and forwarded copies subsequently transmitted from Aspex Technology Limited, are confidential and solely for the use of the intended recipient. Any opinions expressed in this email are those of the individual and not necessarily those of Aspex Technology Limited. If you are not the intended recipient, be advised that you have received this email in error and that any use is strictly prohibited. If you have received this email in error, please notify us immediately by e-mail and delete the original message without keeping any copies. Aspex Technology Limited is registered in England and Wales No.3469577. The registered office for Aspex Technology Limited is York House, Cottingley Business Park, Bradford, BD16 1PF.

1 0

iterzip()
by Raymond Hettinger 02 May '02

02 May '02

What do you guys think about the merits of an iterzip() function that behaves like zip() but returns an iterator instead of a list? Raymond Hettinger P.S. There is a patch for experimentation at http://www.python.org/sf/549662

15 85