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 <anthony.fl...@btinternet.com
<mailto:anthony.fl...@btinternet.com>>:
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_xxxx.py file* :
|
classxxxx():
a
b
c
from.|xxxx_method1|importmethod1
from.|xxxx_method2| importmethod2
|
and in |*xxxx_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
<mailto:django-users%2bunsubscr...@googlegroups.com>
<mailto:django-users+unsubscr...@googlegroups.com
<mailto:django-users%2bunsubscr...@googlegroups.com>>.
To post to this group, send email to
django-users@googlegroups.com
<mailto:django-users@googlegroups.com>
<mailto:django-users@googlegroups.com
<mailto:django-users@googlegroups.com>>.
Visit this group at
https://groups.google.com/group/django-users
<https://groups.google.com/group/django-users>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/CAPLHwtyEAuCs1UcvLTzt1sXL7jpCQH%3DD_TGBgwiqbq7svc%3DNaQ%40mail.gmail.com
<https://groups.google.com/d/msgid/django-users/CAPLHwtyEAuCs1UcvLTzt1sXL7jpCQH%3DD_TGBgwiqbq7svc%3DNaQ%40mail.gmail.com>
<https://groups.google.com/d/msgid/django-users/CAPLHwtyEAuCs1UcvLTzt1sXL7jpCQH%3DD_TGBgwiqbq7svc%3DNaQ%40mail.gmail.com?utm_medium=email&utm_source=footer
<https://groups.google.com/d/msgid/django-users/CAPLHwtyEAuCs1UcvLTzt1sXL7jpCQH%3DD_TGBgwiqbq7svc%3DNaQ%40mail.gmail.com?utm_medium=email&utm_source=footer>>.
For more options, visit https://groups.google.com/d/optout
<https://groups.google.com/d/optout>.
--
--
Anthony Flury
email : *anthony.fl...@btinternet.com
<mailto:anthony.fl...@btinternet.com>*
Twitter : *@TonyFlury <https://twitter.com/TonyFlury/
<https://twitter.com/TonyFlury/>>*
--
--
Anthony Flury
email : *anthony.fl...@btinternet.com*
Twitter : *@TonyFlury <https://twitter.com/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 at https://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/4ad0dd28-6fcd-30e6-1a25-08791d8f7dee%40btinternet.com.
For more options, visit https://groups.google.com/d/optout.
