Mailman 3 February 2007 - Python-Dev

Re: [Python-Dev] Summary of "dynamic attribute access" discussion
by skip＠pobox.com Feb. 14, 2007

Feb. 14, 2007

Greg> skip(a)pobox.com wrote: Greg> for (x in seq1, y in seq2): >> That's already valid syntax though. Greg> No, it's not... >>>> for (x in seq1, y in seq2): Greg> File "<stdin>", line 1 Greg> for (x in seq1, y in seq2): Greg> ^ Greg> SyntaxError: invalid syntax Ah, yeah. Misread it and just focused on the bit that looked like a tuple... Skip

1 0

Summary of "dynamic attribute access" discussion
by Ben North Feb. 14, 2007

Feb. 14, 2007

The support for the including the feature at all is still not unanimous. Perhaps the way forward is to try to reach consensus on the favourite (or least-unfavourite) syntax, and I'll revise the PEP and sample implementation. I think the "obj.[attr_name]" syntax has the most support. To stop this going round in circles for ages, then, I will take this as the winner. I'll mention the other contenders in the PEP, including the new "visually distinctive" suggestions obj@[foo] obj.[[foo]] and the "wrapper class" idea of Nick Coghlan: attrview(obj)[foo] (I personally think the "attrview" idea results in slightly cluttered-looking code, and prefer the visual simplicity of "obj.[foo]".) One of the new opinions against the feature at all was Steve Holden's: > This seems to me to take Python further away from the "Computer > Programming for Everyone" arena and closer to the "Systems Programming > for Clever Individuals" camp. I don't agree. People who find it clearer to write x = getattr(obj, attr_name) can continue to do so. Now, of course, a person with such a preference has no control over what other people write, so everybody will have to understand what the new syntax means, but I think it's quite mnemonic. It's a combination of the "." attribute look-up and the "[]" dictionary look-up. Steve, further down his message, continues: > It threatens to reduce Python's readability substantially I find obj.[attr_name] = other_obj.[attr_name] a much clearer expression of the "assignment" intent of this statement than setattr(obj, attr_name, getattr(other_obj, attr_name)) in the same way that I find my_dict[new_key] = new_value clearer than a hypothetical setvalue(my_dict, new_key, new_value) would be. Opinion is divided on whether it's a readability win, but I think it *is* a win. (Well, I would, I suppose). My experience in Matlab was that code became much more readable when they introduced "dynamic fields", especially in code which sets "fields" in one variable from "fields" in others. I don't know whether others on this list have worked in Matlab and have any opinions from their experience. Turning now to the performance question, Steve also writes: > > Is 1% "too much" for this feature? > > Yes. I believe it would decrease the sum total of Python's efficiency > for a very marginal return in performance on a very marginal feature. The performance question is important, certainly. Initial reaction on python-ideas was that a 1% cost would not count as substantial, but of course quicker would be better, and there were a couple of suggestions as to how the implementation could be improved. I agree that "readability is more important than efficiency", and I think a 1% efficiency loss would be "small" compared to what I think is a readability win, especially in cases like the example above. Thanks very much for all the interest in this idea. I think I've got enough of a sense of the list's reaction to update the PEP, and will do so over the next couple of days. I'll then re-post it so that everyone can check I haven't misrepresented their opinion, and take it from there. Ben.

15 32

New syntax for 'dynamic' attribute access
by Ben North Feb. 14, 2007

Feb. 14, 2007

