App structure : "One file - One object" - Is there a better way ?
35 views
Skip to first unread message
Mickael Barbo
Jul 13, 2018, 7:44:48āÆAM7/13/18
to django...@googlegroups.com
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 :-)
For exemple, I do :
In class_xxxx.py file :
and in
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 :-)
For exemple, I do :
In class_xxxx.py file :
class xxxx():
a
b
c
from .xxxx_method1 import method1
from .xxxx_method2 import method2
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 ;-)Mickael Barbo
Jul 14, 2018, 10:59:57āÆAM7/14/18
to Anthony Flury, django...@googlegroups.com
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 <anthon...@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+unsubscribe@googlegroups.com <mailto:django-users+unsubscrib...@googlegroups.com>.
To post to this group, send email to django...@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 : *Anthon...@btinternet.com*
Twitter : *@TonyFlury <https://twitter.com/TonyFlury/>*
Derek
Jul 14, 2018, 11:48:24āÆAM7/14/18
to django-users
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
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com <mailto:django-users...@googlegroups.com>.
To post to this group, send email to django...@googlegroups.com <mailto:django...@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 : *Anthon...@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...@googlegroups.com.
To post to this group, send email to django...@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.
Melvyn Sopacua
Jul 14, 2018, 2:17:32āÆPM7/14/18
to django...@googlegroups.com
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...).*
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
> *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
> my brain* :-)
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
Anthony Flury
Jul 14, 2018, 6:45:47āÆPM7/14/18
to Mickael Barbo, django...@googlegroups.com
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.
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
> 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 <anthon...@btinternet.com
> <mailto:anthon...@btinternet.com>>:
> it, send an email to django-users...@googlegroups.com
> <mailto:django-users%2Bunsu...@googlegroups.com>
> <mailto:django-users...@googlegroups.com
> <mailto:django-users%2Bunsu...@googlegroups.com>>.
> <mailto:django...@googlegroups.com>
> <mailto:django...@googlegroups.com
> <mailto:django...@googlegroups.com>>.
> <https://groups.google.com/group/django-users>.
> <mailto:Anthon...@btinternet.com>*
> Twitter : *@TonyFlury <https://twitter.com/TonyFlury/
> <https://twitter.com/TonyFlury/>>*
> 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 š
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
> "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 ?
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
>
> 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
>
> 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 ?
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 <anthon...@btinternet.com
> <mailto:django-users%2Bunsu...@googlegroups.com>
> <mailto:django-users...@googlegroups.com
> <mailto:django-users%2Bunsu...@googlegroups.com>>.
> <mailto:django...@googlegroups.com>
> <mailto:django...@googlegroups.com
> <mailto:django...@googlegroups.com>>.
> <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
> <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
> <https://groups.google.com/d/optout>.
> For more options, visit https://groups.google.com/d/optout
> <mailto:Anthon...@btinternet.com>*
> Twitter : *@TonyFlury <https://twitter.com/TonyFlury/
> <https://twitter.com/TonyFlury/>>*
Anthony Flury
Jul 14, 2018, 6:47:39āÆPM7/14/18
to Mickael Barbo, django...@googlegroups.com
On 14/07/18 15:59, Mickael Barbo wrote:
> Hi Anthony š
Michael
>
> 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 š
>
> "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.
>
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 ?
> 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
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"
> 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
>
>
> 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.
>
> 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 ?
> 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
>
>
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 <anthon...@btinternet.com
> <mailto:anthon...@btinternet.com>>:
> Regards
>
>
> 2018-07-14 10:56 GMT+02:00 Anthony Flury <anthon...@btinternet.com
> it, send an email to django-users...@googlegroups.com
> <mailto:django-users%2Bunsu...@googlegroups.com>
> <mailto:django-users...@googlegroups.com
> <mailto:django-users%2Bunsu...@googlegroups.com>>.
> <mailto:django-users%2Bunsu...@googlegroups.com>
> <mailto:django-users...@googlegroups.com
> <mailto:django...@googlegroups.com>
> <mailto:django...@googlegroups.com
> <mailto:django...@googlegroups.com>>.
> <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
> <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
> <https://groups.google.com/d/optout>.
> For more options, visit https://groups.google.com/d/optout
>
>
>
> --
> --
> Anthony Flury
> email : *Anthon...@btinternet.com
> <mailto:Anthon...@btinternet.com>*
> Twitter : *@TonyFlury <https://twitter.com/TonyFlury/
> <https://twitter.com/TonyFlury/>>*
>
>
> <mailto:Anthon...@btinternet.com>*
> Twitter : *@TonyFlury <https://twitter.com/TonyFlury/
> <https://twitter.com/TonyFlury/>>*
>
>
Bill Torcaso
Jul 15, 2018, 10:30:32āÆAM7/15/18
to Django users
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.)
C. Kirby
Jul 16, 2018, 10:11:36āÆAM7/16/18
to Django users
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.Ā
Reply all
Reply to author
Forward
0 new messages