[issue27161] Confusing exception in Path().with_name

Change by Antony Lee : -- nosy: -Antony.Lee ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pyt

[issue27161] Confusing exception in Path().with_name

Irit Katriel added the comment: I agree that it's not worth changing the code for this. If someone tries to pass {"a": "b"} as a name then, yeah, they get a weird error message. -- nosy: +iritkatriel resolution: -> rejected stage: -> resolved status: open -> closed

[issue27161] Confusing exception in Path().with_name

R. David Murray added the comment: To clarify that performance statement: if someone is optimizing a tight loop, the first thing they'll likely do is drop down to the lower level calls to avoid all of the pathlib overhead. -- ___ Python tracker

[issue27161] Confusing exception in Path().with_name

R. David Murray added the comment: Just because it isn't public doesn't mean no one calls it :). But seriously, that's why I said "the risk". Is the small benefit of the codechange worth the small risk of breaking something? I'm not answering that question, I'm posing it. Call me -0 on the

[issue27161] Confusing exception in Path().with_name

Antony Lee added the comment: First, I doubt that this optimization actually changes anything measurable, but if you want you can always replace that line by "if part.startswith(sep)" (also solving the original issue). Additionally, note that `parse_parts` (the only function to call `splitroot

[issue27161] Confusing exception in Path().with_name

Serhiy Storchaka added the comment: The "part and part[0] == sep" check is here for speed. pathlib-splitroot.patch removes this optimization. -- nosy: +pitrou, serhiy.storchaka ___ Python tracker _

[issue27161] Confusing exception in Path().with_name

Antony Lee added the comment: Would it? Note that splitroot is not public, and some quick tests did not show any other behavior difference from the public API side. -- ___ Python tracker _

[issue27161] Confusing exception in Path().with_name

R. David Murray added the comment: It's a resaonable approach, but I question if the gain is worth the chance of introducing bugs (behavior changes...for example, a None argument would be handled differently by the patch). -- ___ Python tracker

[issue27161] Confusing exception in Path().with_name

Antony Lee added the comment: Actually, a simpler approach may be the attached patch (pathlib-splitroot.patch), in which case the exception is AttributeError: 'dict' object has no attribute 'lstrip' which is pretty commonly seen when a wrong type is passed to a function. (Note that it is

[issue27161] Confusing exception in Path().with_name

R. David Murray added the comment: Again, I don't think so. We don't generally wrap TypeErrors or ValueErrors. On the other hand, if the try/except can *add* additional contextual information about the error, it might be worthwhile. -- ___ Python

[issue27161] Confusing exception in Path().with_name

Ethan Furman added the comment: I think the request is to raise a single PathlibError instead of the broad range of possible errors. Something like: try: blah blah except TypeError as e: raise PathlibError(str(e)) Since pathlib is a high level library this seems appropriate. --

[issue27161] Confusing exception in Path().with_name

R. David Murray added the comment: I don't think so. Python uses duck typing, and one of the consequences of that is you can get weird errors if you pass in a type that sort-of-works but doesn't really. Arbitrarily restricting the input type is not something we do (that's what the whole stat

[issue27161] Confusing exception in Path().with_name

New submission from Antony Lee: `Path().with_name` can fail with a lot of different exceptions: >>> Path("foo").with_name(0) Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3.5/pathlib.py", line 800, in with_name raise ValueError("Invalid name