Mailman 3 November 2003 - Python-Dev

RE: [Python-Dev] new language ideas
by Michael Chermside 03 Nov '03

03 Nov '03

Brian Rzycki writes: > Multiline comments Already got it. Triple quoting. > __doc__ variable Just making __doc__ a dictionary instead of a string doesn't achieve anything *unless* there is a fairly standard set of expected keys in this dictionary. (This is documentation, so the list of standard keys doesn't have to be universal but without a common set of keys you can expect to encounter, the only thing you can really do is to print out the entire contents of the dictionary, and if all you can do is print it you might as well just be using a string.) You write: > Think author, > webpage, and version at the global scope and pre/post conditions, > dynamically created information about a function/class. which is an interesting-sounding list, but if I saw a PEP which proposed making __doc__ a dictionary which *didn't* specify just what the "common" key would be and what they would contain, then I'd be -1 on it. And if it *did* specify, I imagine there would be far more controversy than you expect. > bit access of integers > ---------------------------- > Like strings, we can use [] to index into python integers. Hmm... very interesting, actually. But on reflection, I think we're better off leaving integers as *numbers* and having a *separate* type for bitmasks. This separate type could even be written in Python (I doubt the speed of a C implementation would be worthwhile... the real advantage of the type would be ease of use, not performance). Clearly it would have a convert-to-integer feature (perhaps one which would let you specify whether you wanted signed or unsigned, and what width, and what endian-ness, etc.). > alternative base notation > --------------------------------- > Python inherited C's notation for numbers of non-decimal bases. I > propose another with simpler syntax: number_base. Definite -1 from me. Several reasons. Here's a number in hex: b4a0_16 Oh wait... sorry, that's not a number, that's an identifier. Another reason is that it's just not something that is done all that frequently. Another reason is that we already have TWO syntaxes for doing numbers in different bases: There's the 0x prefix for hex and the 0 prefix for octal (but if I had my way we'd dump that... who uses octal?). And there's the "int('<number>', <base>)" syntax which has just a few more characters than your solution and is IMHO more readable. Even if I'm shooting most of these down, don't give up... you're certainly injecting a little creative thought into the process. Sometimes that stirs up really exciting ideas. -- Michael Chermside

2 1

new language ideas
by Brian Rzycki 03 Nov '03

03 Nov '03

Hi all, I've been tinkering with a bit of a pet project on and off for some time now. I'm basically trying to adapt the python style/syntax for a language that is a bit better suited as a classical systems programming language. To be able to program with Python at the high level and something very pythonesque at the lower level is very appealing. :) Well, when thinking about this, I've come up with a few ideas I think might benefit Python as well. Please forgive me if these are repeats, I've never seen anything related to this in the PEPs or on the list. I'm just tossing these out for Python's benefit... /me dons asbestos long-johns... Multiline comments -------------------------- #BEGIN ... #END Everything in between is ignored. It would be very useful when debugging decent sized blocks of code. I know certain editors can auto-comment blocks, but it can be difficult to un-auto-comment said block. The same smart editors could colorize the block accordingly, minimizing readiblity issues. __doc__ variable ------------------------ docstrings are really a special case of programmer documentation. It'd be a lot nicer if there were some way to isolate certain portions of information in the docstring. Most contain a short description as well as the expect things (I won't say types on this list) ;). docstrings could be aliased through the dictionary __doc__. The exact symantics are a bit fuzzy right now, but I wanted to toss out the idea for public scrutiny. Here's an example: def f(x): "does nothing, really." return(x) In this case, __doc__.desc would equal the docstring. This would allow for backward compatibility and allow for extension. Think author, webpage, and version at the global scope and pre/post conditions, dynamically created information about a function/class. bit access of integers ---------------------------- Like strings, we can use [] to index into python integers. It'd be a nice way to set/read individual bits of a given integer. For example: x = 5 x[0] = 0 print x (prints 4) The details of how to index (I was assuming big-endian in this example) are open to discussion. This would make bit-banging in python be even easier than C (not to mention easier to read). This assumes we want Python to be good at bit-banging. ;) alternative base notation --------------------------------- Python inherited C's notation for numbers of non-decimal bases. I propose another with simpler syntax: number_base. An example: x = 24b_16 y = 1001_2 z = 96zz_36 The range for this notation would be 2 to 36 for the base. This allows for the entire alphabet plus numbers to be used as numerical placeholders. I'd be happy if _2, _8, _16 were the only ones implemented because those are the most commonly used. It would be nice to treat it almost as if it were a call to a radix() function. I think the notation has a nice look to it and I think makes it easy to read. So that's it for now. Let me know what you think. -Brian Rzycki

2 1

OT: programming language creator or serial killer?
by David Ascher 03 Nov '03

03 Nov '03

A fun online quiz IMO (flash): http://www.malevole.com/mv/misc/killerquiz/ I got 3/10 =)

2 1

Weekly Python Bug/Patch Summary
by Skip Montanaro 02 Nov '03

02 Nov '03

