Re: [Python-Dev] update_wrapper should preserve staticmethod behavior
Calvin Spealman wrote: I'd like to make a claim about the following example, that update_wrapper should be improved to preserve the behavior of known, built-in decorators. In this case, I'm talking about staticmethod. The order I list here feels natural, but it obviously doesn't work. The only reason it doesn't seems to be that it is trying to decorate the descriptor, not the function itself. This is expected, but it could certainly be smart enough to detect a descriptor and attempt to get the actual callable underneath, could it not? It would not work for all cases, of course. >>> def d(f): ... def nf(*a, **kw): ... print "decorated function called" ... return f(*a, **kwargs) ... functools.update_wrapper(nf, f) ... return nf ... >>> class A(object): ... @d ... @staticmethod ... def a(self): ... print "a" ... Traceback (most recent call last): File "", line 1, in File "", line 3, in A File "", line 5, in d File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/functools.py", line 33, in update_wrapper setattr(wrapper, attr, getattr(wrapped, attr)) AttributeError: 'staticmethod' object has no attribute '__module__' d expects a function object, this code gives it a nonfunction object - that's a bug in the function definition. Decorators differ in whether or not they are stackable with other function decorators (i.e. they return a function object, or another callable with a compatible API), or whether they can only be used as terminal decorators (i.e. they return something that doesn't look like a function). classmethod and staticmethod fit in the latter category, and I don't see any reason to change them. Consider what happens in your example without the update_wrapper line: >>> def d(f): ... def new(*args, **kwds): ... print "Calling decorated function" ... return f(*args, **kwds) ... return new ... >>> class A(object): ... @d ... @staticmethod ... def a(*args, **kwds): ... print "Method called" ... print "Args:", args ... print "Keywords:", kwds ... >>> A().a() Calling decorated function Traceback (most recent call last): File "", line 1, in File "", line 4, in new TypeError: 'staticmethod' object is not callable If anything, the AttributeError from update wrapper is a net win since the buggy code breaks at class definition time rather than when you try to call the broken method. Cheers, Nick. P.S. Checking for __get__ won't help with detecting non-function descriptors anyway - function objects themselves define that method in order to provide Python's normal instance method binding behaviour. -- 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
Re: [Python-Dev] PEP 8 and optional underscores
Benjamin Peterson wrote: On Wed, Jun 11, 2008 at 1:03 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: "Function names should be lowercase, with words separated by underscores as necessary to improve readability." -- PEP 8 If I'm reading this correctly, then underscores are not required everywhere. Can some of these be shortened? function:: active_count() method:: Thread.get_name() method:: Thread.is_alive() method:: Thread.is_daemon() method:: Thread.set_daemon(daemonic) In some cases, the mental pronounciation changes and affects my perception of meaning. For example, Thread.setName or Thread.setname both feel like a setter to me, but Thread.set_name causes a mental pause and a momentary double-take (is it the name of a set?). Actually, in this case, I think the Pythonic thing to do would be to use properties. Thus exposing those details as thread.name, thread.alive, thread.daemonic (with the first two being read-only and the last read/write)? +1 for that approach on the threading.Thread and multiprocessing.Process classes. Not sure what to do about the active thread count function - shortening it as Raymond suggests would probably be fine. Cheers, 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
Re: [Python-Dev] bug or a feature?
At 08:32 PM 6/11/2008 -0400, Terry Reedy wrote: The Data Model chapter of the Reference Manual lists .__dict__ as a special attribute of callables, modules, classes, and instances. It describes __dict__ as a "namespace dictionary" or "implementation of the namespace" thereof. Since namespaces map names (or possibly non-name strings) to objects, this to me implies that an implementation is and should not be required to allow non-strings in __dict__. The same chapter has more than one sentence saying something like "o.x is equivalent to o.__dict__['x']". While one could read this as prohibiting o.__dict__[non_string], one could also read it as being silent, neither allowing nor prohibiting. As it happens, most objects' __dict__ slots are settable by default, and *require* that you set it to a dict or subclass thereof. This seems (to me) to imply that a standard dictionary (i.e. one supporting keys of any type) is required. (In the sense that a dict subclass which rejects non-strings would be violating the Liskov principle.) ___ 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] Assignment to None
Curt Hagenlocher wrote: If I recall correctly, Jython handles this by appending a trailing underscore to the imported name and there's no reason why we couldn't do something similar. It also has the virtue of being the common convention for attribute names that shadow keywords even in CPython (e.g. unittest.TestCase.assert_). Cheers, 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
Re: [Python-Dev] bug or a feature?
At 02:59 AM 6/12/2008 +0200, Maciej Fijalkowski wrote: It's about abusing locals, which are not even given that they'll modify this dict. Note that class bodies are a special case: as of PEP 3115, it's possible for a class body's locals to be a non-dictionary object, so it makes no sense to make a class body's locals() or f_locals return some *other* object. Meanwhile, as a practicality-beats-purity matter, you're going to run into compatibility problems with a fair number of libraries in the field (including Zope and Twisted, and anything using them) if you *don't* support locals() modification in class bodies. (Those other libraries don't use non-string keys like AddOns does, but they *do* depend on modifying a class body's frame locals.) ___ 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-3000] Betas today - I hope
Guido van Rossum wrote: On Wed, Jun 11, 2008 at 4:35 AM, Barry Warsaw <[EMAIL PROTECTED]> wrote: So I had planned to do a bunch of work last night looking at the release blocker issues, but nature intervened. A bunch of severe thunderstorms knock out my 'net access until this morning. I'll try to find some time during the day to look at the RB issues. Hopefully we can get Guido to look at them too and Pronounce on some of them. Guido please start with: http://bugs.python.org/issue643841 I've added a comment. Let me know if anything I said is unclear. The bugtracker seems to be offline atm - I'll reply there once I can get to it again (as well as switching this issue back to being a documentation one). I don't think we're going to see a major clamor for a value-based delegation mixin in the standard library until people using classic classes for value-based delegation start making serious attempts to port to Py3k (where that approach is no longer available). At the moment, such classes only need to care about the methods they want to fiddle with, leaving everything else to __getattr__ based delegation. I've pushed as hard as I'm personally willing to for this without convincing anyone else that it's worth doing, so I'll start working on a documentation patch for the language reference instead which explicitly splits the special methods into the following categories: 1. Method lookup MUST bypass __getattribute__, shadowing the attribute in the instance dictionary MUST NOT have any ill effects. (All tp_* C-level slots and slots looked up via _PyType_Lookup will fit into this category) 2. Method lookup MAY bypass __getattribute__, shadowing the attribute in the instance dictionary MAY have ill effects. (slots such as __enter__ and __exit__ that are looked up via normal attribute lookup in CPython will fit into this category) 3. Technically a subcategory of group 1, these are special methods which can affect the interpreter's behaviour by their mere definition on a type. (The __get__, __set__ and __delete__ descriptor protocol methods fall into this category) Cheers, 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] bugs.python.org down
Hi, could someone look for this ... or I am the only one which noticed that. ping works but http://bugs.python.org giges after a timeout: Proxy Error The proxy server received an invalid response from an upstream server. The proxy server could not handle the request GET /. Reason: Error reading from remote server Apache/2.2.3 (Debian) mod_python/3.2.10 Python/2.4.4 mod_ssl/2.2.3 OpenSSL/0.9.8c Server at bugs.python.org Port 80 ___ 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-3000] No betas today
That's odd - I've been doing all of the mp work on osx 10.5.3 - I'll run the units in a loop today to see if I can catch it. -Jesse On Jun 12, 2008, at 1:00 AM, Barry Warsaw <[EMAIL PROTECTED]> wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Much thanks to Benjamin Peterson and Alexandre Vassalotti for providing much help today trying to get the betas out. Unfortunately, it's not gonna happen today. There are two issues blocking the release. http://bugs.python.org/issue3088 http://bugs.python.org/issue3089 The main problem (issue 3089) is that none of the Python 3.0 buildbots are green. Issue 3088 may only happen for me, but test_multiprocessing simply hangs for me on OS X 10.5.3. I'm going to bed now. As soon as we can turn the bots green we can try again. This weekend might be a good time for me. Please help out by resolving these two issues. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSFCtZHEjvBPtnXfVAQLrHQQAoq1RCNeawpJHaefuvmZiS4VZzzvtV5Bm HFW6FWyO86NNEcCK6Delthf+H1mgjCaoymHojxBJhWm7UJK0WjMz+0RpF8zcLo0R i8I8SiFLy6kRB5UxlZHS/VXDi8QS92SogRvlnWLBwXNNK6wlgeqK8C0zt1ilL0q6 Fqk/AsGO/fA= =HlEA -END PGP SIGNATURE- ___ Python-3000 mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/jnoller%40gmail.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] bugs.python.org down
On Thu, Jun 12, 2008 at 11:48 AM, anton <[EMAIL PROTECTED]> wrote: > ping works but http://bugs.python.org giges after a timeout: Seeing the same thing here, so it's not just you. Schiavo Simon ___ 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] bugs.python.org down
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jun 12, 2008, at 5:48 AM, anton wrote: could someone look for this ... or I am the only one which noticed that. ping works but http://bugs.python.org giges after a timeout: Proxy Error The proxy server received an invalid response from an upstream server. The proxy server could not handle the request GET /. Reason: Error reading from remote server Apache/2.2.3 (Debian) mod_python/3.2.10 Python/2.4.4 mod_ssl/2.2.3 OpenSSL/0.9.8c Server at bugs.python.org Port 80 I can't even ssh into the machine this morning, so I've forwarded this off to the python.org sysadmins. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSFEJenEjvBPtnXfVAQL1DwP/cpAACpa7KTL8BZcuQGcqgmbez1PmtXBG jl85PaULlm6LAvTjtZMy/n2ribZ7TTGLRAHkEoGiQyN03xHFn+w8v6XpXwmvRMsw 19oLBxc3zOptNSfQwSUwdiSHwAdTPW9XjoR0xf7TwOQJZQ5PFtCPniQT2YxVnj4X ZD/VmrIasUo= =Jr3d -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] bug or a feature?
Phillip J. Eby wrote:
> At 08:32 PM 6/11/2008 -0400, Terry Reedy wrote:
>> The Data Model chapter of the Reference Manual lists .__dict__ as a
>> special
>> attribute of callables, modules, classes, and instances. It describes
>> __dict__ as a "namespace dictionary" or "implementation of the namespace"
>> thereof. Since namespaces map names (or possibly non-name strings) to
>> objects, this to me implies that an implementation is and should not be
>> required to allow non-strings in __dict__.
>>
>> The same chapter has more than one sentence saying something like "o.x is
>> equivalent to o.__dict__['x']". While one could read this as prohibiting
>> o.__dict__[non_string], one could also read it as being silent, neither
>> allowing nor prohibiting.
>
> As it happens, most objects' __dict__ slots are settable by default, and
> *require* that you set it to a dict or subclass thereof.
This is wrong for types:
$ python
Python 2.5.2 (r252:60911, Apr 21 2008, 11:12:42)
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> class A(object): pass
...
>>> A.__dict__ = {}
Traceback (most recent call last):
File "", line 1, in
AttributeError: attribute '__dict__' of 'type' objects is not writable
In fact it seems to me that there is no way to set non-string keys into
a type dict after class creation: Cls.__dict__ supports no setitem,
setattr checks for a string argument.
I think there are good arguments for not allowing strings keys in type
dicts, or at least leaving it up to the implementation. Using non-string
keys in type dicts is relatively awkward and allowing them makes many
interesting optimizations (like method caches) a _lot_ harder to get right.
Cheers,
Carl Friedrich Bolz
___
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-3000] No betas today
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jun 12, 2008, at 7:08 AM, Jesse Noller wrote: That's odd - I've been doing all of the mp work on osx 10.5.3 - I'll run the units in a loop today to see if I can catch it. -Jesse Thanks. It's definitely reproducible on both my Leopard boxes. I haven't tried it on my Tiger box. The buildbots seem unhappy too. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSFEJ9HEjvBPtnXfVAQJlNwQAsG2M/hNORYSuCsmKHU+nvbX3cASiFlhj IIhNfdrtkRbjXBaDgxrr/Ps1+Q3I56lpSg5SDEWxXVufNdBdHXGAKKxnrYN22a1x Nwuu+DXOGYmzBcQc2BS5L9/31yeDmSFBMP257BBstCZww97pt8VRLKpUL2Wzfzny MZb6Km/NXwQ= =Ab3l -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] PEP 8 and optional underscores
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jun 11, 2008, at 2:03 PM, Raymond Hettinger wrote: "Function names should be lowercase, with words separated by underscores as necessary to improve readability." -- PEP 8 If I'm reading this correctly, then underscores are not required everywhere. Can some of these be shortened? function:: active_count() method:: Thread.get_name() method:: Thread.is_alive() method:: Thread.is_daemon() method:: Thread.set_daemon(daemonic) +1 on opting for properties in the specific cases here where it makes sense. In some cases, the mental pronounciation changes and affects my perception of meaning. For example, Thread.setName or Thread.setname both feel like a setter to me, but Thread.set_name causes a mental pause and a momentary double-take (is it the name of a set?). A few months ago, I think there was a PEP 8 discussion rejecting suggestions to make underscores required everywhere (leading to getattr-->get_attr, iteritems-->iter_items, staticmethod- >static_method, setdefault->set_default, popitem->pop_item, splitlines->split_lines etc.) Perhaps underscores should only be used when the contracted form lacks clarity. There are some builtins that I wish had used underscores to make them easier to read. isinstance() and issubclass() come to mind. OTOH, getattr and iteritems are already contractions, so leaving them underscoreless doesn't bother me too much. For the others you mention, well I'll invoke ZoP 12 and 13. There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSFENVnEjvBPtnXfVAQIVhAQAn6liMZxAFKPmfvHp7UQLBdCEiI0rkGjR OCxaEQLxpeuHfDGMS47kVJhyAwo3skKzv9Yv1+Vuor7SaP9hAO3h4r3SO2wM9jDF jwrx6ajm9wtsTzSrh9QkYzOyegeMAfj3p8gLZ+eHiRdFHXj++biunvnn4GPl7O5x E84j8rNlWkU= =LYDl -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] bug or a feature?
At 01:34 PM 6/12/2008 +0200, Carl Friedrich Bolz wrote: Phillip J. Eby wrote: > As it happens, most objects' __dict__ slots are settable by default, and > *require* that you set it to a dict or subclass thereof. This is wrong for types: Which is why I said "most" - to exclude types, and objects that don't have a __dict__ slot to begin with. I think there are good arguments for not allowing strings keys in type dicts, or at least leaving it up to the implementation. That may well be, but there is nothing in Python's spec that I'm aware of that *forbids* it. For example the type() constructor doc doesn't say anything about using string-only keys in the class dictionary. Using non-string keys in type dicts is relatively awkward and allowing them makes many interesting optimizations (like method caches) a _lot_ harder to get right. Really? Why? Having non-string dict keys is NOT the same thing as having non-string attribute names, so attribute name lookups should be unaffected. (Attribute names *are* required to be strings, and -- as far as I know -- always have been.) ___ 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] PEP 8 and optional underscores
2008/6/12 Barry Warsaw <[EMAIL PROTECTED]>: >> function:: active_count() >> method:: Thread.get_name() >> method:: Thread.is_alive() >> method:: Thread.is_daemon() >> method:: Thread.set_daemon(daemonic) > > +1 on opting for properties in the specific cases here where it makes sense. I'm +1 too... but which is the normal procedure here? Should it be... 2.n : .is_alive() 2.n+1 : .is_alive() (deprecated), .alive (recommended) 2.n+2 : .alive ...? Regards, -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ 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] bugs.python.org down
2008/6/12 anton <[EMAIL PROTECTED]>: > ping works but http://bugs.python.org giges after a timeout: I can enter into it. Also note that my issues showing system [1] was updated 6.5 hours ago, so it was up at that time (my system goes and get some info twice a day, you have the "last updated" info down on that page). Regards, [1] http://www.taniquetil.com.ar/cgi-bin/pytickets.py -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ 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] PEP 8 and optional underscores
On Thu, Jun 12, 2008 at 7:29 AM, Facundo Batista <[EMAIL PROTECTED]> wrote: >> +1 on opting for properties in the specific cases here where it makes sense. If you can get Guido to agree to it, I'll implement it. > > I'm +1 too... but which is the normal procedure here? > > Should it be... > > 2.n : .is_alive() > 2.n+1 : .is_alive() (deprecated), .alive (recommended) > 2.n+2 : .alive I think: 2.x isAlive() (Py3kWarning), .alive (recommended for compatibility with 3.x) 3.x .alive -- Cheers, Benjamin Peterson "There's no place like 127.0.0.1." ___ 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] bug or a feature?
Phillip J. Eby wrote: > At 01:34 PM 6/12/2008 +0200, Carl Friedrich Bolz wrote: >> Phillip J. Eby wrote: >> > As it happens, most objects' __dict__ slots are settable by default, >> and >> > *require* that you set it to a dict or subclass thereof. >> >> This is wrong for types: > > Which is why I said "most" - to exclude types, and objects that don't > have a __dict__ slot to begin with. Sorry, I thought we were mostly discussing type dictionaries at the moment. >> I think there are good arguments for not allowing strings keys in type >> dicts, or at least leaving it up to the implementation. > > That may well be, but there is nothing in Python's spec that I'm aware > of that *forbids* it. For example the type() constructor doc doesn't > say anything about using string-only keys in the class dictionary. Fine, but as far as I can see there is also nothing that *mandates* it. >> Using non-string >> keys in type dicts is relatively awkward and allowing them makes many >> interesting optimizations (like method caches) a _lot_ harder to get >> right. > > Really? Why? Having non-string dict keys is NOT the same thing as > having non-string attribute names, so attribute name lookups should be > unaffected. (Attribute names *are* required to be strings, and -- as > far as I know -- always have been.) Of course attribute name lookups are affected, because you can have a non-string key that has a __hash__ and __eq__ method to make it look sufficiently like a string to the dict. Then the attribute lookup needs to take these into account. This makes a method cache implementation much more complex, because suddenly arbitrary user code can run during the lookup and your classes (and thus your method caches) can change under your feed during the lookup. In this situation getting the corner cases right is very hard. Cheers, Carl Friedrich ___ 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] PEP 8 and optional underscores
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jun 12, 2008, at 8:29 AM, Facundo Batista wrote: 2008/6/12 Barry Warsaw <[EMAIL PROTECTED]>: function:: active_count() method:: Thread.get_name() method:: Thread.is_alive() method:: Thread.is_daemon() method:: Thread.set_daemon(daemonic) +1 on opting for properties in the specific cases here where it makes sense. I'm +1 too... but which is the normal procedure here? Should it be... 2.n : .is_alive() 2.n+1 : .is_alive() (deprecated), .alive (recommended) 2.n+2 : .alive Personally, I'd go with a property .is_alive - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSFEeznEjvBPtnXfVAQKEeQP8CdF+N1wX4Qwxn7iglGYq0peZEYagn4JG dOkP+TOkAzSciNfIotPaHJTGbyXsFtxLe3Rpq8r56/sPhHKS66+vCMojLBK64Iue 7/PDhZ300KRpPtbJOOA4OmqI2rz1fO+vflavICZlx7oIwC25L7dQSteu/NBJYGJN QX/Z8WutBng= =1B3v -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] bug or a feature?
On Thu, Jun 12, 2008 at 2:56 PM, Carl Friedrich Bolz <[EMAIL PROTECTED]> wrote: > Of course attribute name lookups are affected, because you can have a > non-string key that has a __hash__ and __eq__ method to make it look > sufficiently like a string to the dict. Then the attribute lookup needs > to take these into account. This makes a method cache implementation > much more complex, because suddenly arbitrary user code can run during > the lookup and your classes (and thus your method caches) can change > under your feed during the lookup. In this situation getting the corner > cases right is very hard. I fully agree with this assessment: the theoretical possibilities make attribute handling very hairy. Note that besides non-strings, also user-defined subclasses of string can have their own hash/eq logic. If namespace keys and attributes could be locked down to only be regular strings, not of another type and not a string subclass instance, then implementing attributes becomes a lot less hairy, and optimizations much more straightforward. - Willem (CLPython) ___ 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-3000] Betas today - I hope
[Barry] >>> http://bugs.python.org/issue643841 [Guido] >> I've added a comment. Let me know if anything I said is unclear. On Thu, Jun 12, 2008 at 3:35 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote: > The bugtracker seems to be offline atm - I'll reply there once I can get to > it again (as well as switching this issue back to being a documentation > one). > > I don't think we're going to see a major clamor for a value-based delegation > mixin in the standard library until people using classic classes for > value-based delegation start making serious attempts to port to Py3k (where > that approach is no longer available). At the moment, such classes only need > to care about the methods they want to fiddle with, leaving everything else > to __getattr__ based delegation. Whether they'll care about this issue of course depends on whether they need overloaded operators and other special delegations to be delegated transparently. We'll have to see how important this is. New-style classes have been around and recommended for a long time -- why haven't people pushed for a proxy class before? > I've pushed as hard as I'm personally willing to for this without convincing > anyone else that it's worth doing, What does *it* refer to? Changing the behavior, or adding a proxy class to the stdlib? I'm -1000 on the former, but only -0 on the latter -- as I wrote in the tracker, I just don't want to see an unproven proxy class (and I don't like the module name). > so I'll start working on a documentation > patch for the language reference instead which explicitly splits the special > methods into the following categories: Thanks for doing this, it is needed regardless! > 1. Method lookup MUST bypass __getattribute__, shadowing the attribute in > the instance dictionary MUST NOT have any ill effects. (All tp_* C-level > slots and slots looked up via _PyType_Lookup will fit into this category) Watch out: I think the term "method lookup" may be confusing here. Certainly when the user writes x.__foo__(), the instance dict *is* consulted. It is only on *implied* lookups (e.g. x[y] or x+y) where the instance dict is bypassed. > 2. Method lookup MAY bypass __getattribute__, shadowing the attribute in the > instance dictionary MAY have ill effects. (slots such as __enter__ and > __exit__ that are looked up via normal attribute lookup in CPython will fit > into this category) Why even have a MAY category? Are you expecting these to become tp_ slots at some point? > 3. Technically a subcategory of group 1, these are special methods which can > affect the interpreter's behaviour by their mere definition on a type. (The > __get__, __set__ and __delete__ descriptor protocol methods fall into this > category) I don't follow why this is relevant. This is a different, AFAIK orthogonal issue, used in many places: *if* an object used in a certain context has a specific attribute, *then* that attribute is used, *otherwise* a default action is taken. Applies to __repr__ just as much. These belong in category 1 if and only if the lookup bypasses the instance dict. -- --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] PEP 8 and optional underscores
If you want to have a meaningful discussion about this, the addition of the multiprocessing package and the recent threading.py API changes must be rolled back, so we can design a proper API without the beta 1 pressure. Some observations: - If it's isAlive() in Java style, it should be is_alive in Python style. - I like *methods* (and functions) named isfoo or is_foo, but I like the corresponding properties to be called just foo. - I think properties instead of simple setters and getters is great (as long as the setters implied in the property enforce the conditions). - I hate typing underscores, since they require using the shift key *and* moving my hands away from the home position on the keybord. --Guido On Thu, Jun 12, 2008 at 6:04 AM, Barry Warsaw <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Jun 12, 2008, at 8:29 AM, Facundo Batista wrote: > >> 2008/6/12 Barry Warsaw <[EMAIL PROTECTED]>: >> function:: active_count() method:: Thread.get_name() method:: Thread.is_alive() method:: Thread.is_daemon() method:: Thread.set_daemon(daemonic) >>> >>> +1 on opting for properties in the specific cases here where it makes >>> sense. >> >> I'm +1 too... but which is the normal procedure here? >> >> Should it be... >> >> 2.n : .is_alive() >> 2.n+1 : .is_alive() (deprecated), .alive (recommended) >> 2.n+2 : .alive > > Personally, I'd go with a property .is_alive > > - -Barry > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (Darwin) > > iQCVAwUBSFEeznEjvBPtnXfVAQKEeQP8CdF+N1wX4Qwxn7iglGYq0peZEYagn4JG > dOkP+TOkAzSciNfIotPaHJTGbyXsFtxLe3Rpq8r56/sPhHKS66+vCMojLBK64Iue > 7/PDhZ300KRpPtbJOOA4OmqI2rz1fO+vflavICZlx7oIwC25L7dQSteu/NBJYGJN > QX/Z8WutBng= > =1B3v > -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/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] [Python-3000] Betas today - I hope
Guido van Rossum wrote: [Barry] http://bugs.python.org/issue643841 [Guido] I've added a comment. Let me know if anything I said is unclear. On Thu, Jun 12, 2008 at 3:35 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote: The bugtracker seems to be offline atm - I'll reply there once I can get to it again (as well as switching this issue back to being a documentation one). I don't think we're going to see a major clamor for a value-based delegation mixin in the standard library until people using classic classes for value-based delegation start making serious attempts to port to Py3k (where that approach is no longer available). At the moment, such classes only need to care about the methods they want to fiddle with, leaving everything else to __getattr__ based delegation. Whether they'll care about this issue of course depends on whether they need overloaded operators and other special delegations to be delegated transparently. We'll have to see how important this is. New-style classes have been around and recommended for a long time -- why haven't people pushed for a proxy class before? It's only in Python 3 that old style classes are going away fully, so up until now you could at least use a classic class to do the proxying. I've written my own proxy classes before that look very similar to this, and there are other proxy classes around that do the same (I thought one was by Phillip J Eby but can't find a reference easily). The last one I wrote was to proxy CPython objects from IronPython via Python.NET... I would prefer it if the proxy class wrapped the return values of inplace operations. Michael Foord I've pushed as hard as I'm personally willing to for this without convincing anyone else that it's worth doing, What does *it* refer to? Changing the behavior, or adding a proxy class to the stdlib? I'm -1000 on the former, but only -0 on the latter -- as I wrote in the tracker, I just don't want to see an unproven proxy class (and I don't like the module name). so I'll start working on a documentation patch for the language reference instead which explicitly splits the special methods into the following categories: Thanks for doing this, it is needed regardless! 1. Method lookup MUST bypass __getattribute__, shadowing the attribute in the instance dictionary MUST NOT have any ill effects. (All tp_* C-level slots and slots looked up via _PyType_Lookup will fit into this category) Watch out: I think the term "method lookup" may be confusing here. Certainly when the user writes x.__foo__(), the instance dict *is* consulted. It is only on *implied* lookups (e.g. x[y] or x+y) where the instance dict is bypassed. 2. Method lookup MAY bypass __getattribute__, shadowing the attribute in the instance dictionary MAY have ill effects. (slots such as __enter__ and __exit__ that are looked up via normal attribute lookup in CPython will fit into this category) Why even have a MAY category? Are you expecting these to become tp_ slots at some point? 3. Technically a subcategory of group 1, these are special methods which can affect the interpreter's behaviour by their mere definition on a type. (The __get__, __set__ and __delete__ descriptor protocol methods fall into this category) I don't follow why this is relevant. This is a different, AFAIK orthogonal issue, used in many places: *if* an object used in a certain context has a specific attribute, *then* that attribute is used, *otherwise* a default action is taken. Applies to __repr__ just as much. These belong in category 1 if and only if the lookup bypasses the instance dict. ___ 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-3000] Betas today - I hope
Guido van Rossum wrote: [Barry] http://bugs.python.org/issue643841 [Guido] I've added a comment. Let me know if anything I said is unclear. On Thu, Jun 12, 2008 at 3:35 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote: The bugtracker seems to be offline atm - I'll reply there once I can get to it again (as well as switching this issue back to being a documentation one). I don't think we're going to see a major clamor for a value-based delegation mixin in the standard library until people using classic classes for value-based delegation start making serious attempts to port to Py3k (where that approach is no longer available). At the moment, such classes only need to care about the methods they want to fiddle with, leaving everything else to __getattr__ based delegation. Whether they'll care about this issue of course depends on whether they need overloaded operators and other special delegations to be delegated transparently. We'll have to see how important this is. New-style classes have been around and recommended for a long time -- why haven't people pushed for a proxy class before? There was an easier way to do it in the form of classic classes - the 2,x interpreter is riddled with special cases that ensure that __getattr__ is always consulted when looking for special methods on a classic class. The tracker issue regarding the fact that things aren't so simple with new style classes was actually raised way back in 2002 when someone tried to port such a class to new-style and discovered that overriding __getattribute__ was no longer enough. I've pushed as hard as I'm personally willing to for this without convincing anyone else that it's worth doing, What does *it* refer to? Changing the behavior, or adding a proxy class to the stdlib? I'm -1000 on the former, but only -0 on the latter -- as I wrote in the tracker, I just don't want to see an unproven proxy class (and I don't like the module name). "It" referred to adding the proxy class - I'm personally ambivalent on adding it at this point, because the complexity of it reduces my confidence that I got it right, but it also makes it seem unfair to users of this feature of classic classes to take it away in 3.0 without giving them some kind of functional replacement. As for as the module name goes, I don't particularly like it either - dropping something in the types module instead would be an alternative option. so I'll start working on a documentation patch for the language reference instead which explicitly splits the special methods into the following categories: Thanks for doing this, it is needed regardless! 1. Method lookup MUST bypass __getattribute__, shadowing the attribute in the instance dictionary MUST NOT have any ill effects. (All tp_* C-level slots and slots looked up via _PyType_Lookup will fit into this category) Watch out: I think the term "method lookup" may be confusing here. Certainly when the user writes x.__foo__(), the instance dict *is* consulted. It is only on *implied* lookups (e.g. x[y] or x+y) where the instance dict is bypassed. Ah good point, I'll make sure to be careful with that. 2. Method lookup MAY bypass __getattribute__, shadowing the attribute in the instance dictionary MAY have ill effects. (slots such as __enter__ and __exit__ that are looked up via normal attribute lookup in CPython will fit into this category) Why even have a MAY category? Are you expecting these to become tp_ slots at some point? Either tp_* slots, or just having the invocation bypass the instance attributes and only look at the object's type. I think it would actually be desirable for this category to be empty from a purity point of view (with all the special methods in category 1), but given that CPython itself currently doesn't conform to such a language spec, this seems to be the next best option (i.e. allowing other implementations or later versions of CPython to put these special methods in category 1 along with the rest of the special methods) 3. Technically a subcategory of group 1, these are special methods which can affect the interpreter's behaviour by their mere definition on a type. (The __get__, __set__ and __delete__ descriptor protocol methods fall into this category) I don't follow why this is relevant. This is a different, AFAIK orthogonal issue, used in many places: *if* an object used in a certain context has a specific attribute, *then* that attribute is used, *otherwise* a default action is taken. Applies to __repr__ just as much. These belong in category 1 if and only if the lookup bypasses the instance dict. Actual hasattr() checks aren't a problem - those hit __getattribute__ and a delegating class can correctly check them against the target object. Methods like __str__ or __repr__ also aren't a major issue - those are easy to delegate in a way that reproduces the same behaviour as if the delegating class wasn't there (just reinvoke the appropriate buil
Re: [Python-Dev] [Python-3000] Betas today - I hope
Michael Foord wrote: Guido van Rossum wrote: Whether they'll care about this issue of course depends on whether they need overloaded operators and other special delegations to be delegated transparently. We'll have to see how important this is. New-style classes have been around and recommended for a long time -- why haven't people pushed for a proxy class before? It's only in Python 3 that old style classes are going away fully, so up until now you could at least use a classic class to do the proxying. I've written my own proxy classes before that look very similar to this, and there are other proxy classes around that do the same (I thought one was by Phillip J Eby but can't find a reference easily). The last one I wrote was to proxy CPython objects from IronPython via Python.NET... I would prefer it if the proxy class wrapped the return values of inplace operations. Yeah, the latest version on the issue tracker does that, and allows subclasses to define a return_inplace() method to alter the behaviour (e.g. a weakref.proxy equivalent wouldn't want to wrap the return values so that it can ensure there is always at least one strong reference to the result of the operation). Since you can also replace the .target attribute with a property to affect how the target object is stored and accessed, it's a reasonably flexible approach. Cheers, 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
Re: [Python-Dev] [Python-3000] Betas today - I hope
M.-A. Lemburg wrote:
On 2008-06-11 17:15, Walter Dörwald wrote:
M.-A. Lemburg wrote:
On 2008-06-11 13:35, Barry Warsaw wrote:
So I had planned to do a bunch of work last night looking at the
release blocker issues, but nature intervened. A bunch of severe
thunderstorms knock out my 'net access until this morning.
I'll try to find some time during the day to look at the RB issues.
Hopefully we can get Guido to look at them too and Pronounce on some
of them. Guido please start with:
http://bugs.python.org/issue643841
My plan is to begin building the betas tonight, at around 9 or 10pm
EDT (0100 to 0200 UTC Thursday). If a showstopper comes up before
then, I'll email the list. If you think we really aren't ready for
beta, then I would still like to get a release out today. In that
case, we'll call it alpha and delay the betas.
There are two things I'd like to get in to 3.0:
* .transform()/.untransform() methods (this is mostly done, just need
to add the methods to PyUnicode, PyBytes and PyByteArray)
What would these methods do? Use the codec machinery without any type
checks?
As discussed in another thread some weeks ago:
.transform() and .untransform() use the codecs to apply same-type
conversions. They do apply type checks to make sure that the
codec does indeed return the same type.
E.g. text.transform('xml-escape') or data.transform('base64').
So what would a base64 codec do with the errors argument?
I think for transformations we don't need the full codec machinery:
> ...
No need to invent another wheel :-) The codecs already exist for
Py2.x and can be used by the .encode()/.decode() methods in Py2.x
(where no type checks occur).
By using a new API we could get rid of old warts. For example: Why does
the stateless encoder/decoder return how many input characters/bytes it
has consumed? It must consume *all* bytes anyway!
In Py3.x, .encode()/.decode() only allow conversions of the type
unicode <-> bytes. .transform()/.untransform() add conversions
of the type unicode <-> unicode or bytes <-> bytes.
All other conversions in Py3.x have to go through codecs.encode() and
codecs.decode() which are the generic codec access functions from
the codec registry.
Servus,
Walter
___
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] PEP 8 and optional underscores
>> Should it be... >> >> 2.n : .is_alive() >> 2.n+1 : .is_alive() (deprecated), .alive (recommended) >> 2.n+2 : .alive Barry> Personally, I'd go with a property .is_alive I'm not fond of using a property for this since it can lull you into the false belief that what you are doing is less expensive than it really is (attribute access vs method call). I think this is a case where explicit is better than implicit. 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] bug or a feature?
Hi,
On Wed, Jun 11, 2008 at 10:44:17PM -0400, Scott Dial wrote:
> The only reason the test used locals() was
> because it was the only way to insert a non-string key into the class
> namespace.
This discussion is mistakenly focused on locals(). There is a direct
way to have arbitrary keys in the dict of a type:
>>> MyClass = type('MyClass', (Base,), {42: 64})
>>> MyClass.__dict__[42]
64
There is, however, no way to modify or add non-string keys in the type
after its creation. So the question is whether the type() constructor
is allowed to fail with a TypeError when the initial dict contains
non-string keys (this is PyPy's current behavior).
A bientot,
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] PEP 8 and optional underscores
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jun 12, 2008, at 11:21 AM, [EMAIL PROTECTED] wrote: Should it be... 2.n : .is_alive() 2.n+1 : .is_alive() (deprecated), .alive (recommended) 2.n+2 : .alive Barry> Personally, I'd go with a property .is_alive I'm not fond of using a property for this since it can lull you into the false belief that what you are doing is less expensive than it really is (attribute access vs method call). I think this is a case where explicit is better than implicit. I've heard this argument before, and it's one I'm not unsympathetic to. Usually I've heard it in the context of remote network access, e.g. let's say .alive had to make a REST call over the net each time. Well, maybe there's caching involved which amortizes the costs, so the argument gets trickier. Ideally, I would like for those considerations to not enter into the API design. I'd rather keep it clean, with sufficient documentation to give hints about any additional costs involved. Logically .alive is a property, so I'd like to write it that way. Perhaps function annotations help out here. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSFFDanEjvBPtnXfVAQJxbAQAq2BDNE7m+J+5Jy3E4XlHaw8JXsEaukEA YvZ1M1R1mREGCstIf4tlScKko1eu9PfJIk7+kCmFYezighJ1tPZunyu5zLemlgQe 9rJ9keFIJBLtao8yv+FPkn56idixtkTGq+14Ef+EhjIhOnbonp+eDuhScbE2tdzM 5tuFO/hsrqw= =66R7 -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] [Python-3000] Betas today - I hope
On 2008-06-12 16:59, Walter Dörwald wrote:
M.-A. Lemburg wrote:
.transform() and .untransform() use the codecs to apply same-type
conversions. They do apply type checks to make sure that the
codec does indeed return the same type.
E.g. text.transform('xml-escape') or data.transform('base64').
So what would a base64 codec do with the errors argument?
It could use it to e.g. try to recover as much data as possible
from broken input data.
Currently (in Py2.x), it raises an exception if you pass in anything
but "strict".
I think for transformations we don't need the full codec machinery:
> ...
No need to invent another wheel :-) The codecs already exist for
Py2.x and can be used by the .encode()/.decode() methods in Py2.x
(where no type checks occur).
By using a new API we could get rid of old warts. For example: Why does
the stateless encoder/decoder return how many input characters/bytes it
has consumed? It must consume *all* bytes anyway!
No, it doesn't and that's the point in having those return values :-)
Even though the encoder/decoders are stateless, that doesn't mean
they have to consume all input data. The caller is responsible to
make sure that all input data was in fact consumed.
You could for example have a decoder that stops decoding after
having seen a block end indicator, e.g. a base64 line end or
XML closing element.
Just because all codecs that ship with Python always try to decode
the complete input doesn't mean that the feature isn't being used.
The interface was designed to allow for the above situations.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Jun 12 2008)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/
2008-07-07: EuroPython 2008, Vilnius, Lithuania24 days to go
Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free !
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
___
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] Assignment to None
I haven't been following this thread very closely, so I'm not sure what the status is, but I'd just like to point out that yesterday I used the fact that a[None] = b works, when I used the @memoize decorator from the wiki. This seems to provide an argument that, for symmetry's sake, we might want to keep a.None = b as well. -- Cheers, Leif ___ 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] Assignment to None
On Thu, Jun 12, 2008 at 10:13 AM, Leif Walsh <[EMAIL PROTECTED]> wrote: > I haven't been following this thread very closely, so I'm not sure > what the status is, but I'd just like to point out that yesterday I > used the fact that a[None] = b works, when I used the @memoize > decorator from the wiki. This seems to provide an argument that, for > symmetry's sake, we might want to keep a.None = b as well. That makes about as much sense as wanting to support a.42 = b since a[42] = b works. :-) -- --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] Assignment to None
On Thu, Jun 12, 2008 at 10:28 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > That makes about as much sense as wanting to support a.42 = b since > a[42] = b works. :-) Well don't I feel silly now. -- Cheers, Leif ___ 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-3000] Betas today - I hope
On 6/12/08, Nick Coghlan <[EMAIL PROTECTED]> wrote: > documentation patch for the language reference ... > following categories: ... > 2. Method lookup MAY bypass __getattribute__, shadowing the attribute in > the instance dictionary MAY have ill effects. (slots such as __enter__ and > __exit__ that are looked up via normal attribute lookup in CPython will fit > into this category) Should this category really be enumerated? I thought that was the default meaning of __name__, so the real clarification is: (1) Requiring that the specific names in category 1 MUST be treated this way. (2) Mentioning __*__ and listing any known exceptions. (Can "next" be treated this way despite the lack of __*__? Is it forbidden to treat __context__ this way?) -jJ ___ 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] bug or a feature?
"Phillip J. Eby" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] | At 08:32 PM 6/11/2008 -0400, Terry Reedy wrote: | >The Data Model chapter of the Reference Manual lists .__dict__ as a special | >attribute of callables, modules, classes, and instances. It describes | >__dict__ as a "namespace dictionary" or "implementation of the namespace" | >thereof. Since namespaces map names (or possibly non-name strings) to | >objects, this to me implies that an implementation is and should not be | >required to allow non-strings in __dict__. | > | >The same chapter has more than one sentence saying something like "o.x is | >equivalent to o.__dict__['x']". While one could read this as prohibiting | >o.__dict__[non_string], one could also read it as being silent, neither | >allowing nor prohibiting. | | As it happens, most objects' __dict__ slots are settable by default, | and *require* that you set it to a dict or subclass thereof. This | seems (to me) to imply that a standard dictionary (i.e. one | supporting keys of any type) is required. (In the sense that a dict | subclass which rejects non-strings would be violating the Liskov principle.) Is this requirement a documented Python requirement (not that I found), an undocumented Python requirement, or a CPython-specific requirement (that other implementations may freely ignore)? I don't have much opinion on what the rules for __dict__ attributes should be, just that whatever they are should be documented. This include implementation-defined aspects. This will help both implementors and users who wish to write Python code rather that CPython code. If there is a consensus and BDFL pronouncement, I will make or help review suggested doc changes. tjr ___ 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] bug or a feature?
On Thu, Jun 12, 2008 at 8:24 AM, Armin Rigo <[EMAIL PROTECTED]> wrote:
> This discussion is mistakenly focused on locals(). There is a direct
> way to have arbitrary keys in the dict of a type:
>
MyClass = type('MyClass', (Base,), {42: 64})
MyClass.__dict__[42]
> 64
>
> There is, however, no way to modify or add non-string keys in the type
> after its creation. So the question is whether the type() constructor
> is allowed to fail with a TypeError when the initial dict contains
> non-string keys (this is PyPy's current behavior).
The intention was for these dicts to be used as namespaces. I think of
it as follows:
(a) Using non-string keys is a no-no, but the implementation isn't
required to go out of its way to forbid it.
(b) Using non-empty string keys that aren't well-formed identifiers
should be allowed.
--
--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] bug or a feature?
On Thu, Jun 12, 2008 at 9:46 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> The intention was for these dicts to be used as namespaces. I think of
> it as follows:
>
> (a) Using non-string keys is a no-no, but the implementation isn't
> required to go out of its way to forbid it.
That will allow easier and more efficient implementation, good!
> (b) Using non-empty string keys that aren't well-formed identifiers
> should be allowed.
ok.
Is it allowed to "normalize" subclasses of strings to regular string,
e.g. after:
class mystring(str): pass
class C: pass
x = C()
setattr(x, mystring('foo'), 42)
is it allowed that the dict of x contains a regular string 'foo'
instead of the mystring instance?
- Willem
___
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] bug or a feature?
At 12:46 PM 6/12/2008 -0700, Guido van Rossum wrote: The intention was for these dicts to be used as namespaces. By "these" do you mean type object __dict__ attributes, or *all* __dict__ attributes? ___ 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] bug or a feature?
On Thu, Jun 12, 2008 at 1:01 PM, Willem Broekema <[EMAIL PROTECTED]> wrote:
> On Thu, Jun 12, 2008 at 9:46 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>> The intention was for these dicts to be used as namespaces. I think of
>> it as follows:
>>
>> (a) Using non-string keys is a no-no, but the implementation isn't
>> required to go out of its way to forbid it.
>
> That will allow easier and more efficient implementation, good!
>
>> (b) Using non-empty string keys that aren't well-formed identifiers
>> should be allowed.
>
> ok.
>
> Is it allowed to "normalize" subclasses of strings to regular string,
> e.g. after:
>
> class mystring(str): pass
> class C: pass
>
> x = C()
> setattr(x, mystring('foo'), 42)
>
> is it allowed that the dict of x contains a regular string 'foo'
> instead of the mystring instance?
I think yes, as this would allow for a more efficient implementation
of the custom dict class.
--
--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] bug or a feature?
On Thu, Jun 12, 2008 at 2:42 PM, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > At 12:46 PM 6/12/2008 -0700, Guido van Rossum wrote: >> >> The intention was for these dicts to be used as namespaces. > > By "these" do you mean type object __dict__ attributes, or *all* __dict__ > attributes? Hadn't thought of that one! Since __dict__ is widely advertised as being, well, a dict, it may be harder to enforce this for __dict__ instances of other objects. I'd like to tighten the rules here too, but only if it actually helps Python implementations other than CPython. -- --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] OFF-TOPIC-BUT-IMPORTANT: End of free internet model by 2012 ?
On Wed, Jun 11, 2008 at 4:25 PM, Daniel Bonekeeper <[EMAIL PROTECTED]> wrote: > Hi everybody on the list ! > > Sorry about the off-topic message, but giving the nature of the > message and the nature of the list (after all, everybody here uses > Internet or develops for web in some way), I decided to post this here > and see what you guys think about it. > My gut feeling is that you are being taken by some fairly amateurish viral marketing, and that you've played into it by uncritically regurgitating the message onto these mailing lists. Googling "Dylan Pattyn" yields only references to this very video and a site for a performance art/activist group called IPower, which boasts such "projects" as "an suicide-awareness campaign disguised as a personal suicide blog", a self-described "online stunt" called "40,000 Blowjobs", and a "wacky online reality series". Really, do you honestly think that Time Magazine would use a twenty-something freelancer, who has never published anything in any major periodical, to break a news article that would at the least create a decade or more of anti-trust lawsuits? -- Tim Lesher <[EMAIL PROTECTED]> ___ 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] Assignment to None
On Wed, Jun 11, 2008 at 5:27 PM, Curt Hagenlocher <[EMAIL PROTECTED]> wrote: > If I recall correctly, Jython handles this by appending a trailing > underscore to the imported name and there's no reason why we couldn't > do something similar. In truth the current implementation of Jython allows keywords in many strange places, I expect this was done to allow for method names that are not keywords in Java so, for example, if there is a method called "print" in a Java class that we want to call (quite common) then it can be called. As far as I know appended underscores don't enter into it. Some poking around reveals that the current Jython is probably too lax here, even keywords that are common to both Python and Java can be method names (like "if"). I plan to continue to allow Python keywords that are not Java keywords to behave this way at least for the 2.x series, though I don't think I'm going to go through the effort of allowing keywords common to both Java and Python like "if" (The 2.5 version of Jython will have a new parser so I do actually need to make these explicit choices right now). I think changing this behavior would hurt backwards compatibility too much. Maybe I'll rethink it in our 3.0 timeframe. If a convention like a trailing underscore is adopted we might move to that in the move to 3.0. -Frank ___ 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] Assignment to None
On Thu, Jun 12, 2008 at 8:06 PM, Frank Wierzbicki <[EMAIL PROTECTED]> wrote:
>
> On Wed, Jun 11, 2008 at 5:27 PM, Curt Hagenlocher <[EMAIL PROTECTED]> wrote:
> > If I recall correctly, Jython handles this by appending a trailing
> > underscore to the imported name and there's no reason why we couldn't
> > do something similar.
>
> In truth the current implementation of Jython allows keywords in many
> strange places, I expect this was done to allow for method names that
> are not keywords in Java so, for example, if there is a method called
> "print" in a Java class that we want to call (quite common) then it
> can be called. As far as I know appended underscores don't enter into
> it.
After posting that message, I did what I should have done initially
which was to ask Jim Hugunin about it. He said that Jython had gotten
Guido's blessing to parse keywords in a context-sensitive fashion --
so that "foo.{keyword}" might be considered legal under certain
circumstances. I don't, alas, have any specific cites to that end,
but I suspect that we'll be following that precedent :).
--
Curt Hagenlocher
[EMAIL PROTECTED]
___
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] bug or a feature?
On Wed, Jun 11, 2008 at 5:50 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote: > Greg Ewing wrote: > Implementations are also permitted to restrict namespace dictionaries to > only accept string keys (I believe Jython does this for performance reasons > - CPython just optimised the hell out of normal dictionaries that happen to > only contain string keys instead). Jython's current version (2.2) and back did indeed restrict these dictionaries to accept string keys only, but future versions will allow non-string keys (the trunk version already does). Many frameworks use non-string keys in these dictionaries. -Frank ___ 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] Interesting blog post by Ben Sussman-Collins
My colleague and SVN developer Ben Sussman-Collins occasionally blogs about the social side of (mostly open source) software development. He just posted a new one that struck a chord: http://blog.red-bean.com/sussman/?p=96 The story's main moral: submit your code for review early and often; work in a branch if you need to, but don't hide your code from review in a local repository until it's "perfect". Let's all remember this and make sure not to drop "code bombs" on each other. :-) -- --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] bug or a feature?
On Thu, Jun 12, 2008 at 8:19 PM, Frank Wierzbicki <[EMAIL PROTECTED]> wrote: > On Wed, Jun 11, 2008 at 5:50 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote: >> Greg Ewing wrote: >> Implementations are also permitted to restrict namespace dictionaries to >> only accept string keys (I believe Jython does this for performance reasons >> - CPython just optimised the hell out of normal dictionaries that happen to >> only contain string keys instead). > Jython's current version (2.2) and back did indeed restrict these > dictionaries to accept string keys only, but future versions will > allow non-string keys (the trunk version already does). Many > frameworks use non-string keys in these dictionaries. I think that's laudable from a compatibility POV, but at the same time I think frameworks should rethink such usage and switch to strings containing non-identifier characters, e.g. '$' or '.' or some such convention. -- --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] Interesting blog post by Ben Sussman-Collins
On Thu, Jun 12, 2008 at 8:41 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > My colleague and SVN developer Ben Sussman-Collins occasionally blogs > about the social side of (mostly open source) software development. He > just posted a new one that struck a chord: > > http://blog.red-bean.com/sussman/?p=96 > > The story's main moral: submit your code for review early and often; > work in a branch if you need to, but don't hide your code from review > in a local repository until it's "perfect". > > Let's all remember this and make sure not to drop "code bombs" on each > other. :-) Ben mentions this in the post, but it's a good reminder: comments on python-checkins are *not* personal. The goal is to make the code better and/or gain better understanding. We all make mistakes, better to correct them early before they become big problems.. n ___ 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-3000-checkins] r64217 - in python/branches/py3k/Lib: bsddb/test/test_associate.py bsddb/test/test_join.py bsddb/test/test_lock.py bsddb/test/test_thread.py idlelib/rpc.py idle
It's water under the bridge now, but IMO it was too rash to *remove* the old threading API from Py3k, and doubly rash to do so one day before the beta release. Running up to a release (whether alpha, beta or final) we should practice extra restraint, not rush to get things in right before the deadline. Let's all be more careful the rest of this release cycle! (I think it wasn't just Benjamin who raced to get things in...) --Guido On Thu, Jun 12, 2008 at 7:00 PM, benjamin.peterson <[EMAIL PROTECTED]> wrote: > Author: benjamin.peterson > Date: Fri Jun 13 04:00:47 2008 > New Revision: 64217 > > Log: > fix more threading API related bugs > > Modified: > python/branches/py3k/Lib/bsddb/test/test_associate.py > python/branches/py3k/Lib/bsddb/test/test_join.py > python/branches/py3k/Lib/bsddb/test/test_lock.py > python/branches/py3k/Lib/bsddb/test/test_thread.py > python/branches/py3k/Lib/idlelib/rpc.py > python/branches/py3k/Lib/idlelib/run.py > python/branches/py3k/Lib/socketserver.py > python/branches/py3k/Lib/test/test_threadedtempfile.py > python/branches/py3k/Lib/threading.py > > Modified: python/branches/py3k/Lib/bsddb/test/test_associate.py > == > --- python/branches/py3k/Lib/bsddb/test/test_associate.py (original) > +++ python/branches/py3k/Lib/bsddb/test/test_associate.py Fri Jun 13 > 04:00:47 2008 > @@ -9,7 +9,7 @@ > from pprint import pprint > > try: > -from threading import Thread, currentThread > +from threading import Thread, current_thread > have_threads = 1 > except ImportError: > have_threads = 0 > [etc.] -- --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] Interesting blog post by Ben Sussman-Collins
On Thu, Jun 12, 2008 at 8:49 PM, Neal Norwitz <[EMAIL PROTECTED]> wrote: > On Thu, Jun 12, 2008 at 8:41 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: >> My colleague and SVN developer Ben Sussman-Collins occasionally blogs >> about the social side of (mostly open source) software development. He >> just posted a new one that struck a chord: >> >> http://blog.red-bean.com/sussman/?p=96 >> >> The story's main moral: submit your code for review early and often; >> work in a branch if you need to, but don't hide your code from review >> in a local repository until it's "perfect". >> >> Let's all remember this and make sure not to drop "code bombs" on each >> other. :-) > > Ben mentions this in the post, but it's a good reminder: comments on > python-checkins are *not* personal. The goal is to make the code > better and/or gain better understanding. We all make mistakes, better > to correct them early before they become big problems.. And this reminder applies to reviewer *and* reviewees! (I know I've made this mistake in both roles. :-) -- --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
