[Python-3000] PEPs update

[Raymond Hettinger]

> and rejected some others:
> SR 3126  Remove Implicit String Concatenation         Jewett

I had high hopes for this one.  Cie le vie.

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).


> 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.

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.



Raymond