Kent Johnson wrote:
> Carl Banks wrote:
> > Kent Johnson wrote:
> >> Carl Banks wrote:
> >>> Now, I think this is the best way to use modules, but you don't need to
> >>> use modules to do get higher-level organization; you could use packages
> >>> instead. It's a pain if you're working on two di
Carl Banks wrote:
> Kent Johnson wrote:
>> Carl Banks wrote:
>>> Now, I think this is the best way to use modules, but you don't need to
>>> use modules to do get higher-level organization; you could use packages
>>> instead. It's a pain if you're working on two different classes in the
>>> same s
Matias Jansson wrote:
> I come from a background of Java and C# where it is common practise to have
> one class per file in the file/project structure. As I have understood it,
> it is more common practice to have many classes in a Python module/file.
> What is the motivation behind it, would it b
Gabriel Genellina wrote:
> At Friday 22/12/2006 22:58, Carl Banks wrote:
>
> > > Usually no other files need to change. Ex: you have BigOldModule
> > > including ClassA, ClassB and FunctionC. Move each one onto its own
> > > module, perhaps including a subset of the original imports of
> > > BigO
At Friday 22/12/2006 22:58, Carl Banks wrote:
> Usually no other files need to change. Ex: you have BigOldModule
> including ClassA, ClassB and FunctionC. Move each one onto its own
> module, perhaps including a subset of the original imports of BigOldModule.
> Shrink BigOldModule to just:
>
> f
"Paddy" <[EMAIL PROTECTED]> writes:
> Are there tools out their to help with the refactoring task of
> splitting a module into two or more sections then showing what other
> files need to change?
Sounds like a good feature to add to Bicycle Repair Man:
http://bicyclerepair.sourceforge.net/>
Gabriel Genellina wrote:
> At Friday 22/12/2006 20:25, Paddy wrote:
>
> >Are there tools out their to help with the refactoring task of
> >splitting a module into two or more sections then showing what other
> >files need to change?
>
> Usually no other files need to change. Ex: you have BigOldMod
Paddy wrote:
> Carl Banks wrote:
> > Erik Johnson wrote:
> > > The file has now grown into a 6800 line beast (including docstring,
> > > whitespace, and CVS history). Pretty much any time we implement some new
> > > functionality, there are at least a few changes in that file. When you
> >
At Friday 22/12/2006 20:25, Paddy wrote:
Are there tools out their to help with the refactoring task of
splitting a module into two or more sections then showing what other
files need to change?
Usually no other files need to change. Ex: you have BigOldModule
including ClassA, ClassB and Func
At Friday 22/12/2006 12:56, Kent Johnson wrote:
It does make the imports look funny - I tend to give the module the same
name as the class, Java style, so I have
from foo.bar.MyClass import MyClass
but that is a minor point IMO.
You can always arrange things at the module level (inside
__init
Carl Banks wrote:
> Erik Johnson wrote:
> > The file has now grown into a 6800 line beast (including docstring,
> > whitespace, and CVS history). Pretty much any time we implement some new
> > functionality, there are at least a few changes in that file. When you have
> > multiple developers
Erik Johnson wrote:
> The file has now grown into a 6800 line beast (including docstring,
> whitespace, and CVS history). Pretty much any time we implement some new
> functionality, there are at least a few changes in that file. When you have
> multiple developers working on different project
There are arguments of preference to be made on both sides. I think the
question largely comes down to what is "workable" and "maintainable". To
answer the original question, I think it is not necessarily a bad idea to
have one class per file. But if your classes are small, or certain classes
a
Kent Johnson wrote:
> Carl Banks wrote:
> > Now, I think this is the best way to use modules, but you don't need to
> > use modules to do get higher-level organization; you could use packages
> > instead. It's a pain if you're working on two different classes in the
> > same system you have to kee
Carl Banks wrote:
> Now, I think this is the best way to use modules, but you don't need to
> use modules to do get higher-level organization; you could use packages
> instead. It's a pain if you're working on two different classes in the
> same system you have to keep switching files; but I guess
On Tue, 12 Dec 2006 09:29:17 +0100, Matias Jansson <[EMAIL PROTECTED]> wrote:
> I come from a background of Java and C# where it is common practise to have
> one class per file in the file/project structure. As I have understood it,
> it is more common practice to have many classes in a Python mo
Matias Jansson wrote:
> I come from a background of Java and C# where it is common practise to have
> one class per file in the file/project structure. As I have understood it,
> it is more common practice to have many classes in a Python module/file.
> What is the motivation behind it, would it be
Isaac Rodriguez wrote:
> > Yes, it would be a bad idea. =)
>
> Saying it is a bad idea and not explaining why will not help anyone. I
> would like you to elaborate on why it is a bad idea to have one file
> per class.
>
> Thanks,
>
> - Isaac.
Because it's just a useless limitation.
Python lets y
Isaac Rodriguez wrote:
> I will like to understand why this will not be a good idea for python,
> other than to make beautiful import statements that is.
>
> Thanks,
>
> - Isaac.
Read more Python source Isaac. especially for modules you like to use.
That way you see how others use modules and can
Carl J. Van Arsdall wrote:
> Carl Banks wrote:
> > Carl J. Van Arsdall wrote:
> >> A module per class makes a lot of sense in some cases, or rather, make
> >> your module your class (look at the singleton pattern). I actually like
> >> to structure all of my code like this, it helps me keep things
Carl Banks wrote:
> Carl J. Van Arsdall wrote:
>
>> Isaac Rodriguez wrote:
>>
Yes, it would be a bad idea. =)
>>> Saying it is a bad idea and not explaining why will not help anyone. I
>>> would like you to elaborate on why it is a bad idea to have one file
>>> per c
Matias Jansson wrote:
> I come from a background of Java and C# where it is common practise to have
> one class per file in the file/project structure. As I have understood it,
> it is more common practice to have many classes in a Python module/file.
> What is the motivation behind it, would it be
Carl J. Van Arsdall wrote:
> Isaac Rodriguez wrote:
> >> Yes, it would be a bad idea. =)
> >>
> >
> > Saying it is a bad idea and not explaining why will not help anyone. I
> > would like you to elaborate on why it is a bad idea to have one file
> > per class.
> >
> A module per class makes a lot o
On 12 dic, 16:17, "Isaac Rodriguez" <[EMAIL PROTECTED]>
wrote:
> > Yes, it would be a bad idea. =)Saying it is a bad idea and not explaining
> > why will not help anyone. I
> would like you to elaborate on why it is a bad idea to have one file
> per class.
The HyperText package (http://dustman.ne
> make the import statements look good.
You can still make your import statements look good and have one class
per file, that's one of the __init__.py wonderful features.
Also, C++ support stand alone functions and the rule is to organize
classes and their interface (functions that operate
Isaac Rodriguez wrote:
>> Yes, it would be a bad idea. =)
>>
>
> Saying it is a bad idea and not explaining why will not help anyone. I
> would like you to elaborate on why it is a bad idea to have one file
> per class.
>
A module per class makes a lot of sense in some cases, or rather, mak
> Yes, it would be a bad idea. =)
Saying it is a bad idea and not explaining why will not help anyone. I
would like you to elaborate on why it is a bad idea to have one file
per class.
Thanks,
- Isaac.
--
http://mail.python.org/mailman/listinfo/python-list
On Dec 12, 8:29 am, "Matias Jansson"
<[EMAIL PROTECTED]> wrote:
> I come from a background of Java and C# where it is common practise to have
> one class per file in the file/project structure. As I have understood it,
> it is more common practice to have many classes in a Python module/file.
> W
Matias Jansson wrote:
> I come from a background of Java and C# where it is common practise to have
> one class per file in the file/project structure.
Don't confuse packages and files. Java commonly splits a package
across many files, Python binds a module to a single file. If you see
"Java pa
Matias Jansson wrote:
> I come from a background of Java and C# where it is common practise to have
> one class per file in the file/project structure. As I have understood it,
> it is more common practice to have many classes in a Python module/file.
> What is the motivation behind it, would it b
Matias Jansson wrote:
> I come from a background of Java and C# where it is common practise to have
> one class per file in the file/project structure. As I have understood it,
> it is more common practice to have many classes in a Python module/file.
even more important is that in Python, you
> would it be a bad idea to have a guideline
> in your project that promotes a one class per file structure (assuming most
> of the programmers a background similar to mine)?
Yes, it would be a bad idea. =)
--
http://mail.python.org/mailman/listinfo/python-list
I come from a background of Java and C# where it is common practise to have
one class per file in the file/project structure. As I have understood it,
it is more common practice to have many classes in a Python module/file.
What is the motivation behind it, would it be a bad idea to have a guide
33 matches
Mail list logo
