Mailman 3 April 2005 - Python-Dev

Re: atexit missing an unregister method
by Nick Jacobson 26 Apr '05

26 Apr '05

<< This seems like a poor argument for unregistering exit handlers. If you've registered an exit handler, why then explicitly do what you've already asked the system to do? >> 1. To free up memory for the rest of the program. 2. If the following block is in a loop, and you need to allocate & then deallocate resources multiple times.: << atexit.register(free_resource, x) atexit.register(free_resource, y) # do operations with x and y, potentially causing the program to exit ... # if nothing caused the program to unexpectedly quit, close the resources free_resource(x) free_resource(y) >> << Also, your proposed unregisterall() function would be dangerous. As an application writer you don't know what other parts of the system (libraries you use, for example) might have registered exit functions. Skip >> That's true...it would probably be better to expose the stack of registered functions. That way you can manually unregister functions you've registered. --Nick Jacobson _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

1 0

Removing --with-wctype-functions support
by S.Çağlar Onur 26 Apr '05

26 Apr '05

Hi; I just subscribed this list, so i don't know whether this discussed before. If so, sorry. I want to know status of http://mail.python.org/pipermail/python-dev/2004-December/050193.html this thread. Will python remove wctype functions support from its core? If it will, what about locale-dependent case conversation functions? Without this support python behaves wrong in tr_TR.UTF-8 locale. As a side effect, this problem reported to Gentoo Linux to add a wctype support to current python ebuild ( http://bugs.gentoo.org/show_bug.cgi?id=69322 ), but they don't want to add any removed feature to their ebuilds, and also not break anything because portage is built on python. So :), what will the feature of wctype? Yours -- S.Çağlar Onur <caglar(a)uludag.org.tr> http://cekirdek.uludag.org.tr/~caglar/ Linux is like living in a teepee. No Windows, no Gates and an Apache in house!

3 2

Re: [Python-Dev] Re: anonymous blocks
by ron adam 26 Apr '05

26 Apr '05

Hi, this is my first post here and I've been following this very interesting discussion as is has developed. A really short intro about me, I was trained as a computer tech in the early 80's... ie. learned transistors, gates, logic etc... And so my focus tends to be from that of a troubleshooter. I'm medically retired now (not a subject for here) and am looking for something meaningful and rewarding that I can contribute to with my free time. I will not post often at first as I am still getting up to speed with CVS and how Pythons core works. Hopefully I'm not lagging this discussion too far or adding unneeded noise to it. :-) >> So maybe the 'with' keyword should be dropped (again!) in >> favour of >> >> with_opened(pathname) as f: >> ... >> > > But that doesn't look so great for the case where there's no variable > to be assigned to -- I wasn't totally clear about it, but I meant the > syntax to be > > with [VAR =] EXPR: BLOCK > > where VAR would have the same syntax as the left hand side of an > assignment (or the variable in a for-statement). > I keep wanting to read it as: with OBJECT [from EXPR]: BLOCK >> 2) I'm not sure about the '='. It makes it look rather deceptively >> like an ordinary assignment, and I'm sure many people are going >> to wonder what the difference is between >> >> with f = opened(pathname): >> do_stuff_to(f) >> >> and simply >> >> f = opened(pathname) >> do_stuff_to(f) >> >> or even just unconsciously read the first as the second without >> noticing that anything special is going on. Especially if they're >> coming from a language like Pascal which has a much less magical >> form of with-statement. >> Below is what gives me the clearest picture so far. To me there is nothing 'anonymous' going on here. Which is good I think. :-) After playing around with Guido's example a bit, it looks to me the role of a 'with' block is to define the life of a resource object. so "with OBJECT: BLOCK" seems to me to be the simplest and most natural way to express this. def with_file(filename, mode): """ Create a file resource """ f = open(filename, mode) try: yield f # use yield here finally: # Do at exit of 'with <resource>: <block>' f.close # Get a resource/generator object and use it. f_resource = with_file('resource.py', 'r') with f_resource: f = f_resource.next() # get values from yields for line in f: print line, # Generator resource with yield loop. def with_file(filename): """ Create a file line resource """ f = open(filename, 'r') try: for line in f: yield line finally: f.close() # print lines in this file. f_resource = with_file('resource.py') with f_resource: while 1: line = f_resource.next() if line == "": break print line, The life of an object used with a 'with' block is shorter than that of the function it is called from, but if the function is short, the life could be the same as the function. Then the 'with' block could be optional if the resource objects __exit__ method is called when the function exits, but that may require some way to tag a resource as being different from other class's and generators to keep from evaluating __exit__ methods of other objects. As far as looping behaviors go, I prefer the loop to be explicitly defined in the resource or the body of the 'with', because it looks to be more flexible. Ron_Adam # "The right question is a good start to finding the correct answer."

