Extend FAQ with "How do I get Django and my JS framework to work together?"

2019-02-04 Thread Maciek Olko
I didn't find this topic being discussed before.

It seems to me to be good idea to place "How do I get Django and my JS
framework to work together?" or similar question and answer to it in FAQ in
Django's docs.

Having very big popularity of JS frameworks now it is indeed very common
question being asked or searched on the Internet. Such question for ReactJS
has 65k views on StackOverflow [1].

The answer could briefly explain that one can make use of Django backend
and produce API to be consumed by JS clients. Probably it would be good to
link to Django REST API project as a suggestion for big projects.

What do you think about such addition to FAQ?

Regards,
Maciej

[1]
https://stackoverflow.com/questions/41867055/how-to-get-django-and-reactjs-to-work-together

-- 
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/CALYYG81uHehznRBvR4obTZr8685u0nm9y7yeUykPx8j0%3DJ-GyA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Extend FAQ with "How do I get Django and my JS framework to work together?"

2019-02-04 Thread Cristiano Coelho
Pointing to Django Rest Framework should be more than enough. Anyone 
starting a project with Django and a SPA/JS architecture, will pretty much 
end up with DRF. Correct me if I'm wrong.


El lunes, 4 de febrero de 2019, 19:52:42 (UTC-5), Maciek Olko escribió:
>
> I didn't find this topic being discussed before.
>
> It seems to me to be good idea to place "How do I get Django and my JS 
> framework to work together?" or similar question and answer to it in FAQ in 
> Django's docs.
>
> Having very big popularity of JS frameworks now it is indeed very common 
> question being asked or searched on the Internet. Such question for ReactJS 
> has 65k views on StackOverflow [1]. 
>
> The answer could briefly explain that one can make use of Django backend 
> and produce API to be consumed by JS clients. Probably it would be good to 
> link to Django REST API project as a suggestion for big projects.
>
> What do you think about such addition to FAQ?
>
> Regards,
> Maciej
>
> [1] 
> https://stackoverflow.com/questions/41867055/how-to-get-django-and-reactjs-to-work-together
>

-- 
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/87fb9a35-b274-4d62-b17c-602114719ad5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Extend FAQ with "How do I get Django and my JS framework to work together?"

2019-02-04 Thread Dan Davis
I kind of disagree that saying it works with DRF is enough.  One issue that
needs to be addressed is matching any possible path with re_path, so that
an SPA that takes over the browser history API will work with bookmarks.

Django is opinionated.  The winning strategy for npm frameworks is to let
the CSS/JS/assets come from the framework.  While many projects have used
django-pipeline or django-compressor to good effect, if you use
webpack+react or angular cli, then the output can be a couple of pre-cache
busted bundles, and the solution is:
   (a) tell the javascript framework to put its output files in a
particular directory,
   (b) tell Django to look there with STATICFILES_DIRS,
   (c) Write something to generate tags for the static assets, either a
templatetag or a staticfiles finder/storage.

I think it would be good to include with Django some template tags that can
find a cache-busting bundle by the bundle name, maybe using a manifest
generated during create static.   My code isn't great, but it works like
this:

from django.templatetags.static import static
from ng_loader.utils import BundleMap


logger = logging.getLogger(__name__)

if not settings.DEBUG:
_map = BundleMap(settings.STATIC_ROOT)

register = template.Library()


@register.simple_tag
def ng_load_cssbundle(name):
if settings.DEBUG:
fname = '{}.bundle.css'.format(name)
else:
fname = _map.get_bundle('css', name)
logger.debug('Serving css bundle {} from {}'.format(name, fname))
return mark_safe(''.format(static(fname)))


@register.simple_tag
def ng_load_jsbundle(name):
if settings.DEBUG:
fname = '{}.bundle.js'.format(name)
else:
fname = _map.get_bundle('js', name)
logger.debug('Serving js bundle {} from {}'.format(name, fname))
return mark_safe(''.format(static(fname)))

With the bundle map being created like this:

import os
import re


class BundleMap(object):

def __init__(self, rootpath):
self.rootpath = rootpath
self.rebuild()

def rebuild(self):
self.map = { 'css': {}, 'js': {} }
for name in os.listdir(self.rootpath):
m = re.match(r'([a-z]+)\.[a-z0-9]+\.bundle.(js|css)', name)
if m is not None:
bname = m.group(1)
btype = m.group(2)
if btype in self.map:
self.map[btype][bname] = name

def get_bundle(self, btype, name):
return self.map[btype][name] if name in self.map[btype] else None



On Mon, Feb 4, 2019 at 9:31 PM Jason Johns  wrote:

> Tom Christie wrote this about what DRF brings to the table over plain
> Django:
>
> Django REST framework isn't required, but it helps you get a lot of things
> right that will be time consuming and error prone if you're working from
> core Django.
>  • Serializers
> The Django serializers are not really suitable for anything other than
> dumping and loading fixture data - they don't allow you to customize the
> representation in any substantial way.
> Using Django Forms for validation isn't suitable either as they're
> intended for HTML only validation and can't eg handle nested validation.
> REST frameworks serializers are designed for API usage and cover both JSON
> or form validation, as well as being able to represent as either HTML Forms
> or formats such as JSON. They also give you lots of scope for handling the
> representation of relationships, such as using hyperlinked relations.
>  • Authentication and permissions
> REST framework's authentication will gracefully handle both session based
> and token based schemes at the same time, and get the CSRF behavior right.
> You'll find that really awkward to do if using plain Django. It also helps
> ensure you're issuing failure responses that are suitable for API clients
> (eg get 401 vs 403 responses right)
> The auth, permissions and throttling are also more flexible because
> they're defined at a view level, rather than as middleware or a view
> decorator. This makes it easier to eg combine multiple schemes, or to apply
> different schemes to different parts of your application.
>  • Views
> Django's generic class based views are suitable to HTML applications. REST
> framework's generic class based views are suitable for API services.
> Typicallly API views have slightly different behavior by convention. Eg
> create in an HTML application might typically redirect the user to the
> created item, whereas an API will respond with a 201 CREATED response.
> There's stacks of other functionality and behavior that makes using Django
> REST framework simpler, quicker and likely more correct than if you start
> with plain Django. But those are some of the obvious differences to get
> started with.
>
> https://reddit.com/r/django/comments/3h9oj8/_/cu5pzu9/?context=1
>
> Seems pretty concise and self explanatory to me. This could easily be
> adapted to be in the docs.
>
> --
> You received this message because you are subscribed to the 

