Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Re: Dreaming of new generation IDE

Reply
Thread Tools

Re: Dreaming of new generation IDE

 
 
Steve Holden
Guest
Posts: n/a
 
      02-05-2010
Arnaud Delobelle wrote:
> Robert Kern <(E-Mail Removed)> writes:
>
>> I prefer Guido's formulation (which, naturally, I can't find a direct
>> quote for right now): if you expect that a boolean argument is only
>> going to take *literal* True or False, then it should be split into
>> two functions.

>
> So rather than three boolean arguments, would you have eight functions?
>

If there's genuinely a need for that functionality, yes.

I statement that calls one of two functions depending on the value of a
Boolean is normally considered to be better coupling than calling a
single function with the Boolean as an argument.

As with everything else you have to apply a certain amount of common sense.

regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
PyCon is coming! Atlanta, Feb 2010 http://us.pycon.org/
Holden Web LLC http://www.holdenweb.com/
UPCOMING EVENTS: http://holdenweb.eventbrite.com/

 
Reply With Quote
 
 
 
 
bartc
Guest
Posts: n/a
 
      02-05-2010

"Steve Holden" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Arnaud Delobelle wrote:
>> Robert Kern <(E-Mail Removed)> writes:
>>
>>> I prefer Guido's formulation (which, naturally, I can't find a direct
>>> quote for right now): if you expect that a boolean argument is only
>>> going to take *literal* True or False, then it should be split into
>>> two functions.

>>
>> So rather than three boolean arguments, would you have eight functions?
>>

> If there's genuinely a need for that functionality, yes.


So you want a function such as drawtext(s, bold=true, italic=false,
underline=true) to be split into:

drawtext(s)
drawtextb(s)
drawtexti(s)
drawtextu(s)
drawtextbi(s)
drawtextbu(s)
drawtextiu(s)
drawtextbiu(s)

Which of course is going to be fun if the bold/italic/underline values are
not constants; instead of writing:

drawtext(s,b,i,u)

you have to say:

if b==0 and i==0 and u==0:
drawtext(s)
elif b==1 and i==0 and u==0:
drawtextb(s)

and so on. With half-a-dozen or more booleans, this becomes completely
impractical.

--
Bartc

 
Reply With Quote
 
 
 
 
Robert Kern
Guest
Posts: n/a
 
      02-05-2010
On 2010-02-05 16:22 PM, bartc wrote:
>
> "Steve Holden" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> Arnaud Delobelle wrote:
>>> Robert Kern <(E-Mail Removed)> writes:
>>>
>>>> I prefer Guido's formulation (which, naturally, I can't find a direct
>>>> quote for right now): if you expect that a boolean argument is only
>>>> going to take *literal* True or False, then it should be split into
>>>> two functions.
>>>
>>> So rather than three boolean arguments, would you have eight functions?
>>>

>> If there's genuinely a need for that functionality, yes.

>
> So you want a function such as drawtext(s, bold=true, italic=false,
> underline=true) to be split into:
>
> drawtext(s)
> drawtextb(s)
> drawtexti(s)
> drawtextu(s)
> drawtextbi(s)
> drawtextbu(s)
> drawtextiu(s)
> drawtextbiu(s)
>
> Which of course is going to be fun if the bold/italic/underline values
> are not constants; instead of writing:
>
> drawtext(s,b,i,u)
>
> you have to say:
>
> if b==0 and i==0 and u==0:
> drawtext(s)
> elif b==1 and i==0 and u==0:
> drawtextb(s)
>
> and so on. With half-a-dozen or more booleans, this becomes completely
> impractical.


Then you refactor to

drawtext(s, font)

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco

 
Reply With Quote
 
Steve Holden
Guest
Posts: n/a
 
      02-05-2010
bartc wrote:
>
> "Steve Holden" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> Arnaud Delobelle wrote:
>>> Robert Kern <(E-Mail Removed)> writes:
>>>
>>>> I prefer Guido's formulation (which, naturally, I can't find a direct
>>>> quote for right now): if you expect that a boolean argument is only
>>>> going to take *literal* True or False, then it should be split into
>>>> two functions.
>>>
>>> So rather than three boolean arguments, would you have eight functions?
>>>

