Hello Guiseppe,

At this point I think we can agree on why we disagree :-)

First, I believe that the function responsible for converting datetimes
stored in ISO 8601 format in SQLite databases should parse ISO 8601 and not
do anything else. I'm -1 on changing it to accept localized datetimes. (A
third-party package could provide a model field supporting this.)

So we're discussing the addition of new functionality.

Second, I'm skeptical of functions accepting a variety of more or less well
specified inputs. I don't think such APIs are conducive to good coding
practices. Either you're getting data from an automated system, in which
case the format is known. Or you're getting data from humans, in which case
Django provides one solution: forms. Indeed, when interacting when humans,
the hard part isn't validating the data, it's providing good error messages.

I know that not everyone shares this preference for strict APIs. Some
languages try hard to make sense of poorly specified inputs, for example:

$ node -e 'console.log("1" + 1);'
11
$ php -r 'echo "1" + 1;'
2
$ python -c 'print("1" + 1)'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
TypeError: must be str, not int

I don't think I need to explain my opinion after showing this example :-)

It's a reasonable analogy for the issue we're discussing here. "1" and 1
are the same input provided in a slightly different format that doesn't
make a difference for humans but does make one for computers. So are
2019-02-04 and 04/02/19. (Or is it 02/04/19?)

Anyway, if you think this is generally useful, you can easily package it
into a third-party module. Widespread adoption would be a strong argument
for integrating it into a future version of Django.

Best regards,

Aymeric.

Le lun. 4 févr. 2019 à 10:22, Giuseppe De Marco <giuseppe.dema...@unical.it>
a écrit :

> @Augustin
> Regarding your questions:
>
> - would this be useful?
> I think yes, for the following reasons:
> 1. We have an authentic regexp compiler based on DATE_FORMATS and
> DATETIME_FORMATS
> 3. We don't have to write datetime regexp anymore, this code will compile
> a regexp from a format, indipendently of its delimiter char (if -, / or
> whatever)
> 4. We get generalized function that returns datetime objects, no
> try/except and datetime.strptime, It's faster then other implementations!
> 5. It's settings.py focused, all we have to worry is a correct settings.py
> configuration. In other words We just have to collect all the possibile
> date/datetime formats that could be used in the project, even if they are
> used in forms or in model.fields
> 6. We don't need anymore to hardcode datetime regexp pattern in our code,
> the regexp compiler will work on top of date formats strings!
>
> - would a Form not be a better choice?
> Sure, I'm tring to generalize a method that could be a stop application
> for all the date and datetime approaches. It could be used for forms, in
> DATETIME_INPUT_FORMATS and DATE_INPUT_FORMAT. These could generate form
> specialized regexp compilations if this approach will be implemented.
>
> The main goal is to give a tool that will work well and in every
> conditions,and be funny too!
>
>
> Il giorno lun 4 feb 2019 alle ore 01:30 Tom Forbes <t...@tomforb.es> ha
> scritto:
>
>> I’m pretty sure 0.0241 usec per loop is either a typo or a mistake
>> during benchmarking. I’ve got no comment what you’re proposing but correct
>> and valid benchmarks are important, so I would double check that.
>>
>>
>>
>> On 3 February 2019 at 23:37:14, Giuseppe De Marco (
>> giuseppe.dema...@unical.it) wrote:
>>
>> Regarding the previous example,
>> better to read it here (my fault: I mistaken the format
>> '%Y-%m-%dT%H:%M:%S.%f'):
>>
>> https://github.com/peppelinux/Django-snippets/blob/master/datetime_heuristic_parser.py
>>
>> and also, it should came also with tzinfo regexp and other functions as
>> well, like parse_date time_duration... it's only an example to share our
>> experiences.
>>
>> --
>> 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/CABms%2BYpcU3gbv7MqV1FkwU5mt9xhTRBoPeG6bPoYCnLvTJLGAw%40mail.gmail.com
>> <https://groups.google.com/d/msgid/django-developers/CABms%2BYpcU3gbv7MqV1FkwU5mt9xhTRBoPeG6bPoYCnLvTJLGAw%40mail.gmail.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/CAFNZOJPciEjaiXO0oO-UTDCTnbgcSP3Us3D-gOdP4jvMZPGu_A%40mail.gmail.com
>> <https://groups.google.com/d/msgid/django-developers/CAFNZOJPciEjaiXO0oO-UTDCTnbgcSP3Us3D-gOdP4jvMZPGu_A%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> --
> ____________________
> Dott. Giuseppe De Marco
> CENTRO ICT DI ATENEO
> University of Calabria
> 87036 Rende (CS) - Italy
> Phone: +39 0984 496945
> e-mail: giuseppe.dema...@unical.it
>
> --
> 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/CABms%2BYrNN%3DhU4fV%2BxfAdKPR0%3DXiqGiGS2PVLxQ%3DUG2cxOdZNGw%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CABms%2BYrNN%3DhU4fV%2BxfAdKPR0%3DXiqGiGS2PVLxQ%3DUG2cxOdZNGw%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Aymeric.

-- 
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/CANE-7mUGBcyD4y4kNmEYGUioJFXR7yxpALRF2rwggq-L5GSthg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to