Bug/Patch Summary ----------------- 548 open / 4296 total bugs (+48) 190 open / 2438 total patches (-1) New Bugs -------- python 2.3.2 make test segfault (2003-10-26) http://python.org/sf/830573 httplib.HTTPConnection._send_request header parsing bug (2003-10-27) http://python.org/sf/831271 Solaris term.h needs curses.h (2003-10-27) http://python.org/sf/831574 httplib hardcodes Accept-Encoding (2003-10-28) http://python.org/sf/831747 Docstring for pyclbr.readmodule() is incorrect (2003-10-28) http://python.org/sf/831969 C++ extensions using SWIG and MinGW (2003-10-28) http://python.org/sf/832159 Build fails in ossaudiodev.c with missing macros (2003-10-29) http://python.org/sf/832236 Wrong reference for specific minidom methods (2003-10-29) http://python.org/sf/832251 Bad Security Advice in CGI Documentation (2003-10-29) http://python.org/sf/832515 Inconsitent line numbering in traceback (2003-10-29) http://python.org/sf/832535 Please link modules with shared lib (2003-10-29) http://python.org/sf/832799 urllib.urlencode doesn't work for output from cgi.parse_qs (2003-10-30) http://python.org/sf/833405 Incorrect priority 'in' and '==' (2003-10-31) http://python.org/sf/833905 Ctrl+key combos stop working in IDLE (2003-10-31) http://python.org/sf/833957 Mouse wheel crashes program (2003-11-01) http://python.org/sf/834351 python and lithuanian locales (2003-11-02) http://python.org/sf/834452 simple bsddb interface potential for deadlock with threads (2003-11-02) http://python.org/sf/834461 New Patches ----------- deprecate or fix buffer object (2003-10-28) http://python.org/sf/832058 Implementation PEP 322: Reverse Iteration (2003-11-01) http://python.org/sf/834422 Closed Bugs ----------- test_signal hangs -- signal broken on OpenBSD? (2002-04-26) http://python.org/sf/549081 urllib2 and proxy (2003-01-02) http://python.org/sf/661042 os.popen with mode "rb" fails on Unix (2003-03-13) http://python.org/sf/703198 Test failures on Linux, Python 2.3b1 tarball (2003-04-26) http://python.org/sf/728051 Memory leak on open() only in 2.3? (2003-08-15) http://python.org/sf/789402 urllib.urlopen for https doesn't always provide readlines (2003-08-20) http://python.org/sf/792101 gc.get_referrers() is inherently dangerous (2003-08-23) http://python.org/sf/793822 dis.disassemble_string() broken (2003-09-23) http://python.org/sf/811294 int ("ffffffd3", 16) gives error (2003-09-24) http://python.org/sf/811898 Email.message example missing arg (2003-10-03) http://python.org/sf/817178 httplib.SSLFile lacks readlines() method (2003-10-07) http://python.org/sf/819510 Package Manager Scrolling Behavior (2003-10-15) http://python.org/sf/824430 dict.__init__ doesn't call subclass's __setitem__. (2003-10-16) http://python.org/sf/824854 wrong error message of islice indexing (2003-10-20) http://python.org/sf/827190 ctime is not creation time (2003-10-21) http://python.org/sf/827902 setattr(obj, BADNAME, value) does not raises exception (2003-10-24) http://python.org/sf/829458 python-mode.el: py-b-of-def-or-class looks inside strings (2003-10-25) http://python.org/sf/830347 Closed Patches -------------- Add isxxx() methods to string objects (2002-05-30) http://python.org/sf/562501 Enhanced file constructor (2002-09-11) http://python.org/sf/608182 Experimental Inno Setup Win32 installer (2002-10-24) http://python.org/sf/628301 terminal type option subnegotiation in telnetlib (2003-04-17) http://python.org/sf/723364 Allows os.forkpty to work on more platforms (Solaris!) (2003-05-04) http://python.org/sf/732401 fix problem in about dialog (2003-07-21) http://python.org/sf/775057 pydoc's usage should use basename (2003-08-08) http://python.org/sf/785689 termios module on IRIX (2003-08-11) http://python.org/sf/787189 ignore "b" and "t" mode modifiers in posix_popen (2003-08-13) http://python.org/sf/788404 POP3 over SSL support for poplib (2003-08-19) http://python.org/sf/791706 [_ssl.c] SSL_write() called with -1 as size (2003-09-10) http://python.org/sf/803998 socket.ssl should check certificates (2003-09-22) http://python.org/sf/810754 sprout more file operations in SSLFile, fixes 792101 (2003-10-04) http://python.org/sf/817854 let's get rid of cyclic object comparison (2003-10-17) http://python.org/sf/825639 Add list.copysort() (2003-10-17) http://python.org/sf/825814 itertoolsmodule.c: islice error messages (827190) (2003-10-25) http://python.org/sf/830070 python-mode.el: (py-point 'bod) doesn't quite work (2003-10-25) http://python.org/sf/830341

2 1

Re: test_bsddb blocks testing popitem - reason
by Gregory P. Smith 02 Nov '03

02 Nov '03