Re: Extend FAQ with "How do I get Django and my JS framework to work together?"

2019-02-04 Thread Jason Johns
Tom Christie wrote this about what DRF brings to the table over plain Django:

Django REST framework isn't required, but it helps you get a lot of things 
right that will be time consuming and error prone if you're working from core 
Django.
 • Serializers
The Django serializers are not really suitable for anything other than dumping 
and loading fixture data - they don't allow you to customize the representation 
in any substantial way.
Using Django Forms for validation isn't suitable either as they're intended for 
HTML only validation and can't eg handle nested validation.
REST frameworks serializers are designed for API usage and cover both JSON or 
form validation, as well as being able to represent as either HTML Forms or 
formats such as JSON. They also give you lots of scope for handling the 
representation of relationships, such as using hyperlinked relations.
 • Authentication and permissions
REST framework's authentication will gracefully handle both session based and 
token based schemes at the same time, and get the CSRF behavior right. You'll 
find that really awkward to do if using plain Django. It also helps ensure 
you're issuing failure responses that are suitable for API clients (eg get 401 
vs 403 responses right)
The auth, permissions and throttling are also more flexible because they're 
defined at a view level, rather than as middleware or a view decorator. This 
makes it easier to eg combine multiple schemes, or to apply different schemes 
to different parts of your application.
 • Views
Django's generic class based views are suitable to HTML applications. REST 
framework's generic class based views are suitable for API services. Typicallly 
API views have slightly different behavior by convention. Eg create in an HTML 
application might typically redirect the user to the created item, whereas an 
API will respond with a 201 CREATED response.
There's stacks of other functionality and behavior that makes using Django REST 
framework simpler, quicker and likely more correct than if you start with plain 
Django. But those are some of the obvious differences to get started with.

https://reddit.com/r/django/comments/3h9oj8/_/cu5pzu9/?context=1

Seems pretty concise and self explanatory to me. This could easily be adapted 
to be in the docs.

-- 
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/af24d69f-1d16-40db-9558-11745fce2399%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Extend FAQ with "How do I get Django and my JS framework to work together?"

2019-02-04 Thread Curtis Maloney

On 2/5/19 11:52 AM, Maciek Olko wrote:

I didn't find this topic being discussed before.



I guess it wouldn't take much to say "Just like any other server-side 
framework that can parse and generate arbitrary content, Django can be 
used to support any Javascript or Mobile app that talks HTTP(S)."


Since Django doesn't care what the client is, so long as it talks HTTP...

--
Curtis

--
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/bde91f87-1afe-2f15-4b0b-8e37fd5780dd%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.


Re: Extend FAQ with "How do I get Django and my JS framework to work together?"

2019-02-04 Thread Kye Russell
Say what you want about the arguably unnecessary proliferation of complex
JavaScript applications / build pipelines upon the Internet over the past 5
or so years, but there’s no denying it’s becoming a necessary component in
a large portion of complex web projects.

I also think that—if it hasn’t already been done so already—the Django
documentation should at least contain a passing acknowledgement of this, as
well as some guidance on how to accomplish this.

Compare this to the latest iteration of Rails (I’ve never done more than
take a passing glance at the framework’s progress and am certainly no
expert) which includes a full webpack JS / asset pipeline as standard. I’m
aware of the philosophical differences between Django and Rails, and I’m
not necessary saying that bolting on Webpack was the right decision, but
it’s certainly speaks to how ‘back end’ framework development could lend a
helping hand beginners with a project that lends itself to a JS /
API-driven approach.

Kye


On 5 February 2019 at 8:52:38 am, Maciek Olko (maciej.o...@gmail.com) wrote:

I didn't find this topic being discussed before.

It seems to me to be good idea to place "How do I get Django and my JS
framework to work together?" or similar question and answer to it in FAQ in
Django's docs.

Having very big popularity of JS frameworks now it is indeed very common
question being asked or searched on the Internet. Such question for ReactJS
has 65k views on StackOverflow [1].

The answer could briefly explain that one can make use of Django backend
and produce API to be consumed by JS clients. Probably it would be good to
link to Django REST API project as a suggestion for big projects.

What do you think about such addition to FAQ?

Regards,
Maciej

[1]
https://stackoverflow.com/questions/41867055/how-to-get-django-and-reactjs-to-work-together
--
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/CALYYG81uHehznRBvR4obTZr8685u0nm9y7yeUykPx8j0%3DJ-GyA%40mail.gmail.com

.
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/CANK-yk%3DOWqmfCfSLOVKBxZJz2zxvJr74DFqUUkRac7w9yvr4%2Bg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Extend FAQ with "How do I get Django and my JS framework to work together?"

2019-02-04 Thread Curtis Maloney

On 2/5/19 1:09 PM, Cristiano Coelho wrote:
Pointing to Django Rest Framework should be more than enough. Anyone 
starting a project with Django and a SPA/JS architecture, will pretty 
much end up with DRF. Correct me if I'm wrong.


It's likely they'd end up with DRF, however there are alternatives.

However, by explicitly listing DRF, it might give the impression it's 
the "blessed" solution by Django...


--
Curtis

--
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/77e1f7b8-d5c7-31a9-4e8d-55fc094cc968%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.


