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.
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.
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.