1 0

Re: anonymous blocks vs scope-collapse
by Jim Jewett 26 Apr '05

26 Apr '05

Michael Hudson: > This proposal seems a bit like an effort to make generators good at > doing something that they aren't really intended -- or dare I say > suited? -- for. I think it is more an effort to use the right keyword, which has unfortunately already been claimed by generators (and linked to iterators). yield is a sensible way for code to say "your turn, but come back later". But at the moment, it means "I am producing an intermediate value", and the way to call that function is to treat it as an iterator (which seems to imply looping over a closed set, so don't send in more information after the initial setup). Should we accept that "yield" is already used up, or should we shoehorn the concepts until they're "close enough"? > So, here's a counterproposal! > with expr as var: > ... code ... > is roughly: > def _(var): > ... code ... > __private = expr > __private(_) ... > The need for approximation in the above translation is necessary > because you'd want to make assignments in '...code...' affect the scope > their written in, To me, this seems like the core requirement. I see three sensible paths: (1) Do nothing. (2) Add a way to say "Make this function I'm calling use *my* locals and globals." This seems to meet all the agreed-upon-as-good use cases, but there is disagreement over how to sensibly write it. The calling function is the place that could get surprised, but people who want thunks seem to want the specialness in the called function. (3) Add macros. We still have to figure out how to limit their obfuscation. Attempts to detail that goal seem to get sidetracked. -jJ

2 1

defmacro (was: Anonymous blocks)
by Jim Jewett 26 Apr '05

26 Apr '05

Guido: > My problem with macros is actually more practical: Python's compiler > is too dumb. I am assuming that we want to be able to import macros > from other modules, and I am assuming that macros are expanded by the > compiler, not at run time; but the compiler doesn't follow imports ... Expanding at run-time is less efficient, but it works at least as well semantically. If today's alternative is manual cut-n-paste, I would still rather have the computer do it for me, to avoid accidental forks. It could also be done (though not as cleanly) by making macros act as import hooks. import defmacro # Stop processing until defmacro is loaded. # All future lines will be preprocessed by the # hook collection ... from defmacro import foo # installs a foo hook, good for the rest of the file Michael Chermside: >> I think it would be useful if we approached it like this: either what >> we want is the full power of macros (in which case the syntax we choose >> should be guided by that choice), or we want LESS than the full power >> of macros. If we want less, then HOW less? >> In other words, rather than hearing what we'd like to be able to DO >> with blocks, I'd like to hear what we want to PROHIBIT DOING with >> blocks. I think this might be a fruitful way of thinking about the >> problem which might make it easier to evaluate syntax suggestions. And >> if the answer is that we want to prohibit nothing, then the right >> solution is macros. > I'm personally at a loss understanding your question here. Perhaps you > could try answering it for yourself? Why not just introduce macros? If the answer is "We should, it is just hard to code", then use a good syntax for macros. If the answer is "We don't want xx sss (S\<! 2k3 ] to ever be meaningful", then we need to figure out exactly what to prohibit. Lisp macros are (generally, excluding read macros) limited to taking and generating complete S-expressions. If that isn't enough to enforce readability, then limiting blocks to expressions (or even statements) probably isn't enough in python. Do we want to limit the changing part (the "anonymous block") to only a single suite? That does work well with the "yield" syntax, but it seems like an arbitrary restriction unless *all* we want are resource wrappers. Or do we really just want a way to say that a function should share its local namespace with it's caller or callee? In that case, maybe the answer is a "lexical" or "same_namespace" keyword. Or maybe just a recipe to make exec or eval do the right thing. def myresource(rcname, callback, *args): rc=open(rcname) same_namespace callback(*args) close(rc) def process(*args): ... ... if __name__ == '__main__': myresource("file1", process, arg1, arg2)