Re: App static files (#29586)

2019-02-04 Thread Claude Paroz
Hi Carlton,

I'm currently in "pause mode" for Django master. I didn't receive any input 
until now with my proposal.
I think Django would benefit of such a development, not necessarily with my 
suggested approach, but something similar.
As for GSoC, it's difficult to say. I'm always concerned by the 
"single-person" nature of GSoCs, especially when the development direction 
is not clear like here.

Claude

Le lundi 4 février 2019 10:47:29 UTC+1, Carlton Gibson a écrit :
>
> Hi Claude. 
>
> Is this something you're still interested in? 
>
> Do you think it might make a good GSoC project? 
>
> C.
>
> On Monday, 23 July 2018 17:36:05 UTC+2, Claude Paroz wrote:
>>
>> Hi, 
>>
>> I just created a new feature request [1] to be able to define static 
>> files per application, including a POC patch [2]. 
>>
>> [1] https://code.djangoproject.com/ticket/29586 
>> [2] https://github.com/django/django/pull/10218 
>>
>> Feel free to discuss it here for general discussion on the feature 
>> utility, or comment on the ticket or on the pull request for 
>> implementation details. 
>>
>> Cheers, 
>>
>> Claude 
>> -- 
>> www.2xlibre.net 
>>
>

-- 
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/541da3b4-c65a-4d06-bad0-7bf74cc9e444%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: django.utils.dateparse

2019-02-04 Thread Tom Forbes
For me, I get:

In [4]: %timeit  datetime_heuristic_parser('2019-02-03T17:27:58.645194')
18.9 µs ± 431 ns per loop (mean ± std. dev. of 7 runs, 10 loops each)

And for Django:

In [3]: %timeit parse_datetime('2019-02-03T17:27:58.645194')
6.97 µs ± 408 ns per loop (mean ± std. dev. of 7 runs, 10 loops each)

I assume there is something wrong with the way you benchmarked the code.
Python is not *that* slow, but 0.0241 per loop is way, way too fast.



On 4 February 2019 at 09:22:03, Giuseppe De Marco (
giuseppe.dema...@unical.it) wrote:

Hello everyone, first of all I am grateful for your time and your attention.

@Tom Forbes
The first time I runned it I thought the same thing! Please use
https://github.com/peppelinux/Django-snippets/blob/master/datetime_heuristic_parser.py
and not the previous pasted one. I'm quite sure that all the tests passes
well, because of their output. As we can see I deal with a tuple that
contains ('format', 'compiled_regexp', 'values dictionary'), this obviously
just for test purpose.

Parsing succesfull on "04/12/2018":
[('%d/%m/%Y', '(?P\\d{1,2})/(?P\\d{1,2})/(?P\\d{4})$',
{'year': 2018, 'month': 12, 'day': 4})]

Parsing succesfull on "04/12/2018 3:2:1":
[('%d/%m/%Y %H:%M:%S',
'(?P\\d{1,2})/(?P\\d{1,2})/(?P\\d{4})
(?P\\d{1,2}):(?P\\d{1,2}):(?P\\d{1,2})$', {'second':
1, 'year': 2018, 'minute': 2, 'month': 12, 'hour': 3, 'day': 4})]

Parsing succesfull on "2018-03-4 09:7:4":
[('%Y-%m-%d %H:%M:%S',
'(?P\\d{4})-(?P\\d{1,2})-(?P\\d{1,2})
(?P\\d{1,2}):(?P\\d{1,2}):(?P\\d{1,2})$', {'second':
4, 'year': 2018, 'minute': 7, 'month': 3, 'hour': 9, 'day': 4})]

Parsing succesfull on "2018-03-04T09:7:4.645194":
[('%Y-%m-%dT%H:%M:%S.%f',
'(?P\\d{4})-(?P\\d{1,2})-(?P\\d{1,2})T(?P\\d{1,2}):(?P\\d{1,2}):(?P\\d{1,2}).(?P\\d{6})$',
{'second': 4, 'year': 2018, 'minute': 7, 'month': 3, 'microsecond': 645194,
'hour': 9, 'day': 4})]

Parsing succesfull on "20180304121940.948000Z":
[('%Y%m%d%H%M%S.%fZ',
'(?P\\d{4})(?P\\d{1,2})(?P\\d{1,2})(?P\\d{1,2})(?P\\d{1,2})(?P\\d{1,2}).(?P\\d{6})Z$',
{'second': 40, 'year': 2018, 'minute': 19, 'month': 3, 'microsecond':
948000, 'hour': 12, 'day': 4})]

Yesterday I coded it on a tablet, this morning from my laptop I got this
performance:
python -m timeit -s "from datetime_heuristic_parser import
datetime_heuristic_parser;
datetime_heuristic_parser('2019-02-03T17:27:58.645194')"
1 loops, best of 3: 0.00891 usec per loop

I also added a simple raise Exception in the case it should return an
error, thank you for your suggestion.

@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  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 

Help needed on Django-Guardian.

2019-02-04 Thread Aleksi Häkli
We have had good success in project maintenance with the Jazzband organization 
which collaboratively tends to a number of Django projects. I think that the 
crowd of maintainers could help in the Guardian project infrastructure and take 
care of things like versioning, allowing better focus for issues related to 
functionality.

https://github.com/jazzband

-- 
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/1f716662-96d8-479a-99b9-17b35bb21591%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Google Summer of Code 2019

2019-02-04 Thread Tim Graham
All answers are at 
https://github.com/django/django-team-wiki/wiki/Google-Summer-of-Code-Application-Info

On Monday, February 4, 2019 at 4:19:06 AM UTC-5, Carlton Gibson wrote:
>
> Hey Tim. 
>
> > For each year your organization has participated, provide the counts of 
> successful and total students. (e.g. 2016: 3/4)
>
> I have no idea about this, could you advise? 
>
> Thanks. 
>
>

-- 
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/1d12a3c5-a7be-4df1-bc12-6fb7292d5517%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Help needed on Django-Guardian.

2019-02-04 Thread sibasish mohanty
Hi,
I will go through the code base and try to contribute.
Thanks
Sibasish


