I'm using Python for what is becoming a sizeable project and I'm
already running into problems organizing code and importing packages.
I feel like the Python package system, in particular the isomorphism
between filesystem and namespace, doesn't seem very well suited for
big projects. However, I mi
On Mar 5, 12:45 am, "[EMAIL PROTECTED]"
<[EMAIL PROTECTED]> wrote:
> Remember that you can put code in
> the __init__.py of a package, and that this code can import sub-
> packages/modules namespaces, making the package internal organisation
> transparent to user code
Sure, but that doesn't solve
Jorge, thanks for your response. I replied earlier but I think my
response got lost. I'm trying again.
On Mar 4, 5:20 pm, Jorge Godoy <[EMAIL PROTECTED]> wrote:
> Why? RCS systems can merge changes. A RCS system is not a substitute for
> design or programmers communication.
Text merges are an e
On Mar 5, 9:15 am, "Chris Mellon" <[EMAIL PROTECTED]> wrote:
> That's actually the exact benefit of unit testing, but I don't feel
> that you've actually made a case that this workflow is error prone.
> You often have multiple developers working on the same parts of the
> same module?
Protecting y
On Mar 5, 11:06 am, "Chris Mellon" <[EMAIL PROTECTED]> wrote:
> I never advocated big files with many functional units - just files
> that are "just big enough".
Then we're in total agreement. I'm not sure why you thought my
opinions were the result of baggage from other languages when you
don't s
On Mar 5, 3:11 pm, Bruno Desthuilliers
<[EMAIL PROTECTED]> wrote:
> Your own experience *with Python* ?
No, my experience with Visual Basic. ;)
Of course my experience with Python!
Sorry, I can continue writing snarky replies to your snarky comments
but that won't get us anywhere productive. Ins
On Mar 5, 10:06 pm, [EMAIL PROTECTED] (Alex Martelli) wrote:
> My favorite way of working: add a test (or a limited set of tests) for
> the new or changed feature, run it, check that it fails, change the
> code, rerun the test, check that the test now runs, rerun all tests to
> see that nothing bro
Bruno Desthuilliers wrote:
>
> Which is not a problem. reload() is of very limited use for any
> non-trivial stuff.
>
Now that I've heard this from 5 different people it might be sinking
in. :) :) I really do appreciate all of you taking the time to explain
this to me.
When I started using Pyt
On Mar 5, 2:18 pm, Bruno Desthuilliers
<[EMAIL PROTECTED]> wrote:
> Martin Unsal a écrit :
> > For example, say
> > you want to organize the widgets package as follows:
>
> > widgets/scrollbar/*.py
> > widgets/form/*.py
> > widgets/common/util.py
>
On Mar 6, 6:07 am, "Chris Mellon" <[EMAIL PROTECTED]> wrote:
> Because you're advocating single class per file.
What I actually said was "Smallest practical functional block." I
never said one class per file, in fact I generally have more than one
class per file. Nonetheless I frequently have a cl
On Mar 6, 8:56 am, "Chris Mellon" <[EMAIL PROTECTED]> wrote:
> Scrollbar *can't* assume that util will be present in its namespace,
> because it won't be unless it imports it. Scrollbar needs to import
> its own dependencies. But why do you think thats a problem?
OK, maybe I'm totally missing some
On Mar 6, 9:19 am, "Chris Mellon" <[EMAIL PROTECTED]> wrote:
> You do? Or do you only have trouble because you don't like using "from
> foo import Foo" because you need to do more work to reload such an
> import?
More work, like rewriting __import__ and reload??? :)
There's a point where you shou
On Mar 6, 9:46 am, Dennis Lee Bieber <[EMAIL PROTECTED]> wrote:
> The only usage I've ever made of "reload()" has been during
> interactive debugging: Modify the module, then reload it at the
> interactive prompt so I could create an instance of the modified code,
> and manually manipulate
On Mar 6, 9:34 am, "Chris Mellon" <[EMAIL PROTECTED]> wrote:
> It assumes that util.common is a module thats on the PYTHONPATH.
Now we're getting somewhere. :)
> The common way to ensure that this is the case is either to handle
> util as a separate project, and install it into the system
> site-
On Mar 6, 10:13 am, "Chris Mellon" <[EMAIL PROTECTED]> wrote:
> You have to reload the importing module as well as the module that
> changed. That doesn't require rewriting the import infrastructure.
As far as I can tell, the moment you use "from foo_module import bar",
you've broken reload(). Rel
15 matches
Mail list logo
