I'm not sure if I agree.
On the one hand I would like to say:
"I agree. For instance, if the type is `hex`, it would be really weird if
it were to be cast to an int. For `uuid`, would you expect a `UUID`
instance, or just a string?"
but alternatively, ...
"Wouldn't it be really cool if you could specify like
`<model(myapp.Blog):post>`, and it does a `get_object_or_404(myapp.Blog,
post)`, and passing the actual **instance** to the view?"
Django is really great in that it has a lot of "magic" behind the scenes
which allow you to write simple code. To me a good library is simple, but
not too simple.
Some libraries are made in order to make complicated tasks easy.
Some libraries are made in order to make repetitive tasks less repetitive.
Some libraries do both.
For instance, the Django ORM allows you to replace complicated SQL with
simple Python (although for me I still sometimes prefer the 'simplicity' of
SQL ;) ).
And Django generic views allow you to have less repetitive code for writing
forms and listings.
In this case, we have a potential to get rid of the
def my_sum_view(request, left_term, right_term):
left_term = int(left_term)
right_term = int(right_term)
extra_logic_here
and move all the casting to some "magic" place in a library, where it is
written only once instead of many times over.
As far as naming 'int' or 'integer'... Either the library does casting or
does not. I think 'int' is more obvious **once** you know Python. But
'integer' might be an *alias*, though...
Let me re-iterate: I'm not sure what will be the best approach. It really
is the trade off between a simple library having a singe responsibility, or
a more complex library allowing simpler code. In this case I'm somewhat
considering having a bit more complex library to allow a lot more simple
code.
Kind regards,
Sjoerd Job
On Thursday, September 15, 2016 at 9:27:11 AM UTC+2, Anthony King wrote:
>
> In my opinion, it should remain a string. That's the behaviour it is now,
> and it'll mean it can remain as a 3rd party package.
>
> Perhaps to show it isn't being cast, it could be renamed to "integer",
> which would avoid confusion
>
> On 15 Sep 2016 8:03 a.m., "Sjoerd Job Postmus" <sjoe...@sjec.nl
> <javascript:>> wrote:
>
>> Hi :).
>>
>> Yes, I also added the other syntax yesterday evening, so the <int:year>
>> syntax is now fully supported. (But it does not yield an int!!).
>>
>> Currently only `'int'` is registered as a valid type, with the regex
>> r'[0-9]+'. More can be registered using `django_simple_url.register('hex',
>> '[0-9a-fA-F]+')`.
>>
>> One downside (still) is that it does not get cast to an int. Although I'm
>> not really sure if I find it logical that it gets cast.
>>
>> I don't really have that much time to work on it, but I'm hoping to add
>> the `setup.py` either later today or shortly after the weekend.
>>
>> Kind regards,
>> Sjoerd Job
>>
>> On Thursday, September 15, 2016 at 8:20:03 AM UTC+2, Emil Stenström wrote:
>>>
>>> Great initiative!
>>>
>>> I really think you should use the flask syntax instead of the rails one
>>> that I first suggested. Seems this is the consensus from this thread, and
>>> that makes it more likely to get it to core one day.
>>>
>>> /Emil
>>>
>>> On Wednesday, 14 September 2016 11:02:23 UTC+2, Sjoerd Job Postmus wrote:
>>>>
>>>> Hi all,
>>>>
>>>> Since it seemed like an interesting idea to me, I started development
>>>> of a third-party plugin.
>>>>
>>>> It's currently at:
>>>> https://github.com/sjoerdjob/django-simple-url
>>>>
>>>> Since I only started today, I have no readme/setup.py yet. Will come
>>>> later this week I hope.
>>>>
>>>> Current usage is
>>>>
>>>> from django_simple_url import simple_url
>>>>
>>>> urlpatterns = [
>>>> simple_url('hello/world/', hello_world_view),
>>>> simple_url(':year/:month/', posts_for_month_view),
>>>> ]
>>>>
>>>> It works proper with includes (not adding a $ to the URL), and leaf
>>>> views (adding a $ to the URL).
>>>>
>>>> Maybe this week, or early next week I will also add support for the
>>>> '<int:year>' syntax.
>>>>
>>>> Kind regards,
>>>> Sjoerd Job
>>>>
>>>> On Tuesday, September 13, 2016 at 9:40:47 PM UTC+2, Tim Graham wrote:
>>>>>
>>>>> I would like to see if this could be done as a third-party project
>>>>> (allow "pluggable URLs" which could use any syntax). If not, then let's
>>>>> accept a patch to Django to support it. Over time, if there's some strong
>>>>> consensus about a particular third-party package, then we could bring it
>>>>> in
>>>>> to core. I think this approach is less controversial then Django adopting
>>>>> some new, untested syntax right now.
>>>>>
>>>>> On Tuesday, September 13, 2016 at 3:33:25 PM UTC-4, Emil Stenström
>>>>> wrote:
>>>>>>
>>>>>> So it looks to me that the consensus is that this IS in fact a good
>>>>>> idea, to supply a simpler, regex-free method to define URL:s.
>>>>>>
>>>>>> It also seems that the best liked version is something that's similar
>>>>>> to what flask uses: /articles/<int:year>/<int:month>/.
>>>>>>
>>>>>> I've never written a DEP before, but it sounds like a fun challenge.
>>>>>> I'll try to look at existing DEPs for a pattern and then apply that.
>>>>>>
>>>>>> Does anyone have something in particular that they would like to add
>>>>>> to the DEP? I figure I'll try to keep this first version as simple as
>>>>>> possible, while maintaining extension points for features that can be
>>>>>> added
>>>>>> later on.
>>>>>>
>>>>>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-develop...@googlegroups.com <javascript:>.
>> To post to this group, send email to django-d...@googlegroups.com
>> <javascript:>.
>> Visit this group at https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/d11376c9-8a6f-45bd-940d-bc72589bf8e4%40googlegroups.com
>>
>> <https://groups.google.com/d/msgid/django-developers/d11376c9-8a6f-45bd-940d-bc72589bf8e4%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/2984533a-22e0-4084-9b4f-172f879d0b72%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