4 6

defmacro (was: Anonymous blocks)
by Jim Jewett 25 Apr '05

25 Apr '05

As best I can tell, the anonymous blocks are used to take care of boilerplate code without changing the scope -- exactly what macros are used for. The only difference I see is that in this case, the macros are limited to entire (possibly compound) statements. To make this more concrete, Guido: >> in synchronized(the_lock): >> BODY Nick Coghlan: > s/in/with/ to get PEP 310. ... >Guido's recent screed crystallised the idea of writing resources > as two-part generators: ... [Adding Reinhold Birkenfeld's suggestion of a blank yield] > def my_resource(): > print "Hi!" # Do entrance code > yield # Go on with the contents of the 'with' block > print "Bye!" # Do exit code The macro itself looks reasonable -- so long as there is only ever one changing block inside the macro. I'm not sure that is a reasonable restriction, but the alternative is ugly enough that maybe passing around locals() starts to be just as good. What about a block that indicates the enclosed namespaces will collapse a level? defmacro myresource(filename): <make explicit calls to named callback "functions", but within the same locals() scope.> with myresource("thefile"): def reader(): ... def writer(): ... def fn(): .... Then myresource, reader, writer, and fn would share a namespace without having to manually pass it around. -jJ

2 1

Weekly Python Patch/Bug Summary
by Kurt B. Kaiser 25 Apr '05

25 Apr '05

