On Sat, Mar 08, 2014 at 04:13:59AM -0800, Volker Braun wrote:
> I don't understand how you your comment relates to the question. Of course
> I agree that the intended result (coercion in your example, or
> systematically provide methods for parents/elements on this ticket) should
> work effortlessly. The question is, how should the library implementation
> look like? We could just run the preparser over all Sage library files,
> but good reasons we do not do that. This makes the library code sometimes
> more cumbersome to write, for example 3/5 is 0 if you write it in the Sage
> library and not if you write it on the command line. IMHO the Sage library
> ought to be good (and readable) Python code first and foremost. We do (and
> should) provide domain-specific extensions for interactive use, but not
> for writing the Sage library itself.
I certainly agree, and I bet Florent as well, that we don't want
preparsing in the Sage library. It's more about what the right balance
is between the usual principles (explicit vs implicit, DRY, single
point of truth) to achieve the most readable code.
Cheers,
Nicolas
--
Nicolas M. Thiéry "Isil" <nthi...@users.sf.net>
http://Nicolas.Thiery.name/
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
