#19447: Intword and intabr expansion and intword_internal api exposure
----------------------------------+------------------------------------
Reporter: eire1130 | Owner: eire1130
Type: New feature | Status: new
Component: contrib.humanize | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
----------------------------------+------------------------------------
Comment (by eire1130):
This is my first real attempt at this, so I appreciate the feedback.
Specifically with respect to the points you raised:
* I don't accept the need for intword_internal. What's the use case?
The idea was to not only provide some commonly used filters, but also
allow for this situation to be easily modified. I often have to abbreviate
numbers and the treatment is not always consistent, resulting in a custom
filter. This function allows users to create custom filters with a single
line of code. True, they could call _intword, but in case something should
change, intword_internal should remain consistent.
* The implementation seems excessively complex. What you're doing is a
very simple lookup of prefixes based on the number of decimal places. Why
does this require an interable class instance, other than to prove that
you know how to use Python iterators?
Related to the above, the idea was to expose a simple API, and this
includes allowing users to provide their own iterables on an as needed
basis. I could have iterated over the list itself in the _intword
function, but my preference was and still is to decouple the Converter
class from the filter itself and allow users to create arbitrary
iterators, provided they accept the arguments setforth in the function.
* I'm not wild about intabr as a name for the new template tag. If we were
going to abbreviate at all, I'd use abbr, not abr; but I'd prefer a better
name altogether. Suggestions welcome, but inthuman and intlarge are two to
start with.
I have no issues with changing the filter name to intabbr. I would prefer
not to change to inthuman or intlarge. This is simply because of the older
filter intword and I want the naming convention to be consistent.
Please let me know of any modifications that I should take, and I will
make them as soon as possible. I look forward to hearing back from you.
--
Ticket URL: <https://code.djangoproject.com/ticket/19447#comment:3>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit https://groups.google.com/groups/opt_out.