Patch / Bug Summary ___________________ Patches : 316 open ( +2) / 2831 closed ( +7) / 3147 total ( +9) Bugs : 908 open (+10) / 4941 closed (+20) / 5849 total (+30) RFE : 178 open ( +1) / 153 closed ( +2) / 331 total ( +3) New / Reopened Patches ______________________ package_data chops off first char of default package (2005-04-15) http://python.org/sf/1183712 opened by Wummel [ast] fix for 1183468: return/yield in class (2005-04-16) http://python.org/sf/1184418 opened by logistix urllib2 dloads failing through HTTP proxy w/ auth (2005-04-18) http://python.org/sf/1185444 opened by Mike Fleetwood binascii.b2a_qp does not handle binary data correctly (2005-04-18) http://python.org/sf/1185447 opened by Eric Huss Automatically build fpectl module from setup.py (2005-04-18) http://python.org/sf/1185529 opened by Jeff Epler Typo in Curses-Function doc (2005-04-20) http://python.org/sf/1186781 opened by grzankam subprocess: optional auto-reaping fixing os.wait() lossage (2005-04-21) http://python.org/sf/1187312 opened by Mattias Engdegård Add const specifier to PySpam_System prototype (2005-04-21) http://python.org/sf/1187396 opened by Luis Bruno Don't assume all exceptions are SyntaxError's (2005-04-25) http://python.org/sf/1189210 opened by John Ehresman Patches Closed ______________ fix typos in Library Reference (2005-04-10) http://python.org/sf/1180062 closed by doerwalter [AST] Fix for core in test_grammar.py (2005-04-08) http://python.org/sf/1179513 closed by nascheme Implemented new 'class foo():pass' syntax (2005-04-03) http://python.org/sf/1176019 closed by nascheme range() in for loops, again (2005-04-12) http://python.org/sf/1181334 closed by arigo Info Associated with Merge to AST (2005-01-07) http://python.org/sf/1097671 closed by kbk New / Reopened Bugs ___________________ Minor error in tutorial (2005-04-14) CLOSED http://python.org/sf/1183274 opened by Konrads Smelkovs check for return/yield outside function is wrong (2005-04-15) http://python.org/sf/1183468 opened by Neil Schemenauer try to open /dev/null as directory (2005-04-15) http://python.org/sf/1183585 opened by Roberto A. Foglietta PyDict_Copy() can return non-NULL value on error (2005-04-15) CLOSED http://python.org/sf/1183742 opened by Phil Thompson Popen4 wait() fails sporadically with threads (2005-04-15) http://python.org/sf/1183780 opened by Taale Skogan return val in __init__ doesn't raise TypeError in new-style (2005-04-15) CLOSED http://python.org/sf/1183959 opened by Adal Chiriliuc dest parameter in optparse (2005-04-15) http://python.org/sf/1183972 opened by ahmado Missing trailing newline with comment raises SyntaxError (2005-04-15) http://python.org/sf/1184112 opened by Eric Huss example broken in section 1.12 of Extending & Embedding (2005-04-16) http://python.org/sf/1184380 opened by bamoore Read-only property attributes raise wrong exception (2005-04-16) CLOSED http://python.org/sf/1184449 opened by Barry A. Warsaw itertools.imerge: merge sequences (2005-04-18) CLOSED http://python.org/sf/1185121 opened by Jurjen N.E. Bos pydoc doesn't find all module doc strings (2005-04-18) http://python.org/sf/1185124 opened by Kent Johnson PyObject_Realloc bug in obmalloc.c (2005-04-19) http://python.org/sf/1185883 opened by Kristján Valur python socketmodule dies on ^c (2005-04-19) CLOSED http://python.org/sf/1185931 opened by nodata tempnam doc doesn't include link to tmpfile (2005-04-19) http://python.org/sf/1186072 opened by Ian Bicking [AST] genexps get scoping wrong (2005-04-19) http://python.org/sf/1186195 opened by Brett Cannon [AST] assert failure on ``eval("u'\Ufffffffe'")`` (2005-04-19) http://python.org/sf/1186345 opened by Brett Cannon [AST] automatic unpacking of arguments broken (2005-04-19) http://python.org/sf/1186353 opened by Brett Cannon Python Programming FAQ should be updated for Python 2.4 (2005-02-09) CLOSED http://python.org/sf/1119439 reopened by montanaro nntplib shouldn't raise generic EOFError (2005-04-20) http://python.org/sf/1186900 opened by Matt Roper TypeError message on bad iteration is misleading (2005-04-21) http://python.org/sf/1187437 opened by Roy Smith Pickle with HIGHEST_PROTOCOL "ord() expected..." (2005-04-22) CLOSED http://python.org/sf/1188175 opened by Heiko Selber Rebuilding from source on RH9 fails (_tkinter.so missing) (2005-04-22) http://python.org/sf/1188231 opened by Marty Heyman Python 2.4 Not Recognized by Any Programs (2005-04-23) http://python.org/sf/1188637 opened by Yoshi Nagasaki zipfile module and 2G boundary (2005-04-24) http://python.org/sf/1189216 opened by Bob Ippolito Seg Fault when compiling small program (2005-04-24) http://python.org/sf/1189248 opened by Reginald B. Charney LINKCC incorrect (2005-04-25) http://python.org/sf/1189330 opened by Christoph Ludwig LINKCC incorrect (2005-04-25) CLOSED http://python.org/sf/1189337 opened by Christoph Ludwig file.write(x) where len(x) > 64*1024**2 is unreliable (2005-04-25) CLOSED http://python.org/sf/1189525 opened by Martin Gfeller pydoc may hide non-private doc strings. (2005-04-25) http://python.org/sf/1189811 opened by J Livingston "Atuple containing default argument values ..." (2005-04-25) http://python.org/sf/1189819 opened by Chad Whitacre Bugs Closed ___________ Minor error in tutorial (2005-04-14) http://python.org/sf/1183274 closed by doerwalter copy.py bug (2005-02-03) http://python.org/sf/1114776 closed by anthonybaxter re.escape(s) prints wrong for chr(0) (2005-04-13) http://python.org/sf/1182603 closed by nascheme PyDict_Copy() can return non-NULL value on error (2005-04-15) http://python.org/sf/1183742 closed by rhettinger return val in __init__ doesn't raise TypeError in new-style (2005-04-15) http://python.org/sf/1183959 closed by rhettinger dir() does not include _ (2005-04-13) http://python.org/sf/1182614 closed by nickjacobson Read-only property attributes raise wrong exception (2005-04-16) http://python.org/sf/1184449 closed by bwarsaw Readline segfault (2005-04-05) http://python.org/sf/1176893 closed by mwh python socketmodule dies on ^c (2005-04-19) http://python.org/sf/1185931 closed by nodata101 Bad sys.executable value for bdist_wininst install script (2005-04-12) http://python.org/sf/1181619 closed by theller StringIO and cStringIO don't provide 'name' attribute (2005-04-03) http://python.org/sf/1175967 closed by mwh Python Interpreter shell is crashed (2005-01-12) http://python.org/sf/1100673 closed by mwh Python Programming FAQ should be updated for Python 2.4 (2005-02-09) http://python.org/sf/1119439 closed by jafo Dictionary Parsing Problem (2005-02-05) http://python.org/sf/1117048 closed by tjreedy 2.4.1 breaks pyTTS (2005-04-07) http://python.org/sf/1178624 closed by doerwalter Pickle with HIGHEST_PROTOCOL "ord() expected..." (2005-04-22) http://python.org/sf/1188175 closed by drhok multiple broken links in profiler docs (2005-03-30) http://python.org/sf/1173773 closed by isandler LINKCC incorrect (2005-04-25) http://python.org/sf/1189337 closed by cludwig file.write(x) where len(x) > 64*1024**2 is unreliable (2005-04-25) http://python.org/sf/1189525 closed by tim_one New / Reopened RFE __________________ "replace" function should accept lists. (2005-04-17) CLOSED http://python.org/sf/1184678 opened by Poromenos Make bisect.* functions accept an optional compare function (2005-04-18) http://python.org/sf/1185383 opened by Marcin Ciura RFE Closed __________ "replace" function should accept lists. (2005-04-17) http://python.org/sf/1184678 closed by rhettinger itertools.imerge: merge sequences (2005-04-18) http://python.org/sf/1185121 closed by jneb