On Mon, 4 Feb 2019, 2:31 a.m. Carlton Gibson  Hi all.
>
> Adam Dobrawy who runs Django-Guardian, could do with some help maintaining
> there.
>
> The project seems to be in good shape. (It's up to date) But needs a bit
> of help keeping on top of the issues, dropping old-versions, and the rest
> of it.
>
> I see the project has some regular contributors. If you're one of them, do
> you have a small amount extra to help with the maintenance?
>
> If you're not a contributor but use it, would you be able to lend a hand?
>
> As ever, first step if hanging out on the repo and helping with any
> incoming.
>
> https://github.com/django-guardian/django-guardian
>
> Thanks.
>
> Kind Regards,
>
> Carlton
>
> --
> 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/a33b0fcd-61eb-410f-b30b-37a6234e82db%40googlegroups.com
> 
> .
> 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/CAPtOTEqO0GTaOm3ciMVPgw%2BKiBsnVv3By1OZpDJ6nmDK-mhCLA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Help needed on Django-Guardian.

2019-02-04 Thread Carlton Gibson
Excellent. 

The place to follow up is on the Guardian repo. (Make PRs that close issues!)

I’m sure from there you can work out with Adam the best way forward (be that as 
a collaboration or Jazzband or ...). 

Here I’m just passing on the need for help. Thanks for the positive response 
all! 

Sent from my iPhone

> On 5 Feb 2019, at 07:21, Asif Saif Uddin  wrote:
> 
> Hi Carlton,
> 
> If needed I could be a collaborator of that. I get some monthly payment for 
> my open source python works :)
> 
>> On Monday, February 4, 2019 at 3:01:38 AM UTC+6, Carlton Gibson wrote:
>> Hi all. 
>> 
>> Adam Dobrawy who runs Django-Guardian, could do with some help maintaining 
>> there. 
>> 
>> The project seems to be in good shape. (It's up to date) But needs a bit of 
>> help keeping on top of the issues, dropping old-versions, and the rest of 
>> it. 
>> 
>> I see the project has some regular contributors. If you're one of them, do 
>> you have a small amount extra to help with the maintenance?
>> 
>> If you're not a contributor but use it, would you be able to lend a hand? 
>> 
>> As ever, first step if hanging out on the repo and helping with any incoming.
>> 
>> https://github.com/django-guardian/django-guardian
>> 
>> Thanks. 
>> 
>> Kind Regards,
>> 
>> Carlton
>> 
> 
> -- 
> 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/fdb10e33-ab6a-466b-b209-4cbed1bdc7df%40googlegroups.com.
> 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/94D0F687-0649-495B-B661-6300804F9898%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Help needed on Django-Guardian.

2019-02-04 Thread Asif Saif Uddin
Hi Carlton,

If needed I could be a collaborator of that. I get some monthly payment for 
my open source python works :)

On Monday, February 4, 2019 at 3:01:38 AM UTC+6, Carlton Gibson wrote:
>
> Hi all. 
>
> Adam Dobrawy who runs Django-Guardian, could do with some help maintaining 
> there. 
>
> The project seems to be in good shape. (It's up to date) But needs a bit 
> of help keeping on top of the issues, dropping old-versions, and the rest 
> of it. 
>
> I see the project has some regular contributors. If you're one of them, do 
> you have a small amount extra to help with the maintenance?
>
> If you're not a contributor but use it, would you be able to lend a hand? 
>
> As ever, first step if hanging out on the repo and helping with any 
> incoming.
>
> https://github.com/django-guardian/django-guardian
>
> Thanks. 
>
> Kind Regards,
>
> Carlton
>
>

-- 
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/fdb10e33-ab6a-466b-b209-4cbed1bdc7df%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Extend FAQ with "How do I get Django and my JS framework to work together?"

2019-02-04 Thread ludovic coues
My current job is working on the django backend of a SPA/JS. Truth is, our
django does not serve any JS file. The whole SPA is a bunch of static
files, served by nginx. Every and only request with a path starting with
/api are routed to Django.

On Tue, Feb 5, 2019, 04:16 Curtis Maloney  On 2/5/19 1:09 PM, Cristiano Coelho wrote:
> > Pointing to Django Rest Framework should be more than enough. Anyone
> > starting a project with Django and a SPA/JS architecture, will pretty
> > much end up with DRF. Correct me if I'm wrong.
>
> It's likely they'd end up with DRF, however there are alternatives.
>
> However, by explicitly listing DRF, it might give the impression it's
> the "blessed" solution by Django...
>
> --
> Curtis
>
> --
> 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/77e1f7b8-d5c7-31a9-4e8d-55fc094cc968%40tinbrain.net
> .
> 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/CAEuG%2BTbJU51NE0n2u%3DopdisOANM%3Dp%3Dn-h%3DvdABdzrzUj7F4a7A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Fellow Reports -- January 2019

2019-02-04 Thread Carlton Gibson
Hi all. 


Calendar Week 5 -- ending 03 February.


Triaged:

https://code.djangoproject.com/ticket/30144 -- Support passing timedelta 
for cache timeout (wontfix)
https://code.djangoproject.com/ticket/30139 -- 
django.contrib.auth.forms.UserCreationForm() doesnt call default 
managers create_user() (Invalid)



Reviewed:

https://code.djangoproject.com/ticket/30004 -- Set default 
FILE_UPLOAD_PERMISSION to 0o644
https://github.com/django/django/pull/10908 -- Update to logging 
documentation.
https://code.djangoproject.com/ticket/29943 -- Document that admin 
changelist adds `pk` to ordering
https://github.com/django/django/pull/0913 -- Fixed E117 and F405 flake8 
warnings.
https://code.djangoproject.com/ticket/28905 -- Overhaul extra_requires to 
include more optional dependencies
https://code.djangoproject.com/ticket/29825 -- ngettext returns invalid 
result if msgstr is also a valid msgid in the same catalog
https://github.com/django/django/pull/10832 -- Remove naturaltime 
context for (delta) ago for Swedish.



Authored:

https://github.com/django/django/pull/10882 -- Fixed #30091 -- Documented 
middleware ordering requirements when using CSRF_USE_SESSIONS.


Kind Regards,

Carlton

-- 
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/821dddea-60ba-44a2-9891-96a56c93720c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: django.utils.dateparse

2019-02-04 Thread Giuseppe De Marco
I also added tzinfo as it come from parse_date, I just copy some code and
make get_fixed_timezone as a FixedTimeZone classmethod.
Regarding our doubts about benchmarks, you'll always find them commented in
the top of the file, I hope to make them as many immediate as possible to
avoid waste of time.
https://github.com/peppelinux/Django-snippets/blob/master/datetime_heuristic_parser.py

this is what I get at this moment:
python3 -m timeit -s "import datetime"
"datetime.datetime.strptime('2019-02-03T17:27:58.645194',
'%Y-%m-%dT%H:%M:%S.%f')"
10 loops, best of 3: 11.2 usec per loop

