Ben,
Thanks for your reply. I'll try to ellaborate a little more in the comments
below.
On Tue, Feb 18, 2014 at 2:47 PM, Ben Finney <ben+pyt...@benfinney.id.au>wrote:
> Jonno <jonnojohn...@gmail.com> writes:
>
> > I'm not sure if this list is a suitable place to ask for this kind of
> > help so if it's not please just suggest another forum which might be
> > more suitable.
>
> Welcome! Asking for help with writing Python code is definitely suitable
> here.
>
> > I'm looking for help/suggestions how to architect a module (perhaps
> > just a class).
>
> Right, I don't see anything in your request that indicates why a new
> module would be needed.
>
Only that eventually I might want to distribute this and include some other
features.
>
> > There is an existing module I want to use which has a class we'll call
> > *Existing Class*.
> >
> > I want to create a python module which allows me to create
> > *new_objects*
>
> This is all rather abstract. Can you explain what the existing class is
> for? What the new class is for?
>
> Well I was trying to keep it as generic as possible and only introduce the
necessary features. It's possible I've left out something important though.
> > with the following properties:
> >
> > - The new_objects have all the attributes of the Existing_Class
> (simply
> > create a class that inherits from Existing_Class)
>
> The syntax for that is::
>
> class Bar(Foo):
> ...
>
> where "Foo" is the existing class, "Bar" is the class you're defining.
>
> It's not strictly true to say that Bar will thereby "have all the
> attributes of" the existing class. Rather, the resolution chain will
> mean that accessing attributes on Bar will fall-back to looking at Foo
> for attributes not found in Bar.
>
> Point taken.
> > - I then want to create a nested structure under the new_objects
> > something like:
> >
> > new_object.foo
> > new_object.foo.bar
> > new_object.foo.bar.baz
>
> Again, it's not clear why you're doing this. What are these attributes for?
>
I tried to explain the necessary properties in the requirements below.
Really the main function of creating this new module is to add the
docstring & tab completion capabilities. Essentially it's a way to create
an explorable structure of elements with documentation. If you have other
suggestions how to achieve that I'd be interested.
.
>
> > Where foo, bar, baz have the following properties:
> >
> > - All have *docstrings*
>
> Docstrings are only for code objects: modules, classes, functions. Will
> each of those attributes be one of those?
>
> Only because I'd like them to have docstring attributes.
> > - All are available for *tab completion* tools upon new_object
> creation.
>
> Tab completion is up to the interactive tool you're using. Which tool is
> that?
>
>
For me ipython but I'd like it to work in other tools so the more general
the better.
> > -
> > Some of which will have *new methods* which act in the following way:
> > - new_object.foo.bar()
> >
> > calls
> > - new_object.existing_method("foo.bar", *args)
>
> This would be an unusual semantic. Why not call the existing method?
>
> Basically right now the user has to look up external documentation to
figure out which arguments (foo, bar etc) are necessary and there are many
of them in a nested structure. I'd like to create a module that they can
explore within an enhanced python editor/interpreter.
> > Any pointers would be greatly appreciated.
>
> I am smelling the likelihood that you have a strange design that needs
> to be examined and changed. Can you describe what your purpose is that
> you think needs this strange architecture?
>
>
Hopefully my comments help some.
I'm definitely not opposed to changing the architecture but the main
objectives of documentation & explorability (yes I know that's not a real
word) are top priority.
--
https://mail.python.org/mailman/listinfo/python-list
