Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #108585
| Path | csiph.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail |
|---|---|
| From | Gregory Ewing <greg.ewing@canterbury.ac.nz> |
| Newsgroups | comp.lang.python |
| Subject | Re: Design: Idiom for classes and methods that are customizable by the user? |
| Date | Fri, 13 May 2016 18:35:06 +1200 |
| Lines | 36 |
| Message-ID | <dplassFelugU1@mid.individual.net> (permalink) |
| References | <5734ECDF.7070006@gmx.de> <mailman.617.1463087060.32212.python-list@python.org> |
| Mime-Version | 1.0 |
| Content-Type | text/plain; charset=ISO-8859-1; format=flowed |
| Content-Transfer-Encoding | 8bit |
| X-Trace | individual.net QSIrq/LXXqrVH5k4cBBBEQ+EgDxcjCB8nPs09WVJ7qeCQO2BNH |
| Cancel-Lock | sha1:ee7mNkKZi9AvZdtP/JA61XPwX2g= |
| User-Agent | Mozilla Thunderbird 1.0.5 (Macintosh/20050711) |
| X-Accept-Language | en-us, en |
| In-Reply-To | <mailman.617.1463087060.32212.python-list@python.org> |
| Xref | csiph.com comp.lang.python:108585 |
Show key headers only | View raw
Dirk Bächle wrote: > What happens now and then is, that users are unhappy with the way this > Taskmaster proceeds. One peculiar detail is, that our "default" > Taskmaster always deletes the old target file before re-building > it...and in special situations this may be seen as unwanted. I'm not convinced that replacing the Taskmaster for the entire build is the right way to address this kind of thing. What if you want to override that behaviour for some targets but not others? A single object that controls behaviour globally makes things inflexible. (Distutils suffers from this problem with its "command classes" that can only be overridden in their entirety or not at all.) It seems to me that it would be better for the Taskmaster to delegate as much behaviour to the Nodes as it can, and provide a way of designating which Node classes to use for particular targets. I'd even suggest that *all* of the build logic should be in the Nodes, and the Taskmaster class shouldn't exist at all. The top level logic should just tell the final Nodes to bring themselves up to date, and they recursively do likewise for their dependent nodes. > I'm currently following the "Factory" pattern (more or less) as I know > it from C++ and similar languages. This statement sets off alarm bells for me. If you're using some design pattern in Python just because you learned to do it that way in C++/Java/whatever, you're probably making it more complicated than it needs to be. -- Greg
Back to comp.lang.python | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Design: Idiom for classes and methods that are customizable by the user? Dirk Bächle <tshortik@gmx.de> - 2016-05-12 22:51 +0200
Re: Design: Idiom for classes and methods that are customizable by the user? Marko Rauhamaa <marko@pacujo.net> - 2016-05-13 01:01 +0300
Re: Design: Idiom for classes and methods that are customizable by the user? Dirk Bächle <tshortik@gmx.de> - 2016-05-13 00:42 +0200
Re: Design: Idiom for classes and methods that are customizable by the user? Marko Rauhamaa <marko@pacujo.net> - 2016-05-13 08:53 +0300
Re: Design: Idiom for classes and methods that are customizable by the user? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-05-13 18:35 +1200
Re: Design: Idiom for classes and methods that are customizable by the user? Michael Selik <michael.selik@gmail.com> - 2016-05-13 20:33 +0000
Re: Design: Idiom for classes and methods that are customizable by the user? Dirk Bächle <tshortik@gmx.de> - 2016-05-17 16:51 +0200
Re: Design: Idiom for classes and methods that are customizable by the user? Michael Selik <michael.selik@gmail.com> - 2016-05-17 18:13 +0000
csiph-web