Re: [Python-Dev] Trial balloon: microthreads library in stdlib
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/trunk/Stackless/readme.txt >> >> I have not talked to Christian about it but as the current maintainer >> of Stackless I was under the impression that there was a complete >> lack of interest in even considering it for integration. > > I think this comes from a major misunderstanding of how free software > works. This is not commercial software, so there is no "company > agenda" that drives it forward. There are various contributors, > each having their own agenda; for most of us, it's "scratch your > own itches". Surely, the voices of people have varying significance > (in Python, Guido is the BDFL, for example), but "there was a complete > lack of interest in even considering" just cannot be true: clearly, > some contributors and users *were* interested. > > There were surely objections to the implementation strategy, and > I also had objections to the specific execution of this > implementation strategy, see http://tinyurl.com/27v23r > > Now, the question is whose "job" it would have been to integrate > Stackless to Python. Apparently, Christian tried to make it happen > (see http://tinyurl.com/3bqe5d), although I'm still uncertain > whether he ever got to a point where he said: "this is a patch, > please review it" (of that, I can find no archives, as I said). > > I find it understandable that nobody else took over to work > on integrating it (although there is PEP 219, so apparently > some people worked at some point on it). > > From my point of view, people suggesting to incorporate code > as-is often misunderstand that it is not sufficient for the code > to work in the applications were it is used. It must also be sound > (i.e. work in some meaningful way also in cases for which it wasn't > designed), and it must be maintainable. > > I can understand how discouraging it is when you see that your > code "works" that then people object to incorporating it as-is. > However, I believe the long-term quality of Python can only > be guaranteed when careful review is applied to every change > made, or else we will regret changes in the future (and indeed, > Python 3000 would not have been necessary if no mistakes had > been made). > >> If addition of microthreading is being considered please consider >> Stackless. One reason why Stackless is not so popular is that >> as a fork people shy away from it because it is not the main >> version. It would benefit Stackless to be integrated and I would >> be willing to do any work involved to either integrate or maintain >> it afterwards. > > This is what I'm talking about: nothing "is" ever considered. Instead, > individuals make contributions, individuals review them, and individuals > support and object to changes. There is no abstract python-dev > entity that likes or dislikes changes. Individuals have individual > opinions. > > Now, where is the SF patch that makes Stackless part of Python ?-) > (and if you are serious about it, try to break it down into multiple > pieces, each individually correct and useful; start with one where > the effort isn't too big in case it gets rejected by BDFL > pronouncement) > > I haven't reviewed the Stackless code in a while; last I looked, > I found it was possible to crash the interpreter if you use it > "incorrectly". I *personally* object to changes where it is easy > to crash the interpreter, unless there is a clear specification > when this may happen, and there is a systematic way to avoid that > (this is the ctypes clause). > Well given that ctypes has now been incorporated I suspect that the objections to Stackless might be different should a further integration "effort" materialise. I know that there's work in progress (and indeed almost complete) to put Stackless into 2.5, so it seems as though it might be practical to follow the approach you suggest. 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. My (limited) understanding is that with Stackless installed *all* existing programs that don't import stackless should continue to run unchanged. If that's true then it seems to me it would be a desirable addition as long as maintainability wasn't compromised. I suppose only the patches will allow a sensible judgment on that issue. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://del.icio.us/steve.holden Blog of Note: http://holdenweb.blogspot.com See you at PyCon? http://us.pycon.org/TX2007
Re: [Python-Dev] New syntax for 'dynamic' attribute access
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 definitly should be a bracketed form, or else people
> always wonder what the precedence is, and add parenthesis
> anyway just to be on the safe side.
Indeed.
> BTW, which of these would be correct
>
> (a).[b]
Yes. (you can write (a).b today)
> (a.)[b]
No. (you can't write (a.)b today)
> a.[(b)]
Yes. (you can write a[(b)] today)
> a.([b])
No. (you can't write a([b]) today)
> a . [ b ]
Yes. (you can write a . b today)
In short, I'd just add a new form to Grammar's trailer:
trailer: '(' [arglist] ')' | '[' subscriptlist ']' | '.' attrtrailer
attrtrailer: '[' test ']' | NAME
This should be consistent and unsurprising.
> and what is the semantics of
>
> a.[42]
A TypeError, just as getattr(a, 42) would be.
I think I like the .[] form better, that being a +0 now.
Georg
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Interning string subtype instances
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 implementation ...] Because Python internals don't use that; they call PyString_InternInPlace directly. 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. This information can (and is) used by both Python core and by C extensions. Another advantage is that, as of recently, interned strings can be garbage collected, which is typically not true of simple replacements (although it could probably be emulated by using weak references, it's not trivial.) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New syntax for 'dynamic' attribute access
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_name)) > > from Lib/distutils/dist.py could be rewritten > >self.(method_name) = self.metadata.(method_name) > > The new syntax would also be usable in augmented assignments, as in > >obj.(attr_name) += 1 > > There was some discussion on python-ideas, which I've linked to in the > draft PEP below. In particular, Guido van Rossum wrote: > > > I've thought of the same syntax. I think you should submit this to the > > PEP editor and argue on Python-dev for its inclusion in Python 2.6 -- > > there's no benefit that I see of waiting until 3.0. > I don't like this. Just because an enhancement is syntactically permissible doesn't mean it's a good idea. This seems to me to take Python further away from the "Computer Programming for Everyone" arena and closer to the "Systems Programming for Clever Individuals" camp. > 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: > > * 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_name, 'default string') > > I agree that it looks odd, but perhaps the extra expressive power > gained might be worth the oddness. > It looks extremely odd. Since the opening parenthesis takes us into new syntactic territory the unimaginative use of the (already heavily overloaded) comma would sound the idea's death-knell. If we *have* to have this (and I agree with Greg that many uses cases for dynamic attribute access are invalid) then why not s = obj.(attr_name: 'default-string') I presume that the default value would in fact be an arbitrary expression? > * The draft implementation (a sourceforge patch, linked to in the draft > PEP) may have a general performance penalty of around 1%, although my > initial measurements were quite noisy. Josiah Carlson thought this > would not be too substantial, but he did suggest a couple of other > implementation routes which could be explored. The general > performance hit is offset by a speed gain of around 40% for attribute > access using the new syntax over getattr etc. Is 1% "too much" for > this feature? > Yes. I believe it would decrease the sum total of Python's efficiency for a very marginal return in performance on a very marginal feature. It threatens to reduce Python's readability substantially, and readability is more important than efficiency. "Expressive power" is all very well as long as the expressiveness is comprehensible. This proposal makes the left parenthesis carry a larger burden than the introduction of generator expressions did, and it makes Python a more difficult language to understand. [provisional PEP snipped] If it's added in 2.6 I propose it should be deprecated in 2.7 and removed from 3.0 ... regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://del.icio.us/steve.holden Blog of Note: http://holdenweb.blogspot.com See you at PyCon? http://us.pycon.org/TX2007 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Interning string subtype instances
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. This > information can (and is) used by both Python core and by C extensions. > Another advantage is that, as of recently, interned strings can be > garbage collected, which is typically not true of simple replacements > (although it could probably be emulated by using weak references, it's > not trivial.) 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). For example, in XML parsing, pyexpat supports an interning dictionary. It puts all element and attribute names into (but not element content, which typically isn't likely to be repeated). It starts with a fresh dictionary before parsing starts, and releases the dictionary when parsing is done. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New syntax for 'dynamic' attribute access
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, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Trial balloon: microthreads library in stdlib
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. The 'developer community en masse' does not have a single voice, so it won't object. Not sure about the BDFL, but I personally don't object 'to a change like that' 'in principle', primarily because I don't know what the change is. I know I'm almost certainly object to the change 'incorporate Stackless Python into Python as-is', because history shows that any change of that size would need multiple iterations until it was acceptable (despite the code being in-use for multiple years). Very few people can get away with getting their code unedited into Python (ctypes and elementtree being the most prominent examples); in these cases, I could accept what I consider flaws in the code because: a) the authors promised to maintain the code, and react to actual bug reports, and b) these come as extension modules, so it's easy to ignore them if you don't like them. > My (limited) understanding is that with Stackless installed *all* > existing programs that don't import stackless should continue to run > unchanged. If that's true then it seems to me it would be a desirable > addition as long as maintainability wasn't compromised. I suppose only > the patches will allow a sensible judgment on that issue. My understanding is that incorporating Stackless will reduce the portability: it cannot work on certain platforms, and even for platforms it works on, it cannot work with certain compilers or compiler switches (the Windows SEH being the primary example; the SPARC register stack another one - although this might now be supported through assembler code). On platforms where it isn't supported, it still may compile, but might crash the interpreter when used. Please understand that this is from a shallow inspection a few years ago (actually, a description of the working mechanics that Christian gave me). It would make me feel uncomfortable if Python had modules that may randomly crash the interpreter, and there is no procedure to tell beforehand whether a certain applications is supported or not. Also, I would not like to see modules that monkey-patch other modules in the standard library. If socket.connect is to behave differently, the code that makes that so should be *in* socket.connect, and the documentation of socket.connect should state that it has that modified behavior. Of course, people may object to massive library changes of the nature "if running in stackless mode, this library routine behaves differently". Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New syntax for 'dynamic' attribute access
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 you read code. This is
> my issue with the foo.(bar) syntax. The period is far far too small
> and easy to miss.
That's a good point, but I've been reading this thread in gmail
(proportional font) and quite often using the wrong glasses (:-)) and
I've found that the dot has never been that unreadable. Even where it
isn't very visible, it introduces an extra bit of space, which makes
me look again, and see what's going on.
In practice, I find that distinguishing {}, [] and () is harder...
Just a small data point.
Paul.
PS On the overall change, I'm +1, I don't have much opinion on exact
syntax. And I'd second the comments that the way the PEP has been
handled by Ben has been great - it's been very easy to follow what
could have been a really messy thread.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Interning string subtype instances
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 identical, they are quickly recognized as equal, and as not not-equal. Otherwise, if eq comparison is requested, it compares the size, then the first characters, then does memcmp - so if they are unequal, it doesn't help that they are both interned. If comparison is for notequal, no special casing is performed at all (except that knowing that identical strings aren't notequal). The entire algorithm and optimization works just as fine for a user-defined interning dictionary (assuming that all relevant strings get into it). Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New syntax for 'dynamic' attribute access
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 = self.(name) +try: +method = self.(name) +except AttributeError: +pass +else: if data is None: result = method(url, fp, errcode, errmsg, headers) else: result = method(url, fp, errcode, errmsg, headers, data) if result: return result return self.http_error_default(url, fp, errcode, errmsg, headers) -- Giovanni Bajo ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New syntax for 'dynamic' attribute access
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 = chain.get(kind, ())
for handler in handlers:
func = handler.[[meth_name]]
result = func(*args)
if result is not None:
return result
Little heavy on the eye, but it seems that it's exactly what people want and
can't find in the .[] syntax.
--
Giovanni Bajo
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Any value in setting up pybots for py3k?
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 considered too early. I would expect that packages break in massive ways because of the by-design incompatibilities. It would be good to get an estimate of what the impact is, but having a build once a month might be more than enough. To fully study the problems, one has to install Python 3 locally, anyway, and then run the package in question on top of that. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New syntax for 'dynamic' attribute access
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 Programming for Everyone Committee". Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Trial balloon: microthreads library in stdlib
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 such efforts useless. > > I think I need to try again. The 'developer community en masse' does > not have a single voice, so it won't object. Not sure about the BDFL, > but I personally don't object 'to a change like that' 'in principle', > primarily because I don't know what the change is. > > I know I'm almost certainly object to the change 'incorporate > Stackless Python into Python as-is', because history shows that > any change of that size would need multiple iterations until it > was acceptable (despite the code being in-use for multiple years). > Very few people can get away with getting their code unedited > into Python (ctypes and elementtree being the most prominent > examples); in these cases, I could accept what I consider flaws > in the code because: > a) the authors promised to maintain the code, and react to > actual bug reports, and > b) these come as extension modules, so it's easy to ignore > them if you don't like them. This makes a lot of sense. You have given a lot of food for thought and a path forward. If I gave an impression in my mails that I expected a consensus of objection, it was because I believed objection to Stackless to be an established thing and that it didn't matter whether there was consensus or not because someone would step forward and reiterate that. I didn't want to push the issue or invest wasted effort if that proved to be the case as mistakenly expected. At no time have I expected that Stackless would be added as-is. > > My (limited) understanding is that with Stackless installed *all* > > existing programs that don't import stackless should continue to run > > unchanged. If that's true then it seems to me it would be a desirable > > addition as long as maintainability wasn't compromised. I suppose only > > the patches will allow a sensible judgment on that issue. > > My understanding is that incorporating Stackless will reduce the > portability: it cannot work on certain platforms, and even for > platforms it works on, it cannot work with certain compilers > or compiler switches (the Windows SEH being the primary example; > the SPARC register stack another one - although this might now > be supported through assembler code). On platforms where it isn't > supported, it still may compile, but might crash the interpreter > when used. 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 support for additional platforms is rather straightforward and with access to them I can do it if required. I don't know about SEH but I believe support for SPARC was added in 2002. http://svn.python.org/view/stackless/trunk/Stackless/platf/switch_sparc_sun_gcc.h > Please understand that this is from a shallow inspection a few > years ago (actually, a description of the working mechanics that > Christian gave me). It would make me feel uncomfortable if Python > had modules that may randomly crash the interpreter, and there > is no procedure to tell beforehand whether a certain applications > is supported or not. Right. I imagine that if there are still problems like these, they will be brought to light when and if patches are submitted. But for now I will address what you mention just so that people don't assume they are still the case, especially since Stackless has been rewritten since then. > Also, I would not like to see modules that monkey-patch other > modules in the standard library. If socket.connect is to > behave differently, the code that makes that so should be > *in* socket.connect, and the documentation of socket.connect > should state that it has that modified behavior. Of course, > people may object to massive library changes of the nature > "if running in stackless mode, this library routine behaves > differently". Perhaps my pursuit of better support for asynchronous calls has led to some confusion. Stackless is an implementation with minimal changes to the core. It does not include any modules which monkey patch. However I have a replacement socket module based on asyncore which is not part of the Stackless distribution. If monkey patched it allows people to use sockets suitably in their microthreads. I am experimenting with this in order to see if I can make using Stackless as close to being as straightforward as writing normal Python code as possible, while still gaining the benefits which use of microthreads should allow. It was considered and quickly dismissed to modify the socket and file support in the core at C
Re: [Python-Dev] Interning string subtype instances
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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New syntax for 'dynamic' attribute access
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 functions.
Elsewhere in the thread, Calvin made the suggestion that, rather than
introducing new syntax, this could instead be achieved with a wrapper
class that automatically converted dict-style access into the
appropriate calls to getattr/setattr/delattr.
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 changes, and it provides a few other benefits:
- the two-argument form is naturally available as the .get() method
on the resulting dict-like object (e.g. "attrview(obj).get(some_attr,
None)")
- hasattr() is naturally replaced by containment testing (e.g.
"some_attr in attrview(obj)")
- keywords/builtins are easier to look up in the documentation than
symbolic syntax
With this approach, performance would be attained by arranging to create
the view objects once, and then performing multiple dynamic attribute
accesses using those view objects.
First urllib.py example::
name = 'open_' + urltype
self.type = urltype
name = name.replace('-', '_')
self_d = attrview(self)
if name in self_d:
if proxy:
return self.open_unknown_proxy(proxy, fullurl, data)
else:
return self.open_unknown(fullurl, data)
try:
if data is None:
return self_d[name](url)
else:
return self_d[name](url, data)
except socket.error, msg:
raise IOError, ('socket error', msg), sys.exc_info()[2]
Second urllib.py example::
name = 'http_error_%d' % errcode
self_d = attrview(self)
if name in self_d:
method = self_d[name]
if data is None:
result = method(url, fp, errcode, errmsg, headers)
else:
result = method(url, fp, errcode, errmsg, headers, data)
if result: return result
return self.http_error_default(url, fp, errcode, errmsg, headers)
First urllib.py example::
if attr[:12] == '_Request__r_':
name = attr[12:]
get_name = 'get_' + name
if get_name in attrview(Request):
self_d = attrview(self)
self_d[get_name]()
return self_d[attr]
raise AttributeError, attr
Second urllib2.py example::
handlers = chain.get(kind, ())
for handler in handlers:
func = attrview(handler)[meth_name]
result = func(*args)
if result is not None:
return result
Regards,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://www.boredomandlaziness.org
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Summary of "dynamic attribute access" discussion
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 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 PROTECTED] obj.[[foo]] and the "wrapper class" idea of Nick Coghlan: attrview(obj)[foo] (I personally think the "attrview" idea results in slightly cluttered-looking code, and prefer the visual simplicity of "obj.[foo]".) One of the new opinions against the feature at all was Steve Holden's: > This seems to me to take Python further away from the "Computer > Programming for Everyone" arena and closer to the "Systems Programming > for Clever Individuals" camp. I don't agree. People who find it clearer to write x = getattr(obj, attr_name) can continue to do so. Now, of course, a person with such a preference has no control over what other people write, so everybody will have to understand what the new syntax means, but I think it's quite mnemonic. It's a combination of the "." attribute look-up and the "[]" dictionary look-up. Steve, further down his message, continues: > It threatens to reduce Python's readability substantially I find obj.[attr_name] = other_obj.[attr_name] a much clearer expression of the "assignment" intent of this statement than setattr(obj, attr_name, getattr(other_obj, attr_name)) in the same way that I find my_dict[new_key] = new_value clearer than a hypothetical setvalue(my_dict, new_key, new_value) would be. Opinion is divided on whether it's a readability win, but I think it *is* a win. (Well, I would, I suppose). My experience in Matlab was that code became much more readable when they introduced "dynamic fields", especially in code which sets "fields" in one variable from "fields" in others. I don't know whether others on this list have worked in Matlab and have any opinions from their experience. Turning now to the performance question, Steve also writes: > > Is 1% "too much" for this feature? > > Yes. I believe it would decrease the sum total of Python's efficiency > for a very marginal return in performance on a very marginal feature. The performance question is important, certainly. Initial reaction on python-ideas was that a 1% cost would not count as substantial, but of course quicker would be better, and there were a couple of suggestions as to how the implementation could be improved. I agree that "readability is more important than efficiency", and I think a 1% efficiency loss would be "small" compared to what I think is a readability win, especially in cases like the example above. Thanks very much for all the interest in this idea. I think I've got enough of a sense of the list's reaction to update the PEP, and will do so over the next couple of days. I'll then re-post it so that everyone can check I haven't misrepresented their opinion, and take it from there. Ben. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Summary of "dynamic attribute access" discussion
[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 thinking about this on and off some more, and the only use case I can see that's even vaguely useful (imho) is method lookup. Most other cases I can think of are really better handled with dictionaries rather than objects. I'm not sure that this is really worth adding syntax for. > I think the "obj.[attr_name]" syntax has the most support. If there is to be new syntax, I prefer this over any of the other options. > and the "wrapper class" idea of Nick Coghlan: >attrview(obj)[foo] This also appeals - partly because it's not magic syntax > Steve, further down his message, continues: > > It threatens to reduce Python's readability substantially > I find >obj.[attr_name] = other_obj.[attr_name] > a much clearer expression of the "assignment" intent of this > statement than >setattr(obj, attr_name, getattr(other_obj, attr_name)) I guess that's a matter of preference - given how rarely I see constructs like this, I don't have a problem with the latter. (But see above comment about method lookup) I really cannot think of a single time where the setattr() form of this syntax is something I would have used. Anecdotally, I asked a couple of other folks for their opinions, and they were also fairly unimpressed with it (but of course the plural of anecdote is not "data" :-) so take that for what it's worth). > Opinion is divided on whether it's a readability win, but I think > it *is* a win. (Well, I would, I suppose). My experience in > Matlab was that code became much more readable when they > introduced "dynamic fields", especially in code which sets > "fields" in one variable from "fields" in others. I don't know > whether others on this list have worked in Matlab and have any > opinions from their experience. I haven't touched Matlab for many years - but why wouldn't using dictionaries be preferable here? You have much less restrictions on key names (vs attribute names), for instance. > Turning now to the performance question, Steve also writes: > > > Is 1% "too much" for this feature? > > > > Yes. I believe it would decrease the sum total of Python's > > efficiency for a very marginal return in performance on a very > > marginal feature. > > 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 through my filter of "marginal value". -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Trial balloon: microthreads library in stdlib
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 support for additional platforms is rather straightforward > and with access to them I can do it if required. I don't think portability to all systems should be necessary. Rather, there should be a clear demarcation as to what works and what not, and that demarcation should be fully understood so that anybody using it could know what the restrictions are. > I don't know about SEH but I believe support for SPARC was added > in 2002. > http://svn.python.org/view/stackless/trunk/Stackless/platf/switch_sparc_sun_gcc.h > My concern here is more of the kind "what about the next processor?" Is there some uniform way of dealing with it, if not, is there an explicit list of architectures supported? Is there, or could there be, an automated test telling whether the implementation will work? > Right. I imagine that if there are still problems like these, they > will be brought to light when and if patches are submitted. But for > now I will address what you mention just so that people don't > assume they are still the case, especially since Stackless has > been rewritten since then. This also contributes to misunderstanding. When is "then"? I'm talking about the "new" implementation, the one that bases on setjmp and longjmp, and copies slices of the stack around. It has been rewritten after that implementation strategy was implemented? > Perhaps my pursuit of better support for asynchronous calls > has led to some confusion. Stackless is an implementation > with minimal changes to the core. It does not include any modules > which monkey patch. That's good. > It was considered and quickly dismissed to modify the socket and > file support in the core at C level to do what was needed. Primarily > because it would complicate the limited changes we make to the > core. This is also something to consider: "minimize changes to the core" should not be a goal when contributing to the core (it certainly is when you maintain a fork). Feel free to make any changes you like, completely deviating from the current code base if necessary, as long as a) the resulting code still works in all cases where the old code did (if there are changes to the semantics, they need to be discussed), and b) the resulting code is still as maintainable and readable (or better in these respects) as the old code. This misconception is what kicked out the first attempt to merge setuptools: this was apparently written in a way to minimize changes to the core, and also to preserve semantics unmodified in all details. By doing so, it became less maintainable than if it had taken the liberty to change things. Of course, then you have two versions to maintain: the in-core version that nicely integrates, and the out-of-core version, that has minimal changes. It first takes effort to create the version to contribute, and then also the trick is how to keep both of them maintainable, ideally from a single source. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Summary of "dynamic attribute access" discussion
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 how to propose new > features in Python] Seconded. > I've been thinking about this on and off some more, and the only use > case I can see that's even vaguely useful (imho) is method lookup. > Most other cases I can think of are really better handled with > dictionaries rather than objects. I'm not sure that this is really > worth adding syntax for. > > > I think the "obj.[attr_name]" syntax has the most support. > > If there is to be new syntax, I prefer this over any of the other > options. Agreed again. > > and the "wrapper class" idea of Nick Coghlan: > >attrview(obj)[foo] > > This also appeals - partly because it's not magic syntax 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 = attrview(y)", both x and y refer to the same object, but use a different notation to access it. > > Steve, further down his message, continues: > > > It threatens to reduce Python's readability substantially > > I find > >obj.[attr_name] = other_obj.[attr_name] > > a much clearer expression of the "assignment" intent of this > > statement than > >setattr(obj, attr_name, getattr(other_obj, attr_name)) > > I guess that's a matter of preference - given how rarely I see > constructs like this, I don't have a problem with the latter. (But > see above comment about method lookup) I really cannot think of a > single time where the setattr() form of this syntax is something I > would have used. Anecdotally, I asked a couple of other folks for > their opinions, and they were also fairly unimpressed with it (but > of course the plural of anecdote is not "data" :-) so take that for > what it's worth). This is probably moot given the infrequency. > > Opinion is divided on whether it's a readability win, but I think > > it *is* a win. (Well, I would, I suppose). My experience in > > Matlab was that code became much more readable when they > > introduced "dynamic fields", especially in code which sets > > "fields" in one variable from "fields" in others. I don't know > > whether others on this list have worked in Matlab and have any > > opinions from their experience. > > I haven't touched Matlab for many years - but why wouldn't using > dictionaries be preferable here? You have much less restrictions on > key names (vs attribute names), for instance. > > > Turning now to the performance question, Steve also writes: > > > > Is 1% "too much" for this feature? > > > > > > Yes. I believe it would decrease the sum total of Python's > > > efficiency for a very marginal return in performance on a very > > > marginal feature. > > > > 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 through my filter > of "marginal value". I missed discussion of the source of the 1%. Does it slow down pystone or other benchmarks by 1%? That would be really odd, since I can't imagine that the code path changes in any way for code that doesn't use the feature. Is it that the ceval main loop slows down by having two more cases? That's extremely noisy data; I've seen cases where adding code would actually slow it up, due to the magic of cache collisions. If that's all, I am taking the 1% figure with a lot of salt. There was some discussion of grammar and priorities. IMO the '.' and '[' should remain separate tokens; the grammar for 'trailer' grows a new alternative: trailer: ... | '.' NAME | '.' '[' test ']' There are no ambiguities in this grammar. (Since it needs to evaluate to a string I don't see the need to use testlist.) Regarding hasattr(): yes, this won't have an alternative in syntax yet. IMO that's fine; it means we'll be catching AttributeError instead of using "look before you leap", which if fine with me. As for the 3-arg version of getattr(), it's still there. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Summary of "dynamic attribute access" discussion
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.obj = obj def __getitem__(self, name): return getattr(self.obj, name) def __setitem__(self, name, value): return setattr(self.obj, name, value) def __delitem__(self, name): return delattr(self, name) def __contains__(self, name): return hasattr(self, name) It's so easy people can include in their code for backwards compatibility; in Python 2.6, it could be a highly-efficient builtin (you still pay for the lookup of the name 'attrs', of course). Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New syntax for 'dynamic' attribute access
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 enough Python, but I don't think you need this specialized form of accessing attributes very often. So I've shifted to the "new syntax seems like overkill" camp. Besides, once you've got the attrview() you can use all the existing dict syntax and it looks totally clean. The original example: setattr(self, method_name, getattr(self.metadata, method_name) which became in the new syntax: self.[method_name] = self.metadata.[method_name] would be: attrview(self)[method_name] = attrview(self.metadata)[method_name] And an attrview lets you use get() and the in operator. Plus, if you were performing a lot of operations on attributes all at one go, you'd cache it in a local and then it'd look even better. Perhaps object.__attrs__() returns a view on the object's attributes, and attrview() is simply a convenience function. /larry/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Summary of "dynamic attribute access" discussion
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 more syntax for such a trivial and trivially-implemented feature. The syntax is no real benefit. -- Christopher Armstrong International Man of Twistery http://radix.twistedmatrix.com/ http://twistedmatrix.com/ http://canonical.com/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Summary of "dynamic attribute access" discussion
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 attrs, and >I think its specification is > >class attrs: > def __init__(self, obj): > self.obj = obj > def __getitem__(self, name): > return getattr(self.obj, name) > def __setitem__(self, name, value): > return setattr(self.obj, name, value) > def __delitem__(self, name): > return delattr(self, name) > def __contains__(self, name): > return hasattr(self, name) > >It's so easy people can include in their code for backwards >compatibility; in Python 2.6, it could be a highly-efficient >builtin (you still pay for the lookup of the name 'attrs', >of course). This looks nice. The simplicity of the implementation is great too. Jean-Paul ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Summary of "dynamic attribute access" discussion
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: >def __init__(self, obj): > self.obj = obj >def __getitem__(self, name): > return getattr(self.obj, name) >def __setitem__(self, name, value): > return setattr(self.obj, name, value) >def __delitem__(self, name): > return delattr(self, name) >def __contains__(self, name): > return hasattr(self, name) > > It's so easy people can include in their code for backwards > compatibility; in Python 2.6, it could be a highly-efficient > builtin (you still pay for the lookup of the name 'attrs', > of course). I fear people will confuse vars() and attrs() then. Georg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Summary of "dynamic attribute access" discussion
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 through my filter > of "marginal value". When speed loss was discussed, I was the one who stated that 1% wasn't substantial. Why? I've found variations of up to 3% in benchark times that seemed to be based on whether I was drinking juice or eating a scone while working. One percent is likely noise, in my experience, and the *speed* of Python has tended to gain double-digit percentage increases in the last few releases. - Josiah ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Summary of "dynamic attribute access" discussion
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 > compatibility; in Python 2.6, it could be a highly-efficient > builtin (you still pay for the lookup of the name 'attrs', > of course). attrview() (or whatever name it ultimately gets) feels Pythonic to me. It's a lot cleaner than getattr/setattr/hasattr/delattr. It's perhaps not entirely as pretty as .[], but it's close enough that I question whether adding new syntax is worth it. The easy backwards compatibility is the huge feature here, but there are a couple of others. Because attrview() can be made to support much of the dict interface, it can clearly express things the .[] syntax cannot, like: * attrview(obj).get(key, default) * attrview(obj).setdefault(key, []).append(x) Also, because attrview objects implement a mapping, they can be used in interesting ways in places that expect a mapping. (The locals parameter to eval() comes to mind, but I'm sure there would be many other good uses we won't be able to predict here.) 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 constructed, and so I fail to see what is problematic about it. You propose in PEP 3106 that Py3k's items/keys/values dictionary methods should return wrapper objects, which provide a different interface to the same data, and which can be used to mutate the underlying objects. Aren't the set of ailasing concerns in these two cases exactly the same? +1 for attrview(), +0 for .[] syntax. (-1 for .[] if attrview() is accepted.) Greg F ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Summary of "dynamic attribute access" discussion
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 is >> >> class attrs: >>def __init__(self, obj): >> self.obj = obj >>def __getitem__(self, name): >> return getattr(self.obj, name) >>def __setitem__(self, name, value): >> return setattr(self.obj, name, value) >>def __delitem__(self, name): >> return delattr(self, name) >>def __contains__(self, name): >> return hasattr(self, name) >> >> It's so easy people can include in their code for backwards >> compatibility; in Python 2.6, it could be a highly-efficient >> builtin (you still pay for the lookup of the name 'attrs', >> of course). > > I fear people will confuse vars() and attrs() then. > > Georg Would it be possible for attrview to be a property? Something like... (Probably needs more than this to handle all cases.) class obj(object): def _attrview(self): return self.__dict__ attr = property(_attrview) If it was this simple we just do obj.__dict__[foo] in the first place. Right? I'm overlooking something obvious I think, but the spelling is nice. obj[foo] -> access content obj.foo -> access attribute directly obj.attr[foo]-> access attribute dynamically Ron ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Summary of "dynamic attribute access" discussion
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): > return self.__dict__ > attr = property(_attrview) This doesn't handle descriptors, slots, non-dynamic instance methods, or even objects without a __dict__ . Generally speaking, you need a wrapper object. - Josiah ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Summary of "dynamic attribute access" discussion
"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 > constructed, and so I fail to see what is problematic about it. You > propose in PEP 3106 that Py3k's items/keys/values dictionary methods > should return wrapper objects, which provide a different interface to > the same data, and which can be used to mutate the underlying objects. > Aren't the set of ailasing concerns in these two cases exactly the > same? Only if it was spelled obj.attrview() . Having personally suggested a variant of attrview to others who have asked for dynamic attribute access in the past, I can't say I'm particularly convinced, today, that attrview(obj) or an equivalent is necessarily better than obj.[...] . Why? In order for it to be effective, either you need to save it to a name (cluttering up a namespace, adding mental overhead that values X and Y are really the same thing), or you need to keep calling attrview over and over (in which case you may as well stick to the getattr/setattr/delattr). I personally like the syntax, as my non-proportional font and syntax highlighting editor can easily be taught to recognize that particular bit of syntax and _really_ highlight it if I find that my brain can't do the pattern matching. 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% of which being the 3 argument form), and a trivial number of delattr calls. In terms of applications where dynamic attribute access tends to happen; see httplib, urllib, smtpd, the SocketServer variants, etc. - Josiah ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Summary of "dynamic attribute access" discussion
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 self.__dict__ > attr = property(_attrview) That wouldn't work: you really need to invoke the entire attribute lookup machinery (e.g. to find methods, invoke properties, and so on). Also, for 2.6, it wouldn't support old-style classes. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Summary of "dynamic attribute access" discussion
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 PROTECTED] >obj.[[foo]] > > and the "wrapper class" idea of Nick Coghlan: > >attrview(obj)[foo] For most cases where this is needed, why not just use a mixin class? That works perfectly well with current Python and doesn't even look funny: obj[foo] = blah print obj[foo] My company makes heavy use of this coding style, we can use obj.foo whenever appropriate. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "I disrespectfully agree." --SJM ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Summary of "dynamic attribute access" discussion
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 __getitem__ and friends and the need wouldn't exist. For that specific object. But the use case of general objects is different. On 2/13/07, Aahz <[EMAIL PROTECTED]> wrote: > 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 PROTECTED] > >obj.[[foo]] > > > > and the "wrapper class" idea of Nick Coghlan: > > > >attrview(obj)[foo] > > For most cases where this is needed, why not just use a mixin class? > That works perfectly well with current Python and doesn't even look > funny: > > obj[foo] = blah > print obj[foo] > > My company makes heavy use of this coding style, we can use obj.foo > whenever appropriate. > -- > Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ > > "I disrespectfully agree." --SJM > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Summary of "dynamic attribute access" discussion
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% of which being the 3 argument form), and > a trivial number of delattr calls. In terms of applications where > dynamic attribute access tends to happen; see httplib, urllib, smtpd, > the SocketServer variants, etc. Another data point: on our six-figure loc code base, we have 123 instances of getattr, 30 instances of setattr, and 0 instances of delattr. There are 5 instances of setattr( ... getattr( ... ) ) on one line (and probably a few more that grep didn't pick up that span multiple lines). As a comparison, enumerate (that I would have believed was much more frequent a priori), is used 67 times, and zip/izip 165 times. +1 on .[] notation and the idea in general. -Mike ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New syntax for 'dynamic' attribute access
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 access to the
> getattr/setattr/delattr builtin functions.
>
> Elsewhere in the thread, Calvin made the suggestion that, rather than
> introducing new syntax, this could instead be achieved with a wrapper
> class that automatically converted dict-style access into the
> appropriate calls to getattr/setattr/delattr.
>
In other words, an object view analagous to what Py3K is doing with
keys()/values()/items().
> 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 changes, and it provides a few other benefits:
>
>- the two-argument form is naturally available as the .get() method
> on the resulting dict-like object (e.g. "attrview(obj).get(some_attr,
> None)")
>
>- hasattr() is naturally replaced by containment testing (e.g.
> "some_attr in attrview(obj)")
>
>- keywords/builtins are easier to look up in the documentation than
> symbolic syntax
>
Yeah, the generalization is really nice. It allows use to ditch
getattr/setattr/hasattr all without losing the expressiveness of those
built-ins.
> With this approach, performance would be attained by arranging to create
> the view objects once, and then performing multiple dynamic attribute
> accesses using those view objects.
>
> First urllib.py example::
>
> name = 'open_' + urltype
> self.type = urltype
> name = name.replace('-', '_')
> self_d = attrview(self)
> if name in self_d:
> if proxy:
> return self.open_unknown_proxy(proxy, fullurl, data)
> else:
> return self.open_unknown(fullurl, data)
> try:
> if data is None:
> return self_d[name](url)
> else:
> return self_d[name](url, data)
> except socket.error, msg:
> raise IOError, ('socket error', msg), sys.exc_info()[2]
>
> Second urllib.py example::
>
> name = 'http_error_%d' % errcode
> self_d = attrview(self)
> if name in self_d:
> method = self_d[name]
> if data is None:
> result = method(url, fp, errcode, errmsg, headers)
> else:
> result = method(url, fp, errcode, errmsg, headers, data)
> if result: return result
> return self.http_error_default(url, fp, errcode, errmsg, headers)
>
>
> First urllib.py example::
>
> if attr[:12] == '_Request__r_':
> name = attr[12:]
> get_name = 'get_' + name
> if get_name in attrview(Request):
> self_d = attrview(self)
> self_d[get_name]()
> return self_d[attr]
> raise AttributeError, attr
>
> Second urllib2.py example::
>
> handlers = chain.get(kind, ())
> for handler in handlers:
> func = attrview(handler)[meth_name]
> result = func(*args)
> if result is not None:
> return result
>
I also think it is just as clean as doing it any of the proposed ways::
getattr(self, name)
self.[name]
attrview(self)[name]
So my vote is for Nick's object attribute view; +1. If we are going
to do the view thing, let's go all the way! =)
-Brett
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Summary of "dynamic attribute access" discussion
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 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. In terms of applications where >> dynamic attribute access tends to happen; see httplib, urllib, smtpd, >> the SocketServer variants, etc. > >Another data point: on our six-figure loc code base, we have 123 >instances of getattr, 30 instances of setattr, and 0 instances of >delattr. There are 5 instances of setattr( ... getattr( ... ) ) on >one line (and probably a few more that grep didn't pick up that span >multiple lines). Another data point: in our six-figure loc code base, we have 469 instances of getattr, 91 instances of setattr, and 0 instances of delattr. There is one instances of setattr(..., getattr(...)), and one instance of setattr(getattr(...), ...). > >+1 on .[] notation and the idea in general. > -1 on a syntax change for this. Somewhere between -0 and +0 for a builtin or library function like attrview(). Jean-Paul ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Summary of "dynamic attribute access" discussion
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 that Mike> span multiple lines). 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 they existed in 1.5, and perhaps as far back as 1.0. If you really want to compare the two, go back to your code baseline before enumerate was added to Python (2.3?) and subtract from your counts all the *attr calls that existed then and then compare the adjusted counts with enumerate. Given that you have more uses of zip/izip maybe we should be discussion syntactic support for that instead. ;-) Mike> +1 on .[] notation and the idea in general. Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New syntax for 'dynamic' attribute access
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. Adding syntax is a very big >step, and it needs a very solid reason to jusify >it. I don't see this filling a use case that's >anywhere near common enough to reach that >threshold. I also strongly dislike every syntax that has thus far been proposed, but even if I loved them, there is just no motivating use-case. New syntax is not going to make dynamic attribute access easier to understand, and it *is* going to cause even more version-compatibility headaches. I really, really wish that every feature proposal for Python had to meet some burden of proof, or submit a cost/benefit analysis. Who is this going to help? How much is this going to help them? "Who is this going to hurt" is easy, but should also be included for completeness - everyone who wants to be able to deploy new code on old Pythons. I suspect this would kill 90% of "hey wouldn't this syntax be neat" proposals on day zero, and the ones that survived would be a lot more interesting to talk about. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Summary of "dynamic attribute access" discussion
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 _attrview(self): >> return self.__dict__ >> attr = property(_attrview) > > That wouldn't work: you really need to invoke the entire attribute > lookup machinery (e.g. to find methods, invoke properties, and so > on). Also, for 2.6, it wouldn't support old-style classes. > > Regards, > Martin Yes, I thought that might be a problem. So I guess I'm for the shortened version which wouldn't conflict with a property and could be made to work in more cases. +1 obj.[foo] I don't care for the longer attrview() as it adds another level of indirectness. I feel that is a counter solution to the point of the suggested syntax. Ron ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Summary of "dynamic attribute access" discussion
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 for such > dynamic access, sure, I'd implement __getitem__ and friends and the > need wouldn't exist. For that specific object. But the use case of > general objects is different. 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 and documentation. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "I disrespectfully agree." --SJM ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Trial balloon: microthreads library in stdlib
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 existing framework that does this seems better than >> reinventing the wheel, for something of this magnitude. > >This to me seems to be the low level support you would build >something like Twisted on top of. Pushing Twisted so that others >can get it seems a little over the top. It sounds like you don't really understand what Twisted is, what it does, or the difficulty involved in building that "low level" so that it's usable by something like Twisted. Tristan is correct: this should be a patch against Twisted, or perhaps as a separate library that could implement a reactor. I have no problem with other, competing event-driven mechanisms being developed; in fact, I think it's great that the style of programming is getting some attention. But this is not a robust and straightforward wrapping of some lower level. This is an entirely new, experimental project, and the place to start developing it is _NOT_ in the Python core. Another post in this thread outlined that the first thing you should do is develop something and get people in the community to use it. Please do that, start its own mailing list, and stop discussing it here. On a personal note, I believe that "those who do not understand twisted are doomed to repeat it". I predict that the ultimate outcome of this project will be that all concerned will realize that, actually, Twisted already does almost everything that it proposes, 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. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Summary of "dynamic attribute access" discussion
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 freshly updated 2.5 trunk. The results: 228 1119 18032 sets 679 3547 52532 gets 30 105 2003 dels 937 4771 72567 total Here's wc on all those .py files: 471821 1659218 16585060 total So 937 lines out of 471,821 lines called *attr() functions, or very nearly 0.2%. I'm now totally convinced: +1 on attrview(), -1 on a syntax change. This is a minor improvement for 1 out of every 500 lines, and the class arguably nicer anyway. (Of the syntax changes, I still prefer ".[]".) /larry/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Summary of "dynamic attribute access" discussion
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 they existed in 1.5, and perhaps as far back as 1.0. If you > really want to compare the two, go back to your code baseline before > enumerate was added to Python (2.3?) and subtract from your counts all the > *attr calls that existed then and then compare the adjusted counts with > enumerate. The entire codebase was developed post-2.4, and I am a bit of an enumerate-nazi, so I don't think that is a concern . > Given that you have more uses of zip/izip maybe we should be discussion > syntactic support for that instead. ;-) There are even more instances of len()... len(seq) -> |seq|? -Mike ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Summary of "dynamic attribute access" discussion
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:
927 611 dels
488 2637 38947 gets
120 539 8644 sets
617 3203 48202 total
So 617 lines out of 471,821 lines called *attr() functions, or 0.13%.
In other words *attr() functions are used on 1 out of every 764 lines.
/larry/
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Summary of "dynamic attribute access" discussion
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-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New syntax for 'dynamic' attribute access
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 changes, and it provides a few other benefits: > >- the two-argument form is naturally available as the .get() method > on the resulting dict-like object (e.g. "attrview(obj).get(some_attr, > None)") > >- hasattr() is naturally replaced by containment testing (e.g. > "some_attr in attrview(obj)") > >- keywords/builtins are easier to look up in the documentation than > symbolic syntax > > With this approach, performance would be attained by arranging to create > the view objects once, and then performing multiple dynamic attribute > accesses using those view objects. This changes my vote: +1 on including attrview(), -1 on the syntax proposal. Collin Winter ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New syntax for 'dynamic' attribute access
> 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 changes, and it provides a few other benefits: > > > >- the two-argument form is naturally available as the .get() method > > on the resulting dict-like object (e.g. "attrview(obj).get(some_attr, > > None)") > > > >- hasattr() is naturally replaced by containment testing (e.g. > > "some_attr in attrview(obj)") > > > >- keywords/builtins are easier to look up in the documentation than > > symbolic syntax > > > > With this approach, performance would be attained by arranging to create > > the view objects once, and then performing multiple dynamic attribute > > accesses using those view objects. On 2/13/07, Collin Winter <[EMAIL PROTECTED]> wrote: > This changes my vote: +1 on including attrview(), -1 on the syntax proposal. Me too! I imagine that the addition of the proposed "obj.[name]" syntax to Python 2.6 would lead to more software that will not run on 2.5 and earlier versions. I don't think the benefits outweigh this backward incompatibility of new code. Therefore I'm -1 on including "obj.[name]" in Python 2.6. For Python 3000, I think it would be alright. With "attrview(obj)[name]" it would be possible to provide a fallback implementation in the same module for pre-2.6 users, so +1 for that. Johann C. Rocholl ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New syntax for 'dynamic' attribute access
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 mymodule
Sorry for the noise,
Armin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New syntax for 'dynamic' attribute access
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):
> pass
>
> import *modname as mymodule
>
>
>
Are you for these uses or mocking them ? Some of them look interesting...
FWIW, at Resolver (75k lines of IronPython code currently) we use
getattr / setattr almost as many as 8 times. (I was very surprised at
how low that was.)
That said, when I explained the proposal to two of my colleagues both of
them were *very* happy with the obj.[name] suggestion.
Michael Foord
> Sorry for the noise,
>
> Armin
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk
>
>
>
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Summary of "dynamic attribute access" discussion
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 and > documentation. Ok. I just spent a little time looking in the top level of the stdlib. I count 102 uses of 2-arg getattr. Here's what getattr() is used for: Putting aside all of the stuff that does introspection of objects (pydoc, cgitb, copy, &c - I don't care that these have a slightly more verbose spelling, since writing this sort of introspection tool is hardly a common thing to do throughout a codebase) there's really only three use cases: - Cheap inheritence, ala def __getattr__(self, attr): return getattr(self.socket, attr) - Method lookup by name - as I suspected, this is the #1 use case. - Looking things up in modules - you're generally only going to do a small amount of this, once per module. The other uses of it make up a fairly small handful - and looking at them, there's better ways to do some of them. setattr is even less used. Most uses of it are for copying the attributes of one object en masse to another object. This can be encapsulated in a quickie function to do the work. So based on this quick survey, I _strongly_ question the need for the new syntax. New syntax should need to vault vastly higher hurdles before getting into Python - it's just not possible to write code that's backwards compatible once you add it. I just don't see that this comes even close. We're already looking at a big discontinuity with 2.x -> 3.x in terms of compatibility, I think adding another for 2.5->2.6, for what I consider a marginal use case is VERY BAD. Something like the attrview (or attrdict, the name I'd use) _can_ be done in a backwards compatible way, where people can distribute a workalike with their code. I doubt I'd use it, either, but it's there for people who need it. I again ask for examples of other compelling uses that wouldn't be better solved by using a dictionary with keys rather than an object with attributes. Anthony ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Recent experience with the _ast module
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 mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Trial balloon: microthreads library in stdlib
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 original Stackless implementation certainly was, and to my knowledge nobody has ever suggested a way to do better. If someone could come up with a plan for a stackless interpreter that was just as straightforward as the existing one, that would be worth considering. But I won't be holding my breath. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Trial balloon: microthreads library in stdlib
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 done entirely in userspace. Here's some code I wrote a few months ago but never got around to using it. (Or testing it, for that matter, so it may not work, or even compile!) It requires Python 2.5 and the "simplegeneric" package from the Cheeseshop, and it allows you to "spawn" generators to create independently-running pseudothreads. These pseudothreads can yield to Deferreds, "returning" the value or failure thereof. (Failures cause the error to be raises such that it appears to happen at the yield point.) There are also a few other yield targets like "Return" (to return a value to a calling co-routine), "Pause" (to delay resumption), and "with_timeout" (to wrap some other yieldable in a timeout that raises TimeoutError). Enjoy! import types from twisted.internet import reactor from twisted.internet.defer import Deferred, TimeoutError from twisted.python import failure from simplegeneric import generic from functools import partial __all__ = [ # user APIs: 'spawn', 'Pause', 'Return', 'with_timeout', # extension APIs: 'schedule', 'resume', 'throw', 'current_task', 'yield_to', 'yieldable', ] def spawn(geniter, delay=0): """Create a new task and schedule it for execution Usage:: spawn(someGeneratorFunc(args)) The given generator-iterator will be run by the Twisted reactor after `delay` seconds have passed (0 by default). The return value of this function is a "task" object that can be passed to the ``schedule()``, ``throw()``, and ``yield_to()`` APIs. """ task = [geniter] schedule(task, delay) return task def schedule(task, delay=0, value=None): """Schedule `task` to resume after `delay` seconds (w/optional `value`)""" if task: return reactor.callLater(delay, resume, task, value) # XXX warn if non-None value sent to empty task? def resume(task, value=None): """Resume `task` immediately, returning `value` for the current yield""" if task: _invoke(task, partial(task[-1].send, value)) # XXX warn if non-None value sent to empty task? def throw(task, exc): """Raise `exc` tuple in `task` and immediately resume its execution""" if not task: # Propagate exception out of a failed task raise exc[0], exc[1], exc[2] _invoke(task, partial(task[-1].throw, *exc)) def _invoke(task, method): """Invoke method() in context of `task`, yielding to the return value""" try: value = method() except StopIteration: task.pop() # it's an exit with no return value resume(task)# so send None up the stack except: task.pop() # Propagate exception up the stack throw(task, sys.exc_info()) else: # Handle a yielded value yield_to(value, task) @generic def yield_to(value, task): """Handle a yielded value To register special handlers, use [EMAIL PROTECTED]()`` or or [EMAIL PROTECTED]()``. (See the ``simplegeneric`` docs for details.) """ raise TypeError( "Unrecognized yield value (maybe missing Return()?): %r" % (value,) ) @yield_to.when_type(defer.Deferred): def _yield_to_deferred(value, task): """Return a deferred value immediately or pause until fired""" def _resume(value): if isinstance(value, failure.Failure): throw(task, (type(value), value, None)) # XXX extract error? else: resume(task, value) return value# don't alter the deferred's value # This will either fire immediately, or delay until the appropriate time value.addCallbacks(_resume, _resume) @yield_to.when_type(types.GeneratorType) def _yield_to_subgenerator(value, task): """Call a sub-generator, putting it on the task's call stack""" task.append(value) schedule(task) def yieldable(f): """Declare that a function may be yielded to Usage:: @yieldable def do_something(task): # code that will be invoked upon (yield do_something) (yield do_something) The function's return value will be ignored, and errors in it are NOT caught! It must instead use the ``resume()``, ``schedule()``, ``throw()``, or ``yield_to()`` APIs to communicate with the yielding task (which is provided as the sole argument.) """ f.__yieldable__ = True return f @yield_to.when_type(types.FunctionType) def _yield_to_function(value, task): """Invoke task-management function""" if getattr(value, '__yieldable__', None): return value(task) # function is marked as yieldable else
Re: [Python-Dev] New syntax for 'dynamic' attribute access
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 those, wherever possible. AttributeError can be raised by too many things for me to feel comfortable about catching it. This suggests that any proposed getattr syntax should include a way of specifying a default value. I'm still -1 on the basic idea, though, on the grounds of YAGNIOE (You Aren't Going to Need It Often Enough). -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New syntax for 'dynamic' attribute access
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, 42), which depends on a's __getattr__ implementation. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Trial balloon: microthreads library in stdlib
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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Summary of "dynamic attribute access" discussion
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 = attrview(y)", > both x and y refer to the same object, but use a different > notation to access it. Just touching on this - I meant to earlier. I'm really unsure why this is a problem. We already have similar cases, for instance dict.keys()/values()/items(). The globals() and locals() builtins also provide an alternate view with "different notation to access it". Since you're creating the view explicitly, I really don't see the problem - any more than say, creating a set from a list, or a dict from a list, or the like. Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Recent experience with the _ast module
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 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. Or at least I suspect; Martin can tell me I'm wrong if I am.
-Brett
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New syntax for 'dynamic' attribute access
-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. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRdJaynEjvBPtnXfVAQJHuQP7B7FlA5wO28dEW62q3VSOr7iUm/6FLZ/6 hoXq47S1F/Yre0bl9p1C2bOCAXeBNXoQC55oPw4a4XUC3C2G/Pf3TJnlOZ0u1M7y 5Ug8MbDxf8SvHl3efZSOjvx2S8OPv0m11teP+d9l11upXz7ASAVlwYZhKRMum6/s ECxTGOKH2tc= =ZSIW -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Interning string subtype instances
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 just use 'is' to compare them. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Recent experience with the _ast module
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
always a tuple. Where _fields used to be None, it's now a 0-element
tuple.
2) It turned out that {BinOp, BoolOp,AugAssign,etc}.op were already
singleton instances of their respective classes. I've changed
asdl_c.py to no longer emit the *_singleton names and to use the
corresponding *_type types in their place, which will enable me to
write "node.op is _ast.Add", etc.
3) Adding an Else node was a little more involved, but it proved
do-able. TryFinally.orelse, While.orelse, For.orelse and If.orelse can
now be either None or an instance of Else. Else instances have a
'body' attribute, which is a sequence of statements.
Thanks,
Collin Winter
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New syntax for 'dynamic' attribute access
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 dot and bracket *should* be separare tokens, perhaps because I would be thinking of the [x] as a special kind of argument to the dot operator, rather than there being a funny new operator called ".[". -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New syntax for 'dynamic' attribute access
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 <[EMAIL PROTECTED]> wrote: > 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. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New syntax for 'dynamic' attribute access
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 turn it into a single token (which we just may for Py3k) don't complain if your code breaks. > It's something of an arbitrary choice, but to me it just > seems that the dot and bracket *should* be separare > tokens, perhaps because I would be thinking of the > [x] as a special kind of argument to the dot operator, > rather than there being a funny new operator called ".[". Yes, that's how I was thinking of it. But it's all moot now. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Summary of "dynamic attribute access" discussion
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 sub-expressions, i.e. try: x = getattr(obj, name) except AttributeError: ... else: ... If you're doing that, I see no significant lack of readability in the getattr call that needs to be remedied. So I'm down to -2 now. :-) -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Summary of "dynamic attribute access" discussion
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. :-) -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Summary of "dynamic attribute access" discussion
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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Summary of "dynamic attribute access" discussion
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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Summary of "dynamic attribute access" discussion
[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): ... -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Trial balloon: microthreads library in stdlib
[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 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. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Recent experience with the _ast module
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 go from C enum --> some object, which could as well be an interned string as anything else. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Summary of "dynamic attribute access" discussion
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. I don't really buy that. Frequency of use must be balanced against the improvement in legibility. Assuming that my figures bear some correspondence to typical usage patterns, enumerate() was introduced despite the older idiom of for i, item in zip(xrange(len(seq)), seq): being less frequent than getattr. SImilarly, I see no clamor to add syntactic support for len(). It's current usage is clear. [note: this post is not continuing to argue in favour of the proposal] -Mike ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New syntax for 'dynamic' attribute access
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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Interning string subtype instances
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 PyString_CHECK_INTERNED macro that tests a field in the string object header. But, I can't find anywhere that it's used in the core, apart from the interning code itself and the string alloc/dealloc code. Can anyone shed any light on this? It seems to me that by not using this information, only half the benefit of interning is being achieved. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Summary of "dynamic attribute access" discussion
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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Trial balloon: microthreads library in stdlib
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: > >The need for different event-driven mechanisms to compete >with each other is the very problem that needs to be >addressed. > Invites a response which merely contradicts it (for example, "you are wrong"), an exchange which hasn't helped anyone to understand anything better. If you present supporting evidence for the position, then the validity and the weight of that evidence can be discussed, and one position or another might be shown to have greater validity. Also, show that you have fully understood the position you are arguing against. For example, if you respond to a message in which someone claims to welcome something, don't respond by saying that requiring that thing is bad. As you know, welcoming something is not the same as requiring that thing, so by making this statement alone, you give the impression of talking past the person to whom you are responding and it may seem to readers that you haven't understood the other person's position. >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. > Here, you've built on your unsupported premise to arrive at a conclusion which may be controversial. Again, instead of couching the debate in terms of what you might see as self evidence problems, explain why you hold the position you do. That way, the possibility is created for other people to come to understand why you believe the conclusion to be valid. You have presented what could be the beginning of supporting evidence here, in saying that requiring "everything else" to be modified is undesirable. This is only a place to start, not to end, though. You may want to discuss the real scope of modifications required (because "everything" is obviously hyperbole, focusing on what changes are actually necessary would be beneficial) and why you think that modifications are necessary (it may not be clear to others why they are, or it may be the case that others can correct misconceptions you have). For example, you might give a case in which you have needed to integrate Twisted (or a different event framework) with another event loop and describe difficulties you discovered. This will help advance the discussion around practical, specific concerns. Without this focus, it is hard for a discussion to be productive, since it will involve only vague handwaving. Finally, it is often beneficial to avoid bringing up phrases such as "the problem". Particularly in a context such as this, where the existing discussion is focusing on a specific issue, such as the necessity or utility of adding a new set of functionality to the Python standard library, the relevance of "the problem" may not be apparent to readers. In this case, some may not find it obvious how a third party library can be "the problem" with such new functionality. If you explicitly spell out the detrimental consequences of an action, instead of waving around "the problem", the resulting discussion can be that much more productive and focused. Thanks Jean-Paul ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Twisted Isn't Specific (was Re: Trial balloon: microthreads library in stdlib)
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 the form "that's twisted-specific". The thing is, Twisted isn't specific. Its event mechanism isn't "special". In fact it's hard to imagine how it might be made less "special" than it currently is. Whatever your event dispatch mechanism, *some* code has to be responsible for calling the OS API of select(), WaitForMultipleEvents(), g_main_loop_run(), or whatever. Twisted actually imposes very few requirements for code to participate in this, and was designed from day one specifically to be a generalized mainloop mechanism which would not limit you to one underlying multiplexing implementation, event-dispatch mechanism, or operating system if you used its API. There have even been a few hacks to integrate Twisted with the asyncore mainloop, but almost everyone who knows both asyncore and Twisted has rapidly decided to just port all of their code to Twisted rather than maintain that bridge. In fact, Twisted includes fairly robust support for threads, so if you really need it you can mix and match event-driven and blocking styles. Again, most people who try this find that it is just nicer to write straight to the Twisted API, but for those that need really it, such as Zope and other WSGI-contained applications, it is available. Aside from the perennial issue of restartable reactors (which could be resolved as part of a stdlib push), Twisted's event loop imposes very few constraints on your code. It provides a lot of tools, sure, but few of them are required. You don't even *need* to use Deferreds. Now, "Twisted", overall, can be daunting. It has a lot of conventions, a lot of different interfaces to memorize and deal with, but if you are using the main loop you don't have to necessarily care about our SSH, ECMA 48, NNTP, OSCAR or WebDAV implementation. Those are all built at a higher level. It may seem like I'm belaboring the point here, but every time a thread comes up on this list mentioning the possibility of a "standard" event mechanism, people who do not know it very well or haven't used it start in with implied FUD that Twisted is a big, complicated, inseparable hairy mess that has no place in the everyday Python programmer's life. It's tangled-up Deep Magic, only for Wizards Of The Highest Order. Alternatively, more specific to this method, it's highly specific and intricate and very tightly coupled. Nothing could be further from the truth. It is *strictly* layered to prevent pollution of the lower levels by higher level code, and all the dependencies are one-way. Maybe our introductory documentation isn't very good. Maybe event-driven programming is confusing for those expecting something else. Maybe the cute names of some of the modules are offputting. Still, all that aside, if you are looking for an event-driven networking engine, Twisted is about as straightforward as you can get without slavishly coding to one specific platform API. When you boil it down, Twisted's event loop is just a notification for "a connection was made", "some data was received on a connection", "a connection was closed", and a few APIs to listen or initiate different kinds of connections, start timed calls, and communicate with threads. All of the platform details of how data is delivered to the connections are abstracted away. How do you propose we would make a less "specific" event mechanism? I strongly believe that there is room for a portion of the Twisted reactor API to be standardized in the stdlib so that people can write simple event-driven code "out of the box" with Python, but still have the different plug-in implementations live in Twisted itself. The main thing blocking this on my end (why I am not writing PEPs, advocating for it more actively, etc) is that it is an extremely low priority, and other, higher level pieces of Twisted have more pressing issues (such as the current confusion in the "web" universe). Put simply, although it might be nice, nobody really *needs* it in the stdlib, so they're not going to spend the effort to get it there. If someone out there really had a need for an event mechanism in the standard library, though, I encourage them to look long and hard at how the existing interfaces in Twisted could be promoted to the standard library and continue to be maintained compatibly in both places. At the very least, standardizing on something very much like IProtocol would go a long way towards making it possible to write async clients and servers that could run out of the box in the stdlib as well as with Twisted, even if the specific hookup mechanism (listenTCP, listenSSL, et. al.) were incompatible - although a
