Re: App structure : "One file - One object" - Is there a better way ?

[C. Kirby]

While you are thinking about this I would urge you to also consider your 
future developing in python. If you are using the structure you describe in 
personal/pet projects then that may be alright. If you want to work 
somewhere that develops in python than the direction you are going is a non 
starter. At best you would have to unlearn this style of structure on the 
job. At worst (and probably more likely)  you will be unable to land a 
python job after showing example code with such an outside the mainstream 
code structure.

If you need a resource to understand a pythonic way of structuring a code 
base I would suggest looking at the django code itself.  

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/9d32a52e-cfc1-4b15-b066-1e92c21dfeb1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: App structure : "One file - One object" - Is there a better way ?

[Bill Torcaso]

I ask this out of genuine curiosity -- how do you edit source code?  I'm 
wondering because that seems inseparable from how you structure your python 
code into files.

I say this without any judgement.  If your brain likes one method per file, 
then you are asking your fingers and eyes to do more work than if you allow 
a complete class definition in one file.

Eclipse and PyCharm both allow you to collapse a method body, so that you 
see only its declaration line.  You can also collapse an entire class 
definition to its declaration, so that you can have multiple class 
declarations in one file and only see one at a time.  I wonder what you 
gain by your approach.

Looking forward to your reply,

  ---  Bill

(I myself mostly use "vi", with bash convenience functions for hopping 
around in the source tree.  I like PyCharm a lot, but it does not cover the 
remote execution scenarios that I need.)

>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/ab6317bd-ec55-494f-9321-f209c03b8661%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: App structure : "One file - One object" - Is there a better way ?

['Anthony Flury' via Django users]

On 14/07/18 15:59, Mickael Barbo wrote:

Hi Anthony 


Michael



Thanks for sharing your experience.

"1 file one object doesn't mean what you think it means."

I hope you get the meaning I described 


I understand what you mean - I just don't agree with your analysis of 
one file one object means in practice.


"it normally means (for instance) defining one class (and ALL of it's 
methods' in one file) - not importing methods into class definitions - 
I have never seen anyone suggest that."


A method is a function ? a function an object ? right ?
Strictly speaking a function is an object - but that is a python 
implementation detail. Remember that one object one file originated well 
before python was created. It came from the original OOP days with 
languages such as C++ - where methods are not objects in the OOP sense - 
the normal accepted meaning of 'One file - One Object' is (in terms of 
Python)  'One file - one class'.




My purpose is that *I prefer working on several "small" files 
containing 1 small function/object* and _*NOT*_ *dealing with a "big" 
file* containing all methods of class (for example). It's 
straightforward to find what I look for.


Mixins and inheritance don't really help here - unless you are reusing 
the same method in multiple classes - in which case you might have a 
mixin, or an inheritance situation.

Agree 

