Robert Kern wrote: > On 2009-03-16 15:23, Stefan Behnel wrote: >> Dag Sverre Seljebotn wrote: >>> Stefan Behnel wrote: >>>> Plus, it does not solve the problem at hand, which is a problem with the >>>> semantics of an operator and not with the semantics of a type. >>> Well, strictly speaking, Python % etc. means "invoke __mod__"; and >>> different classes can do different things (indeed NumPy uses C >>> semantics; for speed I presume). So it's not true that types and >>> operators are orthogonal in language design. >> I didn't say that they are "orthogonal in language design". I just said >> that this specific problem "at hand" is a problem with operator semantics, >> not with type semantics. Here's one place where I tried to make that clear: >> >> http://permalink.gmane.org/gmane.comp.python.cython.devel/4907 > > I think Dag's point is that "operator semantics" is not something that you > can > distinguish from "type semantics". You *are* claiming that the two are > orthogonal if you think that the issue at hand can be just one and not the > other.
I agree that part of the problem is that the type semantics are not clear, so this is not orthogonal, even not in this case. What I was trying to bring across was that solving this by extending the type system is (IMHO) the wrong place to start with. This is a small problem that involves the semantics of one, maybe two, operators that interact with integer types. Adding a new integer type will require its definition for all operators and all kinds of interactions with other types, which will let the type system explode just to solve two tiny ambiguities. We will end up explaining to users that they should normally use type X, except in case Y and Z, where they must be aware that P applies (although most people will not care about P, but will have to learn about type X anyway to be able to understand other people's programs). This is a horrible violation of the OWTDI principle. The simple and easy to explain solution is to give the operators the however-determined well-defined Cython default semantics, and to provide a replacement for power users who require a specific feature for performance reasons. Because performance is really the whole issue here. Users can implement any kind of semantics at the one place in their code where they actually really need it, but using an operator leads to the shortest and presumably fastest code. Stefan _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
