[Python-Dev] os.path.join failure mode

[Thomas Scrace]

If a function (or other non-string object) is accidentally passed as an
argument to os.path.join() the result is an AttributeError:


In [3]: os.path.join(fn, "path")
> ---
> AttributeErrorTraceback (most recent call last)
> /home/tom/ in ()
> > 1 os.path.join(fn, "path")
> /usr/lib/python2.7/posixpath.pyc in join(a, *p)
>  66 if b.startswith('/'):
>  67 path = b
> ---> 68 elif path == '' or path.endswith('/'):
>  69 path +=  b
>  70 else:
> AttributeError: 'function' object has no attribute 'endswith'



It's relatively easy to run into this if you mean to pass the return value
of a function (fn()) as the argument but accidentally forget to append
parens (()) to the callable, thus passing the function itself instead.

Would it not be more helpful to raise a TypeError("Argument must be a
string") than the slightly more mysterious AttributeError?

It's not the most difficult error in the world to figure out, I admit, but
a TypeError just seems like the more correct thing to do here.

Thanks,
Tom
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] os.path.join failure mode

[Thomas Scrace]

R. David Murray  bitdance.com> writes:

> The reason we avoid such type checks is that we prefer to operate via
> "duck typing", which means that if an object behaves like the expected
> input, it is accepted.  Here, if we did an explicit type check for str,
> it would prevent join from working on an "act alike" object that had
> just enough str like methods to work correctly in os.join (for example,
> some specialized object that was among other things a filename proxy).


I see, that makes sense. Thanks. I guess this actually goes to the heart of the 
flexibility of dynamic/weakly-typed languages. If we wanted to strictly enforce 
the type of a function's arguments we would use a strong type system.



___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] os.path.join failure mode

[Thomas Scrace]

On 9 February 2013 17:15, R. David Murray  wrote:


>
> No, it is more the difference between *statically* typed and dynamically
> typed.  Python is a strongly typed language (every object has a specific
> type).
>
>
>
Yes, sorry, I think I probably have my terminology confused. What I really
meant by 'strongly typed' was something like "a language where values
passed to functions must be of a specified type". That is to say, something
more along the lines of C, where function definitions explicitly specify
the type of each argument, and where it is an error to pass to a function
an argument whose type does not match that in the definition.

Sorry to turn this into programming design 101, I know it's not really the
place for it.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] os.path.join failure mode

[Thomas Scrace]

On 9 February 2013 20:08, R. David Murray  wrote:
>
>
> Especially given that there is already a try/except there, this seems
> fine to me.  I think perhaps the error text would be better if it
> referred only to the type that is invalid, not to str.  So something
> like:
>
> TypeError("object of type {} is not valid as a path
> "component".format(type(bad)))
>
> --David

I agree that this is a better error message. I have raised an
enhancement issue as Terry suggested:

http://bugs.python.org/issue17174
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com