Mailman 3 February 2007 - Python-Dev

Re: [Python-Dev] New syntax for 'dynamic' attribute access
by Delaney, Timothy (Tim) Feb. 12, 2007

Feb. 12, 2007

Benji York wrote: > Collin Winter wrote: >> On 2/12/07, Brett Cannon <brett(a)python.org> wrote: >>> I actually kind of like that. The connection to pointer indirection >>> meshes well with the idea of indirectly figuring out what attribute >>> to access at runtime. >> >> There's a connection, but I'd say it's the wrong one. In C, "x->y" >> dereferences x, while in Python, "x->y" would dereference y. That's >> just begging for trouble. > > Then the syntax should obviously be "x<-y". I'd actually gone through this process myself, and concluded that I wouldn't be happy with either. "x->y: is currently invalid syntax, but has *very* strong connotations from C. Whilst I'm happy to consider things that deviate from other languages' use, this one is just too strong. "x<-y" is currently valid syntax, and gives (to mee) the wrong impression that y is that thing that's going to be modified. Of all the proposals I've seen, I think I like "x.{y}" best. The use of {} has connotations of interpolation and they're the only braces that currently don't have meaning as x{} (and probably never will). I do worry that giving syntax to getattr/setattr/delattr will encourage the use of dynamic attributes, when they are a fairly advanced feature. OTOH, when you're using advanced features, you want the code to be as readable as possible, and I think this will improve readability over using getattr/setattr/delattr. So I think I've changed to +0.5. Tim Delaney

1 0

safety of Py_CLEAR and self
by Jeremy Hylton Feb. 12, 2007

Feb. 12, 2007

I was wondering today how I could convince myself that a sequence of Py_CLEAR() calls in a tp_clear function was safe. Take for example a really trivial sequence of code on frame_clear(): Py_CLEAR(f->f_exc_type); Py_CLEAR(f->f_exc_value); Py_CLEAR(f->f_exc_traceback); Py_CLEAR(f->f_trace); We use Py_CLEAR() so that multiple calls to frame_clear() are safe. The first time this runs it sets exc_type to NULL before calling DECREF. This guarantees that a subsequent frame_clear() or frame_dealloc() won't attempt to DECREF it a second time. I think I understand why that's desireable and why it works. The primary risk is that via DECREF we may execute an arbitrary amount of Python code via weakref callbacks, finalizers, and code in other threads that gets resumed while the callbacks and finalizers are running. My question, specifically, then: Why it is safe to assume that f doesn't point to trash after a particular call to Py_CLEAR()? Any particular call to Py_CLEAR() could break the cycle that the object is involved in an lead to a call to frame_dealloc(). The frame could get returned to an obmalloc pool, returned to the OS, or just re-used by another object before we get back to Py_CLEAR(). It seems like such behavior would be exceedingly unlikely, but I can't convince myself that it is impossible. Which is it: improbable or impossible? If it is only improbable, should we figure out how to write code that is safe against such an improbable event? Jeremy

3 3

Does Python/Python-ast.c need to be checked in?
by skip＠pobox.com Feb. 12, 2007

Feb. 12, 2007

Someone checked in Parser/Python.asdl. After rebuilding Subversion tells me that Python/Python-ast.c has been modified. I assume the two are related. Did whoever checked in the former need to check in the latter (and maybe add a note to Misc/NEWS)? Skip

5 10

Re: [Python-Dev] New syntax for 'dynamic' attribute access
by Delaney, Timothy (Tim) Feb. 12, 2007

Feb. 12, 2007

Ben North wrote: > c.5 uses which would have to stay as "getattr" because they > are calls of a variable named "getattr" whose default > value is the builtin "getattr"; Have you checked if these 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. Overall, +1 on obj.(attr_name) -0 on obj.(attr_name, default_value) Tim Delaney

1 0

Trial balloon: microthreads library in stdlib
by dustin＠v.igoro.us Feb. 11, 2007

Feb. 11, 2007

Mostly for my own curiosity, I'm working on a PEP-342-based microthreading library with a similar api to threads and threading (coalesced into a single module). It uses coroutines and a trampoline scheduler, and provides basic async wrappers for common IO operations. It's not a framework/environment like Twisted or Kamaelia -- it's just a microthreading library with some solid primitives. My thinking is that this would be the "next level" for apps which currently use asyncore. I won't go into a lot of detail on the module, because (a) it's not even nearly done and (b) my question is higher-level than that. Is there any interest in including a simple microthreading module in Python's standard library? If this sounds like a terrible idea, let fly the n00b-seeking missiles. If it sounds better than terrible, I'll keep working and post a reasonable prototype soon (a PEP would also be in order at some point, correct?). Dustin

4 4

Why is nb_inplace_power ternary?
by Jim Jewett Feb. 10, 2007

Feb. 10, 2007

