Martin v. Löwis wrote:
Richard Tew schrieb:
I can't point you to the posts, but I can point you to something
Christian has written on the subject which may indicate why
it was never actually submitted for inclusion.
See A Bit Of History
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.
Ah, precedence.
It
On Mon, 2007-02-12 at 12:29 -0800, Josiah Carlson wrote:
Hrvoje Nikšic [EMAIL PROTECTED] wrote:
I propose modifying PyString_InternInPlace to better cope with string
subtype instances.
Any particular reason why the following won't work for you?
[... snipped a simple intern
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,
Hrvoje Nikšić schrieb:
Another reason is that Python's interning mechanism is much better than
such a simple implementation: it stores the interned state directly in
the PyString_Object structure, so you can find out that a string is
already interned without looking it up in the dictionary.
Steve Holden schrieb:
The only things that concern me are a) whether it could make sense to
add Stackless in bits and pieces and b) whether the BDFL (or even the
developer community en masse) would object in principle, thereby
rendering such efforts useless.
I think I need to try again.
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 way
Greg Ewing schrieb:
That doesn't quite give you everything that real interning
does, though. The string comparison method knows when both
strings are interned, so it can compare them quickly
whether they are equal or not.
No, it doesn't - see stringobject.c:string_richcompare.
If they are
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):
-method
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 =
Grig Gheorghiu schrieb:
So is there any value or interest in setting up a svn notification
hook for py3k commits that would go to the pybots buildbot master?
A similar question is whether there should be buildbots for Python 3
itself (i.e. running the test suite). Even for that, it was
On 2/13/07, Martin v. Löwis [EMAIL PROTECTED] wrote:
Steve Holden schrieb:
The only things that concern me are a) whether it could make sense to
add Stackless in bits and pieces and b) whether the BDFL (or even the
developer community en masse) would object in principle, thereby
rendering
On Wed, 2007-02-07 at 15:39 +0100, Hrvoje Nikšić wrote:
The patch could look like this. If there is interest in this, I can
produce a complete patch.
The complete patch is now available on SourceForge:
http://sourceforge.net/tracker/index.php?func=detailaid=1658799group_id=5470atid=305470
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
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
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 example of
Anthony Baxter schrieb:
and the wrapper class idea of Nick Coghlan:
attrview(obj)[foo]
This also appeals - partly because it's not magic syntax wink
I also like this. I would like to spell it attrs, and
I think its specification is
class attrs:
def __init__(self, obj):
self.obj =
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
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 wink
I also like this.
Martin and Anthony are correct. We do not need more syntax for
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 wink
I also like this. I would like to spell it attrs, and
I think
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 wink
I also like this. I would like to spell it attrs, and
I think its specification is
class attrs:
def
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, this is
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 wink
It's so easy people can include in their code for backwards
compatibility; in
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 wink
I also like this. I would like to spell it attrs, and
I think its specification is
class
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):
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 being explicitly
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):
return
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
[EMAIL
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
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 10-20%
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 syntactic
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 the trunk
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
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 specifically
On 12 Feb, 05:11 pm, [EMAIL PROTECTED] wrote:
On 2/12/07, Tristan Seligmann [EMAIL PROTECTED] wrote:
* Richard Tew [EMAIL PROTECTED] [2007-02-12 13:46:43 +]:
Perhaps there is a better way. And I of course have no concept of
how this might be done on other platforms.
Building on an
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 a
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 certain
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:
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
___
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 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
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
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, **kwds):
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 education
Brett Cannon wrote:
On 2/12/07, Collin Winter [EMAIL PROTECTED] wrote:
2) {BinOp,AugAssign,BoolOp,etc}.op
I can't think of a reason, off the top of my head, why they can't be
singletons.
Why not just use interned strings?
--
Greg
___
Python-Dev
Martin v. Löwis wrote:
Greg Ewing schrieb:
the end result would be too
convoluted for ordinary people to understand and maintain.
That very much depends on what the end result would be.
True. What I should have said is that Guido *believes*
the outcome would be too convoluted. Christian's
At 08:41 PM 2/13/2007 +, [EMAIL PROTECTED] wrote:
and the microthreading features being discussed here are a trivial hack
somewhere in its mainloop machinery, not an entirely new subsystem that
it should be implemented in terms of.
It doesn't even require hacking the mainloop; it can be
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
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,
Steve Holden wrote:
I know that there's work in progress (and indeed
almost complete) to put Stackless into 2.5
It might be less confusing to rename the current version of
Stackless to microthreads or something, since it's not
really stackless at all.
--
Greg
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: after x
On 2/13/07, Greg Ewing [EMAIL PROTECTED] wrote:
Brett Cannon wrote:
On 2/12/07, Collin Winter [EMAIL PROTECTED] wrote:
2) {BinOp,AugAssign,BoolOp,etc}.op
I can't think of a reason, off the top of my head, why they can't be
singletons.
Why not just use interned strings?
Because the
-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:
OTOH, in an application that needs unique strings, you normally know
what the scope is (i.e. where the strings come from, and when they
aren't used anymore).
That's true -- if you know that all relevant strings have
been interned using the appropriate method, you can
On 2/12/07, Brett Cannon [EMAIL PROTECTED] wrote:
They all sound reasonable. And it's nice to have a wanted feature be
found from actual use. =)
I've just uploaded patch #1659410 to SF, implementing the changes I outlined:
1) I changed some of the code emitted by asdl_c.py so _fields is
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 the
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
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 for it.
But if we ever
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
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. :-)
--
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
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
[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):
[EMAIL PROTECTED] wrote:
I have no problem with other, competing event-driven mechanisms being
developed;
The need for different event-driven mechanisms to compete
with each other is the very problem that needs to be
addressed.
If Twisted is designed so that it absolutely *has* to
use its own
Brett Cannon wrote:
Because the AST code at the C level represent the 'op' value as
basically an enumeration value, not a string. So creating an object
is somewhat easier then trying to do the conversion to an interned
string.
It would seem even easier (and a lot faster) to use an
array to
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 before getattr.
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
Martin v. Löwis wrote:
Greg Ewing schrieb:
The string comparison method knows when both
strings are interned
No, it doesn't - see stringobject.c:string_richcompare.
Well, I'm surprised and confused.
It's certainly possible to tell very easily whether
a string is interned -- there's a
Greg I actually came up with an idea for that, slightly too late to get
Greg considered in the original lockstep-iteration debate:
Gregfor (x in seq1, y in seq2):
Greg ...
That's already valid syntax though.
Skip
___
On Wed, 14 Feb 2007 15:20:13 +1300, Greg Ewing [EMAIL PROTECTED] wrote:
Greg, productive discussion is not furthered by the
unsupported statement of one position or another.
Instead of only stating what you believe to be a problem,
explain why you believe it is a problem. A sentence like:
On 02:20 am, [EMAIL PROTECTED] wrote:
If Twisted is designed so that it absolutely *has* to
use its own special event mechanism, and everything else
needs to be modified to suit its requirements, then it's
part of the problem, not part of the solution.
I've often heard this complaint, usually of
71 matches
Mail list logo
