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
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:
>
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
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 -- the
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:
> 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
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
[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 ow
[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 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
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
a
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
-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
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 string
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
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
__
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
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
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. Chris
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
___
Pyth
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
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
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 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.
>>
>> Bui
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 _
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
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, 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
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
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
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
Richard Tew schrieb:
> If there is no Stackless 'hard switching' available (the stack
> switching done with assistance of assembler) for the platform it is
> being compiled on, then compilation proceeds without Stackless
> compiled into Python. The module is not available. The process
> of adding
[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
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 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=detail&aid=1658799&group_id=5470&atid=305470
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
>
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
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 conside
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
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 ar
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
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.
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
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.
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
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 imp
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.
>
>
>
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"
>> http://svn.python.org/view/stackless/tru
77 matches
Mail list logo
