Re: [Python-Dev] 'hasattr' is broken by design
On 24/08/2010 01:25, Nick Coghlan wrote: On Tue, Aug 24, 2010 at 8:15 AM, Nick Coghlan wrote: Now, it may be worth considering an addition to the inspect module that was basically: def getattr_static(obj, attr): """Retrieve attributes without triggering dynamic lookup via the descriptor protocol, __getattr__ or __getattribute__. Note: this function may not be able to retrieve all attributes reported by dir(obj) """ try: instance_dict = object.__getattribute__(obj, "__dict__") except AttributeError: pass else: if attr in instance_dict: return instance_dict[attr] for entry in getmro(obj.__class__): try: return entry.__dict__[attr] except AttributeError: pass Second attempt with a default value parameter and correctly raising AttributeError if not found: _sentinel = object() def getattr_static(obj, attr, default=_sentinel): """Retrieve attributes without triggering dynamic lookup via the descriptor protocol, __getattr__ or __getattribute__. Note: this function may not be able to retrieve all attributes reported by dir(obj) """ try: instance_dict = object.__getattribute__(obj, "__dict__") except AttributeError: pass else: if attr in instance_dict: return instance_dict[attr] for entry in getmro(obj.__class__): try: return entry.__dict__[attr] except AttributeError: pass if default is not _sentinel: return default raise AttributeError(attr) This doesn't correctly handle the case where obj is a type object or obj uses __slots__. If I have time (currently on vacation with only intermittent internet access) I'll provide an update. Michael Cheers, Nick. -- http://www.ironpythoninaction.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] 'hasattr' is broken by design
On 08/23/2010 04:56 PM, Guido van Rossum wrote:
On Mon, Aug 23, 2010 at 7:46 AM, Benjamin Peterson wrote:
2010/8/23 Yury Selivanov:
1) I propose to change 'hasattr' behaviour in Python 3, making it to swallow
only AttributeError exceptions (exactly like 'getattr'). Probably, Python 3.2
release is our last chance.
I would be in support of that.
I am cautiously in favor. The existing behavior is definitely a
mistake and a trap. But it has been depended on for almost 20 years
now.
I'll note that a similar incompatible change has made it to python2.6.
This has bitten us in production:
class X(object):
def __getattr__(self, name):
raise KeyError, "error looking for %s" % (name,)
def __iter__(self):
yield 1
print list(X())
I would expect it to print [1], and in python2.5 it does. In python2.6
it raises a KeyError! The attribute being looked up is an unexpected one:
{hrzagude5003}[~]$ python2.6 a.py
Traceback (most recent call last):
File "a.py", line 8, in
print list(X())
File "a.py", line 3, in __getattr__
raise KeyError, "error looking for %s" % (name,)
KeyError: 'error looking for __length_hint__'
The __length_hint__ lookup expects either no exception or
AttributeError, and will propagate others. I'm not sure if this is a
bug. On the one hand, throwing anything except AttributeError from
__getattr__ is bad style (which is why we fixed the bug by deriving our
business exception from AttributeError), but the __length_hint__ check
is supposed to be an internal optimization completely invisible to the
caller of list().
Being aware that this can be construed as an argument both in favor and
against the change at hand, my point is that, if propagating
non-AttributeError exceptions is done in checks intended to be
invisible, it should certainly be done in hasattr, where it is at least
obvious what is being done. Other generic functions and operators,
including boolean ones such as ==, happily propagate exceptions.
Also, don't expect that this won't break code out there. It certainly
will, it's only a matter of assessment whether such code was broken in a
different, harder to detect way, to begin with.
___
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] 'hasattr' is broken by design
On Tue, 24 Aug 2010 11:09:10 am Guido van Rossum wrote: > On Mon, Aug 23, 2010 at 4:56 PM, Steven D'Aprano wrote: [...] > > I have always thought that hasattr() does what it says on the box: > > it tests for the *existence* of an attribute, that is, one that > > statically exists rather than being dynamically generated. In other > > words, it is a key in the instance __dict__ or is inherited from > > the class __dict__ or that of a superclass, or a __slot__. > > It tests for the existence of an attribute -- how the attribute is > defined should not have to occur to you But that's the thing... as far as I am concerned, a dynamically defined attribute *doesn't* exist. If it existed, __getattr__ would never be called. A minor semantic difference, to be sure, but it's real to me. Whether I should care about the difference is a separate issue. This conversation has been valuable to me for one thing though... it reminded me of a piece of code I had written a long time ago. A simplified version: class K(object): def __getattribute__(self, name): if hasattr(self, name): # no computation needed print "Attr exists" else: # compute something... print "Attr doesn't exist" I couldn't work out why it was behaving so strangely, and rather than spend time investigating, I abandoned the whole dynamic attribute approach and did something completely different. So at least now I know why it wasn't working as I expected. > (and there are lots of other > ways for attributes to be defined besides the ways you came up with > just now). I never suggested that it would be easy. > > Now that I know that hasattr doesn't do what I thought it does or > > what the name implies it does, it has little or no utility for me. > > In the future, I'll just write a try...except block and catch > > errors if the attribute doesn't exist. > > The try/except block *also* requires you to break your train of > thought. And most of the time the error case just isn't important. > You sound like you are over-engineering it and focusing too much on > performance instead of on getting things done. Performance could be an issue, of course, if somebody writes an expensive __getattr__ or property. Computed attributes should be cheap. But I'm actually more concerned about side-effects than performance. If I'm not worried about potential side-effects, I use a try...except block. If I am worried, I "Look Before You Leap". Only now I've learned that what I thought was LBYL is nothing of the sort, and hasattr gives me no protection against side-effects. That being the case, I might as well just stick to try...except and be done with it. I'm not suggesting this is the One True Way. If others prefer hasattr, then I have no problem with that. I'm just saying that now that I know what it actually does, its value *for me* is minimal. > Like those people who > learn that it saves an usec to copy a built-in function into a defalt > arg (def foo(arg1, len=len): ...) and then overuse the trick even > when the time it took them to write the exra line is more than the > time they'll save in a lifetime in execution time. Aha! The penny drops! Is that why so many methods in random.Random have an "int=int" argument? E.g. def randrange(self, start, stop=None, step=1, int=int, default=None, maxwidth=1L
Re: [Python-Dev] 'hasattr' is broken by design
2010/8/24 Hrvoje Niksic : > The __length_hint__ lookup expects either no exception or AttributeError, > and will propagate others. I'm not sure if this is a bug. On the one hand, > throwing anything except AttributeError from __getattr__ is bad style (which > is why we fixed the bug by deriving our business exception from > AttributeError), but the __length_hint__ check is supposed to be an internal > optimization completely invisible to the caller of list(). __length_hint__ is internal and undocumented, so it can do whatever it wants. -- Regards, Benjamin ___ 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] 'hasattr' is broken by design
On 08/24/2010 02:31 PM, Benjamin Peterson wrote: 2010/8/24 Hrvoje Niksic: The __length_hint__ lookup expects either no exception or AttributeError, and will propagate others. I'm not sure if this is a bug. On the one hand, throwing anything except AttributeError from __getattr__ is bad style (which is why we fixed the bug by deriving our business exception from AttributeError), but the __length_hint__ check is supposed to be an internal optimization completely invisible to the caller of list(). __length_hint__ is internal and undocumented, so it can do whatever it wants. Of course, but that's beside the point. In this case __length_hint__ was neither implemented in the class, nor were we aware of its existence, and the code still broke (as in the example in previous mail). The point I'm making is that: a) a "business" case of throwing anything other than AttributeError from __getattr__ and friends is almost certainly a bug waiting to happen, and b) making the proposed change is bound to break real, production code. I still agree with the proposed change, but I wanted to also point out that it will cause breakage and illustrate it with a similar real-world example that occurred during migration to python 2.6. ___ 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] 'hasattr' is broken by design
2010/8/24 Hrvoje Niksic : > On 08/24/2010 02:31 PM, Benjamin Peterson wrote: >> >> 2010/8/24 Hrvoje Niksic: >>> >>> The __length_hint__ lookup expects either no exception or >>> AttributeError, >>> and will propagate others. I'm not sure if this is a bug. On the one >>> hand, >>> throwing anything except AttributeError from __getattr__ is bad style >>> (which >>> is why we fixed the bug by deriving our business exception from >>> AttributeError), but the __length_hint__ check is supposed to be an >>> internal >>> optimization completely invisible to the caller of list(). >> >> __length_hint__ is internal and undocumented, so it can do whatever it >> wants. > > Of course, but that's beside the point. In this case __length_hint__ was > neither implemented in the class, nor were we aware of its existence, and > the code still broke (as in the example in previous mail). The point I'm > making is that: > > a) a "business" case of throwing anything other than AttributeError from > __getattr__ and friends is almost certainly a bug waiting to happen, and > > b) making the proposed change is bound to break real, production code. I agree with. This is why the change is not making its way into any maintenance release. -- Regards, Benjamin ___ 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] 'hasattr' is broken by design
At 03:37 PM 8/24/2010 +0200, Hrvoje Niksic wrote: a) a "business" case of throwing anything other than AttributeError from __getattr__ and friends is almost certainly a bug waiting to happen, and FYI, best practice for __getattr__ is generally to bail with an AttributeError as soon as you see double underscores in the name, unless you intend to support special attributes. I don't think this is documented anywhere, but experience got this pretty ingrained in my head since Python 2.2 or even earlier. ___ 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] 'hasattr' is broken by design
2010/8/24 P.J. Eby : > At 03:37 PM 8/24/2010 +0200, Hrvoje Niksic wrote: >> >> a) a "business" case of throwing anything other than AttributeError from >> __getattr__ and friends is almost certainly a bug waiting to happen, and > > FYI, best practice for __getattr__ is generally to bail with an > AttributeError as soon as you see double underscores in the name, unless you > intend to support special attributes. Unless you're in an old-style class, you shouldn't get an double underscore methods in __getattr__ (or __getattribute__). If you do, it's a bug. -- Regards, Benjamin ___ 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] 'hasattr' is broken by design
On 8/24/2010 9:45 AM, Benjamin Peterson wrote: > 2010/8/24 Hrvoje Niksic : >> On 08/24/2010 02:31 PM, Benjamin Peterson wrote: >>> >>> 2010/8/24 Hrvoje Niksic: The __length_hint__ lookup expects either no exception or AttributeError, and will propagate others. I'm not sure if this is a bug. On the one hand, throwing anything except AttributeError from __getattr__ is bad style (which is why we fixed the bug by deriving our business exception from AttributeError), but the __length_hint__ check is supposed to be an internal optimization completely invisible to the caller of list(). >>> >>> __length_hint__ is internal and undocumented, so it can do whatever it >>> wants. >> >> Of course, but that's beside the point. In this case __length_hint__ was >> neither implemented in the class, nor were we aware of its existence, and >> the code still broke (as in the example in previous mail). The point I'm >> making is that: >> >> a) a "business" case of throwing anything other than AttributeError from >> __getattr__ and friends is almost certainly a bug waiting to happen, and >> >> b) making the proposed change is bound to break real, production code. > > I agree with. This is why the change is not making its way into any > maintenance release. > > > +1 regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 DjangoCon US September 7-9, 2010http://djangocon.us/ See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.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] 'hasattr' is broken by design
On Tue, Aug 24, 2010 at 4:51 AM, Steven D'Aprano wrote: > But that's the thing... as far as I am concerned, a dynamically defined > attribute *doesn't* exist. If it existed, __getattr__ would never be > called. A minor semantic difference, to be sure, but it's real to me. Eh? If "x.y" succeeds, in what sense does y not exist? > Whether I should care about the difference is a separate issue. Right, you are breaking through too much abstraction. > Performance could be an issue, of course, if somebody writes an > expensive __getattr__ or property. Computed attributes should be cheap. Yes, and it should be considered the problem of the author of that property, not of the user. > But I'm actually more concerned about side-effects than performance. Properties should not have side effects. That would be a problem when using them just as much as with hasattr(). -- --Guido van Rossum (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] 'hasattr' is broken by design
On Tue, 24 Aug 2010 09:26:09 -0500, Benjamin Peterson wrote: > 2010/8/24 P.J. Eby : > > At 03:37 PM 8/24/2010 +0200, Hrvoje Niksic wrote: > >> > >> a) a "business" case of throwing anything other than AttributeError from > >> __getattr__ and friends is almost certainly a bug waiting to happen, and > > > > FYI, best practice for __getattr__ is generally to bail with an > > AttributeError as soon as you see double underscores in the name, unless you > > intend to support special attributes. > > Unless you're in an old-style class, you shouldn't get an double > underscore methods in __getattr__ (or __getattribute__). If you do, > it's a bug. Benjamin, I remember you fixing various special method lookups, so just for clarity's sake, which versions of Python does your statement apply to? -- R. David Murray www.bitdance.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] 'hasattr' is broken by design
2010/8/24 R. David Murray : > On Tue, 24 Aug 2010 09:26:09 -0500, Benjamin Peterson > wrote: >> 2010/8/24 P.J. Eby : >> > At 03:37 PM 8/24/2010 +0200, Hrvoje Niksic wrote: >> >> >> >> a) a "business" case of throwing anything other than AttributeError from >> >> __getattr__ and friends is almost certainly a bug waiting to happen, and >> > >> > FYI, best practice for __getattr__ is generally to bail with an >> > AttributeError as soon as you see double underscores in the name, unless >> > you >> > intend to support special attributes. >> >> Unless you're in an old-style class, you shouldn't get an double >> underscore methods in __getattr__ (or __getattribute__). If you do, >> it's a bug. > > Benjamin, I remember you fixing various special method lookups, so just > for clarity's sake, which versions of Python does your statement apply to? 2.7, 3.1, and 3.2 should all be good. -- Regards, Benjamin ___ 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] 'hasattr' is broken by design
On Aug 24, 2010, at 10:26 AM, Benjamin Peterson wrote: 2010/8/24 P.J. Eby : At 03:37 PM 8/24/2010 +0200, Hrvoje Niksic wrote: a) a "business" case of throwing anything other than AttributeError from __getattr__ and friends is almost certainly a bug waiting to happen, and FYI, best practice for __getattr__ is generally to bail with an AttributeError as soon as you see double underscores in the name, unless you intend to support special attributes. Unless you're in an old-style class, you shouldn't get an double underscore methods in __getattr__ (or __getattribute__). If you do, it's a bug. Uh, did you see the message that was in response to? Maybe it should be a bug report? >>> class Foo(object): ... def __getattr__(self, name): print "ATTR:",name ... def __iter__(self): yield 1 ... >>> print list(Foo()) ATTR: __length_hint__ [1] James ___ 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] 'hasattr' is broken by design
2010/8/24 James Y Knight : > > On Aug 24, 2010, at 10:26 AM, Benjamin Peterson wrote: > >> 2010/8/24 P.J. Eby : >>> >>> At 03:37 PM 8/24/2010 +0200, Hrvoje Niksic wrote: a) a "business" case of throwing anything other than AttributeError from __getattr__ and friends is almost certainly a bug waiting to happen, and >>> >>> FYI, best practice for __getattr__ is generally to bail with an >>> AttributeError as soon as you see double underscores in the name, unless >>> you >>> intend to support special attributes. >> >> Unless you're in an old-style class, you shouldn't get an double >> underscore methods in __getattr__ (or __getattribute__). If you do, >> it's a bug. > > Uh, did you see the message that was in response to? > > Maybe it should be a bug report? Old version of Python I think. -- Regards, Benjamin ___ 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] 'hasattr' is broken by design
At 10:13 AM 8/24/2010 -0500, Benjamin Peterson wrote: 2010/8/24 James Y Knight : > > On Aug 24, 2010, at 10:26 AM, Benjamin Peterson wrote: > >> 2010/8/24 P.J. Eby : >>> >>> At 03:37 PM 8/24/2010 +0200, Hrvoje Niksic wrote: a) a "business" case of throwing anything other than AttributeError from __getattr__ and friends is almost certainly a bug waiting to happen, and >>> >>> FYI, best practice for __getattr__ is generally to bail with an >>> AttributeError as soon as you see double underscores in the name, unless >>> you >>> intend to support special attributes. >> >> Unless you're in an old-style class, you shouldn't get an double >> underscore methods in __getattr__ (or __getattribute__). If you do, >> it's a bug. > > Uh, did you see the message that was in response to? > > Maybe it should be a bug report? Old version of Python I think. If by "old" you mean 2.6, sure. (Also, I did say this was a best practice since 2.2.) ___ 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] Generating "canonical argument call" from `getargspec` and `getcallargs` results
I was happy to see the new `getcallargs` function in the `inspect` module.
But there's one thing I want to do that's related to it, and maybe this was
implemented somewhere or someone can give me some pointers about it.
I want to have a function that takes the results of `getargspec` and
`getcallargs` for a function and a set of arguments, and outputs the
"canonical argument call" that would generate these results.
For example, let's say I have a function `f`:
def f(a, b, c=7, **kwargs):
pass
This is its argument spec:
>>> inspect.getargspec(f)
ArgSpec(args=['a', 'b', 'c'], varargs=None, keywords='kwargs',
defaults=(7,))
Now, different argument combinations can generate the same results
`getcallargs` result
>>> inspect.getcallargs(f, 1, 2, 7, meow='grrr') # Like calling f(1, 2,
7, meow='grrr')
{'a': 1, 'c': 7, 'b': 2, 'kwargs': {'meow': 'grrr'}}
>>> inspect.getcallargs(f, 1, 2, meow='grrr') # Like calling f(1, 2,
meow='grrr')
{'a': 1, 'c': 7, 'b': 2, 'kwargs': {'meow': 'grrr'}}
>>> inspect.getcallargs(f, 1, b=2, c=7, meow='grrr') # Like calling f(1,
b=2, c=7, meow='grrr')
{'a': 1, 'c': 7, 'b': 2, 'kwargs': {'meow': 'grrr'}}
What I would like to have is one canonical argument combination. I assume
that the best way to define the canonical form is "The smallest number of
arguments, and specifying as few keyword arguments as possible." According
to that definition, the canonical argument call in the above example would
be the second one, `f(1, 2, meow='grrr')`.
So I want a function that for a given function and argument call, returns
the canonical argument call, which generates the same `getcallargs` result
as the given argument call.
The reason I want this is to make it easier to organize a set of argument
calls. (I'm doing an application in which the user maintains a set of
argument profiles that he can choose from, and having to deal with only the
canonical form will prevent some annoyances.)
Did anyone implement something like this? Does anyone have ideas? And is
this something that would be of interest to the standard library?
Best Wishes,
Ram Rachum.
___
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] 'hasattr' is broken by design
On Aug 24, 2010, at 8:31 AM, Benjamin Peterson wrote: > 2010/8/24 Hrvoje Niksic : >> The __length_hint__ lookup expects either no exception or AttributeError, >> and will propagate others. I'm not sure if this is a bug. On the one hand, >> throwing anything except AttributeError from __getattr__ is bad style (which >> is why we fixed the bug by deriving our business exception from >> AttributeError), but the __length_hint__ check is supposed to be an internal >> optimization completely invisible to the caller of list(). > > __length_hint__ is internal and undocumented, so it can do whatever it wants. As it happens though, list() is _quite_ public. Saying "X is internal and undocumented, so it can do whatever it wants" is never really realistic, especially in response to someone saying "we already saw this problem in production, _without_ calling / referring to / knowing about this private API". ___ 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] Released: Python 2.6.6
Hello fellow Pythoneers and Pythonistas, I'm very happy to announce the release of Python 2.6.6. A truly impressive number of bugs have been fixed since Python 2.6.5. Source code and Windows installers for Python 2.6.6 are now available here: http://www.python.org/download/releases/2.6.6/ The full details of everything that's changed is available in the NEWS file: http://www.python.org/download/releases/2.6.6/NEWS.txt Python 2.6.6 marks the end of regular maintenance releases for the Python 2.6 series. From now until October 2013, only security related, source-only releases of Python 2.6 will be made available. After that date, Python 2.6 will no longer be supported, even for security bugs. My deepest appreciation go out to everyone who has helped contribute fixes great and small, and much testing and bug tracker gardening for Python 2.6.6. Enjoy, -Barry (on behalf of the Python development community) signature.asc Description: 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] Python-Dev Digest, Vol 85, Issue 71
On 8/24/2010 12:40 AM, [email protected] wrote: Message: 4 Date: Mon, 23 Aug 2010 17:21:50 -0700 From: Brett Cannon It is also non-obvious to any beginner. Are we really going to want to propagate the knowledge of this trick as a fundamental idiom? I would rather leave hasattr in that instance. But I'm +1 on only swallowing AttributeError. I'd argue that since the ability to inherit a class from "dict" was added, dynamically adding attributes is somewhat obsolete. An object instance is not a dictionary. Especially since its namespace interacts with the namespace of its class. I've been using Google Code Search to look at the actual use cases for "setattr". The main uses are: 1. Copying. Object copying is done with "setattr". All the "setattr" objects occur during object construction, or shortly after. 2. Creating proxy objects for remote access. This is much like copying, 3. Representing HTML objects as Python object. This usually requies gyrations to avoid clashes with Python built-in names and functions; "class" is a common attribute in HTML, and a reserved word in Python, and some hack is necessary to make that work. BeautifulSoup does this. It's rare that attributes are added long after object construction. Perhaps a mechanism should be provided for dynamically constructing an object. Something like class foo(object) : pass attrdict = { a : 1, b : 2} make_object(foo, attrdict) This covers most of the use cases for "setattr". John Nagle ___ 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] Released: Python 2.6.6
On Aug 24, 2010, at 12:31 PM, Barry Warsaw wrote: > Hello fellow Pythoneers and Pythonistas, > > I'm very happy to announce the release of Python 2.6.6. Thanks Barry :-) Raymond ___ 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] Released: Python 2.6.6
On Aug 24, 2010, at 03:31 PM, Barry Warsaw wrote: >Python 2.6.6 marks the end of regular maintenance releases for the >Python 2.6 series. From now until October 2013, only security >related, source-only releases of Python 2.6 will be made available. >After that date, Python 2.6 will no longer be supported, even for >security bugs. merwok asks on IRC whether documentation changes to release26-maint will be allowed. I can sympathize with the 'allow' argument; Python 2.6 is still either the default version or soon to be the new default in several distributions, and it will take a while before Python 2.7 is as widely available. I can also sympathize with the 'disallow' argument; it's more work for everybody because it effectively means the branch is still open, and I will probably have to push out new docs every now and then. OTOH, I suspect there won't be *that* many documentation fixes for Python 2.6 and that the overhead will be minimal. What did we do for Python 2.5? I'm willing to support consensus, and if that means allowing documentation fixes, I'll accept the extra RM work. OTOH, I won't cry too much if the consensus is to not allow them. -Barry signature.asc Description: 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] 'hasattr' is broken by design
Steven D'Aprano wrote: But that's the thing... as far as I am concerned, a dynamically defined attribute *doesn't* exist. Maybe for your particular use case, but the concept of whether an attribute is dynamically defined or not is not well-defined in general. Consider an object that is trying to be a transparent proxy for another object, and behave as much as possible as though it really were the other object. Should an attribute statically defined on the proxied object be considered dynamically defined on the proxy? If so, then the proxy isn't as transparent as some people may want. -- 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] Released: Python 2.6.6
Le mercredi 25 août 2010 01:12:40, Barry Warsaw a écrit : > merwok asks on IRC whether documentation changes to release26-maint will be > allowed. I can sympathize with the 'allow' argument; Python 2.6 is still > either the default version or soon to be the new default in several > distributions, and it will take a while before Python 2.7 is as widely > available. Even if I use Python 2.5, I read 2.7 doc because it is usually more complete (eg. 2.7 has more examples). If I use a new function, I just check that it is not a function introduced in Python 2.6 or 2.7. If you compare 2.5 and 2.7 doc, the 2.5 is just ugly :-) 2.5 has no table of content at the left and it uses subpages which is less pratical (to search something using the browser) that a whole module on the same page. So I just don't care of 2.6 doc :-) -- Victor Stinner http://www.haypocalc.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] Released: Python 2.6.6
> OTOH, I suspect there won't be *that* many documentation fixes for Python 2.6 > and that the overhead will be minimal. What did we do for Python 2.5? The question really is whether there is any chance that they will get released, in some form. There won't be further binary releases (at least not from python.org), so there definitely won't be a CHM release. For 2.5, I didn't do releases of the documentation for security releases. You might decide to make it differently, i.e. including doc sets with the security releases. If you are not going to release the documentation (which I would recommend), then committers should be advised not to commit changes to the documentation (as they will not get releases). I do fail to see the point in favor of making documentation changes. Sure, 2.7 isn't yet widely available. However, 2.6 users should generally be fine with the 2.6.6 doc set - will the minor changes that we can make to it (given that no bug fixes will be made to the code) really matter? 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
