My wishlist for Python3K

[Huaiyu Zhu]

On Thu, 08 Jun 2000 14:23:07 -0400, Pablo Bleyer Kocik <pbleyer at embedded.cl>
wrote: 
>
>> 1. Everything is an object of a class that can be subclassed.
>
>    ... And everything is painfully slow and error prone. Strange and unexpected
>things will begin happening as a result for hidden behavior. Developers will go
>mad checking polymorphism when implementing their functions. Moral: Use fixed
>objects for what they are meant to be and keep them that way -- that's their
>raison d'être.

Maybe it's exactly the oposite?  Even with current situation, when you say
print a, Python needs to know the type of a to form the repr.  It might be
hard-coded for builtin types (I don't know), but it's there nevertheless.

Now imagine there is a class Int.  If someone decides 1/2 should be 0.5, he
only need do

class MyInt(Int):
    def __div__(self, other):  # Whatever code necessary.

Operations involving MyInt, other then __div__, will be as fast as Int.  And
the __div__ method is the only place one need to check for error.

Contrast that with the current situation.  One has to rewrite every operation

class MyInt:
   def __init__(self, data):  self.data = data
   def __add__(self, other):  return self.data + other
   ....

in addition to the single method __div__ that one wants to change.  This
slows everything down and introduces pontential errors everywhere -
quite unnecessarily.


>> 6. Have a clean mechanism to work with other programming languages other
>> than C.  (I have matlab/octave in mind.)
>
>    The core is there. I think it's enough clean already. Perhaps there's a need
>for better interfaces/object passing/object marshalling & demarshalling between
>Python and other applications and we should rely on a standard (CORBA?). Or
>better, make Python objects the standard ;^) ("glue it all with Python").

Any examples?  I'd love to incorporate that into the MatPy package.

>> 7. NOT case insensitive.  (No followup on this please.  Enough said already.)
>
>    You are not very fond of computers, are you?

Did you misread my words or did you mistype something?  Never mind.

>    I use Python mostly for scientific work (Numpy et al.). I use Matlab, Octave
>and Scilab also. Instead of changing radically the core language I think it's
>better to concentrate efforts in improving Numpy, for example. What would be nice
>is to reinforce the language in it's "dynamic mode/dynamic interface"
>capabilities via operator overloading, etc. Then you could run something that
>"looks like Matlab" over Python, efficiently.

Don't you think MatPy qualifies as "something that looks like Matlab over
Python"?   I'm really interested in hearing any efficiency suggestions.

>>
>> PS. (Shameless advertising):  Want a Matlab clone in Python?  See
>> https://sourceforge.net/project/?group_id=6490
>
>    Then use Matlab, and not attempt to change Python from it's bases.

I don't quite understand you here.  How do you have a dictionary of lists of
matrices in Matlab?  How do you define classes in Matlab?  Or maybe when you
use Matlab you don't need Python featurs and vice versa?  I need both.


Huaiyu