PEP: Adding new operators for elementwise/objectwise operations

[Huaiyu Zhu]

On Tue, 19 Sep 2000 14:47:23 GMT, gareth_rees at my-deja.com
<gareth_rees at my-deja.com> wrote: 
>hzhu at users.sourceforge.net wrote:
>> This is a Python Extension Proposal for introducing operators for
>> distinguishing between elementwise and objectwise operations.
>
>I think that it would be a bad idea if this proposal were adopted.

(Note that this PEP is now PEP 0225 "Elementwise/Objectwise Operators".)

Some of your concerns have already been debated many times in the past, as
cited in the references in the PEP.  I'll answer a few new ones (and ones
that might not be clear in the PEP).

The increased size appears to be a none issue. It increases the 22MB Python
source by 32KB, according to du, which has 4k granuity on my machine.  This
breaks down to the following subdirectories where changes are made:

directory    size   incr  percent
----------------------------------------
Grammar        20     0    0.00%
Parser        128     0    0.00%
Include       336     8    2.38%
Python        748     4    0.53%
Objects      1072    12    1.12%
Modules      4972     4    0.08%
----------------------------------------
Total        7276    28    0.38%


As to the increased complexity, I think we need to distinguish two types of
complexity: (a) additional structures, (b) more entries of existing
structure.   This PEP does not introduce additional structures, only
additional operators which behave the same way as existing operators.

It might be beneficial to only a "small subset" of users (I'm not going to
argue about how big or small the subset is), but 

- You're not going to see the changes if you do not need them.

- If you do read code that uses them, you'll benefit from the clarity
  compared with alternatives.  This makes it easier to learn and document.
  Here's an excerpt of the result of (in MatPy-0.3.2)
  diff -c tests/test_cross.py Misc/test_elem.py:

  ! checkequal (a.e_mul(b), b.e_mul(a))
  ! checkequal (a.e_div(b), (b.e_div(a)).re_div(1))
  
  --- 16,35 ----
  
  ! checkequal (a~*b, b~*a)
  ! checkequal (a~/b, 1~/(b~/a))


- The reduced risk from clarity in applications would more than off-set the
  risk of possible defects in one-time implementation.  According to Greg
  Lielens, the implementation is very similar to existing stuff, except the
  work around to make expessions like ~-~+~~-1 legal, as it is now.

The most interesting consideration is, in fact, modularity.  While it is
quite easy to add additional functions, packages, classes and various other
things using either python modules or extension modules in C, we can not do
so for operator symbols. They are hard-coded in core python, so are their
behavior on built-in types. This PEP is only borne of this reality.  It did
minimal change that could not be done by extension modules (adding the
symbols and defining their semantics on builtin types), while leaving the
real meat (the semantics on class objects) to applications.  If there were a
modular way to add operators to Python, or if Python had a plentiful supply
of additional operators for users to override, this PEP would not be
necessary.

Huaiyu
-- 
Huaiyu Zhu                       hzhu at users.sourceforge.net
Matrix for Python Project        http://MatPy.sourceforge.net 


>This proposal achieves only a small advantage for a small subset of
>users of Python:
>
>   + greater readability of algebraic operations on vectors and matrices
>
>while introducing disadvantages and risks for all users of Python:
>
>   - increased complexity of language implementation means greater risk
>     of defects
>
>   - increased complexity of language definition makes it harder to
>     learn and harder to document
>
>   - increased size of Python core makes it less suitable for embedding
>
>Python's simplicity and robustness are among the features that make it
>attractive to many of its users.  I think that extensions that make
>Python more complex and less robust should be considered very seriously
>before being adopted.
>
>Python's module system allows extensions like this to be developed
>without affecting people who don't use the extensions.
>
>--
>Gareth Rees
>
>
>Sent via Deja.com http://www.deja.com/
>Before you buy.