Thanks for the comments so far on this. First, on the general idea: Neil Toronto: > I like it. > [...] > > obj.(attr_name) += 1 > Even nicer; much, much better than the current spelling. Brett Cannon: > +0 on the one-item version. Anthony Baxter: > -1 from me. Collin Winter: > I like the general idea [...] I'm +0 on the idea Jack Jansen: > I like the functionality, Raymond Hettinger: > I also like the functionality. Generally gently positive, with the exception of Anthony Baxter's "-1", which I understand to be motivated by concerns about newcomers to the syntax: > Someone coming across this syntax for the first time will not have any > hints as to what it means - and worse, it looks like a syntax error to > me. This was echoed by Collin Winter: > Also, like Anthony Baxter said, someone coming across this for the > first time will think it's a syntax error, allusions to MATLAB and > assembly indirection syntax not withstanding. [...] -1 on the means. I think the argument "someone who hasn't come across it before won't know what it is" could be applied to any new syntax, for instance the new "with" statement, or going further back in time, the introduction of Booleans, semantics of "__slots__", the "extended print" syntax, the "list comprehension" syntax, the "augmented assignment" syntax, etc. Some of these were perhaps more transparent than others, but for instance "with" needs a bit of study to fully understand what's going on. I would argue that the newness itself is not sufficient reason to reject this. Also, I think it's a good thing that it looks like a syntax error --- it *is* currently a syntax error. A newcomer will be alerted to the fact that something new is going on and will know to go and find out about it. I am happy to write a paragraph for the "what's new" release notes, and/or new section(s) for the documentation describing the new syntax. On the two-argument form, feeling was generally pretty negative, with a few "-1"s thrown in. I propose to cut this piece out of the PEP, leaving just the one-argument form. If a default value is required, the coder can still use the three-argument form of "getattr". To be clear (and I'll put this in the PEP), I'm *not* suggesting that python loses "getattr", "setattr", or "delattr". On the syntax: Brett Cannon: > It just makes it look like too much of a function call at that point > to me Collin Winter: > the syntax looks like dirt on my monitor. The period is too easy to > lose visually and without it, there's nothing to distinguish this from > a function call. Jack Jansen: > I don't like the syntax, to me it looks too much like a method call. (Some of the initial comments in python-ideas were along these lines too.) My personal opinion is that "obj.(foo)" is distinct enough from "obj(foo)" to not cause confusion, but perhaps in a proportional font it is less clear. Some people made concrete suggestions as to what syntax could be used instead: Jack Jansen: > To me self.[method_name] = self.metadata.[method_name] looks better: > what we're doing here is more like dictionary lookup than calling > functions. In the same way, though, would this be viewed as too similar to normal dictionary/list indexing? Raymond Hettinger: > Rather than munge existing syntaxes, an altogether new one would be > more clear: > > self->name = self.metadata->name One thing which comes to mind about this one is that, for C/C++ programmers, the difference between obj.member and obj->member is the interpretation of the thing on the *left* of the dot or arrow, whereas the PEP is discussing a new interpretation of the thing on the *right* of the dot. One idea mentioned in the PEP is to bring {}s into service here, but I think the dot should be kept to keep it looking like an attribute access. What would the reaction be to obj.{member} instead? Braces are already used to construct dictionaries, so this has some of the right connotations. It could not be confused with either a function call or a dictionary lookup/list indexing. (Nobody had any comments on the potential 1% performance hit --- is this because it's too early to worry about implementation details?) Thanks, Ben.

17 31

Porting Python 2.4.4. and 2.5 to Sparc Solaris 9 and 10
by vancleef＠lostwells.net Feb. 14, 2007

Feb. 14, 2007

