#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 vbraun):
Note that module imports can not be shadowed by variables:
{{{
$ sage -python
>>> sage = 1
>>> from sage.all import sin
>>> type(sin)
<class 'sage.functions.trig.Function_sin'>
}}}
So its perfectly fine to have an object bound to a variable named `codes`
but its bad to have a module `codes` (without namespace), and it would be
a terrible design pattern to litter the module names space with all kinds
of object catalogs.
Just make your own `sage.coding.codes` module from which to import your
selection of codes.
--
Ticket URL: <http://trac.sagemath.org/ticket/18107#comment:24>
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.