python3 -m timeit -s "from django.utils.dateparse import parse_datetime"
"parse_datetime('2019-02-03T17:27:58.645194')"
10 loops, best of 3: 6.04 usec per loop

python3 -m timeit -s   "import sys, os; sys.path.append(os.getcwd()); from
datetime_heuristic_parser import datetime_heuristic_parser;
print(datetime_heuristic_parser('04/12/2018 09:7:4Z'))"
[datetime.datetime(2018, 12, 4, 9, 7, 4, tzinfo=datetime.timezone.utc)]
[datetime.datetime(2018, 12, 4, 9, 7, 4, tzinfo=datetime.timezone.utc)]
[datetime.datetime(2018, 12, 4, 9, 7, 4, tzinfo=datetime.timezone.utc)]
[datetime.datetime(2018, 12, 4, 9, 7, 4, tzinfo=datetime.timezone.utc)]
[datetime.datetime(2018, 12, 4, 9, 7, 4, tzinfo=datetime.timezone.utc)]
[datetime.datetime(2018, 12, 4, 9, 7, 4, tzinfo=datetime.timezone.utc)]
[datetime.datetime(2018, 12, 4, 9, 7, 4, tzinfo=datetime.timezone.utc)]
[datetime.datetime(2018, 12, 4, 9, 7, 4, tzinfo=datetime.timezone.utc)]
[datetime.datetime(2018, 12, 4, 9, 7, 4, tzinfo=datetime.timezone.utc)]
[datetime.datetime(2018, 12, 4, 9, 7, 4, tzinfo=datetime.timezone.utc)]
[datetime.datetime(2018, 12, 4, 9, 7, 4, tzinfo=datetime.timezone.utc)]
1 loops, best of 3: 0.00878 usec per loop

...as long I'm running it I still can see a good result as a returned and
valid datetime, no exception.
I'll continue to use this code so I'll take care to keep an eye on it, I
also hope to share this with you.

Il giorno lun 4 feb 2019 alle ore 11:07 Tom Forbes  ha
scritto:

> For me, I get:
>
> In [4]: %timeit  datetime_heuristic_parser('2019-02-03T17:27:58.645194')
> 18.9 µs ± 431 ns per loop (mean ± std. dev. of 7 runs, 10 loops each)
>
> And for Django:
>
> In [3]: %timeit parse_datetime('2019-02-03T17:27:58.645194')
> 6.97 µs ± 408 ns per loop (mean ± std. dev. of 7 runs, 10 loops each)
>
> I assume there is something wrong with the way you benchmarked the code.
> Python is not *that* slow, but 0.0241 per loop is way, way too fast.
>
>
>
> On 4 February 2019 at 09:22:03, Giuseppe De Marco (
> giuseppe.dema...@unical.it) wrote:
>
> Hello everyone, first of all I am grateful for your time and your
> attention.
>
> @Tom Forbes
> The first time I runned it I thought the same thing! Please use
> https://github.com/peppelinux/Django-snippets/blob/master/datetime_heuristic_parser.py
> and not the previous pasted one. I'm quite sure that all the tests passes
> well, because of their output. As we can see I deal with a tuple that
> contains ('format', 'compiled_regexp', 'values dictionary'), this obviously
> just for test purpose.
>
> Parsing succesfull on "04/12/2018":
> [('%d/%m/%Y', '(?P\\d{1,2})/(?P\\d{1,2})/(?P\\d{4})$',
> {'year': 2018, 'month': 12, 'day': 4})]
>
> Parsing succesfull on "04/12/2018 3:2:1":
> [('%d/%m/%Y %H:%M:%S',
> '(?P\\d{1,2})/(?P\\d{1,2})/(?P\\d{4})
> (?P\\d{1,2}):(?P\\d{1,2}):(?P\\d{1,2})$', {'second':
> 1, 'year': 2018, 'minute': 2, 'month': 12, 'hour': 3, 'day': 4})]
>
> Parsing succesfull on "2018-03-4 09:7:4":
> [('%Y-%m-%d %H:%M:%S',
> '(?P\\d{4})-(?P\\d{1,2})-(?P\\d{1,2})
> (?P\\d{1,2}):(?P\\d{1,2}):(?P\\d{1,2})$', {'second':
> 4, 'year': 2018, 'minute': 7, 'month': 3, 'hour': 9, 'day': 4})]
>
> Parsing succesfull on "2018-03-04T09:7:4.645194":
> [('%Y-%m-%dT%H:%M:%S.%f',
> '(?P\\d{4})-(?P\\d{1,2})-(?P\\d{1,2})T(?P\\d{1,2}):(?P\\d{1,2}):(?P\\d{1,2}).(?P\\d{6})$',
> {'second': 4, 'year': 2018, 'minute': 7, 'month': 3, 'microsecond': 645194,
> 'hour': 9, 'day': 4})]
>
> Parsing succesfull on "20180304121940.948000Z":
> [('%Y%m%d%H%M%S.%fZ',
> '(?P\\d{4})(?P\\d{1,2})(?P\\d{1,2})(?P\\d{1,2})(?P\\d{1,2})(?P\\d{1,2}).(?P\\d{6})Z$',
> {'second': 40, 'year': 2018, 'minute': 19, 'month': 3, 'microsecond':
> 948000, 'hour': 12, 'day': 4})]
>
> Yesterday I coded it on a tablet, this morning from my laptop I got this
> performance:
> python -m timeit -s "from datetime_heuristic_parser import
> datetime_heuristic_parser;
> datetime_heuristic_parser('2019-02-03T17:27:58.645194')"
> 1 loops, best of 3: 0.00891 usec per loop
>
> I also added a simple raise Exception in the case it should return an
> error, thank you for your suggestion.
>
> @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 

Re: django.utils.dateparse

2019-02-04 Thread Giuseppe De Marco
Thank you Andreas, finally I can see a real benchmark on my laptop:

