On Thu, Jul 27, 2000 at 08:37:24AM -0500, Guido van Rossum wrote: > > I take it you rather see a 'AUGOP' bytecode than a 'GETSET_<type>' bytecode, > > that does the loading, operation and storing ? Not that I disagree, not at > > all, I just want to have that clear ;) > Yes, mostly because there are so many variants based on the kind of > loading and storing: for each load-type operator you need 11 GETSET > operators, and there are many different load operators: local, global, > unspecified (== local by dict instead), by attribute, by index, or by > slice... Except if you add a new type of bytecode, the 2-argument type. Which is what my implementation currently does. It necessitates just 9 new bytecodes that way: GETSET_SUBSCR, SLICE+0 through SLICE+3, NAME, FAST, GLOBAL and ATTR. The last four need 2 arguments, one for the name-index (or local vrbl number) and one for the actual operation. > I am still neutral on the choice between a single AUGOP with an > argument that takes an argument specifying the opcode, and 11 new > operators: AUGASS_ADD, ... (Actually, the latter seem the most > logical given that we also have BINARY_ADD, ...) Agreed. However, there isn't enough place in the current bytecode ranges for 9 consecutive non-argument opcodes. I'm also not sure how scarce a commodity opcodes are. Then again, it can also be 'undone' later. > > What's so special about slice assignment ? > The only special thing about slice assignment is that there are 12 > extra opcodes to deal with slices in the non-augmented-assignment > case. I was making a case for avoiding this explosion, but somehow I > got lost in my own train of thought. :( There's no explosion in the augmented assignment case, anyhow: either it's just 4 opcodes for handling slices, or it reuses the current opcodes. > So we need a new opcode ROT4 (or ROT_FOUR to be consistent in the > spelling). Yes. How about a ROT_ANY <x> argument opcode while we're at it ? <x> would specify the number to rotate... you could even encode *how* to rotate in that argument. (using the upper byte, imposing a sensible limit of 255 for the number of rotations ;-) > > class X: > > def __get_newslice__(self, (start, end, step)): > > where the type of start, end and step is not defined. This can be done with > > slice objects and sequence-unpacking, of course, but it makes it a lot more > > usable. > Another alternative that tries to preserve compatibility is to call > __getslice__(self, start, end) when the step is None, but > __getslice__(self, start, end, step) when it isn't. Old code will > raise a reasonable exception when a step is specified, while > step-aware code can specify the step as a default argument value of > 1 or None. Yes, that's very reasonable. I would suggest making the error 'special', in this case, though. So that you don't get a TypeError about incorrect number of arguments, but rather a 'object does not support extended slices' or some such TypeError. Actually, it might be worth doing it like this: Try to call __getslice__ with unconverted start, stop and step If it fails with a TypeError, and step is not None, raise the above error Else, convert start and stop to ints like the current normal slice behaviour, and try __getslice__ the old way. Or is that too much magic ? I don't think it'll break anything written in Python code, but I'm not sure what to do with the C API... But it's easier to break the API than Python code, me thinks. Break-over-godda-run-ly y'rs, -- Thomas Wouters <thomas@xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4