Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #65836 > unrolled thread

PyWart: More surpises via "implict conversion to boolean" (and other steaming piles!)

Back to article view | Back to comp.lang.python

Contents

  PyWart: More surpises via "implict conversion to boolean" (and other steaming piles!) Rick Johnson <rantingrickjohnson@gmail.com> - 2014-02-10 10:45 -0800
    Re: PyWart: More surpises via "implict conversion to boolean" (and other steaming piles!) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-02-10 19:15 +0000
    Re: PyWart: More surpises via "implict conversion to boolean" (and other steaming piles!) Ned Batchelder <ned@nedbatchelder.com> - 2014-02-10 14:17 -0500
    Re: PyWart: More surpises via "implict conversion to boolean" (and other steaming piles!) Rotwang <sg552@hotmail.co.uk> - 2014-02-10 21:12 +0000
      Re: PyWart: More surpises via "implict conversion to boolean" (and other steaming piles!) Ned Batchelder <ned@nedbatchelder.com> - 2014-02-10 17:00 -0500
      Re: PyWart: More surpises via "implict conversion to boolean" (and other steaming piles!) Terry Reedy <tjreedy@udel.edu> - 2014-02-10 17:59 -0500
    Re: PyWart: More surpises via "implict conversion to boolean" (and other steaming piles!) Chris Angelico <rosuav@gmail.com> - 2014-02-11 09:30 +1100
    Re: PyWart: More surpises via "implict conversion to boolean" (and other steaming piles!) Steven D'Aprano <steve@pearwood.info> - 2014-02-11 06:30 +0000
      Re: PyWart: More surpises via "implict conversion to boolean" (and other steaming piles!) Tim Chase <python.list@tim.thechases.com> - 2014-02-11 09:26 -0600
      Re: PyWart: More surpises via "implict conversion to boolean" (and other steaming piles!) Travis Griggs <travisgriggs@gmail.com> - 2014-02-11 07:36 -0800
        Re: PyWart: More surpises via "implict conversion to boolean" (and other steaming piles!) Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2014-02-11 18:07 +0200
          Re: PyWart: More surpises via "implict conversion to boolean" (and other steaming piles!) Chris Angelico <rosuav@gmail.com> - 2014-02-12 03:14 +1100
        Re: PyWart: More surpises via "implict conversion to boolean" (and other steaming piles!) Steven D'Aprano <steve@pearwood.info> - 2014-02-13 04:11 +0000
          Re: PyWart: More surpises via "implict conversion to boolean" (and other steaming piles!) Chris Angelico <rosuav@gmail.com> - 2014-02-13 15:30 +1100
            Re: PyWart: More surpises via "implict conversion to boolean" (and other steaming piles!) Roy Smith <roy@panix.com> - 2014-02-13 09:58 -0500
              Re: PyWart: More surpises via "implict conversion to boolean" (and other steaming piles!) Chris Angelico <rosuav@gmail.com> - 2014-02-14 06:17 +1100
          Re: PyWart: More surpises via "implict conversion to boolean" (and other steaming piles!) Tim Chase <python.list@tim.thechases.com> - 2014-02-13 05:39 -0600
          Re: PyWart: More surpises via "implict conversion to boolean" (and other steaming piles!) Tim Chase <python.list@tim.thechases.com> - 2014-02-13 05:51 -0600
          Re: PyWart: More surpises via "implict conversion to boolean" (and other steaming piles!) Ian Kelly <ian.g.kelly@gmail.com> - 2014-02-13 15:00 -0700
      Re: PyWart: More surpises via "implict conversion to boolean" (and other steaming piles!) Chris Angelico <rosuav@gmail.com> - 2014-02-12 02:52 +1100
      Re: PyWart: More surpises via "implict conversion to boolean" (and other steaming piles!) Travis Griggs <travisgriggs@gmail.com> - 2014-02-11 08:19 -0800
      Re: PyWart: More surpises via "implict conversion to boolean" (and other steaming piles!) Terry Reedy <tjreedy@udel.edu> - 2014-02-11 12:57 -0500

