Hello, 2013/6/30 Mike Beller <[email protected]>
> Amaury > > Sorry for the high latency. Day job intervenes. (This may take some time > :-) ) > No problem, we are all volunteers here. There is no pressure. The worst that can happen is someone may need the feature and implement it before you :-) > I have reviewed your advice (below) and I can certainly modify class > W_NDimArray as proposed. Here is my question. It seems from looking at > other similar modules, the convention in pypy/module is to have w_subtype > as the second positional parameter to the factory method. Changing the 4 > factory methods of W_NDimArray to follow this convention would involve > changing the following references (found using egrep/awk/uniq so I may not > be exactly right but you get the right order of magnitude): > > 2 arrayimpl/concrete.py: > 2 arrayimpl/scalar.py: > 1 arrayimpl/sort.py: > 1 base.py: > 3 compile.py: > 5 interp_arrayops.py: > 1 interp_dtype.py: > 1 interp_flatiter.py: > 19 interp_numarray.py: > 2 interp_support.py: > 3 interp_ufuncs.py: > 2 iter.py: > 3 loop.py: > 2 test/test_numarray.py: > > 47 references in 14 files. > Ouch! > I'm a bit hesitant to change code spewed all over micronumpy unless > someone with more ownership over the code tells me for sure that's the > right thing to do. So I can also propose 2 alternatives: > > 1) Create a parallel set of methods: from_shape_and_subtype, > from_shape_and_storage_and_subtype, for example, which take w_subtype, but > this would cause method proliferation. > > 2) Add a named parameter to the existing factory methods, so they are like > from_shape(shape, subtype=None....), but this would be kind of > nonstandard. On a related matter, I found other modules in the code base > where w_subtype is ignored (e.g. select/interp_epoll/W_EPoll, and others) > -- seems a common problem -- so maybe "kind of nonstandard" is not that > important -- or perhaps this is an area which was simply left to be cleaned > up later. > Both approach can work IMO: for 1), these are only two new functions, and I'm sure they can share most of the code with existing functions. method 2) would work as well, and is proably even easier to implement. And there is no standard that forbids named parameter! Some calls to from_shape() already use them... Do as you prefer, and what makes the code more natural to you. Cheers, -- Amaury Forgeot d'Arc
_______________________________________________ pypy-dev mailing list [email protected] http://mail.python.org/mailman/listinfo/pypy-dev