1 0

RE: [Python-Dev] defmacro (was: Anonymous blocks)
by Robert Brewer 25 Apr '05

25 Apr '05

Shane Hathaway wrote: > Robert Brewer wrote: > > So currently, all subclasses just override __set__, which leads to a > > *lot* of duplication of code. If I could write the base > class' __set__ > > to call "macros" like this: > > > > def __set__(self, unit, value): > > self.begin() > > if self.coerce: > > value = self.coerce(unit, value) > > oldvalue = unit._properties[self.key] > > if oldvalue != value: > > self.pre() > > unit._properties[self.key] = value > > self.post() > > self.end() > > > > defmacro begin: > > pass > > > > defmacro pre: > > pass > > > > defmacro post: > > pass > > > > defmacro end: > > pass > > Here is a way to write that using anonymous blocks: > > def __set__(self, unit, value): > with self.setting(unit, value): > if self.coerce: > value = self.coerce(unit, value) > oldvalue = unit._properties[self.key] > if oldvalue != value: > with self.changing(oldvalue, value): > unit._properties[self.key] = value > > def setting(self, unit, value): > # begin code goes here > yield None > # end code goes here > > def changing(self, oldvalue, newvalue): > # pre code goes here > yield None > # post code goes here > ... > Which do you prefer? I like fewer methods. ;-) I still prefer more methods, because my actual use-cases are more complicated. Your solution would work for the specific case I gave, but try factoring in: * A subclass which needs to share locals between begin and post, instead of pre and post. or * A set of 10 subclasses which need the same begin() but different end() code. Yielding seems both too restrictive and too inside-out to be readable, IMO. Robert Brewer MIS Amor Ministries fumanchu(a)amor.org