Page 2 of 2 — ← Prev page 1 [2]

#65925

On Feb 11, 2014, at 7:52 AM, Chris Angelico <rosuav@gmail.com> wrote:

> On Wed, Feb 12, 2014 at 2:36 AM, Travis Griggs <travisgriggs@gmail.com> wrote:
>> OTOH, I’m not sure I’ve heard the parameters-less functions are a code one? Is it just loose functions that you’re referring to? As opposed to methods (which are just bound functions)? I could maybe accept that. But methods with fewer arguments, and even none, are a desirable thing. There are code smells that are the opposite in fact, methods with long parameter lists are generally seen as code smell (“passing a paragraph”).
>> 
> 
> 'self' is, imo, a parameter. When you call a parameter-less method on
> an object, it's usually an imperative with a direct object (or
> sometimes a subject):
> 
> some_file.close() # "Close some_file"
> some_list.shuffle() # "Shuffle some_list"
> some_file.readline() # "Some_file, read in a line"
> 
> There are times when, for convenience, the object is implicit.
> 
> print("some text", file=some_file) # Print that text
> print(file=some_file) # Print a blank line
> print("some text") # Print that text to sys.stdout
> print() # Print a blank line to sys.stdout
> 
> So in that situation, the no-args call does make sense. Of course,
> this is a call to a function that does take args, but it's accepting
> all the defaults and providing no additional content. It's quite
> different to actually define a function that mandates exactly zero
> arguments, and isn't making use of some form of implicit state (eg a
> closure, or maybe a module-level function that manipulates
> module-level state - random.random() would be an example of the
> latter). Syntactically, Python can't tell the difference between
> "print()" and "foo()" where foo can never take args.

So at this point, what I’m reading is that actually making a “no arg function” is difficult, if we widen the semantics. The “arguments” of a function may be bound to its implicit self parameter, or tied to module state.

> 
> I'd say that a function taking no args is code smell, unless it's
> obviously taking its state from somewhere else (callbacks, for
> instance - maybe you pass a bound method, or maybe a closure, but in
> either case it has implicit state that's not described by function
> args); but _calling_ with no args isn't as smelly. It's certainly less
> common than using args, but there are plenty of times when a type is
> called without args, for instance[1].

Which leaves me wondering, how would I get my code to smell this way then? What IS an example of a no arg function that doesn’t have an implicit object, that smells? It seems I can  escape the smell clause, as long as I find some data that I reason is attached to my function.

This all aside, I don’t think these are what the OP had in mind. A code inspection algorithm is not going to be able to discern when an explicitly parameterless function has implicit parameters. It’s just going to see something like

print vs print()

or 

aPoint.transpose vs aPoint.transpose()

 

[toc] | [prev] | [next] | [standalone]

#65934

On 2/11/2014 11:19 AM, Travis Griggs wrote:
>
> On Feb 11, 2014, at 7:52 AM, Chris Angelico <rosuav@gmail.com> wrote:
>
>> So in that situation, the no-args call does make sense. Of course,
>> this is a call to a function that does take args, but it's accepting
>> all the defaults and providing no additional content. It's quite
>> different to actually define a function that mandates exactly zero
>> arguments, and isn't making use of some form of implicit state (eg a
>> closure, or maybe a module-level function that manipulates
>> module-level state - random.random() would be an example of the
>> latter). Syntactically, Python can't tell the difference between
>> "print()" and "foo()" where foo can never take args.
>
> So at this point, what I’m reading is that actually making a “no arg function” is difficult, if we widen the semantics.

It is quite easy.

def f(): return 3  # or any other constant.

Chris said that useful functions in Python are (mostly) not really 
niladic, which is equivalent to saying that niladic functions in Python 
are (mostly) not really useful. They are a mainly a device in pure 
function theory to have constants (True, False, 0, 1, ...) while also 
having everything be a function (the 'pure' part).  Pure set theory uses 
its own tricks to make the same constants (and functions) be sets ;-).

-- 
Terry Jan Reedy

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.python

csiph-web