Re: [Python-Dev] super_getattro() Behaviour
> "Phil Thompson" <[EMAIL PROTECTED]> writes: > >> In PyQt, wrapped types implement lazy access to the type dictionary >> through tp_getattro. If the normal attribute lookup fails, then private >> tables are searched and the attribute (if found) is created on the fly >> and >> returned. It is also put into the type dictionary so that it is found >> next >> time through the normal lookup. This is done to speed up the import of, >> and the memory consumed by, the qt module which contains thousands of >> class methods. >> >> This all works fine - except when super is used. >> >> The implementation of super_getattro() doesn't use the normal attribute >> lookup (ie. doesn't go via tp_getattro). Instead it walks the MRO >> hierarchy itself and searches instance dictionaries explicitly. This >> means >> that attributes that have not yet been referenced (ie. not yet been >> cached >> in the type dictionary) will not be found. >> >> Questions... >> >> 1. What is the reason why it doesn't go via tp_getattro? > > Because it wouldn't work if it did? I'm not sure what you're > suggesting here. I'm asking for an explanation for the current implementation. Why wouldn't it work if it got the attribute via tp_getattro? >> 2. A possible workaround is to subvert the ma_lookup function of the >> type >> dictionary after creating the type to do something similar to what my >> tp_getattro function is doing. > > Eek! Agreed. >> Are there any inherent problems with that? > > Well, I think the layout of dictionaries is fiercely private. IIRC, > the only reason it's in a public header is to allow some optimzations > in ceval.c (though this isn't at all obvious from the headers, so > maybe I'm mistaken). Yes, having looked in more detail at the dict implementation I really don't want to go there. >> 3. Why, when creating a new type and eventually calling type_new() is a >> copy of the dictionary passed in made? > > I think this is to prevent changes to tp_dict behind the type's back. > It's important to keep the dict and the slots in sync. > >> Why not take a reference to it? This would allow a dict sub-class >> to be used as the type dictionary. I could then implement a >> lazy-dict sub-class with the behaviour I need. > > Well, not really, because super_getattro uses PyDict_GetItem, which > doesn't respect subclasses... I suppose I was hoping for more C++ like behaviour. >> 4. Am I missing a more correct/obvious technique? (There is no need to >> support classic classes.) > > Hum, I can't think of one, I'm afraid. > > There has been some vague talk of having a tp_lookup slot in > typeobjects, so > > PyDict_GetItem(t->tp_dict, x); > > would become > > t->tp_lookup(x); > > (well, ish, it might make more sense to only do that if the dict > lookup fails). That would be perfect. I can't Google any reference to a discussion - can you point me at something? > For now, not being lazy seems your only option :-/ (it's what PyObjC > does). Not practical I'm afraid. I think I can only document that super doesn't work in this context. Thanks, Phil ___ 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] super_getattro() Behaviour
"Phil Thompson" <[EMAIL PROTECTED]> writes: >>> Questions... >>> >>> 1. What is the reason why it doesn't go via tp_getattro? >> >> Because it wouldn't work if it did? I'm not sure what you're >> suggesting here. > > I'm asking for an explanation for the current implementation. Why wouldn't > it work if it got the attribute via tp_getattro? Well, using type->tp_getattro is just different to looking in tp_dict -- it finds metamethods, for example. Hmm. Well, I'm fairly sure there is a difference, I'm not sure I can explain it right now :( >>> 2. A possible workaround is to subvert the ma_lookup function of the >>> type >>> dictionary after creating the type to do something similar to what my >>> tp_getattro function is doing. [...] > Yes, having looked in more detail at the dict implementation I really > don't want to go there. Good :) >>> 4. Am I missing a more correct/obvious technique? (There is no need to >>> support classic classes.) >> >> Hum, I can't think of one, I'm afraid. >> >> There has been some vague talk of having a tp_lookup slot in >> typeobjects, so >> >> PyDict_GetItem(t->tp_dict, x); >> >> would become >> >> t->tp_lookup(x); >> >> (well, ish, it might make more sense to only do that if the dict >> lookup fails). > > That would be perfect. I can't Google any reference to a discussion - can > you point me at something? Well, most of the discussion so far has been in my head :) There was a little talk of it in the thread "can we stop pretending _PyType_Lookup is internal" here and possibly on pyobjc-dev around the same time. I'm not that likely to work on it soon -- I have enough moderately complex patches to core Python I'm persuading people to think about :-/. >> For now, not being lazy seems your only option :-/ (it's what PyObjC >> does). > > Not practical I'm afraid. I think I can only document that super doesn't > work in this context. Oh well. I can't even think of a way to make it fail reliably... Cheers, mwh -- Java sucks. [...] Java on TV set top boxes will suck so hard it might well inhale people from off their sofa until their heads get wedged in the card slots. --- Jon Rabone, ucam.chat ___ 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] super_getattro() Behaviour
4. Am I missing a more correct/obvious technique? (There is no need to support classic classes.) >>> >>> Hum, I can't think of one, I'm afraid. >>> >>> There has been some vague talk of having a tp_lookup slot in >>> typeobjects, so >>> >>> PyDict_GetItem(t->tp_dict, x); >>> >>> would become >>> >>> t->tp_lookup(x); >>> >>> (well, ish, it might make more sense to only do that if the dict >>> lookup fails). >> >> That would be perfect. I can't Google any reference to a discussion - >> can >> you point me at something? > > Well, most of the discussion so far has been in my head :) > > There was a little talk of it in the thread "can we stop pretending > _PyType_Lookup is internal" here and possibly on pyobjc-dev around the > same time. > > I'm not that likely to work on it soon -- I have enough moderately > complex patches to core Python I'm persuading people to think about > :-/. Anything I can do to help push it along? Phil ___ 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] Re: Unified or context diffs?
Bob Ippolito wrote: > It might be worth mentioning that if/when subversion is used to replace CVS, > unified diffs are > going to be the obvious way to do it, because I don't think that subversion > supports context diffs > without using an external diff command. subversion? you meant bazaar-ng, right? ___ 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] Check out a new way to read threaded conversations.
I hope you will not mind too much if I ask a small favor. Sorry for this off-topic post. I am working on a new design for displaying online conversations. (Some of you saw this at PyCon.) I'm conducting a short survey to gather some opinions on the current design. If you have just a few minutes to spare, would you please visit: http://zesty.ca/threadmap/pydev.cgi You'll see a new way of looking at this discussion list that you may find pretty interesting. I look forward to learning what you think of it. I am very grateful for your time and assistance. (If you reply to this message, please reply to me only -- I don't want to clutter up python-dev with lots of off-topic messages.) -- Ping ___ 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] Re: marshal / unmarshal
On 4/11/05, Tim Peters <[EMAIL PROTECTED]> wrote: > Heh. I have a vague half-memory of _some_ box that stored the two > 4-byte "words" in an IEEE double in one order, but the bytes within > each word in the opposite order. It's always something ... I believe this was the Floating Instruction Set on the PDP 11/35. The fact that it's still remembered 30 years later shows how unusual it was. ___ 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] Re: marshal / unmarshal
Hi,
For AIX:
Python 2.2 (#1, Feb 17 2003, 21:43:03) [C] on aix4
Type "help", "copyright", "credits" or "license" for more information.
>>> import marshal
>>> marshal.dumps(1e1)
'f\x03INF'
>>> marshal.loads(marshal.dumps(1e1))
INF
>>> float("INF")
INF
>>> float("NaN")
NaNQ
>>>
On 4/9/05, Skip Montanaro <[EMAIL PROTECTED]> wrote:
>
> Martin> Yet, this *still* is a platform dependence. Python makes no
> Martin> guarantee that 1e1000 is a supported float literal on any
> Martin> platform, and indeed, on your platform, 1e1000 is not supported
> Martin> on your platform.
>
> Are float("inf") and float("nan") supported everywhere?
>
--
LD Landis - N0YRQ - from the St Paul side of Minneapolis
___
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] PyCallable_Check redeclaration
Why is PyCallable_Check declared in both object.h and abstract.h? It appears that it's been this way for quite some time (exists in both 2.3.4 and 2.4.1). -- Nick ___ 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] Weekly Python Patch/Bug Summary
Patch / Bug Summary ___ Patches : 314 open ( +6) / 2824 closed ( +5) / 3138 total (+11) Bugs: 898 open (+16) / 4921 closed ( +8) / 5819 total (+24) RFE : 177 open ( +1) / 151 closed ( +0) / 328 total ( +1) New / Reopened Patches __ typos in rpc.py (2005-04-09) CLOSED http://python.org/sf/1179503 opened by engelbert gruber [AST] Fix for core in test_grammar.py (2005-04-08) http://python.org/sf/1179513 opened by logistix no html file for modulefinder (2005-04-10) http://python.org/sf/1180012 opened by George Yoshida fix typos in Library Reference (2005-04-10) http://python.org/sf/1180062 opened by George Yoshida great improvement for locale.py formatting functions (2005-04-10) http://python.org/sf/1180296 opened by Georg Brandl clarify behavior of StringIO objects when preinitialized (2005-04-10) CLOSED http://python.org/sf/1180305 opened by Georg Brandl st_gen and st_birthtime support for FreeBSD (2005-04-11) http://python.org/sf/1180695 opened by Antti Louko binary formats for marshalling floats (2005-04-11) http://python.org/sf/1180995 opened by Michael Hudson make float packing copy bytes when they can (2005-04-12) http://python.org/sf/1181301 opened by Michael Hudson range() in for loops, again (2005-04-12) http://python.org/sf/1181334 opened by Armin Rigo HMAC hexdigest and general review (2005-04-13) http://python.org/sf/1182394 opened by Shane Holloway Patches Closed __ Complex commented (2005-04-06) http://python.org/sf/1177597 closed by loewis typos in rpc.py (2005-04-08) http://python.org/sf/1179503 closed by rhettinger clarify behavior of StringIO objects when preinitialized (2005-04-10) http://python.org/sf/1180305 closed by rhettinger Improved output for unittest failUnlessEqual (2003-04-22) http://python.org/sf/725569 closed by purcell [AST] Generator expressions (2005-03-21) http://python.org/sf/1167628 closed by bcannon New / Reopened Bugs ___ 256 should read 255 in operator module docs (2005-04-06) CLOSED http://python.org/sf/1178255 opened by Dan Everhart operator.isMappingType and isSequenceType on instances (2005-04-06) CLOSED http://python.org/sf/1178269 opened by Dan Everhart Erroneous line number error in Py2.4.1 (2005-04-07) http://python.org/sf/1178484 opened by Timo Linna configure: refuses setgroups (2005-04-07) http://python.org/sf/1178510 opened by zosh 2.4.1 breaks pyTTS (2005-04-07) http://python.org/sf/1178624 opened by Dieter Deyke Variable.__init__ uses self.set(), blocking specialization (2005-04-07) http://python.org/sf/1178863 opened by Emil Variable.__init__ uses self.set(), blocking specialization (2005-04-07) http://python.org/sf/1178872 opened by Emil IDLE bug - changing shortcuts (2005-04-08) http://python.org/sf/1179168 opened by Przemysław Gocyła can't import thru cygwin symlink (2005-04-08) http://python.org/sf/1179412 opened by steveward Missing def'n of equality for set elements (2005-04-09) CLOSED http://python.org/sf/1179957 opened by Skip Montanaro codecs.readline sometimes removes newline chars (2005-04-02) http://python.org/sf/1175396 reopened by doerwalter locale.format question (2005-04-10) CLOSED http://python.org/sf/1180002 opened by Andrew Ma test_posix fails on cygwin (2005-04-10) http://python.org/sf/1180147 opened by Henrik Wist subprocess.Popen fails with closed stdout (2005-04-10) http://python.org/sf/1180160 opened by neuhauser broken pyc files (2005-04-10) http://python.org/sf/1180193 opened by Armin Rigo Python keeps file references after calling close methode (2005-04-10) http://python.org/sf/1180237 opened by Eelco expanding platform module and making it work as it should (2005-04-10) http://python.org/sf/1180267 opened by Nikos Kouremenos StringIO's docs should mention overwriting of initial value (2005-04-10) CLOSED http://python.org/sf/1180392 opened by Leif K-Brooks BaseHTTPServer uses deprecated mimetools.Message (2005-04-11) http://python.org/sf/1180470 opened by Paul Jimenez lax error-checking in new-in-2.4 marshal stuff (2005-04-11) http://python.org/sf/1180997 opened by Michael Hudson Bad sys.executable value for bdist_wininst install script (2005-04-12) http://python.org/sf/1181619 opened by follower asyncore.loop() documentation (2005-04-13) http://python.org/sf/1181939 opened by Graham re.escape(s) prints wrong for chr(0) (2005-04-13) http://python.org/sf/1182603 opened by Nick Jacobson dir() does not include _ (2005-04-13) http://python.org/sf/1182614 opened by Nick Jacobson ZipFile __del__/close problem with longint/long files (2005-04-14) http://pyt
[Python-Dev] shadow password module (spwd) is never built due to error in setup.py
Hello, A modification was made in setup.py, cvs rel 1.213 (see diff here: http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/setup.py?r1=1.212&r2=1.213 ) which appears to be wrong. At least, on my system, the spwd module is never built anymore, because the if statement is never true. Actually, the sysconfig doesn't contain *any* of the HAVE_ vars that occur in pyconfig.h (I checked by printing all vars). I don't really understand the distutils magic that is done in setup.py, but it appears to me that either the if statement is wrong (because the vars never exist) or distutils does something wrong by leaving out all HAVE_XXX vars from pyconfig.h. Please advise? I want my spwd module back ;-) --Irmen de Jong PS I checked that pyconfig.h correctly #defines both HAVE_GETSPNAM and HAVE_GETSPENT to 1 on my system (Mandrake linux 10.1), so the rest of the configure script runs fine (it should, I created the original patches for it... see SF patch # 579435) ___ 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] Check out a new way to read threaded conversations.
> http://zesty.ca/threadmap/pydev.cgi Very reminiscent of Paula Newman's work at PARC several years ago. Check out http://www2.parc.com/istl/groups/hdi/papers/psn_emailvis01.pdf, particularly page 5. Bill ___ 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] Inconsistent exception for read-only properties?
I've noticed an apparent inconsistency in the exception thrown for read-only properties for C extension types vs. Python new-style classes. I'm wondering if this is intentional, a bug, a bug worth fixing, or whether I'm just missing something. class other(object): def __init__(self, value): self._value = value def _get_value(self): return self._value value = property(_get_value) With this class, if you attempt "other(1).value = 7" you will get an AttributeError. However, if you define something similar in C using a tp_getset, where the structure has NULL for the setter, you will get a TypeError (code available upon request). At best, this is inconsistent. What's the "right" exception to raise? I think the documentation I've seen (e.g. Raymond's How To for Descriptors) describes AttributeError as the thing to raise when trying to set read-only properties. Thoughts? Should this be fixed (in 2.4?). -Barry signature.asc Description: This is a digitally signed message part ___ 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] shadow password module (spwd) is never built due to error in setup.py
Irmen de Jong wrote: > Please advise? setup.py should refer to config_h_vars, which in turn should be set earlier. 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