If you have one or more methods that provide a useful extra behavior 
to one or many classes (say that you have a set of methods that 
provide extra formatting on some fields, then that would be a mixin

Ok

If you can identify one of your classes being an extension to another 
in some way - so for instance you have a model for Customers, and you 
have a model for your Gold Customers then you might well have an 
inheritance situation - anywhere you can say Model A is a type of 
Model B that is inheritance: Gold Customers are a type of Customer.

Ok

So, for you, *if you would reduce the size of files you are working 
on, how would you do that ?*
If you implement your classes and all of it's methods you can't reduce 
the file size - you can though work to reduce the amount of code on 
screen. Typically you will work on one method at a time, and most good 
code editors have what they call code-folding; code folding allows you 
to collapse individual methods to a few lines (the function signature 
and the doc string), and many good editors will also allow you to fold 
loops, if/else blocks, try/except blocks, and with blocks such that the 
amount of code on screen are reduced. Most good editors will also 
provide a 'contents' type view of your code - so that you can see a list 
of the functions/methods in your file, and jump to them - without 
needing to scroll through your code.


I do understand it doesn't solve your immediate problem as you see it, 
but I think with good quality tools your 'problem' wont actually be a 
problem.


Personally I use PyCharm, which is a very good quality code editor, and 
also entirely free.




For example, let's say you have a Customer class with 15 methods and 
the file is about 1000 lines of code.

How to split this file in smaller files with 1 method per file ?


I wouldn't split it - at all - if you split the methods into files as 
you suggest- you are loosing at least some of the advantages of OOP - it 
is a considerable benefit to have all your code in one place - to be 
able check-in and revert your changes to a single class.


If you do really wish to go down the one function/method one file route, 
then the scheme that you already use is probably the best one(in terms 
of ensuring your code works as you expect); If you do use that strategy 
I would stron





Thanks for your help Anthony, hoping to be as clear as possible.
Regards


2018-07-14 10:56 GMT+02:00 Anthony Flury >:


On 13/07/18 12:44, Mickael Barbo wrote:

Hi !
*
I like working with " 1 file - 1 object " (Object could be
class, function...).*
It simplify visibility, debug etc... and it's easy for me to
*don't pollute my brain* :-)


1 file one object doesn't mean what you think it means.

it normally means (for instance) defining one class (and ALL of
it's methods' in one file) - not importing methods into class
definitions - I have never seen anyone suggest that.

Mixins and inheritance don't really help here - unless you are
reusing the same method in multiple classes - in which case you
might have a mixin, or an inheritance situation.

If you have one or more methods that provide a useful extra
behavior to one or many classes (say that you have a set of
methods that provide extra formatting on some fields, then that
would be a mixin

If you can identify one of your classes being an extension to
another in some way - so for instance you have a model for
Customers, and you have a model for your Gold Customers 

Re: App structure : "One file - One object" - Is there a better way ?

['Anthony Flury' via Django users]

On 14/07/18 15:59, Mickael Barbo wrote:

Hi Anthony 


Michael



Thanks for sharing your experience.

"1 file one object doesn't mean what you think it means."

I hope you get the meaning I described 


I understand what you mean - I just don't agree with your analysis of 
one file one object means in practice.


"it normally means (for instance) defining one class (and ALL of it's 
methods' in one file) - not importing methods into class definitions - 
I have never seen anyone suggest that."


A method is a function ? a function an object ? right ?
Strictly speaking a function is an object - but that is a python 
implementation detail. Remember that one object one file originated well 
before python was created. It came from the original OOP days with 
languages such as C++ - where methods are not objects in the OOP sense - 
the normal accepted meaning of 'One file - One Object' is (in terms of 
Python)  'One file - one class'.




My purpose is that *I prefer working on several "small" files 
containing 1 small function/object* and _*NOT*_ *dealing with a "big" 
file* containing all methods of class (for example). It's 
straightforward to find what I look for.


Mixins and inheritance don't really help here - unless you are reusing 
the same method in multiple classes - in which case you might have a 
mixin, or an inheritance situation.

Agree 

If you have one or more methods that provide a useful extra behavior 
to one or many classes (say that you have a set of methods that 
provide extra formatting on some fields, then that would be a mixin

Ok

If you can identify one of your classes being an extension to another 
in some way - so for instance you have a model for Customers, and you 
have a model for your Gold Customers then you might well have an 
inheritance situation - anywhere you can say Model A is a type of 
Model B that is inheritance: Gold Customers are a type of Customer.

Ok

So, for you, *if you would reduce the size of files you are working 
on, how would you do that ?*
If you implement your classes and all of it's methods you can't reduce 
the file size - you can though work to reduce the amount of code on 
screen. Typically you will work on one method at a time, and most good 
code editors have what they call code-folding; code folding allows you 
to collapse individual methods to a few lines (the function signature 
and the doc string), and many good editors will also allow you to fold 
loops, if/else blocks, try/except blocks, and with blocks such that the 
amount of code on screen are reduced. Most good editors will also 
provide a 'contents' type view of your code - so that you can see a list 
of the functions/methods in your file, and jump to them - without 
needing to scroll through your code.


I do understand it doesn't solve your immediate problem as you see it, 
but I think with good quality tools your 'problem' wont actually be a 
problem.


Personally I use PyCharm, which is a very good quality code editor, and 
also entirely free.




For example, let's say you have a Customer class with 15 methods and 
the file is about 1000 lines of code.

How to split this file in smaller files with 1 method per file ?


I wouldn't split it - at all - if you split the methods into files as 
you suggest- you are loosing at least some of the advantages of OOP - it 
is a considerable benefit to have all your code in one place - to be 
able check-in and revert your changes to a single class.


If you do really wish to go down the one function/method one file route, 
then the scheme that you already use is probably the best one(in terms 
of ensuring your code works as you expect); If you do use that strategy 
I would strongly suggest that you keep your dunder_init, and any factory 
methods with your class definition - these are the most important to be 
honest, since they establish the basis of all of your functionality.





Thanks for your help Anthony, hoping to be as clear as possible.
Regards


2018-07-14 10:56 GMT+02:00 Anthony Flury >:


On 13/07/18 12:44, Mickael Barbo wrote:

Hi !
*
I like working with " 1 file - 1 object " (Object could be
class, function...).*
It simplify visibility, debug etc... and it's easy for me to
*don't pollute my brain* :-)


1 file one object doesn't mean what you think it means.

it normally means (for instance) defining one class (and ALL of
it's methods' in one file) - not importing methods into class
definitions - I have never seen anyone suggest that.

Mixins and inheritance don't really help here - unless you are
reusing the same method in multiple classes - in which case you
might have a mixin, or an inheritance situation.

If you have one or more methods that provide a useful extra
behavior to one or many classes (say that you have a set of
methods that provide extra formatting on some fields, then that
would 

Re: App structure : "One file - One object" - Is there a better way ?

[Melvyn Sopacua]

On vrijdag 13 juli 2018 13:44:21 CEST Mickael Barbo wrote:

> *I like working with " 1 file - 1 object " (Object could be class,
> function...).*
> It simplify visibility, debug etc... and it's easy for me to *don't pollute
> my brain* :-)

It only seems that way.  Debugging is actually much harder, as you jump from 
source file to source file, for the tiniest things.

My assumption is that you come from a php background, where you have single 
inheritance with autoload functionality. In php a lot is implicit, hidden and 
fragmented.

Python is a different animal. Imports are explicit. Sharing imports is a good 
thing. Bunding tiny classes (mixins, utilities) in one file is a good thing. 
Bundling related classes in a single file is a good thing.

When you really want to stick to one file per class, then you sacrifice 
performance. Where you could avoid an import for a related Django model, you 
now have to import the module and depending if you the need to avoid a 
circular import you either cause a runtime import or add extra startup time.

It's better to not adhere to such "one size fits all" rule systems but use your 
brain to construct your modules in a sensible way.

-- 
Melvyn Sopacua

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/11617338.cXBrDTWfSs%40fritzbook.
For more options, visit https://groups.google.com/d/optout.

Re: App structure : "One file - One object" - Is there a better way ?

[Derek]

Not sure I fully understand what you mean by ("How to split this file in
smaller files with 1 method per file") , but if you really want to fragment
your code base, then you could do something like this:


file1.py

def do_stuff(**kwargs):
# process the data passed via kwargs


file2.py

def do_more_stuff(**kwargs):
# process the data passed via kwargs


file3.py

from file1 import do_stuff
from file2 import do_more_stuff

class Short(object):

def __init__(self, *args, **kwargs):
# process the data passed via args & kwargs

def method1(self)
do_stuff(a=1, b=2)

def method2(self)
do_more_stuff(c=1, d=2)


So one function per file, and then the methods of your class are really
short because they call on these external functions to do all the work.

However, I really don't think your code is more readable or maintainable if
you do this.  YMMV.

Derek





On Sat, 14 Jul 2018 at 16:59, Mickael Barbo  wrote:

> Hi Anthony 
>
> Thanks for sharing your experience.
>
> "1 file one object doesn't mean what you think it means."
>
> I hope you get the meaning I described 
>
> "it normally means (for instance) defining one class (and ALL of it's
> methods' in one file) - not importing methods into class definitions - I
> have never seen anyone suggest that."
>
> A method is a function ? a function an object ? right ?
>
> My purpose is that *I prefer working on several "small" files containing
> 1 small function/object* and *NOT* *dealing with a "big" file* containing
> all methods of class (for example). It's straightforward to find what I
> look for.
>
> Mixins and inheritance don't really help here - unless you are reusing the
> same method in multiple classes - in which case you might have a mixin, or
> an inheritance situation.
> Agree 
>
> If you have one or more methods that provide a useful extra behavior to
> one or many classes (say that you have a set of methods that provide extra
> formatting on some fields, then that would be a mixin
> Ok
>
> If you can identify one of your classes being an extension to another in
> some way - so for instance you have a model for Customers, and you have a
> model for your Gold Customers then you might well have an inheritance
> situation - anywhere you can say Model A is a type of Model B that is
> inheritance: Gold Customers are a type of Customer.
> Ok
>
> So, for you, *if you would reduce the size of files you are working on,
> how would you do that ?*
>
> For example, let's say you have a Customer class with 15 methods and the
> file is about 1000 lines of code.
> How to split this file in smaller files with 1 method per file ?
>
>
> Thanks for your help Anthony, hoping to be as clear as possible.
> Regards
>
>
> 2018-07-14 10:56 GMT+02:00 Anthony Flury :
>
>> On 13/07/18 12:44, Mickael Barbo wrote:
>>
>>> Hi !
>>> *
>>> I like working with " 1 file - 1 object " (Object could be class,
>>> function...).*
>>> It simplify visibility, debug etc... and it's easy for me to *don't
>>> pollute my brain* :-)
>>>
>>>
>> 1 file one object doesn't mean what you think it means.
>>
>> it normally means (for instance) defining one class (and ALL of it's
>> methods' in one file) - not importing methods into class definitions - I
>> have never seen anyone suggest that.
>>
>> Mixins and inheritance don't really help here - unless you are reusing
>> the same method in multiple classes - in which case you might have a mixin,
>> or an inheritance situation.
>>
>> If you have one or more methods that provide a useful extra behavior to
>> one or many classes (say that you have a set of methods that provide extra
>> formatting on some fields, then that would be a mixin
>>
>> If you can identify one of your classes being an extension to another in
>> some way - so for instance you have a model for Customers, and you have a
>> model for your Gold Customers then you might well have an inheritance
>> situation - anywhere you can say Model A is a type of Model B that is
>> inheritance: Gold Customers are a type of Customer.
>>
>>
>>> For exemple, I do :
>>>
>>>
>>> In *class_.py file* :
>>>
>>> |
>>> class():
>>> a
>>> b
>>> c
>>>
>>> from.|_method1|importmethod1
>>> from.|_method2| importmethod2
>>> |
>>>
>>>
>>>
>>> and in |*_method1.py file* :
>>> |
>>> |
>>> |
>>> |
>>> |
>>> def|method1(self):
>>> |
>>> "my code"
>>> |
>>> |
>>> |
>>> |
>>> |
>>> |
>>> |
>>> |
>>> |
>>> |
>>> *|It works great, but is there a better way to do that ? is there a
>>> solution to do that "automatically" ?|*
>>> *|
>>> |*
>>> *|
>>> |*
>>>
>>> *||*
>>> |I read lots of thinks about mixin, heritage, etc... but is there a
>>> better way to split code to get a better granularity ?|
>>> |
>>> |
>>>
>>> ||
>>> |Thanks for sharing your point ;-)|
>>> ||*||*
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Django users" group.
>>> To unsubscribe from this group and stop receiving emails from it, 

Re: App structure : "One file - One object" - Is there a better way ?

[Mickael Barbo]

Hi Anthony 

Thanks for sharing your experience.

"1 file one object doesn't mean what you think it means."

I hope you get the meaning I described 

"it normally means (for instance) defining one class (and ALL of it's
methods' in one file) - not importing methods into class definitions - I
have never seen anyone suggest that."

A method is a function ? a function an object ? right ?

My purpose is that *I prefer working on several "small" files containing 1
small function/object* and *NOT* *dealing with a "big" file* containing all
methods of class (for example). It's straightforward to find what I look
for.

Mixins and inheritance don't really help here - unless you are reusing the
same method in multiple classes - in which case you might have a mixin, or
an inheritance situation.
Agree 

If you have one or more methods that provide a useful extra behavior to one
or many classes (say that you have a set of methods that provide extra
formatting on some fields, then that would be a mixin
Ok

If you can identify one of your classes being an extension to another in
some way - so for instance you have a model for Customers, and you have a
model for your Gold Customers then you might well have an inheritance
situation - anywhere you can say Model A is a type of Model B that is
inheritance: Gold Customers are a type of Customer.
Ok

So, for you, *if you would reduce the size of files you are working on, how
would you do that ?*

For example, let's say you have a Customer class with 15 methods and the
file is about 1000 lines of code.
How to split this file in smaller files with 1 method per file ?


Thanks for your help Anthony, hoping to be as clear as possible.
Regards


2018-07-14 10:56 GMT+02:00 Anthony Flury :

> On 13/07/18 12:44, Mickael Barbo wrote:
>
>> Hi !
>> *
>> I like working with " 1 file - 1 object " (Object could be class,
>> function...).*
>> It simplify visibility, debug etc... and it's easy for me to *don't
>> pollute my brain* :-)
>>
>>
> 1 file one object doesn't mean what you think it means.
>
> it normally means (for instance) defining one class (and ALL of it's
> methods' in one file) - not importing methods into class definitions - I
> have never seen anyone suggest that.
>
> Mixins and inheritance don't really help here - unless you are reusing the
> same method in multiple classes - in which case you might have a mixin, or
> an inheritance situation.
>
> If you have one or more methods that provide a useful extra behavior to
> one or many classes (say that you have a set of methods that provide extra
> formatting on some fields, then that would be a mixin
>
> If you can identify one of your classes being an extension to another in
> some way - so for instance you have a model for Customers, and you have a
> model for your Gold Customers then you might well have an inheritance
> situation - anywhere you can say Model A is a type of Model B that is
> inheritance: Gold Customers are a type of Customer.
>
>
>> For exemple, I do :
>>
>>
>> In *class_.py file* :
>>
>> |
>> class():
>> a
>> b
>> c
>>
>> from.|_method1|importmethod1
>> from.|_method2| importmethod2
>> |
>>
>>
>>
>> and in |*_method1.py file* :
>> |
>> |
>> |
>> |
>> |
>> def|method1(self):
>> |
>> "my code"
>> |
>> |
>> |
>> |
>> |
>> |
>> |
>> |
>> |
>> |
>> *|It works great, but is there a better way to do that ? is there a
>> solution to do that "automatically" ?|*
>> *|
>> |*
>> *|
>> |*
>>
>> *||*
>> |I read lots of thinks about mixin, heritage, etc... but is there a
>> better way to split code to get a better granularity ?|
>> |
>> |
>>
>> ||
>> |Thanks for sharing your point ;-)|
>> ||*||*
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-users+unsubscr...@googlegroups.com > django-users+unsubscr...@googlegroups.com>.
>> To post to this group, send email to django-users@googlegroups.com
>> .
>> Visit this group at https://groups.google.com/group/django-users.
>> To view this discussion on the web visit https://groups.google.com/d/ms
>> gid/django-users/CAPLHwtyEAuCs1UcvLTzt1sXL7jpCQH%3DD_
>> TGBgwiqbq7svc%3DNaQ%40mail.gmail.com > sgid/django-users/CAPLHwtyEAuCs1UcvLTzt1sXL7jpCQH%3DD_
>> TGBgwiqbq7svc%3DNaQ%40mail.gmail.com?utm_medium=email_source=footer>.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> --
> --
> Anthony Flury
> email : *anthony.fl...@btinternet.com*
> Twitter : *@TonyFlury *
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group