Hey all, posted up a new patch on
http://trac.sagemath.org/sage_trac/ticket/13282; would appreciate if
someone would give it a quick review. Tom Coates will be maintaining it
after I finish so we would really like someone else to have a look!
Thanks
--
You received this message because you ar
Hi Jason,
On 2012-08-01, Jason Grout wrote:
> On 7/31/12 7:07 AM, Andrey Novoseltsev wrote:
>> I guess you can also have imports inside the functions - if they are
>> not called too often it should not be a big performance penalty.
>
> IIRC, the imports are cached automatically in Python, so it w
On 7/31/12 7:07 AM, Andrey Novoseltsev wrote:
I guess you can also have imports inside the functions - if they are
not called too often it should not be a big performance penalty.
IIRC, the imports are cached automatically in Python, so it would be a
performance hit the first time the function
Hmmm, I think we don't really want the users to think anything
particular about the location of functions module-wise. Those who need
it to write new library code should be able to figure things out. For
"regular users" it is important to see how to access the functions. So
if polytopes_grdb_backen
Dear Samuel,
See if the following might work.
1. Add a module-level docstring in polytopes_grdb.py. The should appear
when one does "polytopes_grdb?" and it should appear in the documentation
when included properly.
2. In the docstring, make an organized "table of contents" for each of the
Well, I've gone for this attempt and have ended up with two files,
polytopes_grdb_backend.py that contains all my functions,
and polytopes_grdb.py that just imports the functions we want to appear to
the user, and then all.py imports polytopes_grdb.
The problem here is that even if I write the
On Jul 31, 5:01 am, samgonshaw wrote:
> Thanks for all the advice and ideas guys!
>
> It maybe though doesn't seem a good idea at this time to embark on having a
> second indexing module for this when this doesn't seem to have been
> implemented elsewhere at this time, though to update to this for
Thanks for all the advice and ideas guys!
It maybe though doesn't seem a good idea at this time to embark on having a
second indexing module for this when this doesn't seem to have been
implemented elsewhere at this time, though to update to this format in the
future?
Definitely right on not u
On Monday, July 30, 2012 1:31:53 PM UTC-7, Nils Bruin wrote:
> While I agree that tab completion is very useful as a low-cost
> documentation tool, I find it a little worrisome if our design
> decisions come to be dominated by having tab completion generate
> appropriate indices. In lots of cas
On Mon, Jul 30, 2012 at 10:31 AM, Nils Bruin wrote:
> While I agree that tab completion is very useful as a low-cost
> documentation tool, I find it a little worrisome if our design
> decisions come to be dominated by having tab completion generate
> appropriate indices. In lots of cases it will g
On Jul 30, 12:06 pm, Rob Beezer wrote:
> Then the thing to do would be to write
>
> my_functions =
No, I would think that the module should appear exactly in the spot
where you want the names imported. "import my_functions" would be the
appropriate thing to do, unless there is some architectural
On Monday, July 30, 2012 10:31:49 AM UTC-7, Nils Bruin wrote:
>
> In python there is the concept of a "module" as well as a class.
> Modules can do that much better.
>
The pattern Samuel suggests shows up several places in Sage, such as for
examples of graphs and posets. I'm doing something si
On Jul 30, 9:02 am, samgonshaw wrote:
> Say I wrote a suite of functions and made them available through a factory
> class such as:
>
> {{{
> class MyFunctions():
> def FunctionA(self,*args,**kwargs):
> ...
> def Functionb(self,*args,**kwargs):
> ...
> def FunctionC(sel
13 matches
Mail list logo