> > It is unfortuantely entirely possible that various berkeleydb libraries > > have bugs. Since the BerkeleyDB db->del() call isn't returning it is > > presumably stuck in a lock waiting for who knows what. > > Right. But the SAME berkeley db library is being used for my build of > both Python 2.4 alpha 0, and 2.3 maintenance branch, both from cvs, > and I can't see any difference in what they're doing with bsddb -- so > clearly I must be missing something because it's hanging on EVERY > attempt to run the unittest w/2.4, but never w/2.3. The big difference i see between 2.3cvs and 2.4cvs that could "explain" it is that Lib/bsddb/__init__.py has been updated to use a private (in memory, single process only) DBEnv with locking and thread support enabled. That explains why db->del() would be doing locking. But not why it would deadlock. This is also easily reproducable here. No special platform or berkeleydb version should be required. Looking closer I suspect what is happening is that Lib/bsddb/__init__.py implementation is not threadsafe. It wants to maintain the current iterator location using a DBCursor object. However, having an active DBCursor holds a lock in the database. DictMixin's popitem() is effectively: k, v = self.iteritems().next() del self[k] return (k, v) The iteritems() call creates an internal DBCursor object for the iterator. The next() call on the iterator (DBCursor) looks up the value for k. The following delete attempts to delete the record without using the DBCursor; thus the deadlock. If we implement our own popitem() for the bsddb dictionary object (_DBWithCursor) to perform the delete using the cursor this deadlock in the unit tests would go away. That won't stop users from intermixing iteration over a database with modifications to the database; causing their own deadlocks (very unexpected in single threaded code). Proposed fix: It should be possible for the bsddb object to maintain internal state of its own about what key is is on and close any internal DB cursor on all non-cursor database accesses leaving the iteration functions to detect this and reopen and reposition the cursor. Since the basic bsddb interface doesn't allow databases with duplicate keys it shouldn't be too difficult. Its not efficient but a user who cares about efficient use of berkeleydb should use the real DB/DBEnv interface directly. How do python dictionaries deal with modifications to the dictionary intermixed with iteration? Greg

3 6

RE: [Python-Dev] Looking for master thesis ideas involving Python
by Delaney, Timothy C (Timothy) 02 Nov '03

02 Nov '03

> From: Dennis Allison [mailto:allison@sumeru.stanford.EDU] > > How about re-engineering the interpreter to make it more MP friendly? > (This is probably a bigger task than a Masters thesis.) The current > interpreter serializes on the global interpreter lock (GIL) and blocks > everything. To me this would probably be the most interesting thing to tackle - especially since it has been tried before with partial success but overall failure. At the very least that gives a body of work which you can refer to both as a starting point for your work, and to show how your approach differs from and improves on existing work. It would also be of tremendous value to Python IMO if it could be done without negatively impacting performance on single-processor machines. Whether it is too large for a Masters thesis I don't know. Does a Masters thesis require *success* in the stated goal? I've been thinking about doing my own Masters in the not-too-distant future if I can find the time ... Tim Delaney

5 5

Deprecate the buffer object?
by Neil Schemenauer 02 Nov '03

02 Nov '03

I happened to be looking at the buffer API today and I came across this posting from Guido: http://mail.python.org/pipermail/python-dev/2000-October/009974.html Over the years there has been a lot of discussion about the buffer API and the buffer object. The general consensus seems to be that the buffer API is not ideal but nonetheless useful. The buffer object, OTOH, is considered fundamentally broken and should be removed. Does anyone object to deprecating the 'buffer' builtin? Eventually we could remove the buffer object completely. Neil

11 25

RE: [Python-Dev] Re: Guido's Magic Code was: inline sort option
by Michael Chermside 01 Nov '03

01 Nov '03

Raymond writes: > If only in the C API, I would like to see just such a universalmethod > alternative to classmethod. That would allow different behaviors to be > assigned depending on how the method is called. And that's exactly why I would be wary of it. One of the GREAT SIMPLICITIES of Python is that all calls are "the same". Calling a function works a particular way. Calling a callable object does the same, although the arguments are passed to __call__. Calling a classmethod does the same thing. Calling a bound method does the same thing except that the first argument is curried. Here in the Python community, we think it is a good thing that one must explicitly name "self" as an argument to methods, and that any function CAN be made a method of objects. Now you're proposing a special situation, where what appears to be a single attribute of a class object is actually TWO functions... two functions that have the same name but subtly different behavior. Right now, I presume that if I have: a = A() # a is an instance of A x = a.aMethod('abc') # this is line 1 y = A.aMethod(a, 'abc') # this is line 2 that line 1 and line 2 do the same thing. This is a direct consequence of the fact that methods in Python are just functions with an instance as the first argument. But your "universalmethod" would break this. It might be worth breaking it, if the result is some *very* readable code in a whole variety of situations. And it's certainly okay for Guido to manually create a class which behaves this way via black magic (and for most users, descriptor tricks are black magic). But to make it a regular and supported idiom, I'd want to see much better evidence that it's worthwhile, because there's an important principle at risk here, and I wouldn't want to trade away the ability to explain "methods" in two sentences: A 'method' is just a function whose first argument is 'self'. The method is an atribute of the class object, and when it is called using "a.method(args)", the instance 'a' is passed as 'self'. for a cute way of making double use of a few factory functions. -- Michael Chermside

3 2