Greg> [EMAIL PROTECTED] wrote:
Greg> for (x in seq1, y in seq2):
>> That's already valid syntax though.
Greg> No, it's not...
for (x in seq1, y in seq2):
Greg>File "", line 1
Greg> for (x in seq1, y in seq2):
Greg>^
Greg> I actually came up with an idea for that, slightly too late to get
Greg> considered in the original lockstep-iteration debate:
Greg>for (x in seq1, y in seq2):
Greg> ...
That's already valid syntax though.
Skip
___
Pytho
On 2/13/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Mike Klaas wrote:
>
> > As a comparison, enumerate (that I would have believed was much more
> > frequent a priori), is used 67 times, and zip/izip 165 times.
>
> By that argument, we should be considering a special syntax
> for zip and izip befor
[EMAIL PROTECTED] wrote:
> Given that you have more uses of zip/izip maybe we should be discussion
> syntactic support for that instead. ;-)
I actually came up with an idea for that, slightly too
late to get considered in the original lockstep-iteration
debate:
for (x in seq1, y in seq2):
Mike Klaas wrote:
> As a comparison, enumerate (that I would have believed was much more
> frequent a priori), is used 67 times, and zip/izip 165 times.
By that argument, we should be considering a special syntax
for zip and izip before getattr.
--
Greg
__
Josiah Carlson wrote:
> In a recent
> source checkout of the trunk Lib, there are 100+ uses of setattr, 400+
> uses of getattr ... and a trivial number of delattr calls.
That's out of about 250,000 lines, or 0.2%.
Not a huge proportion, I would have thought.
--
Greg
__
Ron Adam wrote:
> Would it be possible for attrview to be a property?
To avoid polluting the namespace, it would need to have
a double-underscore name, and then it would be ugly to
use.
Unless we had a function to call it for you... oh,
wait, we've already got one -- it's called getattr. :-)
--
Guido van Rossum wrote:
> it means we'll be catching AttributeError
> instead of using "look before you leap", which if fine with me.
A thought on this: to avoid masking bugs, when catching
AttributeError you really need to isolate the getattr
operation so that it's on a line by itself, with no
su
On Wednesday 14 February 2007 03:03, Guido van Rossum wrote:
> Not to me -- magic objects are harder to grok than magic syntax;
> the magic syntax gives you a more direct hint that something
> unusual is going on than a magic object. Also, Nick's examples
> show (conceptual) aliasing problems: afte
On Wednesday 14 February 2007 07:39, Aahz wrote:
> My point is that I suspect that general objects are not used much
> with getattr/setattr. Does anyone have evidence counter to that?
> I think that evidence should be provided before this goes much
> further; perhaps all that's needed is educatio
Mike Klaas schrieb:
> The entire codebase was developed post-2.4
Can you find out what percentage of these could have used
a __getitem__ if it had been implemented? As a starting
point, count all 'getattr(self' invocations.
Regards,
Martin
___
Python-De
Larry Hastings wrote:
> I just duplicated this test on all the .py files in the Lib directory
> tree of a freshly updated 2.5 trunk.
Whoops! Sorry, bungled it again. I counted definitions of __*attr__ too.
This time I used "fgrep -w getattr | fgrep 'getattr('" to cull. The
corrected results:
On 2/13/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Mike> As a comparison, enumerate (that I would have believed was much
> Mike> more frequent a priori), is used 67 times, and zip/izip 165 times.
>
> But (get|set|has)attr has been around much longer than enumerate. I'm
> almost ce
Josiah Carlson wrote:
> In a recent source checkout of the trunk Lib, there are 100+ uses of setattr,
> 400+ uses of getattr (perhaps 10-20% of which being the 3 argument form), and
> a trivial number of delattr calls.
I just duplicated this test on all the .py files in the Lib directory
tree of
On Tue, Feb 13, 2007, Guido van Rossum wrote:
>
> I think the point of attrview() and x.[y] and getattr()/setattr() is
> that these should be usable regardless of whether the object is
> prepared for such use; they map directly to __getattr__ and
> __setattr__. If I had to design an object specific
Martin v. Löwis wrote:
> Ron Adam schrieb:
>> Would it be possible for attrview to be a property?
>
> Sure. It might conflict with a proper name of an attribute, of course.
>
>> Something like... (Probably needs more than this to handle all cases.)
>>
>> class obj(object):
>> def _
Mike> Another data point: on our six-figure loc code base, we have 123
Mike> instances of getattr, 30 instances of setattr, and 0 instances of
Mike> delattr. There are 5 instances of setattr( ... getattr( ... ) )
Mike> on one line (and probably a few more that grep didn't pick up
On Tue, 13 Feb 2007 11:27:48 -0800, Mike Klaas <[EMAIL PROTECTED]> wrote:
>On 2/13/07, Josiah Carlson <[EMAIL PROTECTED]> wrote:
>
>> As for people who say, "but getattr, setattr, and delattr aren't used";
>> please do some searches of the Python standard library. In a recent
>> source checkout of
On 2/13/07, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> As for people who say, "but getattr, setattr, and delattr aren't used";
> please do some searches of the Python standard library. In a recent
> source checkout of the trunk Lib, there are 100+ uses of setattr, 400+
> uses of getattr (perhaps
I think the point of attrview() and x.[y] and getattr()/setattr() is
that these should be usable regardless of whether the object is
prepared for such use; they map directly to __getattr__ and
__setattr__. If I had to design an object specifically for such
dynamic access, sure, I'd implement __geti
On Tue, Feb 13, 2007, Ben North wrote:
>
> I think the "obj.[attr_name]" syntax has the most support. To stop this
> going round in circles for ages, then, I will take this as the winner.
> I'll mention the other contenders in the PEP, including the new
> "visually distinctive" suggestions
>
>
Ron Adam schrieb:
> Would it be possible for attrview to be a property?
Sure. It might conflict with a proper name of an attribute, of course.
> Something like... (Probably needs more than this to handle all cases.)
>
> class obj(object):
> def _attrview(self):
> retu
"Greg Falcon" <[EMAIL PROTECTED]> wrote:
> 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 be
Ron Adam <[EMAIL PROTECTED]> wrote:
> Georg Brandl wrote:
> Would it be possible for attrview to be a property?
Yes, but getting the right spelling will be hard.
> Something like... (Probably needs more than this to handle all cases.)
>
> class obj(object):
> def _attrview(self):
Georg Brandl wrote:
> Martin v. Löwis schrieb:
>> Anthony Baxter schrieb:
and the "wrapper class" idea of Nick Coghlan:
attrview(obj)[foo]
>>> This also appeals - partly because it's not magic syntax
>> I also like this. I would like to spell it attrs, and
>> I think its specification
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
> compat
Anthony Baxter <[EMAIL PROTECTED]> wrote:
> > The performance question is important, certainly. Initial
> > reaction on python-ideas was that a 1% cost would not count as
> > substantial
>
> I'd disagree. Those 1% losses add up, and it takes a heck of a lot
> of work to claw them back. Again, t
Martin v. Löwis schrieb:
> Anthony Baxter schrieb:
>>> and the "wrapper class" idea of Nick Coghlan:
>>>attrview(obj)[foo]
>>
>> This also appeals - partly because it's not magic syntax
>
> I also like this. I would like to spell it attrs, and
> I think its specification is
>
> class attrs:
On Tue, 13 Feb 2007 17:20:02 +0100, "\"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
>
>I also like this. I would like to spell it at
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
>
> I also like this.
Martin and Anthony are correct. We do not need mo
Anthony Baxter schrieb:
>> and the "wrapper class" idea of Nick Coghlan:
>>attrview(obj)[foo]
>
> This also appeals - partly because it's not magic syntax
I also like this. I would like to spell it attrs, and
I think its specification is
class attrs:
def __init__(self, obj):
self.ob
On 2/13/07, Anthony Baxter <[EMAIL PROTECTED]> wrote:
> [meta-comment: my congratulations to Ben North for managing this
> process as painlessly as any syntax discussion I've ever seen.
> Regardless of the outcome, I'd like to see this thread referenced
> in the appropriate places as a great exampl
[meta-comment: my congratulations to Ben North for managing this
process as painlessly as any syntax discussion I've ever seen.
Regardless of the outcome, I'd like to see this thread referenced
in the appropriate places as a great example of how to propose new
features in Python]
I've been thi
The support for the including the feature at all is still not unanimous.
Perhaps the way forward is to try to reach consensus on the favourite
(or least-unfavourite) syntax, and I'll revise the PEP and sample
implementation.
I think the "obj.[attr_name]" syntax has the most support. To stop this
34 matches
Mail list logo
