On 5/10/07, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > I did not see octal literals on your list. FWIW, I'm -1 on the proposal. > The current situation is only a minor nuisance. While I prefer to see octal > literal support dropped entirely, I would rather live with the 0123 form than > add more complexity with a non-standard format and a set of warnings for > decimals with leading zeros: date(2007, 05, 09).
It was on the list, accepted: > SA 3127 Integer Literal Support and Syntax Maupin > > 3128 (BList) -- I'll leave this for Raymond Hettinger to review. > > After looking at the source, I think this has almost zero chance for > replacing list(). There is too much value in a simple C API, low space > overhead for small lists, good performance is common use cases, and having > performance that is easily understood. The BList implementation lacks these > virtues and trades-off a little performance is common cases for much better > performance in uncommon cases. As a Py3.0 PEP, I think it can be rejected. OK, will do. I'll quote you in the rejection notice. > Depending on its success as a third-party module, it still has a chance for > inclusion in the collections module. The essential criteria for that is > whether it is a superior choice for some real-world use cases. I've scanned > my own code and found no instances where BList would have been preferable to > a regular list. However, that scan has a selection bias because it doesn't > reflect what I would have written had BList been available. So, after a few > months, I intend to poll comp.lang.python for BList success stories. If they > exist, then I have no problem with inclusion in the collections module. > After all, its learning curve is near zero -- the only cost is the clutter > factor stemming from indecision about the most appropriate data structure for > a given task. > > > I'm still hoping Raymond will check his draft PEPs in by Sunday night. > > Sorry for the delay, I've been fully task saturated and the PEP writing has > been slowed by the need to explore the ideas more fully. > > The PEP for eliminating __del__ seemed straight-forward at the outset, but > the use case you presented doesn't seem to have a clean substitute (as it > requires the object to be alive to finalize it). Other use cases do have a > clean solution. So, I'll go forward with the PEP but am a bit disheartened > that it is going to have to advise try/finally or somesuch for the harder > cases. > > The information attributes idea is going well and is sticking close to the > original presentation except that I've now seen the wisdom of modifying > isinstance() to let some objects fake or proxy a type that they don't inherit > from. Cool. FWIW, the rewrite of PEP 3119 will focus mostly on overloading isinstance() and issubclass() and a few examples of what can be done with these. -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