Greg Ewing schrieb: > Might we want to add an in-place version of the 3-arg > pow() function one day? If so, leaving the third argument > there could be useful. "Martin v. Löwis" martin at v.loewis.de replied: > What could the syntax for that be? > Instead of writing > x = pow(x, n, 10) Either x**= n % 10 # The **= changes the parse context, so that % is no longer # immediately evaluated or x**= (n, 10) # exponentiation to a tuple isn't currently defined, and it # does show that both arguments are part of the power # expression -- but I'm not sure it needs a 3-argument form # instead of just unpacking the tuple itself. -jJ

2 1

Re: [Python-Dev] Why is nb_inplace_power ternary?
by python＠rcn.com Feb. 9, 2007

Feb. 9, 2007

[MvL] >>> So here is my proposed change: >>> >>> 1. For 2.5.1, rewrite slot_nb_inplace_power to raise an exception >>> if the third argument is not None, and then invoke __ipow__ with only one argument. Why would you change Py2.5? There is no bug here. Raymond

3 3

Changing a value in a frame (for a debugger)
by Fabio Zadrozny Feb. 7, 2007

Feb. 7, 2007

Hi All, I'm currently trying to change the value for a variable in the debugger using: frame = findFrame(thread_id, frame_id) exec '%s=%s' % (attr, expression) in frame.f_globals, frame.f_locals it works well when the frame for the change is the topmost frame, but fails otherwise... I found some references speaking about some issue with PyFrame_FastToLocals which made it appear like this was not possible to do... so, basically, is there some way to make this work from python (changing a variable having a given frame) or not? Thanks, Fabio

4 6

Re: [Python-Dev] Changing a value in a frame (for a debugger)
by Phillip J. Eby Feb. 7, 2007

Feb. 7, 2007

At 08:11 AM 2/7/2007 -0200, Fabio Zadrozny wrote: >Would it be ok to add a feature request for that? I initially thought it >was completely read-only, but I find it strange that it affects the >topmost frame correctly (so, it seems that even though I get a copy, when >I alter that copy on the topmost frame it affects it correctly)... anyone >has a clue why that happens? The code that calls the debugging hook calls PyFrame_FastToLocals() before invoking the debugger, and then PyFrame_LocalsToFast() afterwards. Thus, the interrupted frame can have its locals modified, but no others can. In order for this to work on other frames, you'd have to explicitly call PyFrame_FastToLocals(frame, 1) -- which you could probably do with ctypes or a C extension.

1 0

Shortcut Notation for Chaining Method Calls
by Michael O'Keefe Feb. 5, 2007

Feb. 5, 2007

I had an idea on some new functionality I'd like to see offered in the python object class. I did some searching on the list but I wouldn't doubt that someone has proposed something like this before as chaining method calls seems like something folks would want to do. Specifically, I'd like to see a built-in shorthand to allow me to chain method calls even when a method call does not explicity return a reference to the instance of the object (self). I have an example below. In this example, someFunc represents the current way of dealing with calling methods that modify an object's state with no return value (if you found yourself doing this a lot, you might just write a wrapper function). The function explicitReturn shows how things might go if python implicitly returned self when no other return value was specified (similar to Ruby). I'm not proposing this, but have included it for completeness. The final two functions give some options for what I'm proposing as a shorthand (ideally included in class object but used in a subclass of class list in this example). The first of the two functions, newFunc01, defines the method "_". I'm not crazy about this because it's not very descriptive but it is the shortest way I could think of. The second possible shorthand is in, newFunc02, which defines the method "self_". I didn't want the method to be too long but my intent was "apply the given method and return self". I used the trailing underscore so as not to confuse with the self instance variable. I'm sure there are other ways to do this as well but what do people think? Has something like this come up before? def someFunc(): a = list([8,9,7,1]) a.sort() a.reverse() a.pop(0) return a def explicitReturn(): a = ExplicitReturnList([8,9,7,1]).sort().reverse() a.pop(0) return a def newFunc01(): return NewList([8,9,7,1])._('sort')._('reverse')._('pop',0) def newFunc02(): return NewList([8,9,7,1]).self_('sort').self_('reverse').self_('pop',0) class NewList(list): def __init__(self,*args,**kwargs): list.__init__(self,*args,**kwargs) def _(self,methodName,*args,**kwargs): method = getattr(self,methodName) method(*args,**kwargs) return self def self_(self,methodName,*args,**kwargs): method = getattr(self,methodName) method(*args,**kwargs) return self class ExplicitReturnList(list): def __init__(self,*args,**kwargs): list.__init__(self,*args,**kwargs) def sort(self): super(ExplicitReturnList,self).sort() return self def reverse(self): super(ExplicitReturnList,self).reverse() return self print someFunc() # returns [8, 7, 1] print explicitReturn() # returns [8, 7, 1] print newFunc01() # returns [8, 7, 1] print newFunc02() # returns [8, 7, 1]

9 9