Re: Dreaming of new generation IDE

Discussion in 'Python' started by Adam Tauno Williams, Feb 3, 2010.

  1. On Wed, 2010-02-03 at 14:10 +0300, Vladimir Ignatov wrote:
    > Hello,
    > I am sitting here for quite some time, but usually keep silent ;-) I
    > use Python since 2003 both "professionally" and for my hobby projects
    > and love it a much.
    > I notice however, that "maintaining" existing/older python code is may
    > be not so enjoyable task. It may be even harder than supporting old
    > code written in some type of "static" languages (like Java or C++).
    > Surely "dynamic" nature of python comes with price.


    Yes, it certainly does. Not that you'll get many Pythonistas to confess
    to that fact. Somehow those who brag about the readability and
    expressiveness of source code just cannot admit that:

    class.method(sting name, int count)

    - is *obviously* more expressive than -

    class.method(name, count)

    Oh, well.

    This is obvious even in the Python documentation itself where one
    frequently asks oneself "Uhh... so what is parameter X supposed to be...
    a string... a list... ?"

    Not knocking Python; Python is great. I maintain a rapidly growing
    Python code base. But the above is almost comically funny sometimes
    [sand.insert_head(pythonista)].

    > Finally I develop a feeling that strong instrumentation / tools can
    > bring us the best of two worlds. That I am dreaming on is an absolute
    > new type/class of IDE suitable for Python and potentially for other
    > dynamic-type languages. Instead of current text-oriented IDEs, it
    > should be a database-centric and resemble current CAD systems instead
    > of being just "fancy text editor". Source text should be an output
    > product of that CAD and not a "source material" itself.


    Ugh, please NO! This has been attempted many many times in many
    environments - it always fails *terribly*.

    > Well. I understand that it is a very ambitious and experimental stuff.
    > Great efforts and motivation needed even to get something "runnable".
    > So I am looking for someone to get in kind of "virtual partnership".
    > If someone interesting it that soft of stuff, I would like to talk and
    > discuss this system.
     
    Adam Tauno Williams, Feb 3, 2010
    #1
    1. Advertising

  2. Adam Tauno Williams, 03.02.2010 14:18:
    > This is obvious even in the Python documentation itself where one
    > frequently asks oneself "Uhh... so what is parameter X supposed to be...
    > a string... a list... ?"
    >
    > Not knocking Python; Python is great. I maintain a rapidly growing
    > Python code base. But the above is almost comically funny sometimes
    > [sand.insert_head(pythonista)].


    So, what's "pythonista" in the above? A dummy?

    Stefan
     
    Stefan Behnel, Feb 3, 2010
    #2
    1. Advertising

  3. On Wed, 03 Feb 2010 08:18:40 -0500, Adam Tauno Williams wrote:

    > On Wed, 2010-02-03 at 14:10 +0300, Vladimir Ignatov wrote:
    >> Hello,
    >> I am sitting here for quite some time, but usually keep silent ;-) I
    >> use Python since 2003 both "professionally" and for my hobby projects
    >> and love it a much.
    >> I notice however, that "maintaining" existing/older python code is may
    >> be not so enjoyable task. It may be even harder than supporting old
    >> code written in some type of "static" languages (like Java or C++).
    >> Surely "dynamic" nature of python comes with price.

    >
    > Yes, it certainly does. Not that you'll get many Pythonistas to confess
    > to that fact. Somehow those who brag about the readability and
    > expressiveness of source code just cannot admit that:
    >
    > class.method(sting name, int count)
    >
    > - is *obviously* more expressive than -
    >
    > class.method(name, count)



    Obviously? I don't know about that. Being told that "count" is an int
    doesn't really help me -- it's obvious just from the name. In a well-
    written API, what else could it be?

    And surely count should be positive or zero but not negative? Saying it's
    an int is misleading. Or perhaps count can be negative, in which case
    maybe negative counts have some special meaning that isn't obvious from
    the function signature. Can I pass None to get the default behaviour?
    Either way, I need to read the docs, so the supposed added expressiveness
    doesn't actually add much.

    And why is count limited to an actual int type, rather than anything
    which is integer-like? Why can't I pass 3.0 or Decimal(3)? If you have a
    good reason for that limitation, great, but if it's just there to satisfy
    the compiler, then boo hiss to you.

    I cheerfully admit that *sometimes* there are type restrictions which
    make sense, and of course we know that there are sometimes useful
    performance gains to be made with static typing. Any compiler which
    requires types to be declared is far too 1970s though -- a good modern
    static language should use type inference to reduce the number of
    declarations needed.

    As for Pythonistas refusing to accept this, how do you explain function
    annotations then?

    Quoting Guido:

    "Optional static typing has long been requested as a Python feature."

    http://www.artima.com/weblogs/viewpost.jsp?thread=85551


    More on function annotations and type inference for Python:

    http://lambda-the-ultimate.org/node/1519
    http://www.python.org/dev/peps/pep-3107/

    http://www.python.org/workshops/2000-01/proceedings/papers/aycock/aycock.html



    > This is obvious even in the Python documentation itself where one
    > frequently asks oneself "Uhh... so what is parameter X supposed to be...
    > a string... a list... ?"


    The answer is usually "both, and anything else that obeys some subset of
    the sequence or iterable protocols".





    --
    Steven
     
    Steven D'Aprano, Feb 3, 2010
    #3
  4. Adam Tauno Williams

    Robert Kern Guest

    On 2010-02-03 15:37 PM, Steven D'Aprano wrote:
    > On Wed, 03 Feb 2010 08:18:40 -0500, Adam Tauno Williams wrote:
    >
    >> On Wed, 2010-02-03 at 14:10 +0300, Vladimir Ignatov wrote:
    >>> Hello,
    >>> I am sitting here for quite some time, but usually keep silent ;-) I
    >>> use Python since 2003 both "professionally" and for my hobby projects
    >>> and love it a much.
    >>> I notice however, that "maintaining" existing/older python code is may
    >>> be not so enjoyable task. It may be even harder than supporting old
    >>> code written in some type of "static" languages (like Java or C++).
    >>> Surely "dynamic" nature of python comes with price.

    >>
    >> Yes, it certainly does. Not that you'll get many Pythonistas to confess
    >> to that fact. Somehow those who brag about the readability and
    >> expressiveness of source code just cannot admit that:
    >>
    >> class.method(sting name, int count)
    >>
    >> - is *obviously* more expressive than -
    >>
    >> class.method(name, count)

    >
    > Obviously? I don't know about that. Being told that "count" is an int
    > doesn't really help me -- it's obvious just from the name. In a well-
    > written API, what else could it be?


    A bool. As in telling the method whether or not it should count something.

    That said, I agree with your later point that this kind of information is better
    provided by the docstring, not the call signature. Not least because the "type"
    may be something wishy-washy and ad-hoc like "sequence" or "string or list of
    strings". I do wish that people would document their parameters with this
    information a little more consistently, though.

    --
    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
     
    Robert Kern, Feb 3, 2010
    #4
  5. On Wed, 03 Feb 2010 16:38:21 -0600, Robert Kern wrote:

    >>> class.method(name, count)

    >>
    >> Obviously? I don't know about that. Being told that "count" is an int
    >> doesn't really help me -- it's obvious just from the name. In a well-
    >> written API, what else could it be?

    >
    > A bool. As in telling the method whether or not it should count
    > something.


    Ha ha, good point. I question that this is a well-written API: such flags
    to change the behaviour of a function/method are generally poor design.
    If method behaves differently depending on whether or not you want it to
    count something, then it is usually better design to have two methods,
    one that counts and one that doesn't.

    In any case, yes, the weakness of naming conventions is that there are
    always odd-corner cases of natural language. Perhaps `name` is also a
    flag telling the method whether or not to name something.

    But then, one can write crappy APIs in any language.



    --
    Steven
     
    Steven D'Aprano, Feb 4, 2010
    #5
  6. Adam Tauno Williams

    Robert Kern Guest

    On 2010-02-03 18:01 PM, Steven D'Aprano wrote:
    > On Wed, 03 Feb 2010 16:38:21 -0600, Robert Kern wrote:
    >
    >>>> class.method(name, count)
    >>>
    >>> Obviously? I don't know about that. Being told that "count" is an int
    >>> doesn't really help me -- it's obvious just from the name. In a well-
    >>> written API, what else could it be?

    >>
    >> A bool. As in telling the method whether or not it should count
    >> something.

    >
    > Ha ha, good point. I question that this is a well-written API: such flags
    > to change the behaviour of a function/method are generally poor design.
    > If method behaves differently depending on whether or not you want it to
    > count something, then it is usually better design to have two methods,
    > one that counts and one that doesn't.


    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. There is a
    use case for a boolean argument like this when you can expect to pass around a
    variable between multiple functions.

    Of course, this also might be the private API that the public API (with two
    distinct methods for each case) uses internally in order to avoid code
    duplication. Private APIs need to be documented, too.

    > In any case, yes, the weakness of naming conventions is that there are
    > always odd-corner cases of natural language. Perhaps `name` is also a
    > flag telling the method whether or not to name something.
    >
    > But then, one can write crappy APIs in any language.


    Well, I'm not trying to make Paul's point that other languages are better in
    this regard. I think that type documentation is quite helpful, but requiring
    static type declaration to get that documentation is an undesirable tradeoff for
    most of the code that I want to write. I do think it is worthwhile to recognize
    that the tradeoff does cut the other way, too. It just so happens that Python
    has docstrings and argument annotations to document argument types without the
    burden of static typing.

    Not all good, clean APIs are always going to have argument names that clearly
    inform the kind of type it expects. And what an author thinks is obviously
    deducible while writing the API is often quite different from what a new user
    thinks is obvious. There isn't much reason to place that cognitive burden on the
    (many) readers of the code when the (single) author can put in a word or two
    into the docstring (once) to describe what the parameter is expected to be.
    Figuring out how to use an API to solve your real problem is hard enough without
    having your brainpower nickled-and-dimed at every turn.

    --
    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
     
    Robert Kern, Feb 4, 2010
    #6
  7. Adam Tauno Williams

    alex23 Guest

    Adam Tauno Williams <> wrote:
    > This is obvious even in the Python documentation itself where one
    > frequently asks oneself "Uhh... so what is parameter X supposed to be...
    > a string... a list... ?"


    Could you provide an actual example to support this?

    The only places I tend to see 'x' as a parameter in the Python library
    docs are where it's clearly a number, or the text immediately beneath
    it explains exactly what it is.

    random.seed([x])
    Initialize the basic random number generator. Optional
    argument x can be any hashable object.

    Everywhere else, the docs seem to declare what the parameters should
    be _and_ explains them in the text:

    itertools.combinations(iterable, r)
    Return r length subsequences of elements from
    the input iterable.

    If you're finding places in the docs where this isn't the case, I'd
    treat them as a documentation bug and report them. If it's not obvious
    to you what an iterable is, well, I'm sure you've got a disparaging
    term for those of us who do...
     
    alex23, Feb 4, 2010
    #7
  8. Adam Tauno Williams

    purui Guest


    > This is obvious even in the Python documentation itself where one
    > frequently asks oneself "Uhh... so what is parameter X supposed to be...
    > a string... a list... ?"
    >


    That is partially why I created this search engine for python, to see
    what parameters other people feed in.
    http://nullege.com/
     
    purui, Feb 4, 2010
    #8
  9. > That is partially why I created this search engine for python, to see
    > what parameters other people feed in.
    > http://nullege.com/


    Thank you for excellent effort! I found it very useful and start using
    it on almost everyday basis. It's much simple to learn from real live
    examples.

    Vladimir Ignatov
     
    Vladimir Ignatov, Feb 4, 2010
    #9
  10. Robert Kern <> 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?

    --
    Arnaud
     
    Arnaud Delobelle, Feb 5, 2010
    #10
  11. Adam Tauno Williams

    Steve Holden Guest

    Arnaud Delobelle wrote:
    > Robert Kern <> 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/
     
    Steve Holden, Feb 5, 2010
    #11
  12. Adam Tauno Williams

    bartc Guest

    "Steve Holden" <> wrote in message
    news:...
    > Arnaud Delobelle wrote:
    >> Robert Kern <> 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
     
    bartc, Feb 5, 2010
    #12
  13. Adam Tauno Williams

    Robert Kern Guest

    On 2010-02-05 16:22 PM, bartc wrote:
    >
    > "Steve Holden" <> wrote in message
    > news:...
    >> Arnaud Delobelle wrote:
    >>> Robert Kern <> 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
     
    Robert Kern, Feb 5, 2010
    #13
  14. Adam Tauno Williams

    Steve Holden Guest

    bartc wrote:
    >
    > "Steve Holden" <> wrote in message
    > news:...
    >> Arnaud Delobelle wrote:
    >>> Robert Kern <> 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/
     
    Steve Holden, Feb 5, 2010
    #14
  15. On Fri, 05 Feb 2010 22:22:39 +0000, bartc wrote:

    > "Steve Holden" <> wrote in message
    > news:...
    >> Arnaud Delobelle wrote:
    >>> Robert Kern <> 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
     
    Steven D'Aprano, Feb 5, 2010
    #15
  16. En Fri, 05 Feb 2010 19:22:39 -0300, bartc <> escribió:
    > "Steve Holden" <> wrote in message
    > news:...
    >> Arnaud Delobelle wrote:
    >>> Robert Kern <> 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
     
    Gabriel Genellina, Feb 6, 2010
    #16
  17. "Gabriel Genellina" <> writes:

    > En Fri, 05 Feb 2010 19:22:39 -0300, bartc <> escribió:
    >> "Steve Holden" <> wrote in message
    >> news:...
    >>> Arnaud Delobelle wrote:
    >>>> Robert Kern <> 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
     
    Arnaud Delobelle, Feb 6, 2010
    #17
  18. Adam Tauno Williams

    bartc Guest

    "Arnaud Delobelle" <> wrote in message
    news:...
    > "Gabriel Genellina" <> writes:
    >
    >> En Fri, 05 Feb 2010 19:22:39 -0300, bartc <> escribió:
    >>> "Steve Holden" <> wrote in message
    >>> news:...
    >>>> Arnaud Delobelle wrote:
    >>>>> Robert Kern <> 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
     
    bartc, Feb 7, 2010
    #18
  19. 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
     
    Steven D'Aprano, Feb 7, 2010
    #19
  20. * 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
     
    Alf P. Steinbach, Feb 7, 2010
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. The Eternal Squire

    dreaming in Python

    The Eternal Squire, Oct 29, 2005, in forum: Python
    Replies:
    3
    Views:
    414
    =?ISO-8859-1?Q?Lasse_V=E5gs=E6ther_Karlsen?=
    Oct 30, 2005
  2. Paul McGuire

    "Dreaming in Code"

    Paul McGuire, Apr 23, 2008, in forum: Python
    Replies:
    2
    Views:
    267
  3. Vladimir Ignatov

    Dreaming of new generation IDE

    Vladimir Ignatov, Feb 3, 2010, in forum: Python
    Replies:
    26
    Views:
    841
    catonano
    Mar 15, 2010
  4. Jean-Michel Pichavant

    Re: Dreaming of new generation IDE

    Jean-Michel Pichavant, Feb 3, 2010, in forum: Python
    Replies:
    4
    Views:
    237
    Robert Kern
    Feb 3, 2010
  5. Vladimir Ignatov

    Re: Dreaming of new generation IDE

    Vladimir Ignatov, Feb 3, 2010, in forum: Python
    Replies:
    4
    Views:
    305
    Vladimir Ignatov
    Feb 4, 2010
Loading...

Share This Page