Dear Python Developers. I posted the following to the python-help yesterday. While I received some interesting responses, they indicated that I'd already gone beyond that group's knowledge, and suggested that I mail the developers directly on this list. By way of background, I'm a retired hardware-software engineer with substantial experience in kernel programming, device drivers, porting between hardware and software architectures, so am probably more prepared than the average systems administrator to get into program details. I have downloaded the tars for Python 2.4.4 and 2.5, and built both of them on two Solaris systems, using a variety of compilers. The original objective was to get a usable Python to support a Mailman 2.1.9 installation. While it was clear that a build of 2.5, using the Sun Studio 11 development system, was incomplete and did not pass all of the regression tests, it did prove to be adequate to support Mailman. I have now come back to audit building Python on Sparc Solaris and to get some idea of what needs to be done to get a clean and reasonably complete build. My attempts to find some support through the Python web site seemed quite inconclusive. I spent part of a day trying to weave my way through the Sourceforge bug tracker, but was unable to find anything that seemed meaningful vis-a-vis what my audits were showing. Accordingly, I chose to devote some time and effort to determining where the build problems lay, and what might be needed to fix some of them. Build Platform Data: System A: Sun Ultra 60, Solaris 10 11/06, with Sun Studio 11 development system (/opt/SUNWspro). A Solaris 10 11/06 full distribution install includes gcc-3.4.3, Python 2.3.3, along with libraries and header files for such things as Tcl/Tk and openssl. System B: Sun Ultra 10, Solaris 9 9/05. Development systems are Sun Studio 11 and a new local build of gcc-4.1.1 (c and c++ only). The O/S is patched with the mid-January Sun patch cluster. Solaris 9 does not include a Python or a gcc, but does include Tcl/Tk libraries and include files. In both cases, the Studio 11 programs have been patched to current. The cc patch level is 121015-03. Both O/S installs are recent "full system" installs on bare machines, plus the development systems noted. I consider these representative of what an average systems administrator would have for resources "out of the box" for building and installing Python from source. On both systems, the non-Solaris software resides in the /usr/sfw directory tree. After having tried several configure/make/make test runs, it appears to me that there are two problem areas. 1. There is no way in the distribution setup to get the build to find the /opt/sfw include libraries for building extension modules. It appears to me that this search is done by setup.py, and that configuring the appropriate paths in the main Makefile does not propogate out to the module build. If the configure script has a way to find these libraries and to set the build up for them, I can't see what that might be. This problem affects both 2.4.4 and 2.5. I have taken the time to add the search code for the Solaris /opt/sfw directories to setup.py. There were other changes needed to existing code to get it to work properly. I include a diff between the code I am using with success and the 2.5 distribution version at the end of this note. It may not be the most appropriate for distribution, but it works on Solaris 9 and 10. I had to revise the setup.py in the 2.4.4 distribution similarly. 2. On Python 2.5, the ctypes and libffi code is not only GNU-specific, but gcc-version-specific as well. The problem with the __attribute__ specification in ffi.h seems to be well-understood, and may be amenable to some sort of workaround. However, attempting to build with the gcc-3.4.3 included with Solaris 10 failed with a linker misalignment error. 3. Regression test failures: test test_ioctl failed -- errors occurred in test.test_ioctl.IoctlTests I get this output when running make test on any build (Sun cc or any gcc) on both 2.4.4 and 2.5. Running the ioctl test standalone does not produce a failure. At this point, I wonder if I am reinventing the wheel or finding things that need to be addressed for Solaris builds. I am new to Python, and while I'd like to use it to make some local changes to Mailman, I feel concerned over reliability and robustness. Just how are you getting full Solaris builds? Hank van Cleef vancleef(a)lostwells.net ==================================================================== The test summary and setup.py diffs follow: 280 tests OK. 1 test failed: test_ioctl 38 tests skipped: test_aepack test_al test_applesingle test_bsddb test_bsddb185 test_bsddb3 test_cd test_cl test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw test_ctypes test_curses test_gdbm test_gl test_imgfile test_linuxaudiodev test_macfs test_macostools test_nis test_normalization test_ossaudiodev test_pep277 test_plistlib test_scriptpackages test_socket_ssl test_socketserver test_sqlite test_startfile test_timeout test_unicode_file test_urllib2net test_urllibnet test_winreg test_winsound test_zipfile64 2 skips unexpected on sunos5: test_ctypes test_nis (nis is not enabled on these systems) Diffs for setup.py: *** setup.py.dist Thu Feb 8 11:39:42 2007 --- setup.py Mon Feb 12 11:04:44 2007 *************** *** 306,311 **** --- 306,316 ---- platform = self.get_platform() (srcdir,) = sysconfig.get_config_vars('srcdir') + # Add search directories for Solaris distribution add-ons + if platform == 'sunos5': + inc_dirs += ['/usr/sfw/include'] + lib_dirs += ['/usr/sfw/lib'] + # Check for AtheOS which has libraries in non-standard locations if platform == 'atheos': lib_dirs += ['/system/libs', '/atheos/autolnk/lib'] *************** *** 520,529 **** depends = ['socketmodule.h']) ) # Detect SSL support for the socket module (via _ssl) search_for_ssl_incs_in = [ '/usr/local/ssl/include', '/usr/contrib/ssl/include/' ] ! ssl_incs = find_file('openssl/ssl.h', inc_dirs, search_for_ssl_incs_in ) if ssl_incs is not None: --- 525,535 ---- depends = ['socketmodule.h']) ) # Detect SSL support for the socket module (via _ssl) search_for_ssl_incs_in = [ + '/usr/sfw/include', '/usr/local/ssl/include', '/usr/contrib/ssl/include/' ] ! ssl_incs = find_file('/openssl/ssl.h', inc_dirs, search_for_ssl_incs_in ) if ssl_incs is not None: *************** *** 531,541 **** ['/usr/kerberos/include']) if krb5_h: ssl_incs += krb5_h ! ssl_libs = find_library_file(self.compiler, 'ssl',lib_dirs, ['/usr/local/ssl/lib', '/usr/contrib/ssl/lib/' ] ) - if (ssl_incs is not None and ssl_libs is not None): exts.append( Extension('_ssl', ['_ssl.c'], --- 537,546 ---- ['/usr/kerberos/include']) if krb5_h: ssl_incs += krb5_h ! ssl_libs = find_library_file(self.compiler, 'ssl.so',lib_dirs, ['/usr/local/ssl/lib', '/usr/contrib/ssl/lib/' ] ) if (ssl_incs is not None and ssl_libs is not None): exts.append( Extension('_ssl', ['_ssl.c'], *************** *** 1245,1251 **** --- 1250,1258 ---- # Check for various platform-specific directories if platform == 'sunos5': include_dirs.append('/usr/openwin/include') + include_dirs.append('/usr/sfw/include') added_lib_dirs.append('/usr/openwin/lib') + added_lib_dirs.append('/usr/sfw/lib') elif os.path.exists('/usr/X11R6/include'): include_dirs.append('/usr/X11R6/include') added_lib_dirs.append('/usr/X11R6/lib64')

