On Thu, Jun 15, 2000 at 08:12:50PM +0200, M.-A. Lemburg wrote: > > I'd like some (minor) feedback on the augmented assignment thing I'm working > > on. I understand Guido is the only one who accepts patches like this, and > > appreciate that, but I'm hoping someone can at least tell me what I'm doing > > wrong so I can fix it before Guido sees it ;-) But if I'm being an impatient > > flap, just tell me so and I'll calm down. > I'd make this a 1.7 issue. 1.6 should go into the stabilization > phase and big complicated patches like yours should receive some > more design and concept discussion before getting checked in. That's more or less what I figured, though I wasn't aware of the revised schedule on 1.6 ;) > BTW, with "augmented assign" I suppose you mean things like > a += 1 and b *= 2, right ? Yes; All binary operands, to be exact: '+=' | '-=' | '*=' | '/=' | '%=' | '&=' | '|=' | '^=' | '<<=' | '>>=' | '**=' > Any reason you can't do this with the existing op codes ? > > E.g. a += b > > 1. load a > 2. load b > 3. add > 4. store a Yes: It wouldn't be thread-safe, and it would be impossible (or at least very hard and complicated) to see the difference between 'a += b' and 'a = a + b', which would make it very hard to make them functionally different. The patch not only adds the syntax (Michael Hudsons' patch did that, roughly how you describe it) but also adds generic semantics for in-place operations on builtin types, extension types and classes. > > * The patch also needs to add 11 new __hooks__, 11 new API calls, 11 new entries > > in the PyNumberMethods struct and 2 new entries in the PySequenceMethods > > struct. Would that conceivably be a problem ? I've heard people on the > > python-list complain about this ;-P > More generic solutions are usually more accepted. I thought so, but I didn't see a good, simple addition to the API that wasn't too complicated. What it adds now is 'PyNumber_InPlaceAdd()', which is functionally the same as 'PyNumber_Add()', except that the left-hand-side object is given the chance to define the operation in-place. That's also where the new PyNumberMethods/PySequenceMethods members come in. > BTW, before hacking too much into this, you ought to consider > that we are planning for rich comparisons and decentralized > coercion in 1.7 (this was planned for 1.6, but David and I > got carried away with other things). Too late. Most, if not all, of the patch is already written. Not that that's a reason to accept it, not at all ;) > I wouldn't want to have to hack 11 new slots to get this right... I'm not sure if that's necessary, but I'll have to look into your comparison/coercion work before I can say that for sure. In any case, I'd be perfectly happy with adjusting the augmented-assignment patch to the comparison/coercion change, instead of the other way 'round ;) > > * Should I start sending the patch, in pieces, to the patches-list, or is > > it a wasted effort because noone will touch it until Guido is back ? If I > > should send it, should I send it in one large patch (minus autogenerated > > files) or in nice functionality-sized pieces ? > Better put it on a web page and inform python-dev of new features, > enhancements, etc. The webpage is already there, with the version I sent to python-list last Friday. That patch is missing quite a few things, but it serves as an example of what it should do: http://www.xs4all.nl/~thomas/python/ I hope to upload an almost-finished version tomorrow morning (Amsterdam time) - if work doesn't intervene again. > > * How 'cool' does Guido actually think this syntax is ? Apparently the > > subject has come up a few times ;) and I got positive signals from both Tim > > and Guido, but if the patch won't go in as a patch, and won't actually be > > used other than some inspiration for a future rewrite of the CPython core, > > I'm not going to worry too much about the patch ;) > Having a patch is good for discussion, whether it gets incorporated > is a different issue ;-) Of course :) The thing is, the patch is actually quite done. What I'm doing now is more or less auditing and optimizing it, and that is probably a waste of time if the patch is going to need a complete rewrite anyway. On the other hand, I'm getting a couple of ideas for optimization of the 'normal' operations too, so it's not like it's wasted time. I guess I'll start a new thread on that issue if/when I reach it ;) Thanx for the feedback! -- 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