Re: [Python-Dev] pypy's interpreter/highlevel backend features
Terry Reedy wrote: > "holger krekel" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > | We'd be very happy about feedback and opinions/questions > | (preferably until Monday, 19th March) > | > | > http://codespeak.net/pypy/extradoc/eu-report/D12.1_H-L-Backends_and_Feature_Prototypes-interim-2007-03-12.pdf > > As of this moment, this is not loading. -- times out Works for me now, in the last days there were routing problems with the provider, maybe that was it. Cheers, Carl Friedrich ___ 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] Question about dictobject.c:lookdict_string
Eyal Lotem wrote: > My question is specifically regarding the transition back from > lookdict_string (the initial value) to the general lookdict. > > Currently, when a string-only dict is trying to look up any > non-string, it reverts back to a general lookdict. > > Wouldn't it be better (especially in the more important case of a > string-key-only dict), to revert to the generic lookdict when a > non-string is inserted to the dict, rather than when one is being > searched? [...] > This does not seem like a significant issue, but as I know a lot of > effort went into optimizing dicts, I was wondering if I am missing > something here. Yes, you are: when doing a lookup with a non-string-key, that key could be an instance of a class that has __hash__ and __eq__ implementations that make the key compare equal to some string that is in the dictionary. So you need to change to lookdict, otherwise that lookup might fail. Cheers, Carl Friedrich Bolz ___ 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] 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
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] 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 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] Opcode frequency
Georg Brandl wrote: > Antoine Pitrou schrieb: >>> Maciej Fijalkowski did an opcode analysis for PyPy, >>> it also shows the relative frequency of opcodes following a >>> specifc one: >>> >>> http://codespeak.net/svn/user/fijal/opcodes.txt >> >> Nice, but we have to be careful here: what is the tested workload? >> For example, I find it hard to believe that CALL_FUNCTION_VAR_KW would >> always (99%) be followed by STORE_FAST. > > I'm sorry, I should have given a reference to the original message: > http://codespeak.net/pipermail/pypy-dev/2008q2/004666.html > >> I'm not even sure we're talking about the same VM/compiler. What are >> CALL_LIKELY_BUILTIN and LOOKUP_METHOD? :-) > > He used the PyPy compiler, of course. Just for the reference, PyPy uses exactly CPython's opcodes. Then there are some completely optional optimizations which add opcodes (like CALL_LIKELY_BUILTIN and LOOKUP_METHOD) that can be enabled at compile time. Cheers, Carl Friedrich Bolz ___ 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] pypy-0.9.0: stackless, new extension compiler
Hi all! Michael Hudson wrote: > The PyPy development team has been busy working and we've now packaged > our latest improvements, completed work and new experiments as > version 0.9.0, our fourth public release. Unfortunately the download links for the release tarballs did not work until very recently. They are now working though. You can download the 0.9 release of PyPy under: http://codespeak.net/download/pypy/pypy-0.9.0.tar.bz2 http://codespeak.net/download/pypy/pypy-0.9.0.tar.gz http://codespeak.net/download/pypy/pypy-0.9.0.zip For detailed notes about how to get started into the world of PyPy see here: http://codespeak.net/pypy/dist/pypy/doc/getting-started.html Sorry for the fuss and cheers, Carl Friedrich Bolz ___ 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] Simplify lnotab? (AST branch update)
Hi! Phillip J. Eby wrote: [snip] > Okay, those are fairly esoteric use cases, I admit. :) However, PyPy > already has some inlining capability in its optimizer, so it's not all that > crazy of an idea that Python in general will need it. It's kind of strange to argue with PyPy's inlining capabilities, since inlining in PyPy happens on a completely different level, that has nothing at all to do with Python code objects any more. So your proposed changes would not make a difference for PyPy (not even to speak about benefits). [snip] cheers, Carl Friedrich Bolz ___ 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] Re: A proposal to modify `None` so that it hashes to a constant
On 29/11/2022 00:51, Guido van Rossum wrote: To stir up some more fire, I would personally be fine with sets having the same ordering guarantees as dicts, *IF* it can be done without performance degradations. So far nobody has come up with a way to ensure that. "Sets weren't meant to be deterministic" sounds like a remnant of the old philosophy, where we said the same about dicts -- until they became deterministic without slowing down, and then everybody loved it. Hi all, hi Guido, Just as a data point, PyPy's sets have been using the same stable ordering like dicts since our introduction of insertion ordered dicts. We have a number of other set optimizations so it's not an apple-to-apple comparison, but still. Cheers, Carl Friedrich ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/52OGDTARUZJMV5ETMTRWHFS2GGVERNE3/ Code of Conduct: http://python.org/psf/codeofconduct/