>> If there's genuinely a need for that functionality, yes.

>
> So you want a function such as drawtext(s, bold=true, italic=false,
> underline=true) to be split into:
>
> drawtext(s)
> drawtextb(s)
> drawtexti(s)
> drawtextu(s)
> drawtextbi(s)
> drawtextbu(s)
> drawtextiu(s)
> drawtextbiu(s)
>

The case I was discussing was where the function was required to
implement significantly different logic flow for the two different
values of the Boolean.

> Which of course is going to be fun if the bold/italic/underline values
> are not constants; instead of writing:
>
> drawtext(s,b,i,u)
>
> you have to say:
>
> if b==0 and i==0 and u==0:
> drawtext(s)
> elif b==1 and i==0 and u==0:
> drawtextb(s)
>
> and so on. With half-a-dozen or more booleans, this becomes completely
> impractical.
>

It's completely impractical the way you've written it anyway, since the
drawtext function shouldn't be required to know whether it's printing
bold, italic, etc. - those properties should be attributes of the font.

regards
Steve


--
Steve Holden +1 571 484 6266 +1 800 494 3119
PyCon is coming! Atlanta, Feb 2010 http://us.pycon.org/
Holden Web LLC http://www.holdenweb.com/
UPCOMING EVENTS: http://holdenweb.eventbrite.com/

 
Reply With Quote
 
Steven D'Aprano
Guest
Posts: n/a
 
      02-05-2010
On Fri, 05 Feb 2010 22:22:39 +0000, bartc wrote:

> "Steve Holden" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> Arnaud Delobelle wrote:
>>> Robert Kern <(E-Mail Removed)> writes:
>>>
>>>> I prefer Guido's formulation (which, naturally, I can't find a direct
>>>> quote for right now): if you expect that a boolean argument is only
>>>> going to take *literal* True or False, then it should be split into
>>>> two functions.
>>>
>>> So rather than three boolean arguments, would you have eight
>>> functions?
>>>

>> If there's genuinely a need for that functionality, yes.

>
> So you want a function such as drawtext(s, bold=true, italic=false,
> underline=true) to be split into:
>
> drawtext(s)
> drawtextb(s)
> drawtexti(s)
> drawtextu(s)
> drawtextbi(s)
> drawtextbu(s)
> drawtextiu(s)
> drawtextbiu(s)



No, of course not. But one might prefer a function with an alternate API,
such as:

style = TextStyle(bold=True, underline=True, size=12, font='helvetica')
drawtext(s, style)
style.italic = True
drawtext(s, style)

Other alternatives might be to pass the style information as a string
"BU" (bold underline) or a numeric flag (BOLD & UNDERLINE).

In general, if your implementation looks like this:


def function(args, flag):
if flag:
do_this()
else:
do_that()


then this is a good candidate for splitting into multiple functions.

Likewise:

def function(args, flag):
result = do_this()
if flag:
result = modify(result)
return result

or similar.

The point is that such a function uses the flag to select between two
different semantics. From a API perspective, it is generally better to
make each behaviour an independent function (perhaps calling a third,
private, function implementing any common behaviour). For example,
instead of:

def extreme(sequence, biggest=True):
"""Return the extreme value from sequence.

If biggest is a true value, return the maximum value, otherwise
return the smallest.
"""
pass # implementation left as an exercise


have two functions, max and min.



--
Steven
 
Reply With Quote
 
Gabriel Genellina
Guest
Posts: n/a
 
      02-06-2010
En Fri, 05 Feb 2010 19:22:39 -0300, bartc <(E-Mail Removed)> escribió:
> "Steve Holden" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> Arnaud Delobelle wrote:
>>> Robert Kern <(E-Mail Removed)> writes:
>>>
>>>> I prefer Guido's formulation (which, naturally, I can't find a direct
>>>> quote for right now): if you expect that a boolean argument is only
>>>> going to take *literal* True or False, then it should be split into

^^^^^^^^^^^^^^^^^^^^^^^
>>>> two functions.
>>>
>>> So rather than three boolean arguments, would you have eight functions?
>>>

>> If there's genuinely a need for that functionality, yes.

