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
On Sat, 09 Feb 2013 09:59:13 +, Thomas Scrace wrote:
> 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")
> >
For now
http://docs.python.org/3/extending/newtypes.html#supporting-cyclic-garbage-collection
at first the doc demonstrate long way than note Py_CLEAR and Py_VISIT macroses.
I like to remove code similar to
if (self->first) {
vret = visit(self->first, arg);
if (vret != 0)
2013/2/9 Andrew Svetlov :
> For now
> http://docs.python.org/3/extending/newtypes.html#supporting-cyclic-garbage-collection
> at first the doc demonstrate long way than note Py_CLEAR and Py_VISIT
> macroses.
>
> I like to remove code similar to
>
> if (self->first) {
> vret = visit(se
On Sat, Feb 9, 2013 at 11:31 PM, R. David Murray wrote:
> 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
On Sat, Feb 9, 2013 at 11:52 PM, Andrew Svetlov
wrote:
> I think we have to demonstrate best practices in our examples.
> Let's py2.7 branch live untouched, change only docs for python 3.x
>
> Any objections?
For debugging purposes, I think extension developers do need to
understand what those ma
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
On Sat, 09 Feb 2013 14:35:33 +, Thomas Scrace wrote:
> 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 e
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
On 2/9/2013 8:31 AM, R. David Murray wrote:
On Sat, 09 Feb 2013 09:59:13 +, Thomas Scrace wrote:
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")
--
On Sat, 09 Feb 2013 13:57:41 -0500, Terry Reedy wrote:
> On 2/9/2013 8:31 AM, R. David Murray wrote:
> Changing AttributeError to TypeError only requires try-except, which is
> cheap if there is no error, not an early type check.
>
> > The reason we avoid such type checks is that we prefer to op
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
Terry Reedy wrote:
I agree. Since the exception type is not documented and since no one
should intentionally pass anything but strings, and therefore should not
be writing
try:
os.path.join(a,b)
except AttributeError:
barf()
I think it would be acceptable to make a change in 3.4.
Why sh
On 2/9/2013 6:23 PM, Greg Ewing wrote:
> Terry Reedy wrote:
>> I agree. Since the exception type is not documented and since no one
>> should intentionally pass anything but strings, and therefore should
>> not be writing
>>
>> try:
>> os.path.join(a,b)
>> except AttributeError:
>> barf()
>>
>>
And this is not just with Python. Try any other dynamic language
(Ruby), send a function in place of a string and see failure msg. And
if the question is really about path joins and path manipulations,
then I believe PEP 428 ( http://www.python.org/dev/peps/pep-0428/)
would be better candidate to
15 matches
Mail list logo
