#18107: The codes collection should be a real module
-------------------------------------+-------------------------------------
Reporter: jsrn | Owner:
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-6.6
Component: coding theory | Resolution:
Keywords: sd66 | Merged in:
Authors: Johan S. R. | Reviewers: Nathann Cohen
Nielsen | Work issues:
Report Upstream: N/A | Commit:
Branch: | ad8a74f57121d8df1d40765330129a520f4f975f
u/jsrn/18107_coding_module | Stopgaps:
Dependencies: |
-------------------------------------+-------------------------------------
Comment (by jsrn):
Replying to [comment:21 ncohen]:
> Is there a reason why you didn't just replace 'iteritems' with 'items' ?
>
> Nathann
I didn't think of it.
> Having said that, I don't like the clobbering of non-sage namespace.
Whats wrong with from
> sage.coding.all import *?
We're doing a selection in `codes` (as is done in the other module-like
objects) such that it is the "user-level" classes which will be in
`codes`, while much-less-frequently-accessed classes should be accessible
in `sage.coding.all`. If you import `sage.coding.all` you'll get a lot of
stuff you probably weren't interested in. Furthermore, it's not very
logical from a user-point of view. "Hmm, there's a nice module `codes`
that I'm using all the time. I think I'll import it so that I don't have
to type `codes.` everywhere. What? I have to import a completely different
path to do this? Why?"
--
Ticket URL: <http://trac.sagemath.org/ticket/18107#comment:23>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