>
> So you want a function such as drawtext(s, bold=true, italic=false,
> underline=true) to be split into:
>
> drawtext(s)
> drawtextb(s)
> drawtexti(s)
> drawtextu(s)
> drawtextbi(s)
> drawtextbu(s)
> drawtextiu(s)
> drawtextbiu(s)


Note the *literal* part. If you (the programmer) is likely to know the
parameter value when writing the code, then the function is actually two
separate functions.
By example, foo.get_path(absolute=True) should be written as
foo.get_absolute_path() and foo.get_relative_path()
It gets worse when one parameter alters the type of the returned value, or
even the number of returned values. This is an actual example:

def build_image(self, zone=-1, return_sizes=False):
...
if return_size:
return img, sizes
else:
return img

image = foo.build_image(3)
but:
image, sizes = foo.build_image(3, True)

It should be split onto two separate functions; in this particular case,
computing 'sizes' required actually drawing the image, so the solution was
to make those 'sizes' attributes of the returned image.

--
Gabriel Genellina

 
Reply With Quote
 
Arnaud Delobelle
Guest
Posts: n/a
 
      02-06-2010
"Gabriel Genellina" <(E-Mail Removed)> writes:

> En Fri, 05 Feb 2010 19:22:39 -0300, bartc <(E-Mail Removed)> escribió:
>> "Steve Holden" <(E-Mail Removed)> wrote in message
>> news:(E-Mail Removed)...
>>> Arnaud Delobelle wrote:
>>>> Robert Kern <(E-Mail Removed)> writes:
>>>>
>>>>> I prefer Guido's formulation (which, naturally, I can't find a direct
>>>>> quote for right now): if you expect that a boolean argument is only
>>>>> going to take *literal* True or False, then it should be split into

> ^^^^^^^^^^^^^^^^^^^^^^^
>>>>> two functions.
>>>>
>>>> So rather than three boolean arguments, would you have eight functions?
>>>>
>>> If there's genuinely a need for that functionality, yes.

>>
>> So you want a function such as drawtext(s, bold=true, italic=false,
>> underline=true) to be split into:
>>
>> drawtext(s)
>> drawtextb(s)
>> drawtexti(s)
>> drawtextu(s)
>> drawtextbi(s)
>> drawtextbu(s)
>> drawtextiu(s)
>> drawtextbiu(s)

>
> Note the *literal* part. If you (the programmer) is likely to know the
> parameter value when writing the code, then the function is actually two
> separate functions.


Thanks, I understand what Steve Holden meant now.

--
Arnaud
 
Reply With Quote
 
bartc
Guest
Posts: n/a
 
      02-07-2010
"Arnaud Delobelle" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> "Gabriel Genellina" <(E-Mail Removed)> writes:
>
>> En Fri, 05 Feb 2010 19:22:39 -0300, bartc <(E-Mail Removed)> escribió:
>>> "Steve Holden" <(E-Mail Removed)> wrote in message
>>> news:(E-Mail Removed)...
>>>> Arnaud Delobelle wrote:
>>>>> Robert Kern <(E-Mail Removed)> writes:
>>>>>
>>>>>> I prefer Guido's formulation (which, naturally, I can't find a direct
>>>>>> quote for right now): if you expect that a boolean argument is only
>>>>>> going to take *literal* True or False, then it should be split into

>> ^^^^^^^^^^^^^^^^^^^^^^^
>>>>>> two functions.
>>>>>
>>>>> So rather than three boolean arguments, would you have eight
>>>>> functions?
>>>>>
>>>> If there's genuinely a need for that functionality, yes.
>>>
>>> So you want a function such as drawtext(s, bold=true, italic=false,
>>> underline=true) to be split into:
>>>
>>> drawtext(s)
>>> drawtextb(s)
>>> drawtexti(s)
>>> drawtextu(s)
>>> drawtextbi(s)
>>> drawtextbu(s)
>>> drawtextiu(s)
>>> drawtextbiu(s)

>>
>> Note the *literal* part. If you (the programmer) is likely to know the
>> parameter value when writing the code, then the function is actually two
>> separate functions.

>
> Thanks, I understand what Steve Holden meant now.


I've just noticed that 'literal' part. But I think I still disagree.

For a real-world example, it means instead of having a room with a
light-switch in it, if I *know* I want the light on or off, I should have
two rooms: one with the light permanently on, and one with it permanently
off, and just walk into the right one.

