[Python-Dev] Gathering Python 2.1 goals and non-goals

[M.-A. Lemburg]

Guido van Rossum wrote:
> 
> Other issues to work on
> -----------------------
> 
> These aren't PEPs yet, but I think they need to become PEPs soon --
> I'd like to see work on them go into Python 2.1:
> 
> - The buffer interface needs a revamping or simplification; this was
>   discussed here previously.
> 
> - A warning framework.  I've got some ideas already.

This would be a *cool* thing. I have a need for such a framework
in mx.ODBC where ODBC often issues warnings. Currently these
turn out as exceptions which is not really all that useful
because some warnings can safely be ignored.
 
> - Integer division.  If we want to play by Paul Prescod's Language
>   Evolution rules (PEP 5), we better get started on the first stage.
>   E.g. we could introduce a // operator in 2.1 for integer division,
>   and issue a warning when / is used for integers.  Then a year later
>   (i.e., March 2002!) we could change / so that it returns a floating
>   point number.

+0... and then only, if there will be a tool to check Python
source code for integer divides.
 
> - Case sensitivity???

Should be left to Py3k. It could then be implemented by using
a special dictionary subclass as instance dictionary.
 
> - Class/type dichotomy???

One thing that would probably be implementable is a way to
maintain "instance" dictionaries for types (which are created
on-demand whenever an assignment is made). This would enable
extending types with new methods and attributes. "Subclassing"
could then be emulated by using new contructors which add the
new or changed methods to each created type instance, e.g.

class myclose:

    def __init__(self, object, basemethod):
        self.object = object
        self.basemethod = basemethod

    def __call__(self):
        print 'Closed file %s' % self.object
        self.basemethod()

def myfile(filename):
    f = open(filename)
    # add/override attributes
    f.newattribute = 1
    # add/override methods
    f.close = myclose(f, f.close)
    return f

Types would have to be made aware of this possibility. Python
could provide some helping APIs to make life easier for the
programmer.

> - Weak references.  This *is* a PEP, but there's no contents yet.  We
>   could also try to implement (just) weak dictionaries.

These already exist... http://www.handshake.de/~dieter/weakdict.html

mx.Proxy also has an implementation which support weak references.

BTW, are these still needed now that we have GC ?
 
> - Internationalization.  Barry knows what he wants here; I bet Martin
>   von Loewis and Marc-Andre Lemburg have ideas too.

We'd need a few more codecs, support for the Unicode compression,
normalization and collation algorithms.

> - Arbitrart attributes on functions?  This would be a generalization
>   of docstrings; with the intent that you don't have to put semantics
>   in docstrings (like SPARK and Zope).  Issue: what syntax to choose?
>   This could possibly lead to implementing private, protected, public
>   attributes too.

Perhaps the above "trick" could help with this ?!
 
-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/