On Thu, Dec 22, 2011 at 1:12 AM, Joachim Durchholz <[email protected]> wrote: > Am 22.12.2011 03:08, schrieb Alexey U. Gudchenko: > >> 15.12.2011 13:07, Joachim Durchholz пишет: >>> >>> int_tested was supposed to do >>>>>> >>>>>> if x!=int(x) raise error, else x = int(x) >>> >>> which happens in a couple of handful cases in the SymPy code. >>> (In fact the whole int_tested idea sprouted from issue #1740, where this >>> idiom was not applied but should have been.) >>> >>> Chris proposed using a decorator, Aaron proposed to extend it to float, >>> my proposal here is to use a decorator that can handle arbitrary types >>> and even arbitrary "normalization functions". >>> I also reworked the interface so that the decorator can use an arbitrary >>> mixture of normalizers; e.g. >>> >> >> As I found, the original discussion is here. >> >> https://github.com/sympy/sympy/pull/713 > > > Yes. > > >> Note that there is a REP 3107 for the type checking (It is stalled >> though): >> >> http://markmail.org/message/onxlt4t5mjqkls6k?q=thread:pruvsejfjvarfodk > > > That's for Python 3, so it's not going to help us as long as we're based on > 2.x.
Annotations can be used in Python 2. You just have to set them manually with __annotations__ instead of using the special syntax. > > >> In particular there exist an old third side module (2006 last updated, >> overgrown with the other functionality a little, though): >> >> http://oakwinter.com/code/typecheck/tutorial/basics.html > > > I'd prefer to remain focused on the task given: Unify and simplify the error > handling around cases like > > def f(a) > a = int(a) > > A fully general type checking framework, interesting as it would be, would > be too far outside the scope of my Python competence to promise any useful > results. > Besides, the typecheck module is dead. Even the users mailing list had its > last activity in 2009: three mails, all of them questions and none answers. A third party type checking module already exists; it's called traits. But this is way beyond the scope of what you are trying to do here. Aaron Meurer > > >> At least the name-token 'accept' is more understandable for me if we >> only check the types and raise an error (and do not transform/align the >> types of th arguments) > > > The code does transform/align the argument type. > > It's right in the docstring: > > If each result compares equal with the original argument, the result > is passed to the wrapped function; > > The checking aspect is more an afterthought, as the docstring continues: > > if any result does not compare > equal, the wrapped function is not called and a ValueError is raised > instead. > > It's obvious that this wasn't visible enough on first glance if you missed > that; do you have an idea how to change the docstring to avoid the next > person reading the function falling to that trap? > > Regards, > Jo > > > -- > You received this message because you are subscribed to the Google Groups > "sympy" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/sympy?hl=en. > -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
