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 <[email protected]> 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 <[email protected]>:
>
>> 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 [email protected] <mailto:
>>> [email protected]>.
>>> To post to this group, send email to [email protected]
>>> <mailto:[email protected]>.
>>> 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 : *[email protected]*
>> 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
> [email protected].
> To post to this group, send email to [email protected].
> 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 [email protected].
To post to this group, send email to [email protected].
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.

Reply via email to