[Python-Dev] __autoinit__ (Was: Proposal: reducing self.x=x; self.y=y; self.z=z boilerplate code)
Hello python-list,
As I Understood, semantic may be next:
def qwerty(a,a.i,b,b.i,f.j):
pass
Would work like:
def qwerty(anonymous1,anonymous2,anonymous3,anonymous4,anonymous5):
(a,a.i,b,b.i,f.j)=(anonymous1,anonymous2,anonymous3,anonymous4,anonymous5)
del anonymous1
del anonymous2
del anonymous3
del anonymous4
del anonymous5
If so then I like it, because it more explicit than anything other
and it is working right now. I just tryed:
>>> class Stub:
... pass
>>> def qwer(a1,a2,a3,a4,a5):
... (a,a.i,b,b.i,f['i'])=(a1,a2,a3,a4,a5)
... del a1
... del a2
... del a3
... del a4
... del a5
... print (a,a.i,b,b.i,f['i'])
>>> f={}
>>> qwer(Stub(),1,Stub(),2,3)
(<__main__.Stub instance at 0x00C49530>, 1, <__main__.Stub instance at
0x00C498C8>, 2, 3)
So there are not too much for implement.
Another question - named arguments. How I can assign to them?
May be so:
f={}
def qwerty(a,a.i,f['i']):
print (a,a.i,f['i'])
qwerty(f['i']=3,a=Stub(),a.i=4) - ?
and for __init__:
class MyClass:
def __init__(self,self.i,self.j,self.k):
pass
MyObject = MyClass(self.i=1,self.j=2,self.k=3)
?
or may be there can be an aliase syntax?
class MyClass:
def __init__(self, self.i by i,self.j by j, self.k by k):
pass
MyObject = MyClass(i=1,j=2,k=3)
--
Sokolov Yura
[EMAIL PROTECTED]
___
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] PEP-343 - Context Managment variant
I know I came after the battle. And I have just another sight on context
managment.
Simple Context Managment may look in Python 2.4.1 like this:
Synhronized example:
def Synhronised(lock,func):
lock.acquire()
try:
func()
finally:
lock.release()
lock=Lock()
def Some():
local_var1=x
local_var2=y
local_var3=Z
def Work():
global local_var3
local_var3=Here_I_work(local_var1,local_var2,local_var3)
Synhronised(lock,Work)
return asd(local_var3)
FileOpenClose Example:
def FileOpenClose(name,mode,func):
f=file(name,mode)
try:
func(f)
finally:
f.close()
def Another(name):
local_var1=x
local_var2=y
local_var3=None
def Work(f):
global local_var3
local_var3=[[x,y(i)] for i in f]
FileOpenClose(name,'r',Work)
return local_var3
It was complicated because :
1. We must declare closure (local function) before using it
2. We must declare local vars, to which we wish assign in "global" statement
3. We cannot create variable local to outter function in closure, so we
must create it before
and declare in global
So one can say: "that is because there're no block lambda". (I can be wrong)
I think it is possible to introduce block-object in analogy to lambda-object
(and function-object)
It's difference from function:
it has no true self local variables, all global(free) and local variables it
steels from outter
scope. And all local vars, introduced in block are really introduced in
outter scope
(i think, during parse state). So its global dicts and local dicts are realy
corresponding dicts
of outter scope. (Excuse my english)
So, may be it would be faster than function call. I don't know.
Syntax can be following:
lock=Lock()
def Some():
local_var1=x
local_var2=y
local_var3=Z
Synhronised(lock,block)
local_var3=Here_I_work(local_var1,local_var2,local_var3)
return asd(local_var3)
def Another(name):
local_var1=x
local_var2=y
FileOpenClose(name,'r',block{f})
local_var3=[[x,y(i)] for i in f]
return local_var3
And here is sample of returning value:
def Foo(context,proc):
context.enter()
try:
res=proc(context.x,context.y)*2
except Exception,Err:
context.throw(Err)
finally:
context.exit()
return res
...
context=MyContext()
...
def Bar():
result=Foo(context,block{x,y})
continue x+y
return result
It's idea was token from Ruby. But I think, good idea is good whatever it came
from.
It can be not Pythonic.
___
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] Summary of "dynamic attribute access" discussion
On 2/13/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Anthony Baxter schrieb: > >> and the "wrapper class" idea of Nick Coghlan: > >>attrview(obj)[foo] > > > > This also appeals - partly because it's not magic syntax > > It's so easy people can include in their code for backwards > compatibility; in Python 2.6, it could be a highly-efficient > builtin (you still pay for the lookup of the name 'attrs', > of course). attrview() (or whatever name it ultimately gets) feels Pythonic to me. It's a lot cleaner than getattr/setattr/hasattr/delattr. It's perhaps not entirely as pretty as .[], but it's close enough that I question whether adding new syntax is worth it. The easy backwards compatibility is the huge feature here, but there are a couple of others. Because attrview() can be made to support much of the dict interface, it can clearly express things the .[] syntax cannot, like: * attrview(obj).get(key, default) * attrview(obj).setdefault(key, []).append(x) Also, because attrview objects implement a mapping, they can be used in interesting ways in places that expect a mapping. (The locals parameter to eval() comes to mind, but I'm sure there would be many other good uses we won't be able to predict here.) Guido van Rossum wrote: > Also, Nick's examples show (conceptual) > aliasing problems: after "x = attrview(y)", both x and y refer to the > same object, but use a different notation to access it. Of course there is an aliasing here, but it's being explicitly constructed, and so I fail to see what is problematic about it. You propose in PEP 3106 that Py3k's items/keys/values dictionary methods should return wrapper objects, which provide a different interface to the same data, and which can be used to mutate the underlying objects. Aren't the set of ailasing concerns in these two cases exactly the same? +1 for attrview(), +0 for .[] syntax. (-1 for .[] if attrview() is accepted.) Greg F ___ 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] Wrapping up 'dynamic attribute' discussion
On 2/15/07, Anthony Baxter <[EMAIL PROTECTED]> wrote: > On Friday 16 February 2007 09:08, Ben North wrote: > > The wrapper class idea was left > > open as a possibility for a future PEP. > > A good first step would be to contribute something like this to the > Python Cookbook, if it isn't already there. I could not find such a class in the cookbook. (That's not to say there's not one there that I missed.) Because I think attrview() should happen, I submitted a recipe to the Python Cookbook. While it awaits editor approval, I have it posted at http://www.verylowsodium.com/attrview.py . One possibly controversial design choice here: since there is no guaranteed way to enumerate attributes in the face of __getattr__ and friends, my version of attrview() does not provide iteration or any other operation that assumes object attributes can be enumerated. Therefore, it technically does not implement a mapping. Once Python grows a __dir__ special method, it's possible I could be convinced this is the wrong choice, but I'm not sure of that. Greg F ___ 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