python3 -m timeit -s "from django.utils.dateparse import parse_datetime"
"print(parse_datetime('2018-04-01 09:07:04'))"
10 loops, best of 3: 11.1 usec per loop

python3 -m timeit -s "import datetime"
"print(datetime.datetime.strptime('2019-02-03T17:27:58.645194',
'%Y-%m-%dT%H:%M:%S.%f'))"
10 loops, best of 3: 18 usec per loop

python3 -m timeit -s   "import sys, os; sys.path.append(os.getcwd()); from
datetime_heuristic_parser import datetime_heuristic_parser"
"print(datetime_heuristic_parser('04/12/2018 09:7:4'))"
1 loops, best of 3: 25.4 usec per loop





Il giorno lun 4 feb 2019 alle ore 15:18 Andreas Pelme  ha
scritto:

> On 4 Feb 2019, at 15:04, Giuseppe De Marco 
> wrote:
>
>
> python3 -m timeit -s   "import sys, os; sys.path.append(os.getcwd()); from
> datetime_heuristic_parser import datetime_heuristic_parser;
> print(datetime_heuristic_parser('04/12/2018 09:7:4Z'))"
>
>
> That command is not correct. timeit -s takes two arguments: setup code and
> benchmark code. This command just executes the setup code and does not run
> any code at all for the actual benchmark.
>
> The correct command would be something like this (I did not run this
> command myself but you get the idea):
> python3 -m timeit -s   "import sys, os; sys.path.append(os.getcwd()); from
> datetime_heuristic_parser import datetime_heuristic_parser”
> "datetime_heuristic_parser('04/12/2018 09:7:4Z’)"
>
> Cheers,
> Andreas
>
> --
> 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/0DCE461D-F01F-48C6-B5DD-CBCEFE2895FC%40pelme.se
> 
> .
> 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%2BYrSBwzpS38yf_tinGfPDnrBr8cF6VM396%3DEO9ALXCpwaA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Google Summer of Code 2019

2019-02-04 Thread Giuseppe De Marco
Hi Tim,

It returns 404 to me
https://github.com/django/django-team-wiki/wiki/Google-Summer-of-Code-Application-Info

Il giorno lun 4 feb 2019 alle ore 13:05 Tim Graham 
ha scritto:

> All answers are at
> https://github.com/django/django-team-wiki/wiki/Google-Summer-of-Code-Application-Info
>

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


Re: django.utils.dateparse

2019-02-04 Thread Andreas Pelme
On 4 Feb 2019, at 15:04, Giuseppe De Marco  wrote:
> 
> python3 -m timeit -s   "import sys, os; sys.path.append(os.getcwd()); from 
> datetime_heuristic_parser import datetime_heuristic_parser; 
> print(datetime_heuristic_parser('04/12/2018 09:7:4Z'))"


That command is not correct. timeit -s takes two arguments: setup code and 
benchmark code. This command just executes the setup code and does not run any 
code at all for the actual benchmark.

The correct command would be something like this (I did not run this command 
myself but you get the idea):
python3 -m timeit -s   "import sys, os; sys.path.append(os.getcwd()); from 
datetime_heuristic_parser import datetime_heuristic_parser” 
"datetime_heuristic_parser('04/12/2018 09:7:4Z’)"

Cheers,
Andreas

-- 
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/0DCE461D-F01F-48C6-B5DD-CBCEFE2895FC%40pelme.se.
For more options, visit https://groups.google.com/d/optout.


Re: Google Summer of Code 2019

2019-02-04 Thread Tim Graham
It's a private wiki that only Django team members like Carlton can access. 
It contains the information for Django to apply for GSoC.

On Monday, February 4, 2019 at 9:07:40 AM UTC-5, Giuseppe De Marco wrote:
>
> Hi Tim,
>
> It returns 404 to me
>
> https://github.com/django/django-team-wiki/wiki/Google-Summer-of-Code-Application-Info
>
> Il giorno lun 4 feb 2019 alle ore 13:05 Tim Graham  > ha scritto:
>
>> All answers are at 
>> https://github.com/django/django-team-wiki/wiki/Google-Summer-of-Code-Application-Info
>>
>

-- 
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/2e76e237-d0ce-4236-825c-33d58a0d145a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Google Summer of Code 2019

2019-02-04 Thread Carlton Gibson
And thank you Tim, yes, exactly what I need. 

To all: 

I will put in the org application today. We'll then see about the 
proposals. 

The main thing is that we need to know who you are, and have confidence in 
you in order to commit to the project with you. 
For people to mentor you is a big commitment of time and energy. You need 
to demonstrate that will be well invested. 

The way to do that is to get involved and show us who you are over the next 
few months. 
Help reproduce bugs, review patches, create patches etc. 
It doesn't take much before you're visible. (Really!) 

The best way (also) to come up with project ideas is to see where there are 
issues already. 
(Much better than us providing a list.) So again, be involved. 

If you start now, there's still lots of time, so I'm hoping. 

Kind Regards,

Carlton





On Monday, 4 February 2019 15:43:39 UTC+1, Tim Graham wrote:
>
> It's a private wiki that only Django team members like Carlton can access. 
> It contains the information for Django to apply for GSoC.
>
> On Monday, February 4, 2019 at 9:07:40 AM UTC-5, Giuseppe De Marco wrote:
>>
>> Hi Tim,
>>
>> It returns 404 to me
>>
>> https://github.com/django/django-team-wiki/wiki/Google-Summer-of-Code-Application-Info
>>
>> Il giorno lun 4 feb 2019 alle ore 13:05 Tim Graham  
>> ha scritto:
>>
>>> All answers are at 
>>> https://github.com/django/django-team-wiki/wiki/Google-Summer-of-Code-Application-Info
>>>
>>

-- 
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/5e410c5e-deb7-4dfe-9f61-0599a1bf80e2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: django.utils.dateparse

2019-02-04 Thread Giuseppe De Marco
Hi Augustin, my name Is Giuseppe, i before u :)

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

Great!


> 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.)
>

+1 when you know the format All this code Is useless.

 Should parse_date be renamed to parse_date_iso8601?


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.
>

