Dear Python Team,
I have a good idea for a new comand in Python.
It’s „intput()“ for numbers. So you don’t have to write „int(Input())“.
It’s much easier to write and it’s faster too.
You can use the same for „floatput()“, so don’t have to write „float(Input())“.
I hope you can make something good
A few of you have expressed concern about how would that look to a
newbie. Being one, this is what I think:
- The idea sounds good. Setattr and getattr seems both unpythonic and illegible.
- please.(dont_torture) =
me(with_dots,that_look,like.(function),calls). Ok, so the dot _is_
needed in order
* Ben North <[EMAIL PROTECTED]> [2007-02-11 23:45:05 +]:
> Dynamic attribute access is currently possible using the "getattr"
> and "setattr" builtins. The present PEP suggests a new syntax to
> make such access easier, allowing the coder for example to write
>
> x.('foo_
On Fri, Feb 16, 2007 at 01:42:54PM +0100, "Martin v. L?wis" wrote:
> Ah, this passive voice again, and again the assumption that there is an
> agenda of python-dev.
Exactly opposite. There is no agenda, and thus there is no pojnt in
trying to prevent new features in Python language based on the
Oleg Broytmann schrieb:
>That changes the meaning, but... have you ever tried to ride a horse
> designed by a group of Clever Individuals loosely connected by email? ;) I
> am afraid of even thinking of its ugliness and speed. (-:
>I think a committee is better than nothing, and I believe C
>I think a committee is better than nothing, and I believe CP4E has
> been dropped from the agenda.
The general CP4E idea is part of the "General Pythonic Ideal",
whatever it may be :P
--
EduardoOPadoan (eopadoan->altavix::com)
Bookmarks: http://del.icio.us/edcrypt
___
On Fri, Feb 16, 2007 at 12:40:54PM +1300, Greg Ewing wrote:
> The quote is actually "a camel is a *racehorse* designed by a committee".
> Camels are very good at surviving in the desert, but not so good at
> winning a horse race (not camel race). Which is the point of the saying.
That changes t
Greg Ewing wrote:
> Oleg Broytmann wrote:
>
>>> Given that they say "a camel is a horse designed by a committee"
>> BTW, camels are very suited for their environments...
>
> The quote is actually "a camel is a *racehorse* designed by a committee".
> Camels are very good at surviving in the desert
Greg Ewing wrote:
> Oleg Broytmann wrote:
>
>>> Given that they say "a camel is a horse designed by a committee"
>>
>> BTW, camels are very suited for their environments...
>
> The quote is actually "a camel is a *racehorse* designed by a
> committee". Camels are very good at surviving in the d
Oleg Broytmann wrote:
> > Given that they say "a camel is a horse designed by a committee"
>
> BTW, camels are very suited for their environments...
The quote is actually "a camel is a *racehorse* designed by a committee".
Camels are very good at surviving in the desert, but not so good at
winni
On Thu, Feb 15, 2007 at 12:48:48AM +, Steve Holden wrote:
> Given that they say "a camel is a horse designed by a committee"
Metaphors can go that far but not farther. And, BTW, camels are very
suited for their environments...
I am not afraid of committees for large tasks. Well, that has
Oleg Broytmann wrote:
> On Wed, Feb 14, 2007 at 03:24:30PM +, Steve Holden wrote:
>> Oleg Broytmann wrote:
>>> On Tue, Feb 13, 2007 at 10:10:37AM +, Steve Holden wrote:
Python further away from the "Computer Programming for Everyone" arena
and closer to the "Systems Programming f
On Wed, Feb 14, 2007 at 03:24:30PM +, Steve Holden wrote:
> Oleg Broytmann wrote:
> > On Tue, Feb 13, 2007 at 10:10:37AM +, Steve Holden wrote:
> >> Python further away from the "Computer Programming for Everyone" arena
> >> and closer to the "Systems Programming for Clever Individuals" ca
Oleg Broytmann wrote:
> On Tue, Feb 13, 2007 at 10:10:37AM +, Steve Holden wrote:
>> Python further away from the "Computer Programming for Everyone" arena
>> and closer to the "Systems Programming for Clever Individuals" camp.
>
>That's because Python is being developed by "Clever Indivi
Hi Michael,
On Tue, Feb 13, 2007 at 11:55:46PM +, Michael Foord wrote:
> > x = *('variable%d' % n)
> > f(a, b, *('keyword%d' % n) = c)
> > class *('33strangename'):
> > pass
> > def *(funcname)(x, y, *(argname), *args, **kwds):
> > pass
> > import *modname a
Guido van Rossum wrote:
> But if we ever turn it into a single token (which we just may for
> Py3k) don't complain if your code breaks.
I won't. I always treat it as a single token
anyway, unless I'm entering an obfuscated
python competition. :-)
--
Greg
_
On 2/13/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Martin v. Löwis wrote:
>
> > OTOH, you can't write
> >
> >x + = 2
> >
> > or
> >
> >a = 2 * * 4
>
> Although oddly enough you *can* write
>
> a[. . .]
>
> I guess whoever added the ellipsis couldn't be bothered
> defining a new token f
This seems to be the overwhelming feedback at this point, so I'm
withdrawing my support for the proposal. I hope that Ben can write up
a PEP and mark it rejected, to summarize the discussion; it's been a
useful lesson. Occasinoally, negative results are worth publishing!
On 2/13/07, Barry Warsaw <
Martin v. Löwis wrote:
> OTOH, you can't write
>
>x + = 2
>
> or
>
>a = 2 * * 4
Although oddly enough you *can* write
a[. . .]
I guess whoever added the ellipsis couldn't be bothered
defining a new token for it.
It's something of an arbitrary choice, but to me it just
seems that
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Feb 13, 2007, at 7:24 PM, Greg Ewing wrote:
> I'm still -1 on the basic idea, though, on the grounds of
> YAGNIOE (You Aren't Going to Need It Often Enough).
I can't really add much more than what's already be stated, but I
echo Greg's sentiment
Martin v. Löwis wrote:
> BTW, which of these would be correct
My thoughts would be
(a).[b] Okay
(a.)[b] Not okay
a.[(b)] Okay
a.([b]) Not okay
a . [ b ]Okay
> and what is the semantics of
>
> a.[42]
The same as getattr(a,
Martin v. Löwis wrote:
> Apparently, people favor hasattr over catching
> AttributeError. I'm not sure why this is - I would probably
> rewrite them all to deal with AttributeError if I use the new
> syntax in the first place.
Actually, I prefer using getattr with a default value over
either of t
Armin Rigo wrote:
> Hi,
>
> On Mon, Feb 12, 2007 at 12:38:27AM -0700, Neil Toronto wrote:
>
>>obj.*str_expression
>>
>
>
> x = *('variable%d' % n)
>
> f(a, b, *('keyword%d' % n) = c)
>
> class *('33strangename'):
> pass
>
> def *(funcname)(x, y, *(argname), *args
Hi,
On Mon, Feb 12, 2007 at 12:38:27AM -0700, Neil Toronto wrote:
>obj.*str_expression
x = *('variable%d' % n)
f(a, b, *('keyword%d' % n) = c)
class *('33strangename'):
pass
def *(funcname)(x, y, *(argname), *args, **kwds):
pass
import *modname as mymo
> On 2/13/07, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> [snip]
> > I've tried this out on Brett's urllib & urllib2 examples below. (calling
> > the new builtin attrview() to emphasise the fact that it retains a
> > reference to the original instance). I don't consider it any uglier than
> > the pro
On 2/13/07, Nick Coghlan <[EMAIL PROTECTED]> wrote:
[snip]
> I've tried this out on Brett's urllib & urllib2 examples below. (calling
> the new builtin attrview() to emphasise the fact that it retains a
> reference to the original instance). I don't consider it any uglier than
> the proposed syntax
On 12 Feb, 11:19 pm, [EMAIL PROTECTED] 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. Add
On 2/13/07, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Taking a step back a bit... the basic issue is that we have an attribute
> namespace (compile time key determination) that we want to access in a
> dictionary style (runtime key determination).
>
> This is currently done by switching from syntac
Nick Coghlan wrote:
I've tried this out on Brett's urllib & urllib2 examples below. (calling
the new builtin attrview() to emphasise the fact that it retains a
reference to the original instance).
Ooh, ooh! I wanna change my vote! +1 on attrview(), +0.25 on ".[]".
Maybe I haven't written en
Taking a step back a bit... the basic issue is that we have an attribute
namespace (compile time key determination) that we want to access in a
dictionary style (runtime key determination).
This is currently done by switching from syntactic access to the
getattr/setattr/delattr builtin function
On Tue, Feb 13, 2007 at 10:10:37AM +, Steve Holden wrote:
> Python further away from the "Computer Programming for Everyone" arena
> and closer to the "Systems Programming for Clever Individuals" camp.
That's because Python is being developed by "Clever Individuals" and not
by "Computer Pr
On 13/02/2007 5.33, Maric Michaud wrote:
> I really dislikes the .[ or .( or .{ operators.
> Just on my mail editor the two expressions
>
> a.[b]
>
> and
>
> a,[b]
>
> are quite hard to differentiate while completely unrelated.
I'll propose a new color for this bikeshed:
a.[[b]]
handlers
On 13/02/2007 7.39, Martin v. Löwis wrote:
> And again. Apparently, people favor hasattr over catching
> AttributeError. I'm not sure why this is -
Because the code becomes longer, unless you want to mask other exceptions:
name = 'http_error_%d' % errcode
-if hasattr(self, name):
-metho
On 13/02/07, Anthony Baxter <[EMAIL PROTECTED]> wrote:
> The killer problem with backticks (to pick the syntax that currently
> causes this problem the most) is with webpages and with printed
> books with code. Sure, everyone can pick a font for coding that
> they can read, but that's not the only
Georg Brandl schrieb:
>
>> a.([b])
> No. (you can't write a([b]) today)
Actually, you can, but it means something
>
>> a . [ b ]
> Yes. (you can write a . b today)
OTOH, you can't write
x + = 2
or
a = 2 * * 4
so it's not that obvious that .[ should be two tokens.
Regards,
M
Ben North wrote:
> Hi,
>
> A few days ago I posted to python-ideas with a suggestion for some new
> Python syntax, which would allow easier access to object attributes
> where the attribute name is known only at run-time. For example:
>
>setattr(self, method_name, getattr(self.metadata, meth
Martin v. Löwis schrieb:
> Ron Adam schrieb:
>> I think it's gets a bit awkward in some situations.
>>
>>
>> if bar->'__%s__' % attr < -42: print 'Hello World'
>>
>> if bar.['__%s__' % attr] > -42: print 'Hello World'
>>
>>
>> To me it's easier to parse the second one visually.
>
>
>
Ron Adam schrieb:
> I think it's gets a bit awkward in some situations.
>
>
> if bar->'__%s__' % attr < -42: print 'Hello World'
>
> if bar.['__%s__' % attr] > -42: print 'Hello World'
>
>
> To me it's easier to parse the second one visually.
Ah, precedence.
It definitly should be a
Brett Cannon schrieb:
> name = 'open_' + urltype
> self.type = urltype
> name = name.replace('-', '_')
> if not hasattr(self, name):
> if proxy:
> return self.open_unknown_proxy(proxy, fullurl, data)
> else:
> r
On 2/12/07, Maric Michaud <[EMAIL PROTECTED]> wrote:
> Le mardi 13 février 2007 01:36, Barry Warsaw a écrit:
> > On Feb 12, 2007, at 7:32 PM, Guido van Rossum wrote:
> > > Oh, now I am definitely in favor of .[]! I read it in gmail in FireFox
> > > which uses a small variable-pitch font whose dot i
M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> You can add a -1 from me to the list as well: I don't think that
> dynamic lookups are common enough to warrant new syntax.
I agree. Also, I think the special syntax may make them too
inviting to new programmers, who haven't figured out that usually
ther
Le mardi 13 février 2007 01:36, Barry Warsaw a écrit :
> On Feb 12, 2007, at 7:32 PM, Guido van Rossum wrote:
> > Oh, now I am definitely in favor of .[]! I read it in gmail in FireFox
> > which uses a small variable-pitch font whose dot is a single pixel.
> > The .() example was hard to find; the
Barry Warsaw wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Feb 12, 2007, at 7:32 PM, Guido van Rossum wrote:
>
>> Oh, now I am definitely in favor of .[]! I read it in gmail in FireFox
>> which uses a small variable-pitch font whose dot is a single pixel.
>> The .() example was
A few of you have expressed concern about how would that look to a
newbie. Being one, this is what I think:
(again, newbie alert)
- The idea sounds good. Setattr and getattr seem kinda unpythonic and
difficult to read.
- please.(dont_torture) =
me(with_dots,that_look,like.(function),calls). Ok,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Feb 12, 2007, at 7:32 PM, Guido van Rossum wrote:
> Oh, now I am definitely in favor of .[]! I read it in gmail in FireFox
> which uses a small variable-pitch font whose dot is a single pixel.
> The .() example was hard to find; the .[] jumped out
Raymond Hettinger wrote:
> Rather than munge existing syntaxes, an altogether new one would be more
> clear:
>
>self->name = self.metadata->name
>
My problem with this is that it isn't a "name". It should grammatically
be a test (i.e. it can take on the expression any function argument
co
Oh, now I am definitely in favor of .[]! I read it in gmail in FireFox
which uses a small variable-pitch font whose dot is a single pixel.
The .() example was hard to find; the .[] jumped out immediately.
(When do you ever see self[anything]?)
On 2/12/07, Brett Cannon <[EMAIL PROTECTED]> wrote:
>
Brett Cannon wrote:
> On 2/12/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>> 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
>> y
On Tuesday 13 February 2007 10:10, Ben North wrote:
> (Gently wandering off-topic,
> but: do people use proportional fonts for coding? Doesn't it
> cause general awkwardness for indentation, especially relevant
> for python?)
The killer problem with backticks (to pick the syntax that currently
Benji York wrote:
> Collin Winter wrote:
>> On 2/12/07, Brett Cannon <[EMAIL PROTECTED]> 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, bu
On 2/12/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> FWIW, I'm strongly -1 on the "->" notation. As a C programmer it's got
> too many neurons committed to it.
>
> I recommend that you do some experiments with the readability of the
> .[...] notation, e.g. write a program that randomly generat
2007/2/12, Benji York <[EMAIL PROTECTED]>:
> Collin Winter wrote:
> > 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".
Someone wi
On 2/12/07, BJörn Lindqvist <[EMAIL PROTECTED]> wrote:
> Is even more syntactic sugar really what Python really needs?
Yes, I need my fix!!!
my 2 cents:
I'm +1 on either the '.(name)' or '.[name]' syntax. I'm leaning more
towards the parentheses though. I don't really buy into the argument
that
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 sol
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 suppor
Is even more syntactic sugar really what Python really needs?
--
mvh Björn
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mai
FWIW, I'm strongly -1 on the "->" notation. As a C programmer it's got
too many neurons committed to it.
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 differen
Collin Winter wrote:
> On 2/12/07, Brett Cannon <[EMAIL PROTECTED]> 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 on
On 2/12/07, Brett Cannon <[EMAIL PROTECTED]> wrote:
> On 2/12/07, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> > [Jack Jansen]
> > > I like the functionality, but I don't like the syntax, to me it looks
> > > too much like a method call.
> > >
> > > To me self.[method_name] = self.metadata.[metho
On 2/12/07, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> [Raymond Hettinger]
> >> Rather than munge existing syntaxes, an altogether new one would be
> >> more clear:
> >>
> >>self->name = self.metadata->name
>
> [Ben North]
> > One thing which comes to mind about this one is that, for C/C++
On 2/12/07, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> [Jack Jansen]
> > I like the functionality, but I don't like the syntax, to me it looks
> > too much like a method call.
> >
> > To me self.[method_name] = self.metadata.[method_name] looks better:
> > what we're doing here is more like dic
I'll take this opportunity to pipe in with a response, since Guido
summed up the many issues nicely and its a good bouncing point to
mention my own thoughts.
On 2/12/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> My perspective:
>
> - There's a lot of support for the basic idea, and only a few
Guido van Rossum schrieb:
> PS Thanks to Ben for excellent summaries of the discussion so far!
I'd like to second this. This is how PEPs ought to work.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/li
[Raymond Hettinger]
>> Rather than munge existing syntaxes, an altogether new one would be
>> more clear:
>>
>>self->name = self.metadata->name
[Ben North]
> One thing which comes to mind about this one is that, for C/C++
> programmers, the difference between
>
> obj.memberand
On Mon, 12 Feb 2007 18:50:35 +1100, you wrote:
>Yes and no. My point is that it's extremely similar to existing
>syntax. (Worse yet, it looks the same but for what's possibly the
>smallest and hardest-to-see character in any character set)
>
>"foo(baz)" vs "foo.(baz)" is... not good.
To me (as
My perspective:
- 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.
- There's near-universal dislike for the two-arg form, so let's drop
that part of the proposal.
- I can't recall that x.[y] has been proposed yet, but thinking
On 2007-02-12 16:19, Georg Brandl wrote:
>> 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
>>> f
Ben North wrote:
> 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
Ben North schrieb:
> 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 mad
Ben North wrote:
> Thanks for the comments so far on this.
Count me as a +0 on the general idea, -1 on the specific proposed syntax
(based on the 'syntax shall not look like grit on Tim's monitor'
guideline, and the fact that nested parentheses make it hard to separate
the dynamic attribute loo
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
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 gen
On 2/11/07, Ben North <[EMAIL PROTECTED]> wrote:
Hi,
A few days ago I posted to python-ideas with a suggestion for some new
Python syntax, which would allow easier access to object attributes
where the attribute name is known only at run-time. For example:
setattr(self, method_name, getatt
[Jack Jansen]
> I like the functionality, but I don't like the syntax, to me it looks
> too much like a method call.
>
> To me self.[method_name] = self.metadata.[method_name] looks better:
> what we're doing here is more like dictionary lookup than calling
> functions.
I also like the functionali
Georg Brandl wrote:
> For the speed argument -- there were quite a few proposals to take builtins as
> constants under certain conditions, in which case getattr() usage could be
> optimized just as well as new syntax.
Even more aggressively, the compiler could recognise it
and make a direct call
Terry Reedy wrote:
> Need: Runtime attributes are a fairly frequent 'How?' question on c.l.p.
That's true, but how many of those are due to an actual
need for runtime attributes, as opposed to someone trying
to transplant idioms from another language that would be
better served by a dict?
In my
On 12-feb-2007, at 0:45, Ben North wrote:
>
>self.(method_name) = self.metadata.(method_name)
I like the functionality, but I don't like the syntax, to me it looks
too much like a method call.
To me self.[method_name] = self.metadata.[method_name] looks better:
what we're doing here is
Collin Winter schrieb:
> I like the general idea, but 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. Also, like Anthony
> Baxter said, someone coming across this for the first time will
On Monday 12 February 2007 18:38, Neil Toronto wrote:
> Anthony Baxter wrote:
> > I have to say that I'm not that impressed by either the 1-arg
> > or 2-arg versions. Someone coming across this syntax for the
> > first time will not have any hints as to what it means - and
> > worse, it looks like
Anthony Baxter wrote:
> I have to say that I'm not that impressed by either the 1-arg or
> 2-arg versions. 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. -1 from me.
>
I'm not sure the "loo
I like the general idea, but 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. Also, like Anthony
Baxter said, someone coming across this for the first time will think
it's a syntax error, allu
I have to say that I'm not that impressed by either the 1-arg or
2-arg versions. 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. -1 from me.
___
Python-De
On 2/11/07, Ben North <[EMAIL PROTECTED]> wrote:
[SNIP]
> * The draft currently allows a two-argument form, to supply a default
> value if the object has no attribute of that name. This mimics the
> behaviour of the three-argument form of getattr, but looks a bit wrong:
>
> s = obj.(attr_
"Ben North" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| so here I am. Does anybody have any opinions/suggestions, particularly
| on the "open questions" referred to in the draft PEP? To summarise
| these open questions:
Need: Runtime attributes are a fairly frequent 'How?' qu
Ben North wrote:
> Hi,
>
> A few days ago I posted to python-ideas with a suggestion for some new
> Python syntax, which would allow easier access to object attributes
> where the attribute name is known only at run-time. For example:
>
> setattr(self, method_name, getattr(self.metadata, method_nam
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 fa
Hi,
A few days ago I posted to python-ideas with a suggestion for some new
Python syntax, which would allow easier access to object attributes
where the attribute name is known only at run-time. For example:
setattr(self, method_name, getattr(self.metadata, method_name))
from Lib/distutils/d
87 matches
Mail list logo