1 0

Re: [Python-Dev] Trial balloon: microthreads library in stdlib
by dustin＠v.igoro.us Feb. 14, 2007

Feb. 14, 2007

On Sun, Feb 11, 2007 at 03:35:29AM +0200, Yotam Rubin wrote: > Why don't you use Stackless? It's very simple, stable, and solves > quite completely the problems in writing concurrect code. That's a great point -- I'm not necessarily producing this to solve a problem I'm having. Rather, I think that the new language features in PEP 342 cry out for a batteries-included library that makes asynchronous programming both natural and easy. Dustin

10 25

Re: [Python-Dev] Trial balloon: microthreads library in stdlib
by Phillip J. Eby Feb. 14, 2007

Feb. 14, 2007

At 08:41 PM 2/13/2007 +0000, glyph(a)divmod.com wrote: > and the microthreading features being discussed here are a trivial hack > somewhere in its mainloop machinery, not an entirely new subsystem that > it should be implemented in terms of. It doesn't even require hacking the mainloop; it can be done entirely in userspace. Here's some code I wrote a few months ago but never got around to using it. (Or testing it, for that matter, so it may not work, or even compile!) It requires Python 2.5 and the "simplegeneric" package from the Cheeseshop, and it allows you to "spawn" generators to create independently-running pseudothreads. These pseudothreads can yield to Deferreds, "returning" the value or failure thereof. (Failures cause the error to be raises such that it appears to happen at the yield point.) There are also a few other yield targets like "Return" (to return a value to a calling co-routine), "Pause" (to delay resumption), and "with_timeout" (to wrap some other yieldable in a timeout that raises TimeoutError). Enjoy! import types from twisted.internet import reactor from twisted.internet.defer import Deferred, TimeoutError from twisted.python import failure from simplegeneric import generic from functools import partial __all__ = [ # user APIs: 'spawn', 'Pause', 'Return', 'with_timeout', # extension APIs: 'schedule', 'resume', 'throw', 'current_task', 'yield_to', 'yieldable', ] def spawn(geniter, delay=0): """Create a new task and schedule it for execution Usage:: spawn(someGeneratorFunc(args)) The given generator-iterator will be run by the Twisted reactor after `delay` seconds have passed (0 by default). The return value of this function is a "task" object that can be passed to the ``schedule()``, ``throw()``, and ``yield_to()`` APIs. """ task = [geniter] schedule(task, delay) return task def schedule(task, delay=0, value=None): """Schedule `task` to resume after `delay` seconds (w/optional `value`)""" if task: return reactor.callLater(delay, resume, task, value) # XXX warn if non-None value sent to empty task? def resume(task, value=None): """Resume `task` immediately, returning `value` for the current yield""" if task: _invoke(task, partial(task[-1].send, value)) # XXX warn if non-None value sent to empty task? def throw(task, exc): """Raise `exc` tuple in `task` and immediately resume its execution""" if not task: # Propagate exception out of a failed task raise exc[0], exc[1], exc[2] _invoke(task, partial(task[-1].throw, *exc)) def _invoke(task, method): """Invoke method() in context of `task`, yielding to the return value""" try: value = method() except StopIteration: task.pop() # it's an exit with no return value resume(task) # so send None up the stack except: task.pop() # Propagate exception up the stack throw(task, sys.exc_info()) else: # Handle a yielded value yield_to(value, task) @generic def yield_to(value, task): """Handle a yielded value To register special handlers, use ``(a)yield_to.when_type()`` or or ``(a)yield_to.when_object()``. (See the ``simplegeneric`` docs for details.) """ raise TypeError( "Unrecognized yield value (maybe missing Return()?): %r" % (value,) ) @yield_to.when_type(defer.Deferred): def _yield_to_deferred(value, task): """Return a deferred value immediately or pause until fired""" def _resume(value): if isinstance(value, failure.Failure): throw(task, (type(value), value, None)) # XXX extract error? else: resume(task, value) return value # don't alter the deferred's value # This will either fire immediately, or delay until the appropriate time value.addCallbacks(_resume, _resume) @yield_to.when_type(types.GeneratorType) def _yield_to_subgenerator(value, task): """Call a sub-generator, putting it on the task's call stack""" task.append(value) schedule(task) def yieldable(f): """Declare that a function may be yielded to Usage:: @yieldable def do_something(task): # code that will be invoked upon (yield do_something) (yield do_something) The function's return value will be ignored, and errors in it are NOT caught! It must instead use the ``resume()``, ``schedule()``, ``throw()``, or ``yield_to()`` APIs to communicate with the yielding task (which is provided as the sole argument.) """ f.__yieldable__ = True return f @yield_to.when_type(types.FunctionType) def _yield_to_function(value, task): """Invoke task-management function""" if getattr(value, '__yieldable__', None): return value(task) # function is marked as yieldable else: raise TypeError( "Function is not marked yieldable (maybe missing Return()?): %r" % (value,) ) @yieldable def current_task(task): """Yield this function (don't call it) to obtain the current task Usage: ``task = (yield current_task)`` The yielding coroutine is immediately resumed; no task switching will occur. """ resume(task, task) class Pause(object): """Object that can be yielded to temporarily pause execution Usage:: yield Pause # allow other tasks to run, then resume ASAP yield Pause(5) # don't run for at least five seconds """ seconds = 0 def __init__(self, seconds=0): self.seconds = seconds def __repr__(self): return 'Pause(%s)' % self.seconds @yield_to.when_type(Pause) @yield_to.when_object(Pause) def _yield_to_pause(value, task): """Allow other tasks to run, by moving this task to the end of the queue""" schedule(task, value.seconds) class Return(object): """Return a value to your caller Usage:: yield Return(42) # returns 42 to calling coroutine yield Return # returns None to calling coroutine """ value = None def __init__(self, value): self.value = value def __repr__(self): return 'Return(%s)' % self.value @yield_to.when_type(Return) @yield_to.when_object(Return) def _yield_to_return(value, task): """Return a value to the caller""" task.pop().close() # ensure any ``finally`` clauses are run resume(task, value.value) def with_timeout(seconds, value): """Raise TimeoutError if `value` doesn't resume before `seconds` elapse Example:: result = yield with_timeout(30, something(whatever)) This is equivalent to ``result = yield something(whatever)``, except that if the current task isn't resumed in 30 seconds or less, a ``defer.TimeoutError`` will be raised in the blocked task. (Note: if the The `value` passed to this routine may be any yieldable value, although it makes no sense to yield a value that will just be returned to a parent coroutine. Note that the ``something(whatever)`` subtask may trap the ``TimeoutError`` and misinterpret its significance, so generally speaking you should use this only for relatively low-level operations, and expose a timeout parameter to your callers, to allow them to simply specify the timeout rather than using this wrapper. In fact, this is what most Twisted APIs do, providing a ``timeout`` keyword argument that you should use instead of this wrapper, as they will then raise ``TimeoutError`` automatically after the specified time expires. So, if you're calling such an API, don't use this wrapper. """ # raise a timeout error in this task after seconds delayedCall = reactor.callLater( seconds, throw, (yield current_task), (TimeoutError, TimeoutError(), None) ) try: yield Return((yield value)) # call the subtask and return its result finally: # Ensure timeout call doesn't fire after we've exited if delayedCall.active(): delayedCall.cancel()

1 0

Re: [Python-Dev] New syntax for 'dynamic' attribute access
by glyph＠divmod.com Feb. 13, 2007

Feb. 13, 2007

On 12 Feb, 11:19 pm, greg.ewing(a)canterbury.ac.nz wrote: >Ben North wrote: > >> Generally gently positive, with the exception of Anthony Baxter's >> "-1", which I understand to be motivated by concerns about newcomers to >> the syntax > >The more I think about it, the more I'm leaning >towards -1 as well. Adding syntax is a very big >step, and it needs a very solid reason to jusify >it. I don't see this filling a use case that's >anywhere near common enough to reach that >threshold. I also strongly dislike every syntax that has thus far been proposed, but even if I loved them, there is just no motivating use-case. New syntax is not going to make dynamic attribute access easier to understand, and it *is* going to cause even more version-compatibility headaches. I really, really wish that every feature proposal for Python had to meet some burden of proof, or submit a cost/benefit analysis. Who is this going to help? How much is this going to help them? "Who is this going to hurt" is easy, but should also be included for completeness - everyone who wants to be able to deploy new code on old Pythons. I suspect this would kill 90% of "hey wouldn't this syntax be neat" proposals on day zero, and the ones that survived would be a lot more interesting to talk about.

1 0

New syntax for 'dynamic' attribute access
by Ben North Feb. 13, 2007

Feb. 13, 2007

Guido van Rossum wrote: > - There's near-universal dislike for the two-arg form, so let's drop > that part of the proposal. This is a strong consensus, definitely, so we can conclude that this point has been decided. I will remove it from the PEP. Guido also wrote: > - There's a lot of support for the basic idea, and only a few > naysayers, so let's keep looking for a syntax that works. If we can take that as a decision, then the various proposals for the syntax break down as follows. By raw numbers, the most popular choice is self.(method_name) = self.metadata.(method_name) but many of the "I like that" messages were in the context of the idea as a whole, so can't really be counted as explicit votes for "obj.(foo)" as such. Next, and Guido's preferred choice, is self.[method_name] = self.metadata.[method_name] (I haven't been following long enough to know whether "Guido likes it" overrides everything else (the "D" of BDFL), or is more of a casting vote in the event of a tie.) With regard to the potential overlookability of the dot, Guido says: > I recommend that you do some experiments with the readability of the > .[...] notation, e.g. write a program that randomly generates x.[foo] > and x[foo], and see how fast you can spot the difference. I bet that > you won't have any trouble. I agree --- just as it's important to have a font that makes it easy to distinguish "I" from "l" and "1", "0" from "O", "(" from "{", etc., I would say it's important to program using a font which makes it easy to tell whether there's a "." in your code. I can imagine that a proportional font where "." might be a single pixel wouldn't help, though. (Gently wandering off-topic, but: do people use proportional fonts for coding? Doesn't it cause general awkwardness for indentation, especially relevant for python?) Also mentioned was self.{method_name} = self.metadata.{method_name} which could not be confused either with function call or indexing but perhaps would preclude braces from any potential future use. Exploring other ideas, the "arrow" notation self->method_name = self.metadata->method_name has support, and is clearly different, but I personally would be misled to think, from the meaning in C, that it ought to be the left-hand operand which is dereferenced somehow. Guido has the same opinion, and is "strongly -1" on this. The "star" form has the "dereference" meaning from C, and is certainly visually distinctive: self.*method_name = self.metadata.*method_name and explicit parentheses could be put in as a syntax requirement, or by individual coder preference, or for more complex attribute calculations: self.*(method_name) = self.metadata.*(method_name) self.*('foo_%d' % n) = self.metadata.*('foo_%d' % n) The downside is that it could be considered "visually distinctive" to the point of being line noise. Could we cut down the choice to self.[method_name] = self.metadata.[method_name] if the danger of overlooking the dot were deemed small enough, or self.*(method_name) = self.metadata.*(method_name) if the consensus was that something more noticeable was needed? (Or there's always the late arrival > > In C, "x->y" dereferences x, while in Python, "x->y" would dereference y. > > Then the syntax should obviously be "x<-y". > [insert in-Soviet-Russia-variables-dereference-you joke here] from Benji York.) Ben.

3 2

Weekly Python Patch/Bug Summary
by Kurt B. Kaiser Feb. 13, 2007

Feb. 13, 2007

Patch / Bug Summary ___________________ Patches : 417 open ( -6) / 3565 closed (+12) / 3982 total ( +6) Bugs : 960 open ( -3) / 6498 closed (+19) / 7458 total (+16) RFE : 266 open ( +6) / 251 closed ( +1) / 517 total ( +7) New / Reopened Patches ______________________ stream writing support in wave.py (2007-02-05) http://python.org/sf/1652328 opened by tom tarfile append behavior (2007-02-05) CLOSED http://python.org/sf/1652681 opened by Witten operator.c slice functions need to parse ssize_t (2007-02-07) http://python.org/sf/1654417 opened by Andy Wingo sys.excepthook shows relevant bindings. (2007-02-08) http://python.org/sf/1654974 opened by Nefarious CodeMonkey, Jr. socketmodule fails to build because missing NETLINK_DNRTMSG (2007-02-11) http://python.org/sf/1657276 opened by Aleksandr Koltsoff Add syntax for dynamic attribute access (2007-02-11) http://python.org/sf/1657573 opened by Ben North documentation for element interface (2007-02-12) http://python.org/sf/1657613 opened by Tim Mitchell Patches Closed ______________ CodeContext visibility (2006-08-15) http://python.org/sf/1540869 closed by kbk Auto-completion list placement (2006-12-23) http://python.org/sf/1621265 closed by kbk Make Python Editor Useful Without Full IDLE (2005-01-26) http://python.org/sf/1110205 closed by kbk allow using normal indent width in shell in IDLE (2005-05-06) http://python.org/sf/1196946 closed by kbk configHandler support for raw data (2007-02-01) http://python.org/sf/1650174 closed by kbk tarfile append behavior (2007-02-05) http://python.org/sf/1652681 closed by gustaebel except too broad (2006-08-15) http://python.org/sf/1540849 closed by kbk Creating dicts for dict subclasses (2006-12-14) http://python.org/sf/1615701 closed by rhettinger Fix dict and set docs, re: immutability (2006-01-05) http://python.org/sf/1397711 closed by rhettinger Remove bad PREDICT in ceval.c (2006-03-04) http://python.org/sf/1443159 closed by rhettinger make trace.py --ignore-dir work (2006-10-05) http://python.org/sf/1571379 closed by montanaro Bugfix for #847665 (XMLGenerator dies in namespace mode) (2006-04-02) http://python.org/sf/1463026 closed by loewis New / Reopened Bugs ___________________ IDLE Hung up after open script by command line... (2006-09-20) CLOSED http://python.org/sf/1562193 reopened by faramir2 Nested Objects scope problem (2007-02-05) CLOSED http://python.org/sf/1652387 reopened by kkelchev Nested Objects scope problem (2007-02-05) CLOSED http://python.org/sf/1652387 reopened by kkelchev Nested Objects scope problem (2007-02-05) CLOSED http://python.org/sf/1652387 reopened by kkelchev Nested Objects scope problem (2007-02-05) CLOSED http://python.org/sf/1652387 opened by kkelchev logging formatter %(lineno)d does not work (2007-02-06) http://python.org/sf/1652788 opened by lx_jakal Double free/corruption? (2007-02-06) http://python.org/sf/1653121 opened by Jarek Zgoda print >> f, "Hello" produces no error: normal? (2007-02-06) http://python.org/sf/1653416 opened by E.-O. Le Bigot Python misbehaves when installed in / (patch attached) (2007-02-06) http://python.org/sf/1653457 opened by Chris Webb Problems in datetime.c and typeobject.c. (2007-02-07) CLOSED http://python.org/sf/1653736 opened by ked-tao crash / abort during install (2007-02-06) CLOSED http://python.org/sf/1653753 opened by SAndreason configure does not check/warn/stop for tk/tcl (2007-02-06) CLOSED http://python.org/sf/1653757 opened by SAndreason popen - wrong order on fileobjects in tuple returned (2007-02-07) CLOSED http://python.org/sf/1653940 opened by Emil Lind Installer should split tcl/tk and tkinter install options. (2007-02-07) http://python.org/sf/1654408 opened by Ron Adam thread join() with timeout hangs on Windows 2003 x64 (2007-02-07) http://python.org/sf/1654429 opened by bentoi thirdparty extensions, --enable-shared, static linking (2007-02-08) http://python.org/sf/1655392 opened by Marien Zwart hotshot.stats.load (2004-02-19) http://python.org/sf/900092 reopened by bcannon 3.4.1 comparison methods content (2007-02-09) CLOSED http://python.org/sf/1655683 opened by Jeffrey Miller email.Generator docs contain a bad off-site link (2007-02-08) CLOSED http://python.org/sf/1655800 opened by Forest Wilkinson Typo in Docs (2007-02-09) CLOSED http://python.org/sf/1656078 opened by Thomas Guettler I think, I have found this bug on time.mktime() (2007-02-10) http://python.org/sf/1656559 opened by Sérgio Monteiro Basto shutil.copyfileobj description is incomplete (2007-02-10) http://python.org/sf/1656578 opened by Witten tarfile.TarFile fileobject use needs clarification (2007-02-10) CLOSED http://python.org/sf/1656581 opened by Witten 'Ok' key in options dialog does nothing (2007-02-11) http://python.org/sf/1657034 opened by torhu random.betavariate(-0,5, -0,5) (2007-02-12) CLOSED http://python.org/sf/1658430 opened by Alain Spineux Bugs Closed ___________ IDLE Hung up after open script by command line... (2006-09-20) http://python.org/sf/1562193 closed by kbk HP-UX11.23: module zlib missing (2007-01-31) http://python.org/sf/1648960 deleted by jabt Nested Objects scope problem (2007-02-05) http://python.org/sf/1652387 closed by kkelchev Nested Objects scope problem (2007-02-05) http://python.org/sf/1652387 closed by gbrandl Nested Objects scope problem (2007-02-05) http://python.org/sf/1652387 closed by kkelchev Nested Objects scope problem (2007-02-05) http://python.org/sf/1652387 closed by gbrandl Quitter object masked (2006-05-01) http://python.org/sf/1479785 closed by kbk Arguments tooltip wrong if def contains tuple (2003-08-20) http://python.org/sf/791968 closed by kbk subprocess fails on GetStdHandle in interactive GUI (2005-02-17) http://python.org/sf/1124861 closed by astrand Problems in datetime.c and typeobject.c. (2007-02-07) http://python.org/sf/1653736 closed by loewis crash / abort during install (2007-02-06) http://python.org/sf/1653753 closed by sandreas41 configure does not check/warn/stop for tk/tcl (2007-02-07) http://python.org/sf/1653757 closed by loewis popen - docs - wrong order on fileobjects in tuple returned (2007-02-07) http://python.org/sf/1653940 closed by gbrandl isSequenceType returns True for dict subclasses (<> 2.3) (2006-10-11) http://python.org/sf/1575169 closed by rhettinger builtin enumerate overflows (2006-06-26) http://python.org/sf/1512504 closed by rhettinger 3.4.1 comparison methods content (2007-02-09) http://python.org/sf/1655683 closed by loewis email.Generator docs contain a bad off-site link (2007-02-09) http://python.org/sf/1655800 closed by loewis --enable-shared links extensions to libpython statically (2006-11-22) http://python.org/sf/1600860 closed by loewis Typo in Docs (2007-02-09) http://python.org/sf/1656078 closed by gbrandl tarfile.TarFile fileobject use needs clarification (2007-02-10) http://python.org/sf/1656581 closed by gustaebel decimals compare badly to floats (2007-02-01) http://python.org/sf/1650053 closed by rhettinger XMLGenerator.startElementNS dies on EMPTY_NAMESPACE attribut (2003-11-23) http://python.org/sf/847665 closed by loewis random.betavariate(-0,5, -0,5) (2007-02-12) http://python.org/sf/1658430 closed by gbrandl New / Reopened RFE __________________ [PATCH] Debuggers need a way to change the locals of a frame (2007-02-07) http://python.org/sf/1654367 opened by Fabio Zadrozny dict(key,values) initializer (2007-02-10) http://python.org/sf/1656538 opened by George Sakkis Drop-Handler for Python files (2007-02-10) http://python.org/sf/1656675 opened by Marek Kubica RFE Closed __________ itertools.count wraps around after maxint (2005-10-13) http://python.org/sf/1326277 closed by rhettinger

1 0

New syntax for 'dynamic' attribute access
by Ben North Feb. 13, 2007

Feb. 13, 2007

Apologies: I overlooked a couple of replies in my summary earlier. Tim Delaney and Terry Reedy both responded in positive terms to the one-argument form and its syntax, and in negative terms to the two-argument form. Also, I missed the fact that Neil Toronto had made the same point as me when he said: > I'm not sure the "looks like a syntax error" argument holds much weight, > because any new syntax is likely to be a syntax error until the syntax > is changed. :) he also suggested: > obj.*str_expression but I'm a bit uneasy about this, although the similarity with C's dereferencing is in its favour. Also, '*' in python is already used for "and the rest" arguments in function calls. Anthony Baxter cooled off a bit on the idea too: > after thinking about it a bit, I'm still not convinced this is > something that needs shorthand syntax Maybe not, but for the cases where you do want to do dynamic attribute access, I think there is a win in readability from nested getattr and/or setattr calls. Georg Brandl: > -1 here too. I fear that this gets too indistinguishable from normal > calling syntax, I think, from the context, that this is "-1" on the syntax rather than the idea as a whole, but I could have misread Georg's message. Possibly a "-0" on the idea? Greg Ewing: > In my experience, the amount of code which truly needs > to use getattr is extremely small. Another "-0"? Gustavo Carneiro: > -1 from me. It does not solve a common problem, therefore it does not > deserve a special syntax. It's not *that* uncommon, judging by the c.600 uses in the existing library code. > Moreover, the existing syntax may be longer > to type but is far more readable. I disagree, although I can see that there might be a small time during which one is getting familiar with the new syntax. Others have voiced the opinion that it's a readability win. Tim Delaney asked in particular: > Have you checked if [the existing uses of getattr, where "getattr" in > that scope is a function argument with default value the built-in > "getattr"] are intended to bring the "getattr" name into local scope > for fast lookup, or to force a binding to the builtin "gettattr" at > compile time (two common (ab)uses of default arguments)? If they are, > they would be better served by the new syntax. They're all in Lib/codecs.py, and are of the form: class StreamRecoder: def __getattr__(self, name, getattr=getattr): """ Inherit all other methods from the underlying stream. """ return getattr(self.stream, name) Without digging deeper into that code I'm afraid I can't say precisely what is going on. Ben.

5 5