3 2

anonymous blocks
by Shannon -jj Behrens 25 Apr '05

25 Apr '05

(I apologize that this is my first post. Please don't flame me into oblivion or think I'm a quack!) Have you guys considered the following syntax for anonymous blocks? I think it's possible to parse given Python's existing syntax: items.doFoo( def (a, b) { return a + b }, def (c, d) { return c + d } ) Notice the trick is that there is no name between the def and the "(", and the ")" is followed by a "{". I understand that there is hesitance to use "{}". However, you can think of this as a Python special case on the same level as using ";" between statements on a single line. From that perspective, it's not inconsistent at all. Best Regards, -jj

32 84

RE: [Python-Dev] defmacro (was: Anonymous blocks)
by Robert Brewer 25 Apr '05

25 Apr '05

Guido van Rossum wrote: > > Why not just introduce macros? > > Because I've been using Python for 15 years without needing them? > Sorry, but "why not add feature X" is exactly what we're trying to > AVOID here. You've got to come up with some really good use cases > before we add new features. "I want macros" just doesn't cut it. I had a use-case recently which could be done using macros. I'll let you all decide whether it would be "better" with macros or not. ;) My poor-man's ORM uses descriptors to handle the properties of domain objects, a lot of which need custom triggers, constraint-checking, notifications, etc. The base class has: def __set__(self, unit, value): if self.coerce: value = self.coerce(unit, value) oldvalue = unit._properties[self.key] if oldvalue != value: unit._properties[self.key] = value At one time, I had something like: def __set__(self, unit, value): if self.coerce: value = self.coerce(unit, value) oldvalue = unit._properties[self.key] if oldvalue != value: if self.pre: self.pre(unit, value) unit._properties[self.key] = value if self.post: self.post(unit, value) ...to run pre- and post-triggers. But that became unwieldy recently when one of my post functions depended upon calculations inside the corresponding pre function. So currently, all subclasses just override __set__, which leads to a *lot* of duplication of code. If I could write the base class' __set__ to call "macros" like this: def __set__(self, unit, value): self.begin() if self.coerce: value = self.coerce(unit, value) oldvalue = unit._properties[self.key] if oldvalue != value: self.pre() unit._properties[self.key] = value self.post() self.end() defmacro begin: pass defmacro pre: pass defmacro post: pass defmacro end: pass ...(which would require macro-blocks which were decidedly *not* anonymous) then I could more cleanly write a subclass with additional "macro" methods: defmacro pre: old_children = self.children() defmacro post: for child in self.children: if child not in old_children: notify_somebody("New child %s" % child) Notice that the "old_children" local gets injected into the namespace of __set__ (the caller) when "pre" is executed, and is available inside of "post". The "self" name doesn't need to be rebound, either, since it is also available in __set__'s local scope. We also avoid all of the overhead of separate frames. The above is quite ugly written with callbacks (due to excessive argument passing), and is currently fragile when overriding __set__ (due to duplicated code). I'm sure there are other cases with both 1) a relatively invariant series of statements and 2) complicated extensions of that series. Of course, you can do the above with compile() and exec. Maybe I'm just averse to code within strings. Some ideas. Now tear 'em apart. :) Robert Brewer MIS Amor Ministries fumanchu(a)amor.org

2 1