Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #70555
| References | <80a82415-fc67-4ccf-8827-27a0ba5459b7@googlegroups.com> <535833D5.7040500@stoneleaf.us> |
|---|---|
| Date | 2014-04-24 09:12 +1000 |
| Subject | Re: Moving to an OOP model from an classically imperitive one |
| From | Chris Angelico <rosuav@gmail.com> |
| Newsgroups | comp.lang.python |
| Message-ID | <mailman.9473.1398294747.18130.python-list@python.org> (permalink) |
On Thu, Apr 24, 2014 at 7:42 AM, Ethan Furman <ethan@stoneleaf.us> wrote: > On 04/23/2014 01:57 PM, tim.thelion@gmail.com wrote: >> >> >> There is one problem though. Currently, I have these functions logically >> organized into source files, each between 40 and 170 LOC. I fear that if >> I were to put all of these functions into one class, than I would have a >> single, very large source file. I don't like working with large source >> files for practicall reasons. > > > I'm curious what these practical reasons are. One my smallest source files > has 870 lines in it, my largest nearly 9000. > > If the problem is your editor, you should seriously consider switching. It's probably not the case here, but one good reason for splitting a file into pieces is to allow separate people or systems to update different parts. Lots of Linux programs support either /etc/foobar.conf or /etc/foobar.conf.d/ where the former is one file and the latter is a directory of separate files, generally deemed to be concatenated to the main config file. (Example: /etc/apt/sources.list and /etc/apt/sources.list.d/ - the main config for your Debian repositories, the directory for additional ones for VirtualBox or PostgreSQL.) It's easier to allow someone to completely overwrite a file than to try to merge changes. But that's not often the case with source code. ChrisA
Back to comp.lang.python | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Moving to an OOP model from an classically imperitive one tim.thelion@gmail.com - 2014-04-23 13:57 -0700
Re: Moving to an OOP model from an classically imperitive one Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-04-23 22:15 +0100
Re: Moving to an OOP model from an classically imperitive one Ian Kelly <ian.g.kelly@gmail.com> - 2014-04-23 15:23 -0600
Re: Moving to an OOP model from an classically imperitive one Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-04-24 12:26 +1200
Re: Moving to an OOP model from an classically imperitive one Ethan Furman <ethan@stoneleaf.us> - 2014-04-23 14:42 -0700
Re: Moving to an OOP model from an classically imperitive one tim.thelion@gmail.com - 2014-04-24 00:32 -0700
Re: Moving to an OOP model from an classically imperitive one MRAB <python@mrabarnett.plus.com> - 2014-04-24 00:08 +0100
Re: Moving to an OOP model from an classically imperitive one tim.thelion@gmail.com - 2014-04-24 00:21 -0700
Re: Moving to an OOP model from an classically imperitive one Chris Angelico <rosuav@gmail.com> - 2014-04-24 17:36 +1000
Re: Moving to an OOP model from an classically imperitive one Steven D'Aprano <steve@pearwood.info> - 2014-04-24 09:08 +0000
Re: Moving to an OOP model from an classically imperitive one Chris Angelico <rosuav@gmail.com> - 2014-04-24 09:12 +1000
Re: Moving to an OOP model from an classically imperitive one Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-04-24 12:21 +1200
Re: Moving to an OOP model from an classically imperitive one tim.thelion@gmail.com - 2014-04-24 09:53 -0700
Re: Moving to an OOP model from an classically imperitive one Amirouche Boubekki <amirouche.boubekki@gmail.com> - 2014-04-25 19:21 +0200
Re:Moving to an OOP model from an classically imperitive one Dave Angel <davea@davea.name> - 2014-04-23 22:01 -0400
csiph-web