Stefan Ram wrote:
The customer pays for the solution. The software
manufacturer does the refactoring for it's own sake,
because when it's a longer running project, the
refactorings will pay for themself.
The customer owns the source code (at least where I was). YMMV
--
https://ma
On Sat, Sep 30, 2017 at 12:45 AM, Stefan Ram wrote:
> Chris Angelico writes:
>>If the behaviour remains *exactly* the same, then it's a code
>>improvement (aka a refactoring), not a bug fix.
>
> Usually, one cannot observe whether behavior stays the same,
> because a program does not map to b
On Sat, Jan 23, 2016 at 12:48 AM, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> Okay. Start persuading "management" (presumably the PSU) that CPython
>> needs to be more modular, with different release cycles for different
>> components. Your first step is to figure out the boundaries between
>> t
On Sat, Jan 23, 2016 at 12:30 AM, Rustom Mody wrote:
> You just gave a graphic vivid description...
> of the same thing Marko is describing: ;-) viz.
> A full-size language parser is something that you - an experienced developer -
> make a point of avoiding.
It's worth noting that "experienced de
On Friday, January 22, 2016 at 7:13:49 PM UTC+5:30, Marko Rauhamaa wrote:
> Rustom Mody :
>
> > IOW anyone who thinks that *arbitrary* complexity can *always* be
> > tamed either has a visa to utopia or needs to re-evaluate (or get) a
> > CS degree
>
> Not all complexity can be tamed, but what yo
Chris Angelico :
> Okay. Start persuading "management" (presumably the PSU) that CPython
> needs to be more modular, with different release cycles for different
> components. Your first step is to figure out the boundaries between
> those components. Get started.
Gladly, I don't need to do anythi
Rustom Mody :
> IOW anyone who thinks that *arbitrary* complexity can *always* be
> tamed either has a visa to utopia or needs to re-evaluate (or get) a
> CS degree
Not all complexity can be tamed, but what you can't tame you shouldn't
release, either.
Marko
--
https://mail.python.org/mailman/
On Friday, January 22, 2016 at 6:05:02 PM UTC+5:30, Chris Angelico wrote:
> On Fri, Jan 22, 2016 at 11:04 PM, Rustom Mody wrote:
> > 2. My students trying to work inside the lexer made a mess because the
> > extant lexer is a mess.
> > I.e. while python(3) *claims* to accept Unicode input, the ac
On Sat, Jan 23, 2016 at 12:00 AM, Marko Rauhamaa wrote:
> However, as a matter of rule, older code bases have been bloated till
> they can barely be maintained. That's when the management starts to
> listen to new ideas. Better late than never.
Okay. Start persuading "management" (presumably the
Chris Angelico :
> Alright. Can you rewrite all of those modules in three months?
The point is not to rewrite modules except as a fallback for a
hopelessly badly written module.
> And then there's the language itself. The cpython/Python directory has
> 58 .c files, many of which are closely tied
On Fri, Jan 22, 2016 at 11:04 PM, Rustom Mody wrote:
> On Friday, January 22, 2016 at 4:49:19 PM UTC+5:30, Chris Angelico wrote:
>> On Fri, Jan 22, 2016 at 9:19 PM, Marko Rauhamaa wrote:
>> > The knowhow, vision and skill is apparently very rare. On the product
>> > management side, we have the f
On Fri, 22 Jan 2016 04:04:44 -0800, Rustom Mody wrote:
> These are just specific examples that I am familiar with Chris' general
> point still stands, viz take the large and complex program that is
> cpython and clean up these messinesses: You will still have a large and
> complex program
I'm not
On Fri, Jan 22, 2016 at 10:54 PM, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> On Fri, Jan 22, 2016 at 9:19 PM, Marko Rauhamaa wrote:
>> So what do you do with a huge program?
>
> Modularize. Treat each module as a separate product with its own release
> cycle, documentation, apis, ownership etc
Rustom Mody :
> These are just specific examples that I am familiar with Chris'
> general point still stands, viz take the large and complex program
> that is cpython and clean up these messinesses: You will still have a
> large and complex program
No, as long as the ugly parts are compartmentali
On Friday, January 22, 2016 at 4:49:19 PM UTC+5:30, Chris Angelico wrote:
> On Fri, Jan 22, 2016 at 9:19 PM, Marko Rauhamaa wrote:
> > The knowhow, vision and skill is apparently very rare. On the product
> > management side, we have the famous case of Steve Jobs, who simply told
> > the engineers
Chris Angelico :
> On Fri, Jan 22, 2016 at 9:19 PM, Marko Rauhamaa wrote:
> So what do you do with a huge program?
Modularize. Treat each module as a separate product with its own release
cycle, documentation, apis, ownership etc.
What is a reasonable size of a module? It is something you would
On Fri, 22 Jan 2016 12:19:50 +0200, Marko Rauhamaa wrote:
> We need similar code sanity management. Developers are given much too
> much power to mess up the source code. That's why "legacy" is considered
> a four-letter word among developers.
When I started in this business, in the mid-70s, ther
On Fri, Jan 22, 2016 at 9:19 PM, Marko Rauhamaa wrote:
> The knowhow, vision and skill is apparently very rare. On the product
> management side, we have the famous case of Steve Jobs, who simply told
> the engineers to go back to the drawing boards when he didn't like the
> user experience. Most
Rustom Mody :
> On Friday, January 22, 2016 at 1:59:15 PM UTC+5:30, Marko Rauhamaa wrote:
>> I've been there. I think the root problem is to have a code base
>> that's so large and complex.
>
> Bizarre comment... Are you saying large and complex code-bases should
> non-exist?
Why, yes, I am.
>>
On Friday, January 22, 2016 at 1:59:15 PM UTC+5:30, Marko Rauhamaa wrote:
> Ben Finney :
>
> > The author points out there are times when a code base is large and
> > complex enough that refactoring puts the programmer in a state of not
> > knowing whether they're making progress, because until th
Ben Finney :
> The author points out there are times when a code base is large and
> complex enough that refactoring puts the programmer in a state of not
> knowing whether they're making progress, because until the whole
> refactoring is complete the errors just cascade and it's hard to tell
> wh
Steven D'Aprano a écrit :
I have some code that currently takes four different classes, A, B, C and
D, and subclasses each of them in the same way:
class MyA(A):
def method(self, x):
result = super(MyA, self).method(x)
if result == "spam":
return "spam spam spam"
On Sat, 11 Sep 2010 08:53:38 +0200, Peter Otten wrote:
> Steven D'Aprano wrote:
>
>> I have some code that currently takes four different classes, A, B, C
>> and D, and subclasses each of them in the same way:
[...]
>> Any suggestions or guidelines?
>
> You could use a mixin:
Nice! I'll give it
Steven D'Aprano wrote:
> I have some code that currently takes four different classes, A, B, C and
> D, and subclasses each of them in the same way:
>
> class MyA(A):
> def method(self, x):
> result = super(MyA, self).method(x)
> if result == "spam":
> return "spam
In article ,
Thomas Jollans wrote:
>
>(3) Why not
>
>try:
>import x
>import y
>import z
>except ImportError as exc:
>display_error_properly(exc)
>raise exc
Why not? Because that destroys the original traceback. Inside an
except clause, you should almost always use a bare ra
On 06/27/10 23:20, quoth GrayShark:
> Thanks for the help
> That was what I was looking for. All the rest, the arguments were
> unhelpful.
>
> Question: If you can't answer the question, why are you talking?
>
> I'm American Indian. That's what I was taught. We don't talk that much.
> But you
On 6/28/10 12:54 PM, rantingrick wrote:
On Jun 27, 10:20 pm, GrayShark wrote:
Question: If you can't answer the question, why are you talking?
Q: If you can't take advice without complaining, then why are you
asking?
I'm American Indian. That's what I was taught. We don't talk that much.
Bu
On Jun 27, 10:20 pm, GrayShark wrote:
> Question: If you can't answer the question, why are you talking?
Q: If you can't take advice without complaining, then why are you
asking?
> I'm American Indian. That's what I was taught. We don't talk that much.
> But you get an answer when we do talk. Ma
Thanks for the help Thomas Jollans. Just what I needed. I was wondering
what the:
__import__(name, globals={}, locals={}, fromlist=[], level=-1)
globals was (that was from the docstring on __import__. Odd, the doc on
www.python.org has globals as a list, not a dictionary). In any case, I
On Jun 27, 6:09 pm, Thomas Jollans wrote:
> > import Tkinter as tk
> > try:
> > import Image #from PIL
> > print 'Using high quality images :)'
> > except ImportError:
> > print 'Using low quality images :('
>
> As such, that still appears rather useless - the following code doesn't
>
On 06/28/2010 12:48 AM, rantingrick wrote:
> On Jun 27, 5:18 pm, Thomas Jollans wrote:
>> On 06/28/2010 12:06 AM, GrayShark wrote:
>>> I have a large list of package files to import. I'm using a try/except
>>> test to verify the import. Looks like:
>
>
>
>> (1) Don't. If you need the module, th
On Jun 27, 5:18 pm, Thomas Jollans wrote:
> On 06/28/2010 12:06 AM, GrayShark wrote:
> > I have a large list of package files to import. I'm using a try/except
> > test to verify the import. Looks like:
> (1) Don't. If you need the module, there's no reason to check for
> exceptions. Just let t
On 06/28/2010 12:06 AM, GrayShark wrote:
> I have a large list of package files to import. I'm using a try/except
> test to verify the import. Looks like:
>
> try:
> import abc
> except ImportError:
> print( "Error importing abc" )
>
> I've got many of those segments. I want to try a
--- Virgil Dupras <[EMAIL PROTECTED]>
wrote:
> How to you handle the tests? Copy over the tests you
> had for foo() and
> apply them to bar()? I don't like copy and pasting
> code. Move the B
> related tests to baz()'s tests? Then your tests
> wouldn't fail if you
> stopped calling baz() in foo()
[EMAIL PROTECTED] wrote:
> On Apr 3, 11:41 pm, "ginstrom" <[EMAIL PROTECTED]> wrote:
>>> On Behalf Of Kevin Walzer
>>> What's the best way to do this? Can anyone point me in the
>>> right direction? How could, for instance, the top snippet be
>>> rewritten to separate the Tkinter parts from the gen
On Apr 3, 11:41 pm, "ginstrom" <[EMAIL PROTECTED]> wrote:
> > On Behalf Of Kevin Walzer
> > What's the best way to do this? Can anyone point me in the
> > right direction? How could, for instance, the top snippet be
> > rewritten to separate the Tkinter parts from the generic stuff?
>
> I like to u
> On Behalf Of Kevin Walzer
> What's the best way to do this? Can anyone point me in the
> right direction? How could, for instance, the top snippet be
> rewritten to separate the Tkinter parts from the generic stuff?
I like to use the broadcaster/broker recipe at
http://aspn.activestate.com/ASPN/
On 2006-11-15, Dennis Lee Bieber <[EMAIL PROTECTED]> wrote:
> On Wed, 15 Nov 2006 18:57:39 +1100, Steven D'Aprano
><[EMAIL PROTECTED]> declaimed the following in
> comp.lang.python:
>> And last but most certainly not least, you can separate the
>> adjustment values into (say) an INI file, read them
On Tue, 14 Nov 2006 10:41:53 -0500, John Salerno wrote:
> My code is below. For now I'm focusing on the lines where health (and
> armor) are increased in each character class. Let's say I decided to
> change the amount of increase in the future. As it is now, I'd have to
> go to each character
John Salerno wrote:
> Paddy wrote:
>
> > You could keep a handle on all object instances created then go through
> > the objects making appropriate changes, e.g:
> >
> >
> > class Character(object):
> > instances = []
> > def __init__(self, name, strength, dexterity, intelligence):
> >
John Salerno wrote:
> My code is below. For now I'm focusing on the lines where health (and
> armor) are increased in each character class. Let's say I decided to
> change the amount of increase in the future. As it is now, I'd have to
> go to each character class and change the number so that e
Paddy wrote:
> You could keep a handle on all object instances created then go through
> the objects making appropriate changes, e.g:
>
>
> class Character(object):
> instances = []
> def __init__(self, name, strength, dexterity, intelligence):
> instances.append(self)
>
John Salerno wrote:
> My code is below. For now I'm focusing on the lines where health (and
> armor) are increased in each character class. Let's say I decided to
> change the amount of increase in the future. As it is now, I'd have to
> go to each character class and change the number so that ea
Kamilche wrote:
> Is there any reason NOT to do this that I may be unaware of?
[snip]
> # --- Module 2.py
> # 'Self' module processing
> import sys
> var = 0
> self = sys.modules[__name__]
>
> def MyRoutine():
> self.var = 1
>
> MyRoutine()
> print var
Looks basically fi
George Sakkis wrote:
> I prefer the the simple global statements if they aren't
> that many, otherwise the assignment of the module to self is also fine.
I replied to this article, and then canceled the reply (but that never
works), thinking you were criticizing the general concept of "module as
a
George Sakkis wrote:
> Carl Banks wrote:
> > I don't see any major problem with it. In fact, I think it's a very
> > good idea to do this, rather than use global statements, when using
> > module as a singleton class.
> >
> > I recently made the same transition myself, though I solved it a bit
>
Carl Banks wrote:
> Kamilche wrote:
> > '''
> > I'm in the middle of a refactoring dilemma.
> > I have several singletons that I'm turning into modules, for ease of
> > access.
> > The usual method is noted as 'Module 1' below.
> > The new method is noted as 'Module 2'.
> > Is there any reason NOT
George Sakkis wrote:
> Kamilche wrote:
> > '''
> > I'm in the middle of a refactoring dilemma.
> > I have several singletons that I'm turning into modules, for ease of
> > access.
> > The usual method is noted as 'Module 1' below.
> > The new method is noted as 'Module 2'.
> > Is there any reason N
Kamilche wrote:
> '''
> I'm in the middle of a refactoring dilemma.
> I have several singletons that I'm turning into modules, for ease of
> access.
> The usual method is noted as 'Module 1' below.
> The new method is noted as 'Module 2'.
> Is there any reason NOT to do this that I may be unaware o
Kamilche wrote:
> '''
> I'm in the middle of a refactoring dilemma.
> I have several singletons that I'm turning into modules, for ease of
> access.
> The usual method is noted as 'Module 1' below.
> The new method is noted as 'Module 2'.
> Is there any reason NOT to do this that I may be unaware o
"Dave Rose" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Hello all
> I've been learning Python for the past few months, reading tutorials and
> postings here. I've bought the personal Komodo then downloaded Eclipse
> with
> Pydev. IDLE also is a staple of everyday use.
>
> ~1
[EMAIL PROTECTED] writes:
> Investigate the CVS histories of the few 1000s python projects
> available at www.sourceforge.net
I don't work with these guys :>
--
http://www.pdemb.prv.pl
--
http://mail.python.org/mailman/listinfo/python-list
Hello
--
http://mail.python.org/mailman/listinfo/python-list
"Peter Hansen" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Terry Reedy wrote:
>> Another specifically helpful reference might be Beck's (author?) book on
>> Test-Driven Development. Part 1 uses an example in Java, I believe.
>> Part 2, I know, uses an example in Python. Ther
Investigate the CVS histories of the few 1000s python projects
available at www.sourceforge.net
enjoy
--
http://mail.python.org/mailman/listinfo/python-list
Terry Reedy wrote:
Another specifically helpful reference might be Beck's (author?) book on
Test-Driven Development. Part 1 uses an example in Java, I believe. Part
2, I know, uses an example in Python. There at least used to be a copy
online.
The online copy was merely a draft, never brought
"Peter Dembinski" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Peter> I am trying to write Master Thesis on refactoring Python
> Peter> code. Where should I look for information?
As best I remember, there has been little posted here over several years
other than genera
Skip Montanaro <[EMAIL PROTECTED]> writes:
> Peter> I am trying to write Master Thesis on refactoring Python
> Peter> code. Where should I look for information?
>
> I'm not sure, but one piece of code to check out would probably
> be Bicycle Repair Man, a early-stage prototype refactorin
Skip Montanaro wrote:
Peter> I am trying to write Master Thesis on refactoring Python code.
Peter> Where should I look for information?
I'm not sure, but one piece of code to check out would probably be Bicycle
Repair Man, a early-stage prototype refactoring tool for Python. I don't
recall
Peter> I am trying to write Master Thesis on refactoring Python code.
Peter> Where should I look for information?
I'm not sure, but one piece of code to check out would probably be Bicycle
Repair Man, a early-stage prototype refactoring tool for Python. I don't
recall where it's hosted.
Peter Maas wrote:
Steven Bethard schrieb:
BJörn Lindqvist wrote:
[...]
I believe this can be nicelier written as:
if "Makefile" in basename:
+1 for "nicelier" as VOTW (Vocabulation of the week) =)
Me too, because nicelier is nicer than more nicely. :)
Is that really the niceliest way to express th
Steven Bethard schrieb:
BJörn Lindqvist wrote:
[...]
I believe this can be nicelier written as:
if "Makefile" in basename:
+1 for "nicelier" as VOTW (Vocabulation of the week) =)
Me too, because nicelier is nicer than more nicely. :)
--
--
BJörn Lindqvist wrote:
# do other non-extension-related tests here
if basename.find( "Makefile" ) != -1:
return "text/x-makefile"
I believe this can be nicelier written as:
if "Makefile" in basename:
+1 for "nicelier" as VOTW (Vocabulation of the week) =)
Steve
--
http://mail.python.o
> # do other non-extension-related tests here
> if basename.find( "Makefile" ) != -1:
> return "text/x-makefile"
I believe this can be nicelier written as:
if "Makefile" in basename:
--
mvh Björn
--
http://mail.python.org/mailman/listinfo/python-list
Stephen Thorne wrote:
As for the overall efficiency concerns, I feel that talking about any
of this is premature optimisation.
I disagree -- using REs is adding unnecessary complication and
dependency. Premature optimization is a matter of using a
conceptually more-complicated method when a sim
Despite the regexp alternatives, I refuse to post a pyparsing solution to
this! :)
-- Paul
--
http://mail.python.org/mailman/listinfo/python-list
Stephen Thorne <[EMAIL PROTECTED]> wrote:
> Why not use a regexp based approach.
Good idea... You could also use sre.Scanner which is supposed to be
fast like this...
import re, sre
scanner = sre.Scanner([
(r"\.php$", "application/x-php"),
(r"\.(cc|cpp)$", "text/x-c++-src"),
(r"\.x
On Thu, 13 Jan 2005 05:18:57 GMT, Bengt Richter <[EMAIL PROTECTED]> wrote:
> On Thu, 13 Jan 2005 12:19:06 +1000, Stephen Thorne <[EMAIL PROTECTED]> wrote:
>
> >On Thu, 13 Jan 2005 01:24:29 GMT, Bengt Richter <[EMAIL PROTECTED]> wrote:
> >> extensiondict = dict(
> >> php = 'application/
On Thu, 13 Jan 2005 12:19:06 +1000, Stephen Thorne <[EMAIL PROTECTED]> wrote:
>On Thu, 13 Jan 2005 01:24:29 GMT, Bengt Richter <[EMAIL PROTECTED]> wrote:
>> extensiondict = dict(
>> php = 'application/x-php',
>> cpp = 'text/x-c-src',
>> # etcetera
>> xsl = 'test
On Thu, 13 Jan 2005 01:24:29 GMT, Bengt Richter <[EMAIL PROTECTED]> wrote:
> extensiondict = dict(
> php = 'application/x-php',
> cpp = 'text/x-c-src',
> # etcetera
> xsl = 'test/xsl'
> )
>
> def detectMimeType(filename):
> extension = os.path.sp
On Wed, 12 Jan 2005 18:16:23 +, Frans Englich <[EMAIL PROTECTED]> wrote:
>
>As continuation to a previous thread, "PyChecker messages", I have a question
>regarding code refactoring which the following snippet leads to:
>
>> > runner.py:200: Function (detectMimeType) has too many returns (11)
Paul McGuire wrote:
"Frans Englich" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
#--
def detectMimeType( filename ):
extension = filename[-3:]
You might consider using os.path.splitext() here, instead of always
assuming
On Wednesday 12 January 2005 18:56, [EMAIL PROTECTED] wrote:
> I can not break the original code in 2.4, if I try this:
[...]
>
> So although the dictionary solution is much nicer nothing seems wrong
> with your code as it is - or am I missing something?
Nope, the current code works. I'm just lo
I can not break the original code in 2.4, if I try this:
import os, sys
class NoMimeError(Exception):
pass
def detectMimeType( filename ):
extension = filename[-3:]
basename = os.path.basename(filename)
if extension == "php":
return "application/x-php"
elif extension == "cpp" or extension.endswit
"Frans Englich" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> As continuation to a previous thread, "PyChecker messages", I have a
question
> regarding code refactoring which the following snippet leads to:
>
> > > runner.py:200: Function (detectMimeType) has too many returns (11)
Kent Johnson <[EMAIL PROTECTED]> wrote in
news:[EMAIL PROTECTED]:
> Here is a simple function that scans through an input file and
> groups the lines of the file into sections. Sections start with
> 'Name:' and end with a blank line. The function yields sections
> as they are found.
>
> def make
Kent Johnson wrote:
Here is a simple function that scans through an input file and groups
the lines of the file into sections. Sections start with 'Name:' and end
with a blank line. The function yields sections as they are found.
def makeSections(f):
currSection = []
for line in f:
77 matches
Mail list logo
