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
--- Mike Meyer [EMAIL PROTECTED] wrote:
Remember that what we're suggesting is just syntactic sugar.
BTW: That's true for all high-level language constructs. You could do
everything in machine language. A good language is the sum of lots of syntactic
sugar... selected with taste. :)
You can
Kay Schluehr wrote:
Dan Sommers schrieb:
How about this:
def __init__(self, self.x, y, self.z):
# self.x, self.z from first and third explicit parameters
do_something_with_y()
Can you tell me in which way it is anyhow better than the original
proposal
def
Reinhold Birkenfeld schrieb:
Kay Schluehr wrote:
Dan Sommers schrieb:
How about this:
def __init__(self, self.x, y, self.z):
# self.x, self.z from first and third explicit parameters
do_something_with_y()
Can you tell me in which way it is anyhow better than
On Mon, 11 Jul 2005 08:34:45 +0200,
Reinhold Birkenfeld [EMAIL PROTECTED] wrote:
Kay Schluehr wrote:
Dan Sommers schrieb:
How about this:
def __init__(self, self.x, y, self.z):
# self.x, self.z from first and third explicit parameters
do_something_with_y()
Can you tell me in which
Dan Sommers wrote:
Without thinking it all the way through, I suppose these:
def method_1(self, *self.l):
pass
def method_2(self, **self.d):
pass
could act as if they were these:
def method_1(self, *args):
self.l = args
del args
def
On Mon, 11 Jul 2005 01:44:07 -0400, Terry Reedy [EMAIL PROTECTED] wrote:
Bengt Richter [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Me too. I liked the leading _, but on second thought it is a weird
language change
re names in a special context. Probably not so good.
To
On Mon, 11 Jul 2005 15:37:35 +0200, Reinhold Birkenfeld [EMAIL PROTECTED]
wrote:
Dan Sommers wrote:
Without thinking it all the way through, I suppose these:
def method_1(self, *self.l):
pass
def method_2(self, **self.d):
pass
could act as if they were these:
support.
I think it would be fantastic if we could push through the
def __init__(self, self.x, y, self.y)
syntax, with the explicit limitation that only the first argument can be used
on the left side of the dot. I'd also happily settle for a decorator approach,
__autoinit__ or over variations
Ralf W. Grosse-Kunstleve [EMAIL PROTECTED] writes:
--- Bengt Richter [EMAIL PROTECTED] wrote:
No, that limitation wouldn't exist, so you wouldn't have to explain it ;-)
I.e., the above would act like
class Foo:
x = Bar()
def method_1(self, _anonymous_arg_1):
x.y =
On Mon, 11 Jul 2005 19:37:03 -0400,
Mike Meyer [EMAIL PROTECTED] wrote:
The question is - how far are you really willing to carry this? What
do you think of allowing arbitrary lvalues, with the assumption that
the previous arguments are all defined (ala let*)? So you could do:
class
be irreversible in
practical applications.
My __autoinit__ suggestion would result in (assuming object supports
this by default):
class grouping(object):
def __autoinit__(self, x, y, z):
pass
I think that's far more intuitive.
Being intuitive is relative to someones
Ralf W. Grosse-Kunstleve [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
I have a suggestion I don't remember seeing for flagging which vars to
autoinit without new syntax: use '_' instead of '.'. I have never seen
local vars with a leading '_'. So, in combination with whatever
On Sun, 10 Jul 2005 16:26:24 -0400, Terry Reedy [EMAIL PROTECTED] wrote:
Ralf W. Grosse-Kunstleve [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
I have a suggestion I don't remember seeing for flagging which vars to
autoinit without new syntax: use '_' instead of '.'. I have never
On Sun, 10 Jul 2005 16:26:24 -0400,
Terry Reedy [EMAIL PROTECTED] wrote:
Ralf W. Grosse-Kunstleve [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
I have a suggestion I don't remember seeing for flagging which vars to
autoinit without new syntax: use '_' instead of '.'. I have
Dan Sommers [EMAIL PROTECTED] writes:
def __init__(self, self.x, y, self.z):
# self.x, self.z from first and third explicit parameters
do_something_with_y()
Hey, I like that.
--
http://mail.python.org/mailman/listinfo/python-list
Dan Sommers [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
On Sun, 10 Jul 2005 16:26:24 -0400,
Terry Reedy [EMAIL PROTECTED] wrote:
I have a suggestion I don't remember seeing for flagging which vars to
autoinit without new syntax: use '_' instead of '.'. I have never seen
local
On Sun, 10 Jul 2005 20:11:38 -0400,
Terry Reedy [EMAIL PROTECTED] wrote:
Dan Sommers [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
That's a pretty big change; now all formal parameters beginning with
an underscore have a brand new meaning.
As I said, 'in combination with
On 10 Jul 2005 16:07:40 -0700, Paul Rubin http://[EMAIL PROTECTED] wrote:
Dan Sommers [EMAIL PROTECTED] writes:
def __init__(self, self.x, y, self.z):
# self.x, self.z from first and third explicit parameters
do_something_with_y()
Hey, I like that.
Me too. I liked the
Dan Sommers schrieb:
How about this:
def __init__(self, self.x, y, self.z):
# self.x, self.z from first and third explicit parameters
do_something_with_y()
Can you tell me in which way it is anyhow better than the original
proposal
def __init__(self, .x, y, .z):
Bengt Richter [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Me too. I liked the leading _, but on second thought it is a weird
language change
re names in a special context. Probably not so good.
To repeat: while my '_' proposal could have been for a language change (in
3.0),
My initial proposal
(http://cci.lbl.gov/~rwgk/python/adopt_init_args_2005_07_02.html) didn't
exactly get a warm welcome...
And Now for Something Completely Different:
class autoinit(object):
def __init__(self, *args, **keyword_args):
self.__dict__.update(
zip(self.__autoinit__
Ralf W. Grosse-Kunstleve schrieb:
My initial proposal
(http://cci.lbl.gov/~rwgk/python/adopt_init_args_2005_07_02.html) didn't
exactly get a warm welcome...
Well ... yes ;)
Ralf, if you want to modify the class instantiation behaviour you
should have a look on metaclasses. That's what they
--- Kay Schluehr [EMAIL PROTECTED] wrote:
Ralf, if you want to modify the class instantiation behaviour you
I don't. I simply want to give the user a choice:
__init__(self, ...) # same as always (no modification)
or
__autoinit__(self, ...) # self.x=x job done automatically
plain_adopt_grouping:
def __init__(self, x, y, z):
plain_adopt()
class autoinit(object):
def __init__(self, *args, **keyword_args):
self.__dict__.update(
zip(self.__autoinit__.im_func.func_code.co_varnames[1:], args))
self.__dict__.update(keyword_args)
self.__autoinit__
.update(
zip(self.__autoinit__.im_func.func_code.co_varnames[1:], args))
self.__dict__.update(keyword_args)
self.__autoinit__(*args, **keyword_args)
Should be:
class autoinit(object):
def __init__(self, *args, **keyword_args):
for name, value in zip(self
--- Scott David Daniels [EMAIL PROTECTED] wrote:
Should be:
class autoinit(object):
def __init__(self, *args, **keyword_args):
for name, value in zip(self.__autoinit__.im_func.func_code.
co_varnames[1:], args
fine-tuning
capabilities. The auto_ prefix is all the declarative magic.
My __autoinit__ suggestion would result in (assuming object supports
this by default):
class grouping(object):
def __autoinit__(self, x, y, z):
pass
I think that's far more intuitive.
Being intuitive
28 matches
Mail list logo