I was wondering to a utility used to parse the dt format configured in
setting.py. It's not mandatory to use this utility.

>

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

I Hope that this idea Will not Be murdered by those example :)

So are 2019-02-04 and 04/02/19. (Or is it 02/04/19?)
>

It Will depend by settings.py, that's the goal

>

> Anyway, if you think this is generally useful, you can easily package it
> into a third-party module.
>

Consider It done, I thougth on a wider featureset in Django.utils.dateparse


>>>
>>
>> --
>> 
>> 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
>> 
>> .
>> 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.
>

-- 
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%2BYpPo_mcBKokFV9Q4%2BGnvHZPJktG%3DykM%3D0-7F7xQv3KgOA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: django.utils.dateparse

2019-02-04 Thread Aymeric Augustin
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 "", line 1, in 
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 
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  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
>> 
>> .
>> 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 

Re: Google Summer of Code 2019

2019-02-04 Thread Carlton Gibson
Hey Parth, 

Yes, you're right: 

> Students can register and submit their applications to mentor 
organizations. All proposals must be submitted by April 9, 2019 20:00 
(CEST).

There's time. I was thinking tomorrow was the full proposal deadline. 
(That's my lack of familiarity with it.) 

I will fill do the the Organisation application today. The programme seems 
a good opportunity. 

Kind Regards,

Carlton



On Monday, 4 February 2019 09:40:32 UTC+1, PARTH PATIL wrote:
>
>
>
> Hey, I am really enthusiastic for doing GSoC with Django, I had been 
> working for a few months to get myself familiar with the code base. I have 
> quite a few unpolished ideas in my mind for projects like the one posted 
> here 
> 
> .
>
> Though I'm unable to understand why Django is not ready to participate in 
> GSoC this year?
>
> Also, I would like to point out what *Carlton* said in his post 
> 
> .
>
>- I don't think it is justified to expect mind-blowing project 
>proposal this early. As per the GSoC's timeline, the application deadline 
>is April 9 which is like two months for now.
>- Even the discussions of ideas according to Google begins from 20 
>days from now.
>- There is also no ideas page for Django for 2019, to which students 
>can refer.
>- More importantly, as a student, I think many students will be 
>genuinely interested to take up a few good projects with Django.
>
>
>
> On Monday, February 4, 2019 at 2:41:11 AM UTC+5:30, Carlton Gibson wrote:
>>
>> Yes. GSoC wasn't at all on my radar before your post here Tim. 
>>
>> We've had a few "hello" posts but no even semi-concrete proposals from 
>> students. (Equally we don't have a list ready to go.) 
>>
>> I had a look at the process. It seems a moderate commitment, so, for me, 
>> I think I'd want to be familiar with applicants before we took that on. 
>> i.e. We need say to students to get involved months before. 
>> I'll think about messaging for that for next year because GSoC seems good 
>> overall. 
>>
>> SO unless someone is going to blow us away with an outline of a proposal 
>> TOMORROW, we'll have to pass this year. (Deadline being Tuesday.)
>>
>> On Friday, 1 February 2019 22:32:43 UTC+1, Tim Graham wrote:
>>>
>>> As of now, I haven't seen any existing Django contributors who are 
>>> planning to propose a project, therefore I don't think it's worthwhile for 
>>> the DSF to apply for this summer. The decision to apply on behalf of the 
>>> DSF is up to Carlton, Mariusz, or another potential mentor.
>>>
>>> On Thursday, January 31, 2019 at 6:24:36 AM UTC-5, gaurav jain wrote:

 One Idea i have a one command django project maker to instead having 
 1+n commands(n number of apps) and linking them in setting we can have 
 command take the number of apps and app_names in ine do and then later we 
 can add functionality for heroku ,docker etc

 On Wednesday, January 16, 2019 at 8:03:55 PM UTC+5:30, Tim Graham wrote:
>
> Org applications for Google's Summer of Code are now open (deadline 
> February 6). Do you think the Django Software Foundation should 
> participate?
>
> We haven't had any high quality student applications that we could 
> accept for the past two years.
>
> Perhaps it's partly a function of a poor ideas page (
> https://code.djangoproject.com/wiki/SummerOfCode2018). Perhaps we 
> don't do a great job of publicizing our involvement and attracting high 
> quality students. Perhaps it's because the student payment isn't all that 
> much (+/-$6000 USD, depending on student's country)* for the amount of 
> work 
> involved (also, students have to put in a lot of work up front in their 
> application, with no guarantee of being accepted into the program).
>
> If you have any ideas about mentoring or suggesting a project, or if 
> you're serious about being a student (you should start contributing to 
> Django now if you don't already), please share.
>
> * https://developers.google.com/open-source/gsoc/help/student-stipends
>


-- 
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/f8a1ff9d-c5d6-48b6-b181-20ee4b68bb5f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Google Summer of Code 2019

2019-02-04 Thread PARTH PATIL



Hey, I am really enthusiastic for doing GSoC with Django, I had been 
working for a few months to get myself familiar with the code base. I have 
quite a few unpolished ideas in my mind for projects like the one posted 
here 

.

Though I'm unable to understand why Django is not ready to participate in 
GSoC this year?

Also, I would like to point out what *Carlton* said in his post 

.

   - I don't think it is justified to expect mind-blowing project proposal 
   this early. As per the GSoC's timeline, the application deadline is April 9 
   which is like two months for now.
   - Even the discussions of ideas according to Google begins from 20 days 
   from now.
   - There is also no ideas page for Django for 2019, to which students can 
   refer.
   - More importantly, as a student, I think many students will be 
   genuinely interested to take up a few good projects with Django.



On Monday, February 4, 2019 at 2:41:11 AM UTC+5:30, Carlton Gibson wrote:
>
> Yes. GSoC wasn't at all on my radar before your post here Tim. 
>
> We've had a few "hello" posts but no even semi-concrete proposals from 
> students. (Equally we don't have a list ready to go.) 
>
> I had a look at the process. It seems a moderate commitment, so, for me, I 
> think I'd want to be familiar with applicants before we took that on. i.e. 
> We need say to students to get involved months before. 
> I'll think about messaging for that for next year because GSoC seems good 
> overall. 
>
> SO unless someone is going to blow us away with an outline of a proposal 
> TOMORROW, we'll have to pass this year. (Deadline being Tuesday.)
>
> On Friday, 1 February 2019 22:32:43 UTC+1, Tim Graham wrote:
>>
>> As of now, I haven't seen any existing Django contributors who are 
>> planning to propose a project, therefore I don't think it's worthwhile for 
>> the DSF to apply for this summer. The decision to apply on behalf of the 
>> DSF is up to Carlton, Mariusz, or another potential mentor.
>>
>> On Thursday, January 31, 2019 at 6:24:36 AM UTC-5, gaurav jain wrote:
>>>
>>> One Idea i have a one command django project maker to instead having 1+n 
>>> commands(n number of apps) and linking them in setting we can have command 
>>> take the number of apps and app_names in ine do and then later we can add 
>>> functionality for heroku ,docker etc
>>>
>>> On Wednesday, January 16, 2019 at 8:03:55 PM UTC+5:30, Tim Graham wrote:

 Org applications for Google's Summer of Code are now open (deadline 
 February 6). Do you think the Django Software Foundation should 
 participate?

 We haven't had any high quality student applications that we could 
 accept for the past two years.

 Perhaps it's partly a function of a poor ideas page (
 https://code.djangoproject.com/wiki/SummerOfCode2018). Perhaps we 
 don't do a great job of publicizing our involvement and attracting high 
 quality students. Perhaps it's because the student payment isn't all that 
 much (+/-$6000 USD, depending on student's country)* for the amount of 
 work 
 involved (also, students have to put in a lot of work up front in their 
 application, with no guarantee of being accepted into the program).

 If you have any ideas about mentoring or suggesting a project, or if 
 you're serious about being a student (you should start contributing to 
 Django now if you don't already), please share.

 * https://developers.google.com/open-source/gsoc/help/student-stipends

>>>

-- 
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/65c300ab-16b0-4a4f-8de7-3f86d1dd29d1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: App static files (#29586)

2019-02-04 Thread Carlton Gibson
Hi Claude. 

Is this something you're still interested in? 

Do you think it might make a good GSoC project? 

C.

On Monday, 23 July 2018 17:36:05 UTC+2, Claude Paroz wrote:
>
> Hi, 
>
> I just created a new feature request [1] to be able to define static 
> files per application, including a POC patch [2]. 
>
> [1] https://code.djangoproject.com/ticket/29586 
> [2] https://github.com/django/django/pull/10218 
>
> Feel free to discuss it here for general discussion on the feature 
> utility, or comment on the ticket or on the pull request for 
> implementation details. 
>
> Cheers, 
>
> Claude 
> -- 
> www.2xlibre.net 
>

-- 
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/869f847f-295c-4b17-b442-abbcc43955f5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Google Summer of Code 2019

2019-02-04 Thread Carlton Gibson
Hey Tim. 

> For each year your organization has participated, provide the counts of 
successful and total students. (e.g. 2016: 3/4)

I have no idea about this, could you advise? 

Thanks. 

-- 
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/e1bb1cc8-8628-435c-a5c6-8466ed4e8d4e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: django.utils.dateparse

2019-02-04 Thread Giuseppe De Marco
Hello everyone, first of all I am grateful for your time and your attention.

@Tom Forbes
The first time I runned it I thought the same thing! Please use
https://github.com/peppelinux/Django-snippets/blob/master/datetime_heuristic_parser.py
and not the previous pasted one. I'm quite sure that all the tests passes
well, because of their output. As we can see I deal with a tuple that
contains ('format', 'compiled_regexp', 'values dictionary'), this obviously
just for test purpose.

Parsing succesfull on "04/12/2018":
[('%d/%m/%Y', '(?P\\d{1,2})/(?P\\d{1,2})/(?P\\d{4})$',
{'year': 2018, 'month': 12, 'day': 4})]

Parsing succesfull on "04/12/2018 3:2:1":
[('%d/%m/%Y %H:%M:%S',
'(?P\\d{1,2})/(?P\\d{1,2})/(?P\\d{4})
(?P\\d{1,2}):(?P\\d{1,2}):(?P\\d{1,2})$', {'second':
1, 'year': 2018, 'minute': 2, 'month': 12, 'hour': 3, 'day': 4})]

Parsing succesfull on "2018-03-4 09:7:4":
[('%Y-%m-%d %H:%M:%S',
'(?P\\d{4})-(?P\\d{1,2})-(?P\\d{1,2})
(?P\\d{1,2}):(?P\\d{1,2}):(?P\\d{1,2})$', {'second':
4, 'year': 2018, 'minute': 7, 'month': 3, 'hour': 9, 'day': 4})]

Parsing succesfull on "2018-03-04T09:7:4.645194":
[('%Y-%m-%dT%H:%M:%S.%f',
'(?P\\d{4})-(?P\\d{1,2})-(?P\\d{1,2})T(?P\\d{1,2}):(?P\\d{1,2}):(?P\\d{1,2}).(?P\\d{6})$',
{'second': 4, 'year': 2018, 'minute': 7, 'month': 3, 'microsecond': 645194,
'hour': 9, 'day': 4})]

Parsing succesfull on "20180304121940.948000Z":
[('%Y%m%d%H%M%S.%fZ',
'(?P\\d{4})(?P\\d{1,2})(?P\\d{1,2})(?P\\d{1,2})(?P\\d{1,2})(?P\\d{1,2}).(?P\\d{6})Z$',
{'second': 40, 'year': 2018, 'minute': 19, 'month': 3, 'microsecond':
948000, 'hour': 12, 'day': 4})]

Yesterday I coded it on a tablet, this morning from my laptop I got this
performance:
python -m timeit -s "from datetime_heuristic_parser import
datetime_heuristic_parser;
datetime_heuristic_parser('2019-02-03T17:27:58.645194')"
1 loops, best of 3: 0.00891 usec per loop

I also added a simple raise Exception in the case it should return an
error, thank you for your suggestion.

@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  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
> 
> .
> 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