Re: [Django] #36131: URL validation redesign and modernization
6 views
Skip to first unread message
Django
Feb 5, 2025, 9:17:55 PM2/5/25
to django-...@googlegroups.com
#36131: URL validation redesign and modernization
-------------------------------+-----------------------------------------
Reporter: Ludwig Kraatz | Owner: Ludwig Kraatz
Type: New feature | Status: closed
Component: Core (Other) | Version: dev
Severity: Normal | Resolution: wontfix
Keywords: URL Validator | Triage Stage: Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
-------------------------------+-----------------------------------------
Comment (by Ludwig Kraatz):
== I understand that you feel unhappy about my messages.
The reason for my extensive elaboration is easily explained: i dont get
your [django representatives] point, I dont feel like you get mine, so I
try to do my best to offer ways that might help you see what i mean. Or
tell me where i am wrong.
Is it confrontational? Well, it is reactional, to what i was presented so
far:
- it was closed right away, without an explanation or trying to understand
what it was really about
- it was changed in meaning - reinterpreted, so it is easier to disregard
an issue, thats about conformity to standards and consistency in regards
to Name vs Functionality
- and as you are doing again right now: it is redefined as a feature
request, soley because 'people are used to it' / thats how it would have
to be tackled.
== Bug vs Feature Request
We seem to have very different understandings of Bugs and Feature
Requests.
If i call something 'ABC'. And all it does is 'a' (or XYZ or ABxC), then
the code does not do, what is rightfully to be expected, that it would do.
Thats what i call a bug.
If i call something 'ABC' and that is what it does. And now i want it to
do 'ABCD' or something like 'A[B&/C] - then i would agree, it describes a
new feature. Because it would introduce a change into the code that is not
needed for the code to consistently do what it claims or suggests to do.
Now i gave plenty of reasons regarding my position, that an URLValidator,
that self proclaimed 'validates what **looks like** an URL' and actively
documents that it excludes known and generally accepted and standardized
file:/// URLs (besides the other shortcommings)- is **called ABC**, but
only **delivers a**.
And that few people called it a bug in a ticket - does not make a bug, a
feature request. Or a bug, less of a bug.
Same goes for difficulties - when dealing with resolving a bug.
Those are no reasons to not accept the severity of an issue - those are
things that might influence the way one handles an issue. rightfully, of
course.
== <this ticket> vs [django] dev process
I completely acknowledge your process and am happy to let you do it your
way - all i'm saying is: don't make a bug report a feature request, when
you still have not provided an argument, to why this is not a bug.
The only thing you described is, how you would rather treat it as a
feature request, due to its nature.
And as i said - i completely understand and support that -- if you decide
to handle a bug, that calls for it, by going through a more complex
feature request process: i do support that.
But I am here, to report a bug. That is my role - and i take it serious.
And it is a bug.
And as long as i am being asssigned i will stand for that.
And i will call it what it is. An URLValidator, not **correctly**
validating URLs.
Even if you try to 'sell' it that way. it is simply wrong. it validates a
certain, django approved, subset of URLs. Which is why it should have
never been called URLValidator - because that leads to bugs in downstream
projects, simply because it has the wrong name.
Thats why I elaborated on the whole project vs framework and social
responsibility stuff.
Fact is - you dont even know how many of django dependent platforms use a
URLValidator and dont even know they limit their users in this unneccesary
non-conformative 'django-special' way.
Bottom line:
If you accept the responsibility of this BUG i presented to you, then feel
free to do the django internal process of dealing with it - and if thats
via a new internal modernization feature: sure. makes sense to me. if you
dont care about it and just want me silent - then ok, leave it as a bug
and close it. Im ok with that - not my project, i accept your [django]
independece-from-me.
But if you have to use THIS TICKET (because you lack some Trac bug =>
internal dev mapping i suppose? no criticism, just trying to make sense of
it), then do me a solid here, assign yourself to take responsibility of
the matter, THEN you can change title, type and whatever you consider
right. Thats the only way you're not completly disrespecting my efforts to
help you keep [django] code 'in sync with reality' (not meaning this as
confrontation -- simply do not know any better way to say it).
sry its been so many words, again - but... if i would understand why my
position is so difficult to understand and deal with, trust me - i would
have an easier life. but i want things to be done right, because it
matters. so i try my best. simple as that, but sometimes messy..
--
Ticket URL: <https://code.djangoproject.com/ticket/36131#comment:19>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
-------------------------------+-----------------------------------------
Reporter: Ludwig Kraatz | Owner: Ludwig Kraatz
Type: New feature | Status: closed
Component: Core (Other) | Version: dev
Severity: Normal | Resolution: wontfix
Keywords: URL Validator | Triage Stage: Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
-------------------------------+-----------------------------------------
Comment (by Ludwig Kraatz):
== I understand that you feel unhappy about my messages.
The reason for my extensive elaboration is easily explained: i dont get
your [django representatives] point, I dont feel like you get mine, so I
try to do my best to offer ways that might help you see what i mean. Or
tell me where i am wrong.
Is it confrontational? Well, it is reactional, to what i was presented so
far:
- it was closed right away, without an explanation or trying to understand
what it was really about
- it was changed in meaning - reinterpreted, so it is easier to disregard
an issue, thats about conformity to standards and consistency in regards
to Name vs Functionality
- and as you are doing again right now: it is redefined as a feature
request, soley because 'people are used to it' / thats how it would have
to be tackled.
== Bug vs Feature Request
We seem to have very different understandings of Bugs and Feature
Requests.
If i call something 'ABC'. And all it does is 'a' (or XYZ or ABxC), then
the code does not do, what is rightfully to be expected, that it would do.
Thats what i call a bug.
If i call something 'ABC' and that is what it does. And now i want it to
do 'ABCD' or something like 'A[B&/C] - then i would agree, it describes a
new feature. Because it would introduce a change into the code that is not
needed for the code to consistently do what it claims or suggests to do.
Now i gave plenty of reasons regarding my position, that an URLValidator,
that self proclaimed 'validates what **looks like** an URL' and actively
documents that it excludes known and generally accepted and standardized
file:/// URLs (besides the other shortcommings)- is **called ABC**, but
only **delivers a**.
And that few people called it a bug in a ticket - does not make a bug, a
feature request. Or a bug, less of a bug.
Same goes for difficulties - when dealing with resolving a bug.
Those are no reasons to not accept the severity of an issue - those are
things that might influence the way one handles an issue. rightfully, of
course.
== <this ticket> vs [django] dev process
I completely acknowledge your process and am happy to let you do it your
way - all i'm saying is: don't make a bug report a feature request, when
you still have not provided an argument, to why this is not a bug.
The only thing you described is, how you would rather treat it as a
feature request, due to its nature.
And as i said - i completely understand and support that -- if you decide
to handle a bug, that calls for it, by going through a more complex
feature request process: i do support that.
But I am here, to report a bug. That is my role - and i take it serious.
And it is a bug.
And as long as i am being asssigned i will stand for that.
And i will call it what it is. An URLValidator, not **correctly**
validating URLs.
Even if you try to 'sell' it that way. it is simply wrong. it validates a
certain, django approved, subset of URLs. Which is why it should have
never been called URLValidator - because that leads to bugs in downstream
projects, simply because it has the wrong name.
Thats why I elaborated on the whole project vs framework and social
responsibility stuff.
Fact is - you dont even know how many of django dependent platforms use a
URLValidator and dont even know they limit their users in this unneccesary
non-conformative 'django-special' way.
Bottom line:
If you accept the responsibility of this BUG i presented to you, then feel
free to do the django internal process of dealing with it - and if thats
via a new internal modernization feature: sure. makes sense to me. if you
dont care about it and just want me silent - then ok, leave it as a bug
and close it. Im ok with that - not my project, i accept your [django]
independece-from-me.
But if you have to use THIS TICKET (because you lack some Trac bug =>
internal dev mapping i suppose? no criticism, just trying to make sense of
it), then do me a solid here, assign yourself to take responsibility of
the matter, THEN you can change title, type and whatever you consider
right. Thats the only way you're not completly disrespecting my efforts to
help you keep [django] code 'in sync with reality' (not meaning this as
confrontation -- simply do not know any better way to say it).
sry its been so many words, again - but... if i would understand why my
position is so difficult to understand and deal with, trust me - i would
have an easier life. but i want things to be done right, because it
matters. so i try my best. simple as that, but sometimes messy..
--
Ticket URL: <https://code.djangoproject.com/ticket/36131#comment:19>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Feb 6, 2025, 9:42:21 AM2/6/25
to django-...@googlegroups.com
#36131: URL validation redesign and modernization
-------------------------------+--------------------------------------
Reporter: Ludwig Kraatz | Owner: (none)
-------------------------------+--------------------------------------
Type: New feature | Status: closed
Component: Core (Other) | Version: dev
Severity: Normal | Resolution: wontfix
Keywords: URL Validator | Triage Stage: Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
-------------------------------+--------------------------------------
Changes (by Natalia Bidart):
Component: Core (Other) | Version: dev
Severity: Normal | Resolution: wontfix
Keywords: URL Validator | Triage Stage: Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
-------------------------------+--------------------------------------
* resolution: => wontfix
* status: assigned => closed
--
Ticket URL: <https://code.djangoproject.com/ticket/36131#comment:22>
Reply all
Reply to author
Forward
0 new messages