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 martinunsal at gmail.com wrote:
I'm perfectly well aware that
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, 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 broke,
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, rerun
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 core?
I
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 snarky replies
[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).
That's
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 result of baggage
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 thought my
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 now runs,
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 and run
Bruno Desthuilliers wrote:
imho
Which is not a problem. reload() is of very limited use for any
non-trivial stuff.
/imho
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
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, which is horrible,
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 of
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/form/*.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 class
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 generally
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 something
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 dependencies. But why
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 struggling
to
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 should blame
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 it.
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 work, like
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
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, etc.
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 either to handle
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(). Reloading
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 tell, the
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 filesystem
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 is either to
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 interpreter for
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 __import__ and reload???
[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 gets
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, like rewriting
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 reload(),
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 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
$ cat
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 namespace,
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 the
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
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 not a
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 your
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 multiple
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
Sure, but
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, 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
coordination
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 universal in
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 seem to
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.
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
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
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 prefixes, or
52 matches
Mail list logo
