[Python-Dev] What about CALL_ATTR?
While rummaging in the old patches, I found this: The result of the PyCore sprint of me and Brett: the CALL_ATTR opcode (LOAD_ATTR and CALL_FUNCTION combined) that skips the PyMethod creation and destruction for classic classes (but not newstyle classes, yet.) The code is somewhat rough yet, it needs commenting, some renaming, and most importantly testing. It seems to work, however, and provides between a 35% and 5% speedup. (5% in 'average' code, up to 35% in instance method calls and instance creation alone.) It also needs to be updated to include newstyle classes. I will likely work on this on the flight home. (patch #709744) How is the status of this? Sounds promising, I'd say... Reinhold -- Mail address is perfectly valid! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] What about CALL_ATTR?
Reinhold Birkenfeld wrote: While rummaging in the old patches, I found this: The result of the PyCore sprint of me and Brett: the CALL_ATTR opcode (LOAD_ATTR and CALL_FUNCTION combined) that skips the PyMethod creation and destruction for classic classes (but not newstyle classes, yet.) The code is somewhat rough yet, it needs commenting, some renaming, and most importantly testing. It seems to work, however, and provides between a 35% and 5% speedup. (5% in 'average' code, up to 35% in instance method calls and instance creation alone.) It also needs to be updated to include newstyle classes. I will likely work on this on the flight home. (patch #709744) How is the status of this? Sounds promising, I'd say... See my reply in the Store x Load x -- DupStore thread at http://mail.python.org/pipermail/python-dev/2005-February/051725.html . Basically Thomas discovered that it was slower when used with new-style classes. But this was almost two years ago with Thomas having not done hacking on the core for two years IIRC and me having practically zero experience. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Comment regarding PEP 328
In a recent discussion in a SF patch, I noticed that PEP 328* only seems to support relative imports within packages, while bare import statements use the entirety of sys.path, not solving the shadowing of standard library module names. I have certainly forgotten bits of discussion from last spring, but I would offer that Python could offer standard library shadowing protection through the use of an extended PEP 328 semantic. More specifically; after a 'from __future__ import absolute_import' statement, any import in the module performing import foo will only check for foo in the standard library, and the use of the leading period, from . import foo, the will signify relative to the current path. ** The lack of a 'from __future__ import absolute_import' statement in a module will not change the import semantic of that module. This allows current code to continue to work, and for those who want to choose names which shadow the standard library modules, a way of dealing with their choices. Further, in the case of PEP 328, the package relative imports were to become the default in 2.6 (with deprecation in 2.5, availability in 2.4), but with the lack of an implementation, perhaps those numbers should be incremented. If the behavior I describe is desireable, it would subsume PEP 328, and perhaps should also become the default behavior at some point in time (perhaps in the same adjusted timeline as PEP 328). Alternatively, PEP 328 could be implemented as-is, and a second future import could be defined which offers this functionality, being permanently optional (or on a different timeline) via the future import. Essentially, it would ignore the empty path in sys.path when the functionality has been enabled via the proper future import in the current module. - Josiah * PEP 328 first describes the use of parenthesis in import statements so that long import listings do not require backslash-escaping of newlines. It then describes a semantic for not checking sys.path when performing an import, as well as allowing parent, cousin, uncle, etc., imports via additional leading periods. from . import foo for sibling imports, from .. import foo for parent imports, etc. ** I describe the semantic as being a per-module option, as this is the only backwards-compatible mechanism in the near future (Python 2.5). An import implementation would merely check the existance of the proper name binding - object pair in the importer's global namespace. The standard library would need to be modified if or when current behavior is deprecated (this would extend the modules needing to be modified due to PEP 328). ___ Python-Dev mailing list Python-Dev@python.org 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: Some old patches
Reinhold Birkenfeld wrote: No one listening? I'm sorry when patch reviews are not welcome in python-devel; in this case I'll post individual comments to the patches on SF. I have seen them, and I appreciate them, but I had no time to respond, yet (likewise for the 20+ other reviews which I still need to look at). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] __str__ vs. __unicode__
Walter Dörwald wrote: M.-A. Lemburg wrote: Walter Dörwald wrote: M.-A. Lemburg wrote: [...] __str__ and __unicode__ as well as the other hooks were specifically added for the type constructors to use. However, these were added at a time where sub-classing of types was not possible, so it's time now to reconsider whether this functionality should be extended to sub-classes as well. So can we reach consensus on this, or do we need a BDFL pronouncement? I don't have a clear picture of what the consensus currently looks like :-) If we're going for for a solution that implements the hook awareness for all __typename__ hooks, I'd be +1 on that. If we only touch the __unicode__ case, we'd only be created yet another special case. I'd vote -0 on that. [...] Here's the patch that implements this for int/long/float/unicode: http://www.python.org/sf/1109424 Any movement on this? +1 for making things work like str; if a subclass overrides __str__ it should use that method. If correctness of what is returned is a worry then a check could be tossed in before the value is returned. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
