I apologize for bringing up something that's a month dead. But, I've
been reading through the recent archives and came across this
discussion, and want to make sure I understand a particular about the
interactive prompt.
"Martin Unsal" wrote:
> I'm perfectly well aware that I'm not going to be a
> package_name/
> package_pre.py - contains globals for the package
> component_a.py- a useful-sized collection of functionality
> component_b.py- another
> component_c.py- another
> package_post.py - stuff that relies on the prior stuff
> __init__.py
On Mar 5, 1:21 am, "Martin Unsal" <[EMAIL PROTECTED]> wrote:
> 2) Importing and reloading. I want to be able to reload changes
> without exiting the interpreter.
What about this?
$ cat reload_obj.py
"""
Reload a function or a class from the filesystem.
For instance, suppose you have a module
$
Martin Unsal wrote:
> 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
On Mar 6, 4:58 pm, Ben Finney <[EMAIL PROTECTED]>
wrote:
> "Martin Unsal" <[EMAIL PROTECTED]> writes:
> > I think you should be asking yourselves, "Did we all abandon reload()
> > because it is actually an inferior workflow, or just because it's
> > totally broken in Python?"
>
> I never "abandoned
On Mar 6, 12:49 pm, "Martin Unsal" <[EMAIL PROTECTED]> wrote:
> 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,
[EMAIL PROTECTED] (Alex Martelli) writes:
> Not sure I get what you mean; when I write tests, just as when I write
> production code, I'm focused (not worried:-) about the application
semantics... ;-) Thanks for the correction.
> functionality I'm supposed to deliver. The language mostly "get
"Martin Unsal" <[EMAIL PROTECTED]> writes:
> 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 __impor
"Martin Unsal" <[EMAIL PROTECTED]> writes:
> I think you should be asking yourselves, "Did we all abandon reload()
> because it is actually an inferior workflow, or just because it's
> totally broken in Python?"
I never "abandoned reload()", because it never even occurred to me to
use the interpr
In article <[EMAIL PROTECTED]>,
"Martin Unsal" <[EMAIL PROTECTED]> wrote:
> 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
In article <[EMAIL PROTECTED]>,
"Martin Unsal" <[EMAIL PROTECTED]> wrote:
> 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 fil
On 6 Mar 2007 10:58:14 -0800, Martin Unsal <[EMAIL PROTECTED]> wrote:
> 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 tel
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
On 6 Mar 2007 10:30:03 -0800, Martin Unsal <[EMAIL PROTECTED]> wrote:
> 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 eithe
Martin Unsal <[EMAIL PROTECTED]> wrote:
> We could discuss this till we're blue in the face but it's beside the
> point. For any given project, architecture, and workflow, the
> developers are going to have a preference for how to organize the
> code structurally into files, directories, packages,
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 6 Mar 2007 09:49:55 -0800, Martin Unsal <[EMAIL PROTECTED]> wrote:
> 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
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: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
Diez B. Roggisch a écrit :
>>I'd like to point out something though. More than one of the people
>>who responded have implied that I am bringing my prior-language
>>mindset to Python, even suggesting that my brain isn't built for
>>Python. ;) In fact I think it's the other way around. I am struggli
On 6 Mar 2007 09:24:32 -0800, Martin Unsal <[EMAIL PROTECTED]> wrote:
> 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 dependenc
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 6 Mar 2007 09:09:13 -0800, Martin Unsal <[EMAIL PROTECTED]> wrote:
> 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
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 6 Mar 2007 08:42:00 -0800, Martin Unsal <[EMAIL PROTECTED]> wrote:
> 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/for
> I'd like to point out something though. More than one of the people
> who responded have implied that I am bringing my prior-language
> mindset to Python, even suggesting that my brain isn't built for
> Python. ;) In fact I think it's the other way around. I am struggling
> to take full advantage
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
>
> > Other than messing around with PYTHONPATH, whi
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
Jorge Godoy <[EMAIL PROTECTED]> 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 broke, add
Martin Unsal <[EMAIL PROTECTED]> wrote:
> 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 no
On 5 Mar 2007 23:35:00 -0800, Martin Unsal <[EMAIL PROTECTED]> wrote:
> 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 thoug
"Martin Unsal" <[EMAIL PROTECTED]> writes:
> 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 re
[EMAIL PROTECTED] (Alex Martelli) writes:
> Bruno Desthuilliers <[EMAIL PROTECTED]> wrote:
>
>> >>I don't reload... When my investigative tests gets bigger I write a script
>> >>and run it with the interpreter. It is easy since my text editor can call
>> >>Python on a buffer (I use Emacs).
>> >
Martin Unsal a écrit :
> 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 but this was really not obvious.
> Sorry, I can continue writing sn
In article <[EMAIL PROTECTED]>,
"Martin Unsal" <[EMAIL PROTECTED]> wrote:
> That too... although I think that's unfortunate. If reload() were
> reliable, would you use it? Do you think it's inherently unreliable,
> that is, it couldn't be fixed without fundamentally breaking the
> Python language
En Tue, 06 Mar 2007 04:57:18 -0300, Martin Unsal <[EMAIL PROTECTED]>
escribió:
> 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,
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
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, 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
Bruno Desthuilliers <[EMAIL PROTECTED]> wrote:
> >>I don't reload... When my investigative tests gets bigger I write a script
> >>and run it with the interpreter. It is easy since my text editor can call
> >>Python on a buffer (I use Emacs).
> >
> > That's interesting, is this workflow pretty
Martin Unsal a écrit :
> On Mar 5, 9:15 am, "Chris Mellon" <[EMAIL PROTECTED]> wrote:
(snip)
> There are myriad other benefits of breaking up large files into
> functional units. Integration history, refactoring, reuse, as I
> mentioned. Better clarity of design. Easier communication and
> coordina
Martin Unsal a écrit :
(snip)
> When refactoring, it's much better to move small files around than to
> move chunks of code between large files.
Indeed. But having hundreds or thousands of files each with at most a
dozen lines of effective code is certainly not an ideal. Remember that
Python let
Martin Unsal a écrit :
> 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
On 5 Mar 2007 10:31:33 -0800, Martin Unsal <[EMAIL PROTECTED]> wrote:
> 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 mul
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 5 Mar 2007 08:32:34 -0800, Martin Unsal <[EMAIL PROTECTED]> wrote:
> 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 no
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, 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
On 5 mar, 01:21, "Martin Unsal" <[EMAIL PROTECTED]> wrote:
> 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 names
"Martin Unsal" <[EMAIL PROTECTED]> writes:
> 1) Namespace. Python wants my namespace heirarchy to match my filesystem
> heirarchy. I find that a well organized filesystem heirarchy for a
> nontrivial project will be totally unwieldy as a namespace. I'm either
> forced to use long namespace prefixe
1a) Module/class collision. I like to use the primary class in a file
as the name of the file. However this can lead to namespace collisions
between the module name and the class name. Also it means that I'm
going to be stuck with the odious and wasteful syntax foo.foo
everywhere, or forced to
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
52 matches
Mail list logo
