Jonathan <[email protected]> added the comment:
Interesting conversation
As I see it, there are two ways to solve this, both discussed above:
A) Python can compute and ValueError at parse-time
B) Python can ValueError at property-call time. (Current method)
But both have Advantages/Disadvantages.
A - Pros) - The function is more consistent with all the other Python builtins
(well, the one's I've dealt with).
A - Pros) - Not carrying around a "bad" port.
A - Cons) - As Matt suggests, we could be "taking something from the user"
because they may want the other values. (although in that case, the current
semi-related behaviour: "Unmatched square brackets in the netloc attribute will
raise a ValueError" is also potentially taking something from the user).
B - Pros) - User gets the other values even if they don't get the port.
B - Cons) - User needs to have more Try/Excepts in the code (whereever you may
access the property), or to write their own wrapper function.
Given the above, of the those options I still think option (A) is better. The
other values may have a reduced worth if the port is invalid (depending on the
user's goal).
May I suggest a third option:
C) A flag for urlsplit/urlparse to indicate we don't want to do port
validation, and to just return whatever it thinks is there.
(example.com:3293849038 would return 3293849038. example.com:gibberish would
return "gibberish" etc).
This way the user can choose what behaviour they want with the bad port and
test the value of the port themselves if they care (something I was going to do
anyway before I discovered it was included in the builtin). Some of the url
quoting functions have a similar flag ("errors") for handling bad data
transparently or not.
----------
_______________________________________
Python tracker <[email protected]>
<https://bugs.python.org/issue33034>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
