Adam Dobrawy who runs Django-Guardian, could do with some help maintaining
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
I see the project has some regular
Thanks for reaching out to the mailing list. I've stared the repo and will
start contributing from now on.
On Mon, Feb 4, 2019, 2:01 AM Carlton Gibson Hi all.
> Adam Dobrawy who runs Django-Guardian, could do with some help maintaining
> The project seems to be in good shape.
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
My idea is to add the applied datetime value to the showmigrations command.
I've run into the case where I'm working on a branch that involves a number
of migrations across various apps, but then have to switch to a different
branch which has different migrations. It can be troublesome to
This sounds interesting.
You should think a bit about backwards compatibility because there's a good
chance that some users are calling django-admin showmigrations in scripts or
tools. I don't think this is a blocker for changing the output format. However
you should plan to minimize
Hi All, it's the first time for me in this ml,
I'd like to purpose a refactor of django.utils.dateparse functions.
Currently a function in it, like parse_date for example, extract date time
string with a static regexp...
Not changing the default output makes a lot of sense. I initially was
wondering if it should have its own option. Making it an addition to a
higher verbosity level will work too.
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to
django.utils.dateparse provides helpers needed by Django to implement datetime,
date and time fields on SQLite. (SQLite doesn't have a native date time type.)
Their job is to parse ISO 8601 fast. That's it.
A utility module should do exactly what Django needs and nothing more.
The Django test runner currently only displays tests that failed, and not
those that succeeded. It would be nice if Django were to print out a list
of tests that succeeded. First of all, it is satisfying to see tests
succeed. Second of all, it would be easier to debug (if certain tests were
Django's test runner is based on Python's built-in unittest:
https://docs.python.org/3/library/unittest.html#module-unittest . I believe
you can use the verbose mode (e.g. -v 2) to see the list of all executed
On Sun, 3 Feb 2019 at 21:56, Jeremy Potter
> The Django test runner
Thank you for the answer and for the tests as well.
I understand and also agree your vision on all the line, I got the specific
purpose of parse_date.
I'd like to introduce a generalized way to parse date and datetime string
based on Django project configuration, in settings.py.
Regarding the previous example,
better to read it here (my fault: I mistaken the format
and also, it should came also with tzinfo regexp and other functions as
well, like parse_date
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 (
Hey, can you elaborate on what your idea is?
On Thursday, January 31, 2019 at 4:54:36 PM UTC+5:30, gaurav jain wrote:
> from django.db import models
> from django.contrib.auth.models import User
> class CommenInfo(models.Model):
> archived = models.BooleanField(default=False)
Hey, I had a project idea for GSoC.
I wanted to make a tool which will help to port static projects like Jekyll
to Django directly.
I am still thinking about the details of the idea.
But I want to know:
- is this idea feasible/useful?
- Does there already exist a similar tool for this?
please someone can help me to fix this issues
On Sun, Feb 3, 2019 at 12:46 AM Tim Graham wrote:
> Week ending February 2, 2019
This mailing list is for the development of Django. itself, not for support
using Django. Please keep such questions to Stack Overflow, or the
django-users mailing list.
On Sun, 3 Feb 2019 at 14:03, hunar techie
I personally like the option better. This seems like a different use-case
than I'd normally expect from a verbosity level.
On Sun, Feb 3, 2019 at 12:45 PM Tim Schilling
> Not changing the default output makes a lot of sense. I initially was
> wondering if it should have its own option.
In which circumstances:
- would this be useful?
- would a Form not be a better choice?
> On 4 Feb 2019, at 00:10, Giuseppe De Marco wrote:
> Hi Aymeric,
> Thank you for the answer and for the tests as well.
> I understand and also agree your
Mail list logo