string literal or NoneType

[castironpi at gmail.com]

On Mar 15, 2:41 pm, "Terry Reedy" <tjre... at udel.edu> wrote:
> <menosa... at gmail.com> wrote in message
>
> news:b2d5cbd3-b207-4c46-89ef-75ae101752ca at e6g2000prf.googlegroups.com...
> | hi all
> | i want to check a condition and if true should return a filename
> | string  from a list.if the condition is false i am returning a
> | ""  (string literal)..
> |
> | retv=""
> | if  somecondition:
> |    retv=mylist[x]
> | ...
> | return retv
> |
> |
> | The calling function will check the return value and print the
> | filename if it is not """.
> | in the calling function i can code
> | if returnval !="":
> |    print "filename is:",returnval
> | else:
> |    print "no filename found"
> |
> | what i want to know is ,should i rewrite the  if returnval !=""  as
> |
> | if returnval:
> |   print "filename is:",returnval
> | else:
> |    print "no filename found"
>
> In this situation, where returnval must be a string, the two are
> equivalent.
> So I consider the shorter, more efficient form stylistically better.
> In situations where various null or non-null conditions are not equivalent,
> one should use the one that is correct for the situation.
>
> | or is the way i coded the right way ? i am little confused here
> | Someone suggested that i make a variable retv None and if the
> | condition true then set retv as filename ,
> |
> | retv=None
> | if somecondition:
> |    retv=mylist[x]
> |
> | ...
> | return retv
> |
> | which approach is correct..?
>
> As long as the function returns are documented and the behavior matches the
> documentation and the calling code matched the behavior, both are
> 'correct'.
> I see this as stylistic preference.  I can think of situations where a null
> string might be more useful that None, so I might go with that. Others
> might think of situations where a None return might be better.  But a
> function cannot satisfy all possible callers ;-)
> (The is one problem with writing library code.)
>
> Terry Jan Reedy

I actually took Caller Satisfaction in grad school.  Before computer
science.

It depends somewhat on what you might do later-- what changes you want
to make be easy.  Will your return always be a primitive?  Always a
single value?  Do you ever want to return the name of a buffer?  Will
the file ever already be open?  You can buy yourself some time: use
_noval= object(); return _noval; assert returnval is _noval.  'None'
works too until you use it to signal something.  But caveat emptor*.

If you want to ascribe a property to an object, such as 'wasn't
found', 'too small', and 'insufficient', do it.  Maybe 'specialflag'
is the right value for None in the -other- place, so you are free to
return it.  Poor None here is overworked, is the point.

Search the Python library for 'None'.  5961 occurrences in 3.0a3
including comments, yet including 308 'return None's, still including
comments.  There's a 'return None # bad format' and a 'return None,
None, line'.  You've got a '__UNDEF__ = [] # a special sentinel
object' too; there's precedent.

Take this one.

- Return code object if the command is complete and valid
- Return None if the command is incomplete - codeop.py

No code object will ever be 'None'; you're ok to return it without
conflicts.  But at a second level of abstraction, you'll need a
distinction.

For example: you're mapping indices to code objects.  Does 'None' mean
'uninitialized'** or 'the command is incomplete'?  It's ok to
initialize array items to 'None'; you don't need to worry about
omitting them until your call is complete.

You'll get nothing but a headache if you're expecting
    def retrlines(self, cmd, callback = None):
to throw an exception if you pass an uninitialized value to
'callback'.  Twelve lines later:
        if callback is None: callback = print_line
So, whoops.

* Under the doctrine of caveat emptor, the buyer could not recover
from the seller for defects on the property that rendered the property
unfit for ordinary purposes.  -wikipedia.
**
    sock = None
    file = None
    welcome = None
- ftplib.py