Re: [Python-Dev] properties and block statement
on 18.10.2005 19:17 Antoine Pitrou said the following:
>>What would this mythical block statement look like that would make
>>properties easier to write than the above late-binding or the subclass
>>Property recipe?
>
> I suppose something like:
>
> class C(object):
> x = prop:
> """ Yay for property x! """
> def __get__(self):
> return self._x
> def __set__(self, value):
> self._x = x
>
> and then:
>
> def prop(@block):
> return property(
> fget=block.get("__get__"),
> fset=block.get("__set__"),
> fdel=block.get("__delete__"),
> doc=block.get("__doc__", ""),
> )
>
> (where "@bargs" would be the syntax to refer to block args as a dict,
> the same way "**kargs" already exist)
>
I think there is no need for a special @syntax for this to work.
I suppose it would be possible to allow a trailing block after any
function invocation, with the effect of creating a new namespace that
gets treated as containing keyword arguments.
No additional function needed for the property example::
class C(object):
x = property():
doc = """ Yay for property x! """
def fget(self):
return self._x
def fset(self, value):
self._x = x
(This does not help with the problem of overridability though...)
A drawback is that such a "keyword block" would only be possible for the
last function invocation of a statement.
Although the block could also be inside the method invocation
parentheses? I do not think that this is a pretty sight but I'll spell
it out anyways ;-) ::
class C(object):
x = property(:
doc = """ Yay for property x! """
def fget(self):
return self._x
def fset(self, value):
self._x = x
)
--stefan
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Definining properties - a use case for class decorators?
On 10/18/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I wonder if at some point in the future Python will have to develop a
> macro syntax so that you can write
>
> Property foo:
> def get(self): return self._foo
> ...etc...
This reminds me of an idea I have kept in my drawer for a couple of years or so.
Here is my proposition: we could have the statement syntax
:
to be syntactic sugar for
= (, , )
For instance properties could be defined as follows:
def Property(name, args, dic):
return property(
dic.get('fget'), dic.get('fset'), dic.get('fdel'), dic.get('__doc__'))
Property p():
"I am a property"
def fget(self):
pass
def fset(self):
pass
def fdel(self):
pass
Another typical use case could be a dispatcher:
class Dispatcher(object):
def __init__(self, name, args, dic):
self.dic = dic
def __call__(self, action, *args, **kw):
return self.dic.get(action)(*args, **kw)
Dispatcher dispatch(action):
def do_this():
pass
def do_that():
pass
def default():
pass
dispatch('do_this')
Notice that the proposal is already implementable by abusing the class
statement:
class :
__metaclass__ =
But abusing metaclasses for this task is ugly. BTW, if the proposal was
implemented, the 'class' would become redundant and could be replaced
by 'type':
class :
<=>
type :
;)
Michele Simionato
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] properties and block statement
Stefan Rank <[EMAIL PROTECTED]> wrote in news:[EMAIL PROTECTED]:
> I think there is no need for a special @syntax for this to work.
>
> I suppose it would be possible to allow a trailing block after any
> function invocation, with the effect of creating a new namespace that
> gets treated as containing keyword arguments.
>
I suspect that without any syntax changes at all it will be possible (for
some stack crawling implementation of 'propertycontext', and assuming
nobody makes property objects immutable) to do:
class C(object):
with propertycontext() as x:
doc = """ Yay for property x! """
def fget(self):
return self._x
def fset(self, value):
self._x = value
for inheritance you would have to specify the base property:
class D(C):
with propertycontext(C.x) as x:
def fset(self, value):
self._x = value+1
propertycontext could look something like:
import sys
@contextmanager
def propertycontext(parent=None):
classframe = sys._getframe(2)
cvars = classframe.f_locals
marker = object()
keys = ('fget', 'fset', 'fdel', 'doc')
old = [cvars.get(key, marker) for key in keys]
if parent:
pvars = [getattr(parent, key) for key in
('fget', 'fset', 'fdel', '__doc__')]
else:
pvars = [None]*4
args = dict(zip(keys, pvars))
prop = property()
try:
yield prop
for key, orig in zip(keys, old):
v = cvars.get(key, marker)
if v is not orig:
args[key] = v
prop.__init__(**args)
finally:
for k,v in zip(keys,old):
if v is marker:
if k in cvars:
del cvars[k]
else:
cvars[k] = v
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Defining properties - a use case for class decorators?
Josiah Carlson wrote: >> Another option would be to allow attribute reference targets when binding >> function names: > > *shivers at the proposal* That's scary. It took me a few minutes just > to figure out what the heck that was supposed to do. Yeah, I think it's a concept with many, many more downsides than upsides. A "given" or "where" clause based solution would be far easier to read: x.get = f given: def f(): pass A given clause has its own problems though (the out-of-order execution it involves being the one which seems to raise the most hackles). Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Definining properties - a use case for class decorators?
On 10/19/05, Michele Simionato <[EMAIL PROTECTED]> wrote:
> On 10/18/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > I wonder if at some point in the future Python will have to develop a
> > macro syntax so that you can write
> >
> > Property foo:
> > def get(self): return self._foo
> > ...etc...
>
> This reminds me of an idea I have kept in my drawer for a couple of years or
> so.
> Here is my proposition: we could have the statement syntax
>
> :
>
>
> to be syntactic sugar for
>
> = (, , )
Cor. That looks like very neat/scary stuff. I'm not sure if I feel
that that is a good thing or a bad thing :-)
One question - in the expansion, "name" is used on both sides of the
assignment. Consider
something name():
This expands to
name = something(name, (), )
What should happen if name wasn't defined before? A literal
translation will result in a NameError. Maybe an expansion
name = something('name', (), )
would be better (ie, the callable gets the *name* of the target as an
argument, rather than the old value).
Also, the bit needs some clarification. I'm guessing
that it would be a suite, executed in a new, empty namespace, and the
is the resulting modified namespace (with
__builtins__ removed?)
In other words, take , and do
d = {}
exec in d
del d['__builtins__']
then is the resulting value of d.
Interesting idea...
Paul.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Defining properties - a use case for class decorators?
Phillip J. Eby wrote: > Note that a "where" or "given" statement like this could make it a > little easier to drop lambda. I think the "lambda will disappear in Py3k" concept might have been what triggered the original 'where' statement discussion. The idea was to be able to lift an arbitrary subexpression out of a function call or assignment statement without having to worry about affecting the surrounding namespace, and without distracting attention from the original statement. Basically, let a local refactoring *stay* local. The discussion wandered fairly far afield from that original goal though. One reason it fell apart was trying to answer the seemingly simple question "What would this print?": def f(): a = 1 b = 2 print 1, locals() print 3, locals() given: a = 2 c = 3 print 2, locals() print 4, locals() Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Definining properties - a use case for class decorators?
On 10/19/05, Paul Moore <[EMAIL PROTECTED]> wrote:
>
> One question - in the expansion, "name" is used on both sides of the
> assignment. Consider
>
> something name():
>
>
> This expands to
>
> name = something(name, (), )
>
> What should happen if name wasn't defined before? A literal
> translation will result in a NameError. Maybe an expansion
>
> name = something('name', (), )
>
> would be better (ie, the callable gets the *name* of the target as an
> argument, rather than the old value).
>
> Also, the bit needs some clarification. I'm guessing
> that it would be a suite, executed in a new, empty namespace, and the
> is the resulting modified namespace (with
> __builtins__ removed?)
>
> In other words, take , and do
>
> d = {}
> exec in d
> del d['__builtins__']
>
> then is the resulting value of d.
>
> Interesting idea...
>
> Paul.
>
would be a string and a dictionary.
As I said, the semantic would be exactly the same as the current
way of doing it:
class :
__metaclass__ =
I am just advocating for syntactic sugar, the functionality is already there.
Michele Simionato
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Definining properties - a use case for class decorators?
Hi Michele, > Property p(): > "I am a property" > def fget(self): > pass > def fset(self): > pass > def fdel(self): > pass In effect this is quite similar to the proposal I've done (except that you've reversed the traditional assignment order from "p = Property()" to "Property p()") If others find it interesting and Guido doesn't frown on it, maybe we should sit down and start writing a PEP ? ciao Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pythonic concurrency - offtopic
On 10/14/05, Josiah Carlson <[EMAIL PROTECTED]> wrote: > Until Microsoft adds kernel support for fork, don't expect standard > Windows Python to support it. AFAIK the NT kernel has support for fork, but the Win32 subsystem doesn't support it (you can only use it with the POSIX subsystem). -- JanC ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Early PEP draft (For Python 3000?)
(In http://mail.python.org/pipermail/python-dev/2005-October/057251.html) Eyal Lotem wrote: > Name: Attribute access for all namespaces ... > global x ; x = 1 > Replaced by: > module.x = 1 Attribute access as an option would be nice, but might be slower. Also note that one common use for a __dict__ is that you don't know what keys are available; meeting this use case with attribute access would require some extra machinery, such as an iterator over attributes. -jJ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Defining properties - a use case for class decorators?
(In http://mail.python.org/pipermail/python-dev/2005-October/057409.html,)
Nick Coghlan suggested allowing attribute references as binding targets.
>x = property("Property x (must be less than 5)")
>def x.get(instance): ...
Josiah shivered and said it was hard to tell what was even intended, and
(in http://mail.python.org/pipermail/python-dev/2005-October/057437.html)
Nick agreed that it was worse than
>x.get = f given:
>def f(): ...
Could someone explain to me why it is worse?
I understand not wanting to modify object x outside of its definition.
I understand that there is some trickiness about instancemethods
and bound variables.
But these objections seem equally strong for both forms, as well
as for the current "equivalent" of
def f(): ...
x.get = f
The first form (def x.get) at least avoids repeating (or even creating)
the temporary function name.
The justification for decorators was to solve this very problem within
a module or class. How is this different? Is it just that attributes
shouldn't be functions, and this might encourage the practice?
-jJ
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Definining properties - a use case for class decorators?
Michele Simionato wrote: > This reminds me of an idea I have kept in my drawer for a couple of years or > so. > Here is my proposition: we could have the statement syntax > > : > > > to be syntactic sugar for > > = (, , ) > [snip] > BTW, if the proposal was implemented, the 'class' would become > redundant and could be replaced by 'type': > > class : > > > <=> > > type : > Wow, that's really neat. And you save a keyword! ;-) I'd definitely like to see a PEP. STeVE -- You can wordify anything if you just verb it. --- Bucky Katt, Get Fuzzy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Defining properties - a use case for class decorators?
At 07:47 PM 10/19/2005 +1000, Nick Coghlan wrote: >Phillip J. Eby wrote: > > Note that a "where" or "given" statement like this could make it a > > little easier to drop lambda. > >I think the "lambda will disappear in Py3k" concept might have been what >triggered the original 'where' statement discussion. > >The idea was to be able to lift an arbitrary subexpression out of a function >call or assignment statement without having to worry about affecting the >surrounding namespace, and without distracting attention from the original >statement. Basically, let a local refactoring *stay* local. > >The discussion wandered fairly far afield from that original goal though. > >One reason it fell apart was trying to answer the seemingly simple question >"What would this print?": > >def f(): > a = 1 > b = 2 > print 1, locals() > print 3, locals() given: > a = 2 > c = 3 > print 2, locals() > print 4, locals() It would print "SyntaxError", because the 'given' or 'where' clause should only work on an expression or assignment statement, not print. :) In Python 3000, where print is a function, it should print the numbers in sequence, with 1+4 showing the outer locals, and 2+3 showing the inner locals (not including 'b', since b is not a local variable in the nested block). I don't see what's hard about the question, if you view the block as syntax sugar for a function definition and invocation on the right hand side of an assignment. Of course, if you assume it can occur on *any* statement (e.g. print), I suppose things could seem more hairy. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] AST branch merge status
I'm still making slow progress on this front. I have a versioned merged to the CVS head. I'd like to make a final pass over the patch. I'd upload it to SF, but I can't connect to a web server there. If anyone would like to eyeball that patch before I commit it, I can email it to you. Jeremy On 10/16/05, Jeremy Hylton <[EMAIL PROTECTED]> wrote: > Real life interfered with the planned merge tonight. I hope you'll > all excuse and wait until tomorrow night. > > Jeremy > > On 10/16/05, Jeremy Hylton <[EMAIL PROTECTED]> wrote: > > I just merged the head back to the AST branch for what I hope is the > > last time. I plan to merge the branch to the head on Sunday evening. > > I'd appreciate it if folks could hold off on making changes on the > > trunk until that merge happens. > > > > If this is a non-trivial inconvenience for anyone, go ahead with the > > changes but send me mail to make sure that I don't lose the changes > > when I do the merge. Regardless, the compiler and Grammar are off > > limits. I'll blow away any changes you make there <0.1 wink>. > > > > Jeremy > > > > > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Definining properties - a use case for class decorators?
>> : >> ... Steve> Wow, that's really neat. And you save a keyword! ;-) Two if you add a builtin called "function" (get rid of "def"). Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Definining properties - a use case for class decorators?
At 11:43 AM 10/19/2005 -0500, [EMAIL PROTECTED] wrote: > >> : > >> > ... > > Steve> Wow, that's really neat. And you save a keyword! ;-) > >Two if you add a builtin called "function" (get rid of "def"). Not unless the tuple is passed in as an abstract syntax tree or something. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pythonic concurrency - offtopic
JanC <[EMAIL PROTECTED]> wrote: > > On 10/14/05, Josiah Carlson <[EMAIL PROTECTED]> wrote: > > Until Microsoft adds kernel support for fork, don't expect standard > > Windows Python to support it. > > AFAIK the NT kernel has support for fork, but the Win32 subsystem > doesn't support it (you can only use it with the POSIX subsystem). Good to know. But if I remember subsystem semantics properly, you can use a single subsystem at any time, so if one wanted to use fork from the POSIX subsystem, one would necessarily have to massage the rest of Python into NT's POSIX subsystem, which could be a problem because NT/2K's posix subsystem doesn't support network interfaces, memory mapped files, ... http://msdn2.microsoft.com/en-us/library/y23kc048 Based on this page: http://www.cygwin.com/cygwin-ug-net/highlights.html ...it does seem possible to borrow cygwin's implementation of fork for use on win32, but I would guess that most people would be disappointed with its performance in comparison to unix fork. - Josiah ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Early PEP draft (For Python 3000?)
Jim Jewett <[EMAIL PROTECTED]> wrote: > > (In http://mail.python.org/pipermail/python-dev/2005-October/057251.html) > Eyal Lotem wrote: > > > Name: Attribute access for all namespaces ... > > > global x ; x = 1 > > Replaced by: > > module.x = 1 > > Attribute access as an option would be nice, but might be slower. > > Also note that one common use for a __dict__ is that you don't > know what keys are available; meeting this use case with > attribute access would require some extra machinery, such as > an iterator over attributes. This particular use case is easily handled. Put the following once at the top of the module... module = __import__(__name__) Then one can access (though perhaps not quickly) the module-level variables for that module. To access attributes, it is a quick scan through module.__dict__, dir(), or vars(). Want to make that automatic? Write an import hook that puts a reference to the module in the module itself on load/reload. - Josiah ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Early PEP draft (For Python 3000?)
Calvin Spealman <[EMAIL PROTECTED]> wrote: > On 10/16/05, Josiah Carlson <[EMAIL PROTECTED]> wrote: [snip] > > What I'm saying is that whether or not you can modify the contents of > > stack frames via tricks, you shouldn't. Why? Because as I said, if the > > writer wanted you to be hacking around with a namespace, they should > > have passed you a shared namespace. > > > > From what I understand, there are very few (good) reasons why a user > > should muck with stack frames, among them because it is quite convenient > > to write custom traceback printers (like web CGI, etc.), and if one is > > tricky, limit the callers of a function/method to those "allowable". > > There may be other good reasons, but until you offer a use-case that is > > compelling for reasons why it should be easier to access and/or modify > > the contents of stack frames, I'm going to remain at -1000. > > I think I was wording this badly. I meant to suggest this as a way to > define nested functions (or classes?) and probably access names from > various levels of scope. In this way, a nested function would be able > to say "bind the name 'a' in the namespace in which I am defined to > this object", thus offering more fine grained approached than the > current global keyword. I know there has been talk of this issue > before, but I don't know if it works with or against anything said for > this previously. And as I have said, if you want people to modify a namespace, you should be creating a namespace and passing it around. If you want people to have access to some embedded definition, then you expose it. If some writer of some module/class/whatever decides that they want to embed some thing that you think should have been exposed to the outside world, then complain the the writer that they have designed it poorly. Take a walk though the standard library. You will likely note the rarity of embedded function/class definitions. In those cases where they are used, it is generally for a good reason. You will also note the general rarity of stack frame access. Prior to the cycle-removing garbage collector, this was because accessing stack frames could result in memory leaks of stack frames. You may also note the rarity of modification of stack frame contents (I'm not sure there are any), which can be quite dangerous. Right now it is difficult to go and access the value of a local 'x' three callers above you in the stack frame. I think this is great, working as intended in fact. Being able to read and/or modify arbitrary stack frame contents, and/or being able to pass those stack frames around: foo(frame[3]), is quite dangerous. I'm still -1000. - Josiah ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Definining properties - a use case for class decorators?
> "Phillip" == Phillip J Eby <[EMAIL PROTECTED]> writes: Phillip> At 11:43 AM 10/19/2005 -0500, [EMAIL PROTECTED] wrote: >> >> : >> >> >> ... >> Steve> Wow, that's really neat. And you save a keyword! ;-) >> >> Two if you add a builtin called "function" (get rid of "def"). Phillip> Not unless the tuple is passed in as an abstract syntax tree or Phillip> something. Hmmm... Maybe I misread something then. I saw (I think) that type Foo (base): def __init__(self): pass would be equivalent to class Foo (base): def __init__(self): pass and thought that function myfunc(arg1, arg2): pass would be equivalent to def myfunc(arg1, arg2): pass where "function" a builtin that when called returns a new function. Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Definining properties - a use case for class decorators?
[EMAIL PROTECTED] wrote: > > > "Phillip" == Phillip J Eby <[EMAIL PROTECTED]> writes: > > Phillip> At 11:43 AM 10/19/2005 -0500, [EMAIL PROTECTED] wrote: > >> >> : > >> >> > >> ... > >> > Steve> Wow, that's really neat. And you save a keyword! ;-) > >> > >> Two if you add a builtin called "function" (get rid of "def"). > > Phillip> Not unless the tuple is passed in as an abstract syntax tree or > Phillip> something. > > Hmmm... Maybe I misread something then. I saw (I think) that > > type Foo (base): > def __init__(self): > pass > > would be equivalent to > > class Foo (base): > def __init__(self): > pass > > and thought that > > function myfunc(arg1, arg2): > pass > > would be equivalent to > > def myfunc(arg1, arg2): > pass > > where "function" a builtin that when called returns a new function. For it to work in classes, it would need to execute the body of the class, which is precisely why it can't work with functions. - Josiah ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Defining properties - a use case for class decorators?
Jim Jewett <[EMAIL PROTECTED]> wrote:
> (In http://mail.python.org/pipermail/python-dev/2005-October/057409.html,)
> Nick Coghlan suggested allowing attribute references as binding targets.
>
> >x = property("Property x (must be less than 5)")
>
> >def x.get(instance): ...
>
> Josiah shivered and said it was hard to tell what was even intended, and
> (in http://mail.python.org/pipermail/python-dev/2005-October/057437.html)
> Nick agreed that it was worse than
>
> >x.get = f given:
> >def f(): ...
>
> Could someone explain to me why it is worse?
def x.get(...): ...
Seems to imply that one is defining a method on x. This is not the case.
It is also confused by the x.get(instance) terminology that I doubt has
ever seen light of day in production code. Instance of what? Instance
of x? The class? ...
I'm personally averse to the 'given:' syntax, if only because under
certain situations, it can be reasonably emulated.
> I understand not wanting to modify object x outside of its definition.
>
> I understand that there is some trickiness about instancemethods
> and bound variables.
>
> But these objections seem equally strong for both forms, as well
> as for the current "equivalent" of
>
> def f(): ...
> x.get = f
>
> The first form (def x.get) at least avoids repeating (or even creating)
> the temporary function name.
>
> The justification for decorators was to solve this very problem within
> a module or class. How is this different? Is it just that attributes
> shouldn't be functions, and this might encourage the practice?
Many will agree that there is a problem with how properties are defined.
There are many proposed solutions, some of which use decorators, custom
subclasses, metaclasses, etc.
I have a problem with it because from the description, you could use...
def x.y.z.a.b.c.foobarbaz(...):
...
...and it woud be unclear to the reader or writer what the hell
x.y.z.a.b.c is (class, instance, module), which can come up if the
definition/import of x is far enough away from the definition of
x. . Again, ick.
- Josiah
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Definining properties - a use case for class decorators?
At 12:46 PM 10/19/2005 -0700, Josiah Carlson wrote: >[EMAIL PROTECTED] wrote: > > > "Phillip" == Phillip J Eby <[EMAIL PROTECTED]> writes: > > > > Phillip> Not unless the tuple is passed in as an abstract syntax > tree or > > Phillip> something. > > > > Hmmm... Maybe I misread something then. I saw (I think) that > > > > type Foo (base): > > def __init__(self): > > pass > > > > would be equivalent to > > > > class Foo (base): > > def __init__(self): > > pass > > > > and thought that > > > > function myfunc(arg1, arg2): > > pass > > > > would be equivalent to > > > > def myfunc(arg1, arg2): > > pass > > > > where "function" a builtin that when called returns a new function. > >For it to work in classes, it would need to execute the body of the >class, which is precisely why it can't work with functions. Not only that, but the '(arg1, arg2)' for classes is a tuple of *values*, but for functions it's just a function signature, not an expression! Which is why this would effectively have to be a macro facility. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Definining properties - a use case for classdecorators?
Guido van Rossum wrote:
> OK, so how's this for a radical proposal.
>
> Let's change the property built-in so that its arguments can be either
> functions or strings (or None). If they are functions or None, it
> behaves exactly like it always has.
>
> If an argument is a string, it should be a method name, and the method
> is looked up by that name each time the property is used. Because this
> is late binding, it can be put before the method definitions, and a
> subclass can override the methods. Example:
>
> class C:
>
> foo = property('getFoo', 'setFoo', None, 'the foo property')
>
> def getFoo(self):
> return self._foo
>
> def setFoo(self, foo):
> self._foo = foo
>
> What do you think?
+1 from here.
> If you can think of a solution that looks better than mine, you're a genius.
letting "class" inject a slightly magic "self" variable into the class
namespace ?
class C:
foo = property(self.getFoo, self.setFoo, None, 'the foo property')
def getFoo(self):
return self._foo
def setFoo(self, foo):
self._foo = foo
(figuring out exactly what "self" should be is left as an exercise etc)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Definining properties - a use case for classdecorators?
On 10/19/05, Fredrik Lundh <[EMAIL PROTECTED]> wrote: > letting "class" inject a slightly magic "self" variable into the class > namespace ? > > class C: > > foo = property(self.getFoo, self.setFoo, None, 'the foo property') > > def getFoo(self): > return self._foo > > def setFoo(self, foo): > self._foo = foo > > (figuring out exactly what "self" should be is left as an exercise etc) It's magical enough to deserve to be called __self__. But even so: I've seen proposals like this a few times in other contexts. I may even have endorsed the idea at one time. The goal is always the same: forcing delayed evaluation of a getattr operation without using either a string literal or a lambda. But I find it quite a bit too magical, for all values of xyzzy, that xyzzy.foo would return a function of one argument that, when called with an argument x, returns x.foo. Even if it's easy enough to write the solution (*), that sentence describing it gives me goosebumps. And the logical consequence, xyzzy.foo(x), which is an obfuscated way to write x.foo, makes me nervous. (*) Here's the solution: class XYZZY(object): def __getattr__(self, name): return lambda arg: getattr(arg, name) xyzzy = XYZZY() -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] enumerate with a start index
Hi Just wondering, would anyone think of it as a good idea if the enumerate() builtin could accept a "start" argument? I've run across a few cases where this would have been useful. It seems generic enough too. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Coroutines, generators, function calling
Andrew Koenig wrote: >> Sure, that would work. Or even this, if the scheduler would >>automatically recognize generator objects being yielded and so would run >>the the nested coroutine until finish: > > > This idea has been discussed before. I think the problem with recognizing > generators as the subject of "yield" statements is that then you can't yield > a generator even if you want to. > > The best syntax I can think of without adding a new keyword looks like this: > > yield from x > > which would be equivalent to > > for i in x: > yield i My eyes really like the syntax, but I wonder about it's usefulness. In rdflib, particularly here: http://svn.rdflib.net/trunk/rdflib/backends/IOMemory.py We yield values from inside for loops all over the place, but the yielded value is very rarely just the index value (only 1 of 14 yields) , but something calculated from the index value, so the new syntax would not be useful, unless it was something that provided access to the index item as a variable, like: yield foo(i) for i in x which barely saves you anything (a colon, a newline, and an indent). (hey wait, isn't that a generator comprehension? Haven't really encountered those yet). Of course rdflib could be the minority case and most folks who yield in loops are yielding only the index value directly. off to read the generator comprehension docs... -Michel ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] enumerate with a start index
Martin Blais wrote: > Hi > > Just wondering, would anyone think of it as a good idea if the > enumerate() builtin could accept a "start" argument? I've run across > a few cases where this would have been useful. It seems generic > enough too. +1, but something more useful might be a a cross between enumerate a zip, where you pass N iterables and it yields N-tuples. Then you could do something like: zipyield(range(10, 20), mygenerator()) and it would be like you wanted for enumerate, but starting from 10 in this case. -Michel > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Coroutines, generators, function calling
> We yield values from inside for loops all over the place, but the > yielded value is very rarely just the index value (only 1 of 14 yields) > , but something calculated from the index value, so the new syntax would > not be useful, unless it was something that provided access to the index > item as a variable, like: > > yield foo(i) for i in x > > which barely saves you anything (a colon, a newline, and an indent). > (hey wait, isn't that a generator comprehension? Here's a use case: def preorder(tree): if tree: yield tree yield from preorder(tree.left) yield from preorder(tree.right) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] enumerate with a start index
Michel Pelletier <[EMAIL PROTECTED]> wrote: > > Martin Blais wrote: > > Hi > > > > Just wondering, would anyone think of it as a good idea if the > > enumerate() builtin could accept a "start" argument? I've run across > > a few cases where this would have been useful. It seems generic > > enough too. > > +1, but something more useful might be a a cross between enumerate a > zip, where you pass N iterables and it yields N-tuples. Then you could > do something like: > > zipyield(range(10, 20), mygenerator()) > > and it would be like you wanted for enumerate, but starting from 10 in > this case. All of this already exists. from itertools import izip, count for i,j in izip(count(start), iterable): ... Read your standard library. - Josiah ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Pre-PEP: Task-local variables
This is still rather rough, but I figured it's easier to let everybody fill in the remaining gaps by arguments than it is for me to pick a position I like and try to convince everybody else that it's right. :) Your feedback is requested and welcome. PEP: XXX Title: Task-local Variables Author: Phillip J. Eby <[EMAIL PROTECTED]> Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 19-Oct-2005 Python-Version: 2.5 Post-History: 19-Oct-2005 Abstract Many Python modules provide some kind of global or thread-local state, which is relatively easy to implement. With the acceptance of PEP 342, however, co-routines will become more common, and it will be desirable in many cases to treat each as its own logical thread of execution. So, many kinds of state that might now be kept as a thread-specific variable (such as the "current transaction" in ZODB or the "current database connection" in SQLObject) will not work with coroutines. This PEP proposes a simple mechanism akin to thread-local variables, but which will make it easy and efficient for co-routine schedulers to switch state between tasks. The mechanism is proposed for the standard library because its usefulness is dependent on its adoption by standard library modules, such as the ``decimal`` module. The proposed features can be implemented as pure Python code, and as such are suitable for use by other Python implementations (including older versions of Python, if desired). Motivation == PEP 343's new "with" statement makes it very attractive to temporarily alter some aspect of system state, and then restore it, using a context manager. Many of PEP 343's examples are of this nature, whether they are temporarily redirecting ``sys.stdout``, or temporarily altering decimal precision. But when this attractive feature is combined with PEP 342-style co-routines, a new challenge emerges. Consider this code, which may misbehave if run as a co-routine:: with opening(filename, "w") as f: with redirecting_stdout(f): print "Hello world" yield pause(5) print "Goodbye world" Problems can arise from this code in two ways. First, the redirection of output "leaks out" to other coroutines during the pause. Second, when this coroutine is finished, it resets stdout to whatever it was at the beginning of the coroutine, regardless of what another co-routine might have been using. Similar issues can be demonstrated using the decimal context, transactions, database connections, etc., which are all likely to be popular contexts for the "with" statement. However, if these new context managers are written to use global or thread-local state, coroutines will be locked out of the market, so to speak. Therefore, this PEP proposes to provide and promote a standard way of managing per-execution-context state, such that coroutine schedulers can keep each coroutine's state distinct. If this mechanism is then used by library modules (such as ``decimal``) to maintain their current state, then they will be transparently compatible with co-routines as well as threaded and threadless code. (Note that for Python 2.x versions, backward compatibility requires that we continue to allow direct reassignment to e.g. ``sys.stdout``. So, it will still of course be possible to write code that will interoperate poorly with co-routines. But for Python 3.x it seems worth considering making some of the ``sys`` module's contents into task-local variables rather than assignment targets.) Specification = This PEP proposes to offer a standard library module called ``context``, with the following core contents: Variable A class that allows creation of a context variable (see below). snapshot() Returns a snapshot of the current execution context. swap(ctx) Set the current context to `ctx`, returning a snapshot of the current context. The basic idea here is that a co-routine scheduler can switch between tasks by doing something like:: last_coroutine.state = context.swap(next_coroutine.state) Or perhaps more like:: # ... execute coroutine iteration last_coroutine.state = context.snapshot() # ... figure out what routine to run next context.swap(next_coroutine.state) Each ``context.Variable`` stores and retrieves its state using the current execution context, which is thread-specific. (Thus, each thread may execute any number of concurrent tasks, although most practical systems today have only one thread that executes coroutines, the other threads being reserved for operations that would otherwise block co-routine execution. Nonetheless, such other threads will often still require context variables of their own.) Context Variable Objects A context variable object provides the following methods: get(default=None) Return the value of the variable in the current execution context, or `d
Re: [Python-Dev] Pre-PEP: Task-local variables
"Phillip J. Eby" <[EMAIL PROTECTED]> wrote: > For efficiency's sake, however, CPython could simply store the > execution context dictionary in its "thread state" structure, creating > an empty dictionary at thread initialization time. This would make it > somewhat easier to offer a C API for access to context variables, > especially where efficiency of access is desirable. But the proposal > does not depend on this. What about a situation in which corutines are handled by multiple threads? Any time a corutine passed from one thread to another, it would lose its state. While I agree with the obvious "don't do that" response, I don't believe that the proposal will actually go very far in preventing real problems when using context managers and generators or corutines. Why? How much task state is going to be monitored/saved? Just sys? Perhaps sys and the module in which a corutine was defined? Eventually you will have someone who says, "I need Python to be saving and restoring the state of the entire interpreter so that I can have a per-user execution environment that cannot be corrupted by another user." But how much farther out is that? - Josiah ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pre-PEP: Task-local variables
At 07:30 PM 10/19/2005 -0700, Josiah Carlson wrote: >What about a situation in which corutines are handled by multiple >threads? Any time a corutine passed from one thread to another, it >would lose its state. It's the responsibility of a coroutine scheduler to take a snapshot() when a task is suspended, and to swap() it in when resumed. So it doesn't matter that you've changed what thread you're running in, as long as you keep the context with the coroutine that "owns" it. >While I agree with the obvious "don't do that" response, I don't believe >that the proposal will actually go very far in preventing real problems >when using context managers and generators or corutines. Why? How much >task state is going to be monitored/saved? Just sys? Perhaps sys and >the module in which a corutine was defined? As I mentioned in the PEP, I don't think that we would bother having Python-defined variables be context-specific until Python 3.0. This is mainly intended for the kinds of things described in the proposal: ZODB current transaction, current database connection, decimal context, etc. Basically, anything that you'd have a thread-local for now, and indeed most anything that you'd use a global variable and 'with:' for. > Eventually you will have >someone who says, "I need Python to be saving and restoring the state of >the entire interpreter so that I can have a per-user execution >environment that cannot be corrupted by another user." But how much >farther out is that? I don't see how that's even related. This is simply a replacement for thread-local variables that allows you to also be compatible with "lightweight" (coroutine-based) threads. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pre-PEP: Task-local variables
"Phillip J. Eby" <[EMAIL PROTECTED]> wrote: > It's the responsibility of a coroutine scheduler to take a snapshot() when > a task is suspended, and to swap() it in when resumed. So it doesn't > matter that you've changed what thread you're running in, as long as you > keep the context with the coroutine that "owns" it. > > As I mentioned in the PEP, I don't think that we would bother having > Python-defined variables be context-specific until Python 3.0. This is > mainly intended for the kinds of things described in the proposal: ZODB > current transaction, current database connection, decimal context, > etc. Basically, anything that you'd have a thread-local for now, and > indeed most anything that you'd use a global variable and 'with:' for. > > I don't see how that's even related. This is simply a replacement for > thread-local variables that allows you to also be compatible with > "lightweight" (coroutine-based) threads. I just re-read the proposal with your clarifications in mind. Looks good. +1 - Josiah ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
