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 <mickael.ba...@gmail.com> 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 <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+unsubscr...@googlegroups.com>.
>>> To post to this group, send email to django-users@googlegroups.com
>>> <mailto: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/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
>>> >.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>> --
>> --
>> Anthony Flury
>> email : *anthony.fl...@btinternet.com*
>> Twitter : *@TonyFlury <https://twitter.com/TonyFlury/>*
>>
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-users/DaH8OXgcc_0/unsubscribe.
> To unsubscribe from this group and all its topics, 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/CAPLHwtwCc6ssY6fS%3Dg85gDxO6rfGNa2jX_wKfeywYROOiEh%3Dcw%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-users/CAPLHwtwCc6ssY6fS%3Dg85gDxO6rfGNa2jX_wKfeywYROOiEh%3Dcw%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
--
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/CAF1Wu3PC8m-Ko-VOpk%3DctpM2Sdj4QugFD%3D57-EWtNEzZv8KcEg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