--
Bartc


 
Reply With Quote
 
Steven D'Aprano
Guest
Posts: n/a
 
      02-07-2010
On Sun, 07 Feb 2010 01:34:14 +0000, bartc wrote:

> For a real-world example, it means instead of having a room with a
> light-switch in it, if I *know* I want the light on or off, I should
> have two rooms: one with the light permanently on, and one with it
> permanently off, and just walk into the right one.


I don't think you can apply real-world analogies to software in that way.
They're too different.

Think of the objections to having two rooms, one permanently lit up, the
other permanently not:

(1) Having two rooms is expensive and wasteful of physical space, which
is in short supply.

(2) You typically use rooms for storing things (furniture and smaller
objects), having two rooms mean you would need to clone every object
inside it and somehow keep them in perfect synchronisation.

(3) the light that is always on will use electricity 24 hours a day,
regardless of whether you are inside it or not.

But none of those objections apply to functions:

(1) Functions are cheap and live in memory, which is not in short supply
unless you're programming for an embedded device.

(1a) Even if you are programming in a device that is short of memory, the
overhead of a second function is minimal. There's little difference
between:

def func(flag):
if flag:
blockA
else:
blockB


and


def funcA():
blockA

def funcB():
blockB


for any non-trivial code blocks, particularly if any common code is
factored out into another function which you call.

(2) Functions aren't typically used for storage, and when they need
external data, it is easy to have them access a common data store.

(3) Functions don't use CPU cycles just by existing.



--
Steven
 
Reply With Quote
 
Alf P. Steinbach
Guest
Posts: n/a
 
      02-07-2010
* Steven D'Aprano:
> On Sun, 07 Feb 2010 01:34:14 +0000, bartc wrote:
>
>> For a real-world example, it means instead of having a room with a
>> light-switch in it, if I *know* I want the light on or off, I should
>> have two rooms: one with the light permanently on, and one with it
>> permanently off, and just walk into the right one.

>
> I don't think you can apply real-world analogies to software in that way.
> They're too different.
>
> Think of the objections to having two rooms, one permanently lit up, the
> other permanently not:
>
> (1) Having two rooms is expensive and wasteful of physical space, which
> is in short supply.
>
> (2) You typically use rooms for storing things (furniture and smaller
> objects), having two rooms mean you would need to clone every object
> inside it and somehow keep them in perfect synchronisation.
>
> (3) the light that is always on will use electricity 24 hours a day,
> regardless of whether you are inside it or not.
>
> But none of those objections apply to functions:
>
> (1) Functions are cheap and live in memory, which is not in short supply
> unless you're programming for an embedded device.
>
> (1a) Even if you are programming in a device that is short of memory, the
> overhead of a second function is minimal. There's little difference
> between:
>
> def func(flag):
> if flag:
> blockA
> else:
> blockB
>
>
> and
>
>
> def funcA():
> blockA
>
> def funcB():
> blockB
>
>
> for any non-trivial code blocks, particularly if any common code is
> factored out into another function which you call.
>
> (2) Functions aren't typically used for storage, and when they need
> external data, it is easy to have them access a common data store.
>
> (3) Functions don't use CPU cycles just by existing.


I agree with your reasoning , but it's not either/or.

Consider, sometimes one wants to do

switch.off()

and sometimes one wants to do

original_switch_state = switch.state()
switch.off()
# ... Do things that are best done in utter darkness.
switch.set_state( original_switch_state )

E.g. the "switch" might be the enabled/disabled state of some GUI widget.

So IMHO it depends.

Sometimes one wants both kinds of "protocols".



Cheers,

- Alf
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Dreaming of new generation IDE Vladimir Ignatov Python 26 03-15-2010 01:41 PM
Re: Dreaming of new generation IDE Vladimir Ignatov Python 4 02-04-2010 10:54 AM
Re: Dreaming of new generation IDE Jean-Michel Pichavant Python 4 02-03-2010 10:27 PM
Dreaming? JD Digital Photography 5 03-06-2004 04:18 PM
I would like to start serious day dreaming about the Canon D10. Michael P Gabriel Digital Photography 5 08-11-2003 06:19 AM



Advertisments