Re: Stalled tickets

[ludovic coues]

I have seen other open source project handling that with a comment saying
the ticket will be closed in a short time. I assume closing with a comment
it's fine to reopen if it's still relevant would be fine. Maybe also
tagging the tickets with a label "closed as stalled" ?

On Fri, Sep 27, 2019, 01:45 David Vaz  wrote:

> Hi,
>
> I am playing around at the DjangoCon US 2019 Sprints and while trying to
> do my share one thing stands out in the open tickets is: Some are very old
> and others have not been touched in a while.
>
> I did a simple analysis of accepted and open tickets based on last
> modified time (kind of a live status).
>
> The numbers might change over time, but I also linked them:
>
> Modified at any time All
> :
> 1264
>
> Modified in last 5 years
> :
> 1039
>
> Modified in last 4 years:
> 
> 887
>
> Modified in last 3 years
> :
> 728
>
> Modified in last 2 years
> :
> 494
>
> Modified in last year
> :
>329
>
>
> So if we would decide to close stalled tickets after some inactivity
> period we could massively reduce the opened tickets list. Imagine if we
> close any ticket no modified in the last 5 years we would reduce by 20% the
> active ticket list. If we decide to be more aggressive, say 3 years we can
> cut by half the active tickets list.
>
>
> I also believe that apparently stalled tickets might be important. This
> auto-close approach would also trigger *a live prof, *any automatically
> closed ticket could be reopened if relevant.
>
>
> Let us focus the efforts on the really active ones.
>
>
> Anyway, these are just my thoughts.
>
>
> For those of you who do not know me, I am organizing DjangoCon Europe 2020
> in Porto Portugal and you are all invited, official details are about to be
> released.
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/b3b855e5-7fd6-4b26-b365-75ff687c4b4c%40googlegroups.com
> 
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAEuG%2BTYPvHMVHL9ZEy5fTsA%2Bfj7L_sisehVcRiQbgJF9eKTXsg%40mail.gmail.com.

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

[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: [Looking for feedback] Make Admin raw_id_fields the default choice for FKs, or project-wide configurable

[ludovic coues]

Django's admin default widget for foreign keys is a select. If you try to
populate a select elements with 20,000 options, your page take at least a
few seconds to load. Probably a minute or two, if it load at all.

By configuring your model admin to display the foreign key as a
raw_id_fields, you get an simple input instead of a select. It's less nice
to use but it's much faster.

On Thu, Jan 17, 2019, 13:48 shiva kumar  actually i am new to django i am not able to understand the problem which
> ur dealing with?
>
> On Thu, Jan 17, 2019 at 3:33 AM Santiago Basulto <
> santiago.basu...@gmail.com> wrote:
>
>> Hey folks, I was about to submit a ticket but i thought it might be
>> better to ask everybody for opinions on the matter first. I am running a
>> couple of medium (not even large) Django websites (around +20K users) and
>> we rely on the admin heavily. We have multiple models pointing to Users (or
>> other derived models) and every time we create a new model, we MUST
>> remember to include User in `raw_id_fields` for that model. If we forget to
>> do so, the whole testing site crashes when the whole `SELECT * FROM User`
>> query is run.
>>
>> To add to the problem, some derived models (for example Customer) include
>> in their `__str__` both the User + something else. Think about the model
>> Customer in this way:
>>
>> class Customer(models.Model):
>> user = models.ForeignKey(User)
>> plan = models.ForeignKey(Plan)
>>
>>
>> def __str__(self):
>> return f"{self.user} - {self.plan}"
>>
>>
>> (Not a real example, but to make the point)
>>
>> Imagine any other model with an FK to Customer, an `Inquiry`, for
>> example. If you open the `Inquiry` add/change page on the admin, the whole
>> thing will blow up.
>>
>> I know the related select field is an amazing feature, and looks slick on
>> the admin when starting a new Django projects (specially for beginners),
>> but it just doesn't scale for large websites.
>>
>> *My proposal*
>>
>> I think just a project-wide setting `settings.ADMIN_DEFAULT_FK_WIDGET =
>> [raw|select]` would work and help us (running a medium/large site) a lot.
>>
>> What do you think?
>>
>> Thanks for all the support, this community rocks 🤘!
>>
>> PS: I can create a ticket if that's a better medium of discussion, just
>> let me know?
>>
>> --
>> 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/5dae8b31-356c-45f3-b707-83b5ef33f396%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/CAMsYeuFUNE3W8Cc2RGwn7L-LZ%2BhrNy9NPxiYVx_ZH7H4kUzR0Q%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/CAEuG%2BTaajgmBC37fjiHfSXJNOFvTmU%2B29Cz-G-zbLMsiuN3yyQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Database connection retry

[ludovic coues]

Are you using runserver in production ?

On Sat, Dec 15, 2018, 08:52 Jamesie Pic  Hi all,
>
> Sorry to bump this, but I didn't find another thread, and I'm pretty sure
> re-trying the database connection is the sane thing to do.
>
> Otherwise, Django will remain in failed state after reboot in some cases:
> psycopg2.OperationalError: FATAL:  the database system is starting up
>
> It would be better if Django could tolerate this situation and retry, then
> the server would be reboot proof.
>
> At least, show a 500 page until the DB server has started, would be more
> reasonnable.
>
> Are you sure Django should not be a bit a bit more tolerant with databases
> starting up ?
>
> Or should we open a ticket ?
>
> Thanks in advance for your reply
>
> Have a great weekend
>
> --
> 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/CAC6Op18ET_ZZs_XBQou70sJL9vo2fsk2BL57q4j-U-j5H_d4oQ%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/CAEuG%2BTbXZL%2BH5kgZryAsK_i06NwaRCb5EkHMRLmgZ6rA%3D7yhjA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: A faster paginator for django

[ludovic coues]

The preferred way for this kind of scenario is to make a third party
package. This let you release new version faster than the Django
development cycle and it's super easy to install thanks to tools like pip.

Once your solution is stable, if it's popular enough, it could be
incorporated into Django.

I'm really curious how you want to do it. I thought there was no other way
to skip some row in an SQL query


On Wed, Dec 5, 2018, 13:15 Saleem Jaffer  Hi all,
>
> The default paginator that comes with Django is inefficient when dealing
> with large tables. This is because the final query for fetching pages uses
> "OFFSET" which is basically a linear scan till the last index of the
> current page. Does it make sense to have a better paginator which does not
> use "OFFSET".
>
> If this sounds like a good idea, I have some ideas on how to do it and
> with some help from you guys I can implement it.
>
> Saleem
>
> --
> 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/020f66e0-ec58-47e2-be0b-00c3f1688c5b%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/CAEuG%2BTar6iM5sctRSyPkOHtmL7u9pM%3D01bUvWn%2BZEeQHZsk2fg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Pluggable secret key backend

[ludovic coues]

I don't see how this would work.

For example the session. You take the user cookie. You try to validate with
your secret key. That doesn't work because the current key is the new one.

With a custom cookie backend, you could check if the old secret could
validate the cookie. But you need to change your cookie backend to handle
the case of multiple secret key. And all third party session backend need
to update.


On Sat, Nov 10, 2018, 11:12 Andreas Pelme  Hi,
>
> settings.SECRET_KEY can be used for sessions, password resets, form
> wizards and
> other cryptographic signatures via the signing APIs. Changing SECRET_KEY
> means
> that all of those will be invalidated and the users will be affected in
> weird
> ways without really knowing what happened. (Why am I logged out? Where did
> my
> form submission go? Why does not this password reset link work?). This is
> desirable in case the key is compromised and swift action must be taken.
>
> There are other situations when it would be nice to change the SECRET_KEY
> when
> this sudden invalidation is not desirable:
>
> - When someone leaves a project/company that had access to the production
>   system. After SSH keys/login credentials is revoked the developer could
>   potentially have a copy of the secret key. It is essentially a backdoor
> with
>   full remote access. It would be wise to rotate the key in those cases.
>
> - Periodic and automatic rotations of keys to make it less useful in the
>   future.
>
> The current situation of a single SECRET_KEY makes key rotation
> impractical. If
> you run a busy site with active users 24/7, there is never a nice time to
> change the SECRET_KEY.
>
> A solution for this problem would be sign new secrets with a new key while
> still allow signatures made with the old key to be considered valid at the
> same
> time. Changing keys and having a couple of hours of overlap where
> signatures
> from both keys are accepted would mitigate most of the user facing problems
> with invalidating sessions, password reset links and form wizard progress.
>
> You could do this today by implementing your own session backend, message
> storage backend and password reset token generator but that is cumbersome
> and
> does not work across reusable apps that directly use low level Django
> signing
> APIs unless they too provide hooks to provide your own secret.
>
> I propose a pluggable project wide secret key backend
> (settings.SECRET_KEY_BACKEND maybe?) with an API something like:
>
> class SecretKeyBackend:
>   def get_signing_key(self): …
>   def get_verification_keys(self): ...
>
> The default (and backward compatible) backend would then be implemented as
> something like:
>
> class SecretKeySettingsBackend:
>   def get_signing_key(self):
> return settings.SECRET_KEY
>   def get_verification_keys(self):
> return [settings.SECRET_KEY]
>
> django.core.signing.Signer.{sign,unsign} would need to be updated to use
> this
> backend instead of directly using settings.SECRET_KEY.
>
> That would solve the problem project wide and work across any third party
> application that uses django.core.signing directly.
>
> This would open the door for third party secrets backend packages that
> retrieves keys from systems such as Hashicorp Vault, AWS Secrets Manager,
> Google Cloud KMS, Docker Secrets etc.
>
> Having a method that retrieves the key would allow changes to secret key
> during
> run time instead of relying on a hard coded setting would allow the key to
> change without restarting the server process.
>
> Would something like this be worth pursuing? Could it be designed in som
> other
> way? I could not find any previous discussion/tickets on this and thought
> it
> would be a good idea to discuss it here before opening a ticket or making
> an
> attempt at a PR. :)
>
> 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/20D8A2BD-BC9C-4F02-9038-044687165DE9%40pelme.se
> .
> 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%2B

Re: Idea: Allow queryset.get() and queryset.filter() to accept a positional argument for implicit primary key filtering

[ludovic coues]

When experimenting with code in the shell, debugging or troubleshooting, I
personally tend to do a lot of get. I know some object cause issue so I try
to get them to poke them and see what's the problem.

When trying to get them, if I have the id, I always try to type
Model.objects.get(id). Sometimes I correct myself before typing enter but
that's something to remember and amount to a lot of little irritation,
sometimes while trying to solve elusive issues or trying to fix asap some
major issues in prod.


Maybe that feature belong in a third party app. Monkey-patching is a thing.

On Tue, Nov 6, 2018, 08:48 James Bennett  I still don't understand the problem this is solving; is typing "pk=" (or
> "id=") that much of a burden? Or that frequently left out by accident?
>
> As it stands, I agree with Adam that this adds implementation complexity
> (including potential future implementation complexity, as Ivan noted) and
> proliferates different ways to do the same thing, without presenting much
> in the way of concrete arguments for why it's needed. If there's a really
> convincing case to be made for this, I'm open to reading it when it's made,
> but for now I'd be -1 on the whole thing.
>
> --
> 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/CAL13Cg9ocm_LmZSGbQG%3DEB2U0Z%2BOF5eupJFwK3OWbyz46JDj5Q%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/CAEuG%2BTZ6Nm4Hwm_oKBRbdzxztORgD%3DAAsFkZBPXnPULJhC2Egg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: django.contrib.auth CLI

[ludovic coues]

I'm sure your extreme DevOps expertise can find a way to automate the
deployment of a pip package.

I mean, you are argument about manual step for an automatic step is a straw
man.

Let's say you make two deployment of your app. One on your system, one on
premises on a customer system. You want both system to make use of a
different set of user. But you want that idenpotent function to manage user
on both system. Because that's part of your solution. You want to automate
deploying your requirements.txt more than your set of user.

Beside, these days, starting your pet Django feature as a third party
project is the recommended way to go. You will be able to react more
quickly to user demand while your feature mature and the Django project
will be able to judge how useful is your project.

Look at whitenoise or Django rest framework.

And please, read the code of conduct one more time. No subscriber of this
mailing list should have to read Neither this email nor your because we are
acting like children, being all snarky and passive aggressive.

On Oct 11, 2018 12:27, "Jamesie Pic"  wrote:

Sorry, I forgot to answer about the loaddata proposal.

So, loaddata will not do user removal for one thing.

About user creation, the process we have is:

- add the user to the users list,
- set the password in `ansible-vault create passwords/username`
- CM will execute createsuperuser for users,

>From that, it should maintain the userbase, on an ootb django project.

The workflow you are suggesting is:

- add the user to the users list,
- set the password in `ansible-vault create passwords/username`,
- somehow parse the settings to know the user model,
- generate a json file with the users, and hope that it will work with
their model,
- use a script that django doesn't have to generate a salted password,
- upload the script and apply it.

I don't think I want my automation steps to rely on hope.

What about the debugging process of such a complex implementation for such
a simple task ?
The cost is not worth the benefit. Injecting code in django-admin shell
still does the same with
a much cheaper complexity cost.

Have a great day.

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

Re: ModelForm unique validation is not done right IMHO.

[ludovic coues]

First, that's a discussion for the Django user list, not the Django
developers one.

I would add a clean_book method on the form and use it to check if the user
already have a book with that name. For that specific problems, that's the
cleanest solution in my opinion. Simply do a
Book.objects.filter(user=form.user, name=form.cleaned_data["name"]).
exists() and if you get a hit, raise a Validation error. The error will be
associated to the book field.

If someone want to write a patch for adding full validation of a ModelForm,
I wish them good luck. You could try a save commit=False but you will only
get an integrity error and a string coming from the database. Which can be
translated. You could check for your unique_together with an extra request.
Then the form will raise a Validation error saying there is already a book
with that user and that name. Confusing the user.

If you think a ModelForm giving guarantee that the save method will work
make sense, the best way to proceed is a third party module. Doing so let
you do quick release for development and testing, user will be able try the
module and see if it solves their problems. In my opinion, something
generic won't help when validating unique_together relationship when one of
the fields is not exposed to the user. But I could be wrong.

On Sep 24, 2018 07:34, "Protik"  wrote:

I am using Django 1.11. Further, adding a new book with user field disabled
results in the following error:

[image: Selection_046.png]


I have attached the code to reproduce the error.


On Monday, September 24, 2018 at 1:59:31 AM UTC+5:30, Todor Velichkov wrote:
>
> First thought: What is your Django version? The `disabled` attribute was
> added in Django 1.9.
> However by looking at your code (w/o testing anything) after
> `form.is_valid()` you should only call `form.save()`, no need to do
> `commit=False` and manually assigning user, you have already done that in
> the form constructor (by settings initial value + disabled attr).
>
> On Sunday, September 23, 2018 at 9:25:41 PM UTC+3, Protik wrote:
>>
>> Hi, Todor
>>
>> I have tested this solution and It looks like it works only when you
>> don't disable the field (i.e the last line in the BookForm's `__init__()`
>> method. My views looks like this:
>>
>>
>> def book_add(request):
>> user = get_object_or_404(User, id=1)
>>
>> if request.method == 'POST':
>>
>> f = BookForm(request.POST, user=user)
>> if f.is_valid():
>> book = f.save(commit=False)
>> book.user = user
>> book.save()
>> messages.add_message(request, messages.INFO, 'book added.')
>> return redirect('book_add')
>> else:
>> f = BookForm(user=user)
>>
>> return render(request, 'blog/book_add.html', {'f': f})
>>
>>
>> def post_update(request, post_pk):
>> user = get_object_or_404(User, id=1)
>> book = get_object_or_404(Book, pk=post_pk)
>> if request.method == 'POST':
>> f = BookForm(request.POST, instance=book, user=user)
>> if f.is_valid():
>> post = f.save(commit=False)
>> post.user = user
>> post.save()
>> messages.add_message(request, messages.INFO, 'Post added.')
>> return redirect('post_update', post.pk)
>> else:
>> f = BookForm(instance=book, user=user)
>>
>> return render(request, 'blog/book_update.html', {'f': f})
>>
>>
>> The code for models and modelform is exactly same as yours.
>>
>>
>> Am I doing something wrong?
>>
>>
>> On Sunday, September 23, 2018 at 9:11:55 PM UTC+5:30, Todor Velichkov
>> wrote:
>>>
>>> You can use the `disabled
>>> `
>>> attribute on form fields with a combination of HiddenInput
>>> 
>>>
>>> Using the Book example from the first comment it will look like this:
>>>
>>> class BookForm(forms.ModelForm):
>>> class Meta:
>>> model = Book
>>> fields = ('user', 'name')
>>>
>>> def __init__(self, *args, **kwargs):
>>> user = kwargs.pop('user')
>>> super(BookForm, self).__init__(*args, **kwargs)
>>> self.fields['user'].widget = forms.HiddenInput()
>>> self.fields['user'].initial = user
>>> self.fields['user'].disabled = True
>>>
>>>
>>> First we hide the the user field because we dont want the user to see
>>> it, and at the same time keeping it inside form fields we wont prevent the
>>> unique_together validation.
>>> Second - we disable the field and programmatically set initial value to
>>> be used during form validation
>>>
>>> On Sunday, September 23, 2018 at 4:57:15 PM UTC+3, Protik wrote:

 Hi  Todor

 I am experiencing the same problem. Can you please post the
 possible solution?

 On Tuesday, October 10, 2017 at 8:26:32 AM UTC+5:30, Todor Velichkov
 wrote:
>
> It does? Can you give me a link

Re: The behavior of QueryDict.get(_key_, _default=None_)

[ludovic coues]

This will probably breaking compatibility with previous version of Django,
breaking a lot of website in subtle way.

Printing a debug message in the log when calling QueryDict.get on key being
present more than once sound more reasonable. That should be doable as an
third party app but that wouldn't help beginners.

On 19 Jul 2018 8:19 am, "Philip Lee"  wrote:

I was trapped by the behavior of `QueryDict.get(_key_, _default=None_)` for
a bit while before consulting the documentation , for that *If the key has
more than one value, it returns the last value.*
So as for  multiple values for the same key,  is returning the last value
of key more often expected than returning all the values of the key(that is
the behavior of `QueryDict.getlist(_key_, _default=None_)` right now)?  If
not, I'd suggest to change the behavior of `QueryDict.get(_key_,
_default=None_)` to return all the values of the same key for a natural
usage so that avoid confusing problems caused by the current behavior like
https://stackoverflow.com/questions/50044626/querydict-returning-strange-value-in-django
https://code.djangoproject.com/ticket/1130

-- 
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/5a6263e2-5872-400c-af1b-aa2c74244247%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/CAEuG%2BTagMKZ-XQu31RodotpK0-uKpC8tmMNuH4Q8m0SudDfQng%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: App Name

[ludovic coues]

That question should be posted on Django user, where people discuss on how
to use django to build web site and web application. This list is for
improving djnago.

Anyway.
The first argument of the url tag is the name of the URL you want. The most
common way to specify an URL name is with the format "{app}:{url}". This
let you have each app have an home view without conflict and you can still
can fetch the URL from the right app.

The name of an app is always stored in a variable app_name. And URL won't
alter the URL name you gave it. So if you ask for 'app_name:posts', you
will get the URL named posts from the app with a variable app_name set to
the value app_name.


Maybe you are thinking of relative URL name resolving, which would be an
improvement to Django. What I mean is the url tag would recognize a special
value as meaning "fetch that view from the current app".

In my opinion, either a blank app name or 'self' would be a better choice
for that special value. And it would cause a lot of issue. It might break
existing Django app, which is bad. It will make finding all references if
an URL in you code harder as you need to search for both the absolute and
the relative name version.


I hope this answer your questions and thanks for asking


On Thu, 12 Jul 2018, 03:55 Aniket Aryamane, 
wrote:

> Hello,
>
> If in the urls.py, I can write:
> *app_name* = '*posts*'
> .
> .
> path(' ', views.home, name='home'),
>
>
>
> then why it is required to refer url name (from the template) by the *app_name
> value* as:
> {% url '*posts*:home' %}
>
> It should be referred instead by *app_name variable* like below:
> {% url '*app_name*:home' %}
>
>
> What do you guys think?
>
>
>
> Thanks,
> Aniket.
>
> --
> 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/ce6c2ef7-b463-43d5-bd57-5f2ca3d6fda6%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.a
>

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

Re: GSoC 2018

[ludovic coues]

On Sat, 17 Mar 2018, 21:55 Manasvi Saxena,  wrote:

> Hello Sir,
>
> I'll give some background. The Django Templating Language was very
>> specifically designed to NOT allow putting business logic or allow calling
>> arbitrary functions in the template. Jinja2 loosened up that a bit, but it
>> still doesn't let you do whatever you want. There's a couple reasons, but
>> one is performance. Django gains a lot of optimizations because all
>> database queries can happen in a small region. It also means one cannot
>> potentially have 3 functions that each request the same data thus doing 3
>> DB queries, which is very slow.
>>
>> It is also generally "bad form" to mix your business logic and your
>> display logic. I get that there's some times where it's much simpler to
>> break that separation. That is part of why Jinja2 gained some traction
>> (though I personally really like the better whitespace control). It also
>> creates a much better chance for a security flaw and maintenance issues.
>> Obviously, there is nothing stopping you from creating such a templating
>> language. It may get really popular.
>>
>> Finally, I'll mention that there's nothing in Django that stops you from
>> just changing the template language used. It's as simple as not using the
>> render shortcut function. The joy of Python is that you just need to
>> generally match the interface.
>>
>> Not to be mean, but I wanted to point out what's being proposed. Your
>> proposal is that Django pays you to create yet another templating language
>> that they have to support. This leads to three separate paths that the code
>> can take. There then needs to be some ability to cross communicate between
>> all three languages. Then there's the "sales" end of explaining why there's
>> 3 templating languages and why one needs to choose another. One of the real
>> selling points of Django over other frameworks is that they're opinionated
>> and chose a specific set of tools. I started back in Pylons/TurboGears, and
>> I would spend a long time looking over which DB layer to chose and which
>> templating language to chose. In the end, I'll say that it was refreshing
>> to go to Django and have some of that chosen for you and to just start
>> working.
>>
>> I really do wish you the best of luck if you attempt to make this. I'm
>> sure there is a need, but I personally do not see it being a direct fit
>> into Django.
>>
>
>
> I have decided to drop my earlier idea to create a python to HTML library.
>
> But I still believe that Django templating language(DTL) or Jinja has some
> limitations and drawback. First of all, as I said earlier for large data
> set it takes more time. Secondly, it has limited scope for flexibility
> while implementing logic.
> The solution I was offering earlier for it was deeply flawed as mentioned
> above by you.
> I have decided to create an approach that (a) can cross
> communicate between jinja and DTL. (b) is easy to maintain and use.
>
> What I'm planning to do is to provide a library that can inject data into
> the template before rendering the template.
>
> For now, assume that there will be a function, only a single function, let
> us call it
>
> *populate(replace_with, new_content)*
>
> Now inside the template just like DTL ask us to write {{variable_name}} we
> now have to write let say
>
> **
>
> The above function when called will look into the file for the
> *"replace_with"  *variable and will replace it will with *"new_content".*
> This was just a simple example, simplest example I would say. The real
> functionality will be different from it.
>
> *"populate"* function can replace HTML content, plain text, or even a
> list of *new_content*. Anything that is within our custom tag will be
> replaced with the *new_content.*
>
> Benefits of this approach include:
> 1. Generation of HTML page with dynamically populated data and simply
> serving it through *HttpResponse() *[Fast maybe].
> 2. Flexibility in implementing any logic. As soon as you have the data
> call *populate() *and place it inside the template.
> 3. DTL can still be used for providing any other functionality if the need
> persists. However, I intend to cover every functionality offered by DTL in
> it.
> 4. While for some cases DTL works in a really optimized manner, it will be
> in the hands of the developer to chose which approach to follow.
> 5. It does not require the developer to learn anything extra other than
> DTL (or if successfully implemented, not even DTL).
>
> Things I'll work on is to
> 1. Find an efficient way to implement *populate() *function. While we do
> have a naive approach to finding next and replacing. I intend to find an
> optimized way to implement this function.
> 2. Making the library compatible with the existing Django features. No
> changes will be made to any existing features. It'll act as an API and will
> work independently of any other Django library.
>
> Please let me know what do you think of this new approach so tha

Re: Hello everyone I'm a new member

[ludovic coues]

There is a chapter in the documentation on how to contribute to django. It
should answer most of your questions.

On 13 Dec 2017 3:10 am, "Asad Ahmed"  wrote:

> Hello everyone,
> I'm new to open source community. I've been working on python and django
> framework for few years now. I've done few projects based on them and ML.
> I'm planing for Gsoc.
> I would be really grateful if anyone can guide me on how to proceed for
> open source contribution on django.
>
> Thanks
> Your sincerely
> Asad Ahmed
>
> --
> 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/ad4a0f57-3f59-4723-bd3e-
> b41170d240f2%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/CAEuG%2BTZrMJoN8z%3DaYG8v0DD%2Bc4tCEU4XMEfpq86V2LQwNEZp3g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: New Permissions Scheme

[ludovic coues]

There are a lot of issue with your new permissions.

Some people have been asking for a view permission in admin. With
current system, all one have to do is add a permission per model. With
your proposal, the whole system have to be ditched in favor of a more
flexible one.

I have also seen production code using permission like is_something.
Yeah, sure, it's not semantically correct. Being a bot or a moderator
or a senior user is not a permission. But current permission system
work nicely for that kind of stuff.

Yeah, sure, people can swap the model like with user. But I have seem
more often code adding a foreign key pointing to the user rather than
swapping the model. I doubt that kind of solution will work with stuff
like user.has_perm().

In a nutshell, what you propose will break a lot of code, require more
work from developer, won't really help with translation and the only
help with the widget because you are cutting most of the useful stuff
out of the permission system.

2017-09-21 22:14 GMT+02:00 Ramez Ashraf :
> Good day dear fellow Django developers,
>
> Current permissions scheme in Django does suffer many flaws
> Like Inconsistency with permissions for proxy models #11154 and the fact
> that permission names are not translatable (no translation in the database)
> and the Permission Widget (FilteredSelect) is not very user friendly if we
> have a lot of models.
> Some of these issues have some work around like gists creating correct
> permissions for proxy models, widgets to display the permissions in a
> translated Tabular format (django-tabular-permissions)
> But the problems are still there.
> And the current implementation in itself is some what naive, only add ,
> change , delete
> Maybe i can delete only the records created by me, maybe i can delete but
> not older then 1 day unless i'm superuser
>
> I want to suggest a complete Permission makeover
> Basically a new model / db table for User permissions which look something
> like this (and another one for the groups of course.)
>
> user_id | contenttype_id | add  | change| delete
> 1   | 1  | True | True| False
>
> The new model can be swap-able (like the User model) so end developers might
> add more specified fields beside the add , change,  delete like (can edit
> other users entries, limit to date etc.)
> It might be also advised to create your own Permission model at the start of
> the project (like what is happening now with the user model)
>
> And the current Permissions table can be used for the custom permissions .
>
> I understand that this is might not be the most backward compatible solution
> (although if accepted by you, we can figure this out, using data migrations
> or something)
>
> But Permissions in Django have been dragging for far too long, and delaying
> fixing them if not helping.
> I see the new simplified url (and letting go of the regular expressions- at
> least up front) and i say wow, things can change. :-)
>
> Looking forward for your much appreciated input, ideas & discussion.
>
> Thank you for your time reading this and Best wishes to all of you.
>
>
> Ramez
>
>
>
>
>
>
> --
> 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/bbdf1910-6b89-4568-8c1b-a681b5807871%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



-- 

Cordialement, Ludovic Coues
+33 6 14 87 43 42

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

Re: In-memory queryset

[ludovic coues]

This look like a question for django user.

The QuerySet API is only an abstraction layer to SQL code. That's why
it require a database.
If you really don't want to store your object on a filesystem, sqlite
support database living only in memory. That's mainly for testing
purpose but that could fit your use-case. And django support multiple
database.

2017-03-07 15:13 GMT+01:00  :
> Hi,
>
> It would be really convenient for me if there was an implementation of the
> QuerySet API which instead of using a database as its data source, used
> in-memory model instance that had not been persisted to the database at all.
>
> I looked around and found nothing like this.
>
> Is this because nothing like this exists? Is it because it's a terrible idea
> for a reason that's not obvious to me? Would it not be awesome for the API
> for interacting with collections of in-memory instances and with a
> database-backed collection to be the same?
>
> Many thanks,
>
> Paul
>
> --
> 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/d4f7c142-5d3f-4158-98bb-1e2171f0e63e%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



-- 

Cordialement, Coues Ludovic
+336 148 743 42

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

Time based one time password and django ?

[ludovic coues]

Hello,

After reading the recent thread on authentification in django, I
wondered about the chance of getting a 2-step auth mechanism in
django.contrib.

Time based one time password, or TOTP, is now part of the RFC 6238.
For those who don't know it, it use a shared secret and current time
to produce 6 digit number. That number change every 30 seconds and is
used to confirm login after entering a correct username and password.

As far as I can tell, there is no such thing present in django
currently. But I don't know if it's because nobody have done the  work
or if there are reason to not include 2-step solution in django.

-- 

Cordialement, Coues Ludovic
+336 148 743 42

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

Re: Django

[ludovic coues]

First, this mail list is for working on the internal of django, not
for using it to create website. You are looking for the django user
mail list.

Second, there is a tutorial on django website [1] and there are other
easier to follow and covering more subject, like [2].

[1] https://docs.djangoproject.com/en/1.10/intro/
[2] https://tutorial.djangogirls.org/

2016-10-27 23:15 GMT+02:00 Gaddam Bhasker Reddy :
> Hi everyone,
> I am new to django,i want learn django indepth,could please let me know ,how
> to start learning django and how start django practice ,could please help me
> ,if any one have idea about how to fluent django,i am ready to do hard work
> on python and django.
>
>  please help me
>
> --
> 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/CAOD1959uQx7-1p9rGbPNG7CqbTgb1bDEh-uhLWymPZFa440dDA%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.



-- 

Cordialement, Coues Ludovic
+336 148 743 42

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

Re: is_valid as property

[ludovic coues]

If we choose to move the call to full_clean from errors to is_valid
with a deprecation period, maybe we could rename is_valid to validate.
is_valid could be kept  as a property, raising error if called before
validate like error would be after the change.

2016-10-11 17:50 GMT+02:00 Aymeric Augustin
:
> On 11 Oct 2016, at 14:52, Sven R. Kunze  wrote:
>
> I did never say "let's do business logic in templates". AFAIK, displaying
> errors (or preparing for it HTML-structure-wise) requires knowing whether a
> form is invalid or not.
>
>
> The API for displaying errors is form.errors.
>
> If the documentation implies otherwise, please accept my apologies!
>
> --
> 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/810B668F-D4D3-4C39-90CF-7357DF029921%40polytechnique.org.
>
> For more options, visit https://groups.google.com/d/optout.



-- 

Cordialement, Coues Ludovic
+336 148 743 42

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

Re: is_valid as property

[ludovic coues]

First time you access form.errors, it will call form.full_clean.

But after looking at the code and not simply reading the doc, I agree
that is_valid should be a property. After the first call to is_valid,
the value won't change, even if a field is set to a non-valid value.

2016-10-11 15:49 GMT+02:00 Sven R. Kunze :
> Am Dienstag, 11. Oktober 2016 15:03:21 UTC+2 schrieb ludovic coues:
>>
>> If I remember correctly, form.is_valid do the actual form validation
>> and return false in case of error.
>
>
> I don't know what counts as "actual form validation" but form.is_valid is
> "just" a wrapper on form.errors which is a property.
>
> cf.
> https://github.com/django/django/blob/3c447b108ac70757001171f7a4791f493880bf5b/django/forms/forms.py#L164
>
> --
> 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/bc3d0c3a-024a-4149-afde-6f34c99f53d2%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.



-- 

Cordialement, Coues Ludovic
+336 148 743 42

-- 
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%2BTY-SjFvX8TgT%3Dd57fX0Z6P_bkp3nfLTUmRWKiC-US-qrQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: is_valid as property

[ludovic coues]

If I remember correctly, form.is_valid do the actual form validation
and return false in case of error.

In your template, you can use {% if form.errors %} to check if the
form has any error. It's a dict with field as key and list of errors
as value.

2016-10-11 14:52 GMT+02:00 Sven R. Kunze :
> Am Dienstag, 11. Oktober 2016 14:16:50 UTC+2 schrieb Aymeric Augustin:
>>
>> Hello Sven,
>>
>> On 11 Oct 2016, at 14:07, Sven R. Kunze  wrote:
>>
>> I took a sample of 4 of my colleagues and asked them what the problem with
>> expressions like {% if form.is_valid %} is. They have no idea. They said "it
>> might not make sense in some cases but when it makes sense, it doesn't look
>> very terrible me”.
>>
>>
>> Can you show a non-contrived example, predating this discussion, of a
>> situation where this pattern make sense?
>
>
>
> For displaying some error indicators, changing backgrounds to signal colors
> (like red), etc. I don't know what counts as a non-contrived example to you.
>
>
>>
>>
>> So, what's the real problem here?
>>
>>
>> The real problem is that templates aren’t the correct place to implement
>> business logic such as form validation.
>
>
>
> I did never say "let's do business logic in templates". AFAIK, displaying
> errors (or preparing for it HTML-structure-wise) requires knowing whether a
> form is invalid or not.
>
> When there's some logic to do, that's fine. But when some developer requires
> a simple boolean flag to know whether a form is valid or not, why shouldn't
> he use form.is_valid? That looks to me like making things more complicated
> than necessary.
>
>
> Also, think about GET forms + AJAX which do not POST after redirect at all
> (e.g. search form + result table in separate AJAX containers). There you
> will re-use the same template for success and failure.
>
> --
> 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/4ffb3d8c-43fa-4bc1-9762-eae79334af28%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.



-- 

Cordialement, Coues Ludovic
+336 148 743 42

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

Re: DEP pre-proposal for a simpler URLs syntax.

[ludovic coues]

Sorry about the way the question are formulated. Writing a rambling
post under emotion was pretty stupid of me.

About the url convention, the DEP take a pretty strong stance,
suggesting to raise an exception if the user don't use a convention
which is different from the one in place. I don't recognize the
proposed convention at all. It's not Django, it's not Ruby on Rails
and flask don't seems to have a convention on the ending slash, using
both with and without in the documentation on routing.

The only technical reason I see for enforcing the starting slash is
the smart shim, which is the main source of unintended error.


The question about the old routing system is about the plan to build
on top the old one. I'm not saying the old one is bad. But if we start
to build upon it, it will be harder to replace it. It might be more
interesting to refactor the routing system, so the new one could be
build next to the old one, rather than on top.

This might open the way for third party module providing new way to
route request in django.

2016-10-04 14:55 GMT+02:00 Aymeric Augustin
:
> Hello Ludovic,
>
>
> On 04 Oct 2016, at 14:25, ludovic coues  wrote:
>
>> I have a better DEP for you.
>> Introduce a dependency on django-simple-url.
>
> I don’t think we want to depend on a third party package for something
> as fundamental as URL dispatching. We can take good ideas and, if
> the license allows it, good code from there, though.
>
>> I would like as much as anybody a better
>> way to write url than regex. But I feel like the process is rushed.
>
> Major changes to Django are often driven by flares of excitement. I’m
> sorry if that makes you uncomfortable. Usually the excitement fades
> quickly and then the more boring work on the DEP starts.
>
>
> Moving on to your actual questions...
>
>> What are the merit of the new URL Convention ?
>
> The starting slash and trailing slash are separate questions; let’s not mix 
> them.
>
>> * Why do we suddenly start with slash while the regex url end with a slash ?
>
> Historically Django doesn’t include the starting slash because it’s always 
> there,
> so there’s no need to specify it every time. However everyone else writes URLs
> /foo/bar/ rather than foo/bar/.
>
> Reversing the historical decision would remove a pitfall. I think it’s worth 
> doing it
> and I also thing it’s worth explaining why in the DEP.
>
>> * Are we following the non-existent flask convention ? Which sometime
>> end with a slash, sometimes not ?
>> * Are we following the ruby on rail convention ?
>
> I assume you’re talking about the trailing slash, but if you want to have a
> discussion, you’ll have to ask your question more constructively.
>
>> * The proposed convention would make the default admin url "/admin//“.
>
> You’re allowed to think that you’re talking to complete morons but I would
> appreciate if you didn’t make it that obvious.
>
>
>> Why the "preventing unintented error” ?
>
> The DEP needs to discuss the developer experience during and after the
> change.
>
>> * Why the shim is trying to be smart and use the typed url ?
>
> I expect further discussion on this topic. Constructive arguments welcome.
>
>> * Why introducing a new function named url if we believe it will be a
>> cause of error ?
>
> This part of the DEP is being debated right now.
>
>
>> Why do we keep the old routing system ?
>> * How old is this code ?
>
> Mostly pre-1.0, as far as I know, but that doesn’t mean much. It’s pretty 
> good.
>
>> * Do we plan to keep it forever ?
>
> I didn’t see a proposal to deprecate it in the DEP, all the more since the 
> plan
> is to build the simplified system upon the current system.
>
>> * Do we plan to make it harder to change it ?
>
> I’m not sure why you’re saying that nor what kind of answer you expect.
>
>> * Do we want to prevent third party module providing alternative
>> routing system ?
>
> Look at Marteen Kenbeek’s GSoC for the general direction we’re taking
> and please ask the question in a less obviously biased way.
>
>
> Thanks,
>
> --
> 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/dj

Re: DEP pre-proposal for a simpler URLs syntax.

[ludovic coues]

In my opinion, there is too much question for this DEP.
Here is a quick timeline.
September 12, Emil Stenström rise a valid criticism, using regex for
url routing is a bit too much in 99% of the case. It suggest a syntax
similar to the ruby on rails routing syntax.
September 13, someone mention surlex, something that have existed for years.
September 14, we have a new third party module using the proposed syntax.
September 19, the syntax move to the one used by flask.
October 3, we are joyfully trying to enshrine the new syntax without
technical discussion but a lot of bike shedding.

Damn, half the post here are about the order of the the group name and
the format name. Should we use year:Y or Y:year.
But nobody try to answer question like these:

Is it too early ?

What are the merit of the new URL Convention ?
 * Why do we suddenly start with slash while the regex url end with a slash ?
 * Are we following the non-existent flask convention ? Which sometime
end with a slash, sometimes not ?
 * Are we following the ruby on rail convention ?
 * The proposed convention would make the default admin url "/admin//".

Why the "preventing unintented error" ?
 * Why the shim is trying to be smart and use the typed url ?
 * Why introducing a new function named url if we believe it will be a
cause of error ?

Why do we keep the old routing system ?
 * How old is this code ?
 * Do we plan to keep it forever ?
 * Do we plan to make it harder to change it ?
 * Do we want to prevent third party module providing alternative
routing system ?

The DEP mention that the use of regex is an implementation detail.
Django come with a full test suite. It should be easy to see that an
alternative routing system is compatible with older code. Everybody
seems to be so eager to get ride of regex that they don't care how
that happen under the hood.

Are you seriously suggesting to implement the new URL as a subclass of
the old one ? If that's the case, I have a better DEP for you.
Introduce a dependency on django-simple-url. Tada, no need to alter
the django core source code. That's what the Internal RegexURLPattern
API paragraph feel like. The whole DEP feel like that.

Sorry if I sound a bit rude. I would like as much as anybody a better
way to write url than regex. But I feel like the process is rushed.

And I would really like a way to replace the whole routing component,
like we can replace the whole template component. So we can try
alternative without patching django.

2016-10-04 11:26 GMT+02:00 Markus Holtermann :
> Thanks for your update, Tom!
>
> 1. I think `route` is used in Django Channels (haven't looked it up. Not
> a real issue but something to think about). I'd prefer `path` instead.
>
> 2. Too much magic for my taste. I like the explicit name `typed_url`
> though (if we stick with `url` as opposed to `path` as per 1.). So
> either `regex_url` and `typed_url` or `regex_path` and `typed_path`.
> Either one with a import chim for `django.conf.urls.url` to point to
> `regex_url` or `regex_path`.
>
> 3. Consider me -0 to -1 on deprecating `url()`. If we "rename" `url` to
> `path` I'd rather see the docs updated and have a chim around for _a
> while_. It's unnecessary work for every user to fix this in _every_
> Django project.
>
> /Markus
>
>
> On Tue, Oct 04, 2016 at 02:17:00AM -0700, Tom Christie wrote:
>>
>> Some possibilities:
>>
>> 1. Use a different name for the new function.
>>
>>path('/users//')
>>
>> Actually `path` is pretty valid as a name there - that's *exactly* what it
>> represents - the path portion of the URL.
>> Alternately `route`?
>>
>> 2. Keep `url` for both styles, but with a really simple determination
>> between regexs/typed urls.
>>
>>The pattern *must* start with either `^` or `/`.  (Include a
>> `regex_url` and `typed_url` for the explicit cases)
>>
>> 3. As per (2) but additionally have the usage of regexs in `url(...)` be
>> placed on the deprecation path.
>>
>> I think (1) is probably my favorite choice of those, but I'm open to
>> discussion.
>> That'd give us `from django.conf import path`, and `from django.conf
>> import
>> regex_path`. The existing `from django.conf.urls import url` would keep
>> the
>> existing behavior but move towards deprecation.
>>
>> I'm very strongly in favor of keeping Flask's style for "".
>> Considering the wider ecosystem, the choice between having Python's two
>> biggest web frameworks share the same routing syntax vs. having them share
>> subtly different syntaxes is pretty clear.
>> I think that's a far bigger concern that if the routing syntax echos
>> Python's type hinting syntax or not.
>>
>> To me, the alternative reads like this:
>>
>> A: "Hey folks! Django's got a new routing sytnax!"
>> B: "Great what's it like?"
>> A: "Exactly the same as Flask. Oh, but we've reversed two of the arguments
>> around."
>> B: "Uh, WTF?"
>>
>> Cheers for the input everyone,
>>
>>  Tom
>>
>
> --
> You received this message because you are subscribed to the Google 

Re: does anyone use models with underscores in the name?

[ludovic coues]

I have seen that and so far I haven't found any issue if the
underscore is in the middle of the model name.

2016-10-03 18:30 GMT+02:00 Tim Graham :
> Ticket #27295 notes that the ORM doesn't work well with models that start
> with an underscore (e.g. _UsersGroup). I didn't check if the same problem
> exists with an underscore anywhere in the name, but I wanted to ask if
> anyone has seen model names that use underscores? If not, my proposal is to
> add a system check that prohibits an underscore in model names.
>
> https://code.djangoproject.com/ticket/27295
>
> --
> 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/44532a2c-69b7-45d7-8782-7b87eea09a20%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



-- 

Cordialement, Coues Ludovic
+336 148 743 42

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

Re: Contributing to ORM module

[ludovic coues]

There is a list of bug and feature request on the django's tracker

https://code.djangoproject.com/query

2016-10-02 14:49 GMT+02:00  :
> Hi everyone!
>
> First of all, I'm not sure that I'm writing in the right place, so excuse me
> if this so.
>
> Second - let me introduce myself - my Name is Evgeniy, I'm active web
> developer (mostly Django) for at least one year, and I'm finishing
> university this winter by speciality "program engineering". So right now I'm
> choosing a theme for my diploma. My background in SQL databases is more
> deep, so I thought that I could implement some feature in Django's ORM
> module, and describe it in my graduation work.
> The question is - is there available unimplemented features that should
> improve performance of ORM module and at the same time is not easy, but also
> is not incredible hard for one person like me? Thanks in advance, hope for
> answer!
>
> --
> 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/56d7e6ff-5ef4-45b7-bffe-631e773cd063%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



-- 

Cordialement, Coues Ludovic
+336 148 743 42

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

Re: Django Channels Load Testing Results

[ludovic coues]

For exemple, student trying to do an interactive browser game.
>From what I understood, ASGI main objective is to be the standard for
websocket with django.

In my opinion, the tested case is not pathological. It is the default
one. Django configured barely enough to have stuff working.

I agree that the benchmark only show one face of the truth. Maybe ASGI
scale way better than WSGI. Maybe ASGI require only a fraction of the
CPU or memory required by WSGI. I don't know.

But the use case isn't pathological. If the default are the worst
configuration possible, something is wrong.

2016-09-26 22:30 GMT+02:00 Chris Foresman :
> Why would you be running a small website in ASGI mode with a single worker?
> My suspicion is that someone using Django in ASGI mode has a specific reason
> to do so. Otherwise, why not run it in WSGI mode?
>
>
> On Monday, September 26, 2016 at 2:25:04 PM UTC-5, ludovic coues wrote:
>>
>> What you call a pathological case is a small website, running on
>> something like cheap VPS.
>>
>>
>>
>> 2016-09-26 15:59 GMT+02:00 Chris Foresman :
>> > Robert,
>> >
>> > Thanks! This really does clear things up. The results were a little
>> > surprising at first blush since I believe part of the idea behind
>> > channels
>> > is to be able to serve more requests concurrently than a single-threaded
>> > approach typically allows. This is why I don't think this benchmark
>> > alone is
>> > very useful. We already knew it would be slower to serve requests with a
>> > single worker given the overhead as you described. So what does this
>> > benchmark get us? Is it merely to characterize the performance
>> > difference in
>> > the pathological case? I think ramping up the number of workers on a
>> > single
>> > machine would be an interesting next step, no?
>> >
>> > Anyway, thanks for taking the time to do this work and help us
>> > understand
>> > the results.
>> >
>> >
>> >
>> > On Sunday, September 25, 2016 at 8:23:45 PM UTC-5, Robert Roskam wrote:
>> >>
>> >> Hey Chris,
>> >>
>> >> Sure thing! I'm going to add a little color to this; probably a little
>> >> more than required.
>> >>
>> >> I have gunciorn for comparison on both graphs because channels supports
>> >> HTTP requests, so we wanted to see how it would do against a serious
>> >> production environment option. I could have equally done uwsgi. I chose
>> >> gunicorn out of convenience. It serves as a control for the redis
>> >> channels
>> >> setup.
>> >>
>> >> The main point of comparison is to say: yeah, Daphne has an order of
>> >> magnitude higher latency than gunicorn, and as a consequence, it's
>> >> throughput in the same period of time as gunicorn is less. This really
>> >> shouldn't be surprising. Channels is processing an HTTP request,
>> >> stuffing it
>> >> in a redis queue, having a worker pull it out, process it, and then
>> >> send a
>> >> response back through the queue. This has some innate overhead in it.
>> >>
>> >> You'll note I didn't include IPC for latency comparison. It's because
>> >> it's
>> >> so bad that it would make the graph unreadable. You can get the sense
>> >> of
>> >> that when you see it's throughput. So don't use it for serious
>> >> production
>> >> machines. Use it for a dev environment when you don't want a complex
>> >> setup,
>> >> or use it with nginx splitting traffic for just websockets if you don't
>> >> want
>> >> to run redis for some reason.
>> >>
>> >>
>> >>
>> >> Robert Roskam
>> >>
>> >> On Wednesday, September 14, 2016 at 10:21:27 AM UTC-4, Chris Foresman
>> >> wrote:
>> >>>
>> >>> Yes. Honestly, just explain what these results mean in words, because
>> >>> I
>> >>> cannot turn these graphs into anything meaningful on my own.
>> >>>
>> >>>
>> >>>
>> >>> On Monday, September 12, 2016 at 8:41:05 PM UTC-5, Robert Roskam
>> >>> wrote:
>> >>>>
>> >>>> Hey Chris,
>> >>>>
>> >>>> The goal of these tests is to see how channels performs with normal
>> >>>> HTTP
>&

Re: Django Channels Load Testing Results

[ludovic coues]

What you call a pathological case is a small website, running on
something like cheap VPS.



2016-09-26 15:59 GMT+02:00 Chris Foresman :
> Robert,
>
> Thanks! This really does clear things up. The results were a little
> surprising at first blush since I believe part of the idea behind channels
> is to be able to serve more requests concurrently than a single-threaded
> approach typically allows. This is why I don't think this benchmark alone is
> very useful. We already knew it would be slower to serve requests with a
> single worker given the overhead as you described. So what does this
> benchmark get us? Is it merely to characterize the performance difference in
> the pathological case? I think ramping up the number of workers on a single
> machine would be an interesting next step, no?
>
> Anyway, thanks for taking the time to do this work and help us understand
> the results.
>
>
>
> On Sunday, September 25, 2016 at 8:23:45 PM UTC-5, Robert Roskam wrote:
>>
>> Hey Chris,
>>
>> Sure thing! I'm going to add a little color to this; probably a little
>> more than required.
>>
>> I have gunciorn for comparison on both graphs because channels supports
>> HTTP requests, so we wanted to see how it would do against a serious
>> production environment option. I could have equally done uwsgi. I chose
>> gunicorn out of convenience. It serves as a control for the redis channels
>> setup.
>>
>> The main point of comparison is to say: yeah, Daphne has an order of
>> magnitude higher latency than gunicorn, and as a consequence, it's
>> throughput in the same period of time as gunicorn is less. This really
>> shouldn't be surprising. Channels is processing an HTTP request, stuffing it
>> in a redis queue, having a worker pull it out, process it, and then send a
>> response back through the queue. This has some innate overhead in it.
>>
>> You'll note I didn't include IPC for latency comparison. It's because it's
>> so bad that it would make the graph unreadable. You can get the sense of
>> that when you see it's throughput. So don't use it for serious production
>> machines. Use it for a dev environment when you don't want a complex setup,
>> or use it with nginx splitting traffic for just websockets if you don't want
>> to run redis for some reason.
>>
>>
>>
>> Robert Roskam
>>
>> On Wednesday, September 14, 2016 at 10:21:27 AM UTC-4, Chris Foresman
>> wrote:
>>>
>>> Yes. Honestly, just explain what these results mean in words, because I
>>> cannot turn these graphs into anything meaningful on my own.
>>>
>>>
>>>
>>> On Monday, September 12, 2016 at 8:41:05 PM UTC-5, Robert Roskam wrote:

 Hey Chris,

 The goal of these tests is to see how channels performs with normal HTTP
 traffic under heavy load with a control. In order to compare accurately, I
 tried to eliminate variances as much as possible.

 So yes, there was one worker for both Redis and IPC setups. I provided
 the supervisor configs, as I figured those would be helpful in describing
 exactly what commands were run on each system.

 Does that help bring some context? Or would you like for me to elaborate
 further on some point?

 Thanks,
 Robert


 On Monday, September 12, 2016 at 2:38:59 PM UTC-4, Chris Foresman wrote:
>
> Is this one worker each? I also don't really understand the implication
> of the results. There's no context to explain the numbers nor if one 
> result
> is better than another.
>
> On Sunday, September 11, 2016 at 7:46:52 AM UTC-5, Robert Roskam wrote:
>>
>> Hello All,
>>
>> The following is an initial report of Django Channels performance.
>> While this is being shared in other media channels at this time, I fully
>> expect to get some questions or clarifications from this group in
>> particular, and I'll be happy to add to that README anything to help
>> describe the results.
>>
>>
>> https://github.com/django/channels/blob/master/loadtesting/2016-09-06/README.rst
>>
>>
>> Robert Roskam
>
> --
> 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/f58727ac-fc47-439b-8943-eddf4021a96f%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.



-- 

Cordialement, Coues Ludovic
+336 148 743 42

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

Re: Challenge teaching Django to beginners: urls.py

[ludovic coues]

In my opinion, there is two point. First, core django should allow
different url resolver. Second, these different url resolver should
start as third party package.

Without first point, people need to hack django if they want to
experiment new kind of resolver. Like one providing typecasting or a
faster one or a localized one. And the resolver isn't "loosely
coupled" unlike most of the other part of django.

For the second point, I have a simple reason. Choosing between the
rail or the werkzeug syntax is bike shedding. It is not a technically
choice. It's an aesthetic one. There is no right answer, only lost
time.


2016-09-16 9:30 GMT+02:00 Curtis Maloney :
> On 15/09/16 16:37, Curtis Maloney wrote:
>>
>> Somewhere I have code to provide a "parse" based URL router.
>>
>> Will dig it up now 1.10 has has shipped
>
>
> Ah, found it...
>
> So, here is a gist of a sample of using parse
> (https://pypi.org/project/parse/) instead of regex.
>
> https://gist.github.com/funkybob/3d90c57a837bc164d8b402a1c5b95a8b
>
> Since you can register extra type names, and those types can cast also, it
> covers a lot of things some people expect [but don't get] from regex.
>
>
> --
> C
>
>
>>
>> On 14 September 2016 6:38:20 PM AEST, Florian Apolloner
>>  wrote:
>>
>> Hi Emil,
>>
>> On Tuesday, September 13, 2016 at 9:50:22 PM UTC+2, Emil Stenström
>> wrote:
>>
>> and more experienced users are expected to switch over to using
>> regexes directly to get the exact behavior they want.
>>
>>
>> How so? Personally I would use this quite quickly since a few
>> builtin types would cover 99%. While I can write regex in sleep
>> nowadays, I still find it kinda tedious to redefine what "slug"
>> means in every URL I wanna match something… I am sure others think
>> the same.
>>
>>
>> Beginners likely won't look at all the different options and
>> choose one based on it's merits, they'll pick whatever their
>> teacher suggests they use. Also installing an extra package when
>> setting up django feels a bit strange.
>>
>>
>> I think the eco system is far enough to support that, after all
>> south lived long and well as external package. Either way, DEP or
>> not, having an implementation out there would definitely help.
>>
>> Cheers,
>> Florian
>>
>>
>> --
>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>>
>> --
>> 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/B35D1655-D658-41FC-9EB5-83311B6C892C%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/9ab6342b-f969-4a3b-1263-aabd27cc0eb9%40tinbrain.net.
>
> For more options, visit https://groups.google.com/d/optout.



-- 

Cordialement, Coues Ludovic
+336 148 743 42

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

Re: Challenge teaching Django to beginners: urls.py

[ludovic coues]

There is third party module providing third party url function. Surlex
[1] have been mentionned. But any third party solution will need to
provide function compatible with django.conf.urls.url.
Line 64 of django/urls/revolvers.py is get_resolver. This function
return a RegexURLResolver, using is argument or the setting
ROOT_URLCONF as argument.

This make impossible, for exemple, to have resolver giving to the view
an int argument.

[1] http://codysoyland.com/2009/sep/6/introduction-surlex/

2016-09-13 21:40 GMT+02:00 Tim Graham :
> 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///.
>>
>> 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-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/37e44d86-696d-4b36-803a-0089232eedf9%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.



-- 

Cordialement, Coues Ludovic
+336 148 743 42

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

Re: Django Rest Framework inside of a Django Project

[ludovic coues]

You might get more responses on the django users mailing list. This
one is for discussing new feature of the framework, not its usage.

2016-08-26 17:30 GMT+02:00 Sylvain Dégué :
> Hi,
>
> I am building a mobile application and I need a Rest API and a web version
> of my app. So I was wondering if I could make a website with Django Rest
> Framework or if I have create a Django project for my website and a Django
> Rest Framwork for my API
>
> --
> 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/a99e46c7-7def-4fab-9427-e4203fbb091b%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



-- 

Cordialement, Coues Ludovic
+336 148 743 42

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

Re: PEP 484 type hinting in Django

[ludovic coues]

Dropping support for python 2.7 has been planned for some time. Django
1.11 will be the last one supporting python 2. The following release
will be django 2 and will only support django 3.5+. See
https://docs.djangoproject.com/en/dev/releases/1.11/

That's what Tim was talking about. You can target inclusion in django
2 and forget about the quite uglier #type comment.

2016-08-17 16:13 GMT+02:00 Daniel Moisset :
> Thanks for the replies,
>
> As I mentioned, I have already started implementation (and I'm willing to go
> through with it, having even some time from my work allocated to do it); I
> wasn't aware of the JetBrains plan (it's a nice plus, but I don't depend on
> it), and I'll probably do it as external files if the django core team
> itself is not interested, but I think it's more beneficial to do it inline.
>
> One clarification is that there is no need to drop 2.7 support to use inline
> annotations; there's a python2 compatible way to annotate described now in
> PEP484.
>
> What I'd like to do is to get a reading of the room to see if there's some
> degree of interest (at least a "I'm curious to see how it looks if you do
> the work") before following up with the DEP process. I made a very quick
> summary of what I think the benefits would be, but if it's not clear I'd be
> happy to ellaborate.
>
> Some key things that have changed since last year (regarding the links
> posted by Florian and Tim) are:
>
> * PEP-484 is now approved and standard part of python. The mypy checker is
> now under the python project umbrella and getting active maintainance and
> backed by key people in the python community
> * Having a standard (instead of just a 3rd party tool supporting this) means
> that this now annotations can help to interoperate with many tools (type
> checkers, editors, documentation generators, refactoring tools), so the
> impact in the ecosystem is larger
> * There's some evidence that this works on production (people in dropbox
> have been using it for ~ a year, according to [1])
> * There are several complaints telling that "this won't be actually
> optional", but I see no evidence to support it. And in any case those are
> arguments around deciding to include this in the language, and that decision
> has been made already. But in my experience, annotations help more in some
> particular modules/APIs and not in others, so an abvious option is to add
> them only where they add value (i.e. increase readbility and clarity of
> interfaces)
> * Cory Benfield points at some complex types, that (from a quick look) with
> new type aliases and overload semantics can probably be described in a much
> simpler and readable way. And again, if they don't that function (or that
> argument) shouldn't be annotated.
> * There's someone volunteering to do the work (me and some colleagues at
> Machinalis) :)
>
> I've already been looking at some interfaces in django and I feel that a lot
> of them are as not dynamic and polymorphic as requests is, so some success
> can be achieved here.
>
> So, how do you guys feel about this? what are the risks/fears that you'd
> like to have addressed? do you share my opinion that this will be positive
> for both the framework and its users?
>
> Best,
>
> [1] http://pythonpodcast.com/david-greg-mypy.html
>
>
> On Wed, Aug 17, 2016 at 2:41 PM, Tim Graham  wrote:
>>
>> The JetBrains announcement that they want to fund the project isn't a
>> guarantee that it'll be implemented. The feature needs to go through the
>> normal feature acceptance process, which as Markus said, might involve a
>> DEP.
>>
>> Assuming the idea is accepted, my sense on timing would be to wait until
>> January when Django drops support for Python 2.7 and 3.4 in master. Then we
>> could use inline annotations rather than the stub files.
>>
>> Past discussions of type hinting:
>> https://groups.google.com/d/topic/django-developers/z_P1TvJ6QG8/discussion
>> https://groups.google.com/d/topic/django-developers/xOTmq93YZuQ/discussion
>>
>> On Wednesday, August 17, 2016 at 5:30:56 AM UTC-4, Florian Apolloner
>> wrote:
>>>
>>>
>>>
>>> On Wednesday, August 17, 2016 at 11:06:47 AM UTC+2, dmoisset wrote:

 @Florian
 Would you care to ellaborate? I couldn't find the post you mention
 (although requests is one of the few 3rd party projects that have support 
 at
 the official typeshed repository, https://github.com/python/typeshed )
>>>
>>>
>>> https://lwn.net/Articles/643269/ and https://lwn.net/Articles/643399/ --
>>> might be that things changed by now.
>>
>> --
>> 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 vi

Re: I'm looking for a part-time job in Django

[ludovic coues]

Developer of Django are working on a voluntary basis, without being paid.
If you are interested, you can read
https://docs.djangoproject.com/en/dev/internals/contributing/ for more
information.

2016-08-14 21:20 GMT+02:00 Uri Even-Chen :

> Hi Asif,
>
> How can I become a developer of Django? Do you need developers for Django?
>
> Thanks,
> Uri.
>
>
> *Uri Even-Chen*
> [image: photo] Phone: +972-54-3995700
> Email: u...@speedy.net
> Website: http://www.speedysoftware.com/uri/en/
> 
> 
>   
>
> On Sun, Aug 14, 2016 at 8:23 PM, Asif Saifuddin  wrote:
>
>> Hi uri,
>>
>> this list is for development of django internals/itself only.
>>
>> Reagrds,
>> Asif
>>
>> On Sunday, August 14, 2016 at 1:27:19 PM UTC+6, uri wrote:
>>>
>>> To django-d...@googlegroups.com,
>>>
>>> I'm looking for a part-time job in Django, do you know anything? I live
>>> in Herzliya, Israel. I can't relocate but I can work from home. I can also
>>> help developing the next versions of Django. You can see my CV on LinkedIn.
>>> Please let me know if you have any job for me.
>>>
>>> Thanks,
>>> Uri.
>>>
>>> *Uri Even-Chen*
>>> [image: photo] Phone: +972-54-3995700
>>> Email: u...@speedy.net
>>> Website: http://www.speedysoftware.com/uri/en/
>>> 
>>> 
>>> 
>>> 
>>>
>> --
>> 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/ms
>> gid/django-developers/1963b463-8d10-48d5-b5cd-d29e412e2fa0%
>> 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/CAMQ2MsGsYX7SWmHQZyZ%3Dtp9A7sEa%2BWoz24Agu3tQCZKQ-
> 9QjHA%40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 

Cordialement, Coues Ludovic
+336 148 743 42

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

Re: CheckiO Community is looking for more ways to contribute into Open Source

[ludovic coues]

There is a section in the django documentation about contributing :)

https://docs.djangoproject.com/en/dev/internals/contributing/

2016-08-12 11:23 GMT+02:00 Alexander Lyabah :
> Hi Django developers.
>
> My name is Alex I’m CEO and founder of CheckiO. I hope I found a right place
> to post this kind of message.
>
> CheckiO is a game for python developers where players solving puzzles and
> improving their coding skills by sharing their solution and checking
> solutions of other user. Right now we have more than 200k python-coders who
> have tried a game at least once.
>
> I know quite a lot CheckiO-players, who solved an impressive amount of
> puzzles, are looking for their next step. I want to help them. I’m sure that
> contributing into Open Source projects can be a great next step for them.
>
> The problem here is that I don't have too much experience in Open Source
> contribution and I want to make sure I do it right from Open Source
> perspective, so maybe you can give me some advice here.
>
> What can be the first step into Open Source? What can be the first
> contribution into Django?
>
> Maybe you know some projects on GitHub that fits better for new
> contributors?
>
> Thank you very much for your contribution into Open Source. I enjoy using
> Django in our projects.
>
> --
> 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/47133ff4-206d-441a-9612-2992a05be293%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



-- 

Cordialement, Coues Ludovic
+336 148 743 42

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

Re: Extend support for long surnames in Django Auth

[ludovic coues]

Someone mentioned mysql not supporting nicely string of 255 unicode characters.

2016-08-02 13:42 GMT+02:00 Malcolm Box :
> Hi Aymeric,
>
> I'm sorry that you feel this has devolved to a bikeshedding fest, that
> certainly wasn't my intent, and I'd hate to see this issue die. I think we
> both agree that supporting people's names is important - which is the main
> thing.
>
> To summarise the available options discussed so far:
>
> Status Quo: Do nothing, and fail to handle a large chunk of the world's
> population who's names don't fit in 30 characters
> Radical changes (in order of increasing radicalness):
>  - Change fields to a TextField
>  - Replace last_name / first_name with a single "name" field
>  - Change startproject to default to a custom user model with default fields
> that are in line with W3C recommendations
> Minimal change: Increase the length of the existing fields
>
> As far as I can see, everyone is in favour of the minimal change option NOW,
> and possibly some of the Radical changes later.
>
> So the only remaining disagreement is over the value of max_length to change
> to. Proposals of 60, 100 and 255 have been made.
>
> If I created a patch that set the max_length to 255, would anyone object? If
> so, what's the objection - storage space shouldn't be a concern, and
> breaking a form seems as likely with 60 as 255?
>
> Cheers,
>
> Malcolm
>
> On 2 August 2016 at 12:26, Aymeric Augustin
>  wrote:
>>
>> Hello Malcolm,
>>
>> > On 02 Aug 2016, at 10:28, Malcolm Box  wrote:
>> >
>> > Having read the W3C Q&A carefully, the relevant comment on field lengths
>> > is "avoid limiting the field size for names in your database".
>>
>> Indeed. I chose to propose something else because I didn’t want the
>> solution to depend on an implementation of “CharField of unlimited length”.
>>
>> That feature isn’t hard to implement but it involves more difficult design
>> decisions. Look at the archives for this mailing-list for more information.
>>
>> Anyway, it seems that this issue is bound to die in a bikeshedding fest,
>> so I’ll leave it there, with my apologies to Brazilian users who will remain
>> unable to log into Django-based websites :-(
>>
>> --
>> Aymeric.
>>
>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Django developers  (Contributions to Django itself)" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/django-developers/h98-oEi7z7g/unsubscribe.
>> To unsubscribe from this group and all its topics, 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/36DD2C84-E5ED-4646-9857-B6BC5D92BE94%40polytechnique.org.
>> 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/CAF3R4sU%3D1gaTk3AGRY7nuQHFX8op9-b00Frc6z_1k69k_R-bNA%40mail.gmail.com.
>
> For more options, visit https://groups.google.com/d/optout.



-- 

Cordialement, Coues Ludovic
+336 148 743 42

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

Re: Extend support for long surnames in Django Auth

[ludovic coues]

The W3C have some recommandation on the question.

https://www.w3.org/International/questions/qa-personal-names

2016-07-29 17:47 GMT+02:00 Aymeric Augustin
:
> Hello,
>
> Indeed, Django’s default limit on last name length doesn’t work well for 
> Brazilians (at least).
>
> Actually having a `first_name` and `last_name` field doesn’t work well in 
> various cultures, including the US when you want a middle initial. Custom 
> user models are the general answer to that question.
>
> In this particular case, the drawbacks of increasing the `max_length` of 
> `first_name` and `last_name` to something like 50 seem limited now that we 
> have the migrations framework. Making that change will automatically avoid 
> the issue for many people — perhaps at the cost of introducing UI issues when 
> the name is displayed in the header, but that’s arguably a lesser evil.
>
> So I’m +0 on making that change.
>
> --
> Aymeric.
>
>> On 29 Jul 2016, at 09:18, Raony Guimaraes Corrêa Do Carmo Lisboa Cardenas 
>>  wrote:
>>
>> Hello everyone,
>>
>> For a long time I was having problems to login to djangopackages.com using 
>> my github account (pydanny/djangopackages#338). After investigating I 
>> discovered the problem was because my surname is longer than 30 characters. 
>> I don't know why both first_name and last_name fields have the same size 
>> limit of 30 characters in Django. That doesn't sound very reasonable.
>>
>> I'm sure there are other people on the same situation and this already 
>> happened with me trying to login in other django websites.
>>
>> Tim Graham suggested I should first ask on this maillist 
>> (https://github.com/django/django/pull/6988#issuecomment-235945422) to see 
>> if there is consensus to make the change.
>>
>> I would like to ask your opinion about an increase from 30 to 60 characters 
>> on last_name field so that my login and others won't break again in the 
>> future. I can create a Trac ticket if the response is positive.
>>
>> Kind Regards,
>>
>>
>>
>> --
>> 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/56bc25d9-372e-4985-b601-3cce9664160c%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/4A15ED67-802B-4A3A-85DA-265A5A5ADEF1%40polytechnique.org.
> For more options, visit https://groups.google.com/d/optout.



-- 

Cordialement, Coues Ludovic
+336 148 743 42

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

Re: Joining the "Python 3 Statement"

[ludovic coues]

The 1.11 release note already tell clearly it will be the last version
of django supporting python2.

2016-07-10 16:17 GMT+02:00 Sam Willis :
> As far as I can tell the only place where Django's Python 2.x deprecation is 
> stated is here https://www.djangoproject.com/weblog/2015/jun/25/roadmap/
>
> I think it should be more prominently stated in the docs, and as 1.11 is 
> supposedly the last to support 2.7 (according to the blog post) it may be 
> worth promoting it as such.
>
> Maybe there should be a pominant announcement about which version is the last 
> to support 2.7? Maybe in the release notes of 1.10?
>
> --
> 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/678cee6c-3df4-4715-b6af-3d20bf3f3822%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



-- 

Cordialement, Coues Ludovic
+336 148 743 42

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

Re: Fate of sql* management commands

[ludovic coues]

2016-06-22 14:13 GMT+02:00 Marcin Nowak :
>
> The reason of removing two differenct ways of managing db schema is clear
> for me. I just do not understand removing the tool without providing decent
> replacement for it.  For example, CBV generics were replacement for FBV
> generics. There was an incompatibility in the interface, but the generic
> views functionality was saved. For "sql*" commands there is no replacement.

I see two reason for not replacing the sql* commands. Lack of interest
and lack of time.

There is a finite amount of time available from volunteer to work on
the project. This time is allocated according to what people want to
do and what is the best for most of the user. I hope.
If theses commands have been dropped, I believe it means they were not
needed by most of the user and they could not be kept without a
non-trivial amount of work.

-- 

Cordialement, Coues Ludovic
+336 148 743 42

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

Re: [RFC] Test methods filtering on tests run

[ludovic coues]

I might be saying something stupid, but rather than filtering test,
would it not be better to have a flag to rerun all the test that
failed in the previous run ?

So the command would always be the same for testA, testB or even both,
and might be more user-friendly if there is a bunch of test failing.

2016-05-17 2:32 GMT+02:00 Josh Smeaton :
> Hi Antonio
>
> I have the same problem when running tests in Django's test suite. When
> there's a failure, I have to copy the test path, paste that, then copy the
> failing test. The entire path to the test isn't printed in the failures. I'd
> be a big fan of *some* kind of implementation that allows me to filter test
> methods. I think I'd prefer some kind of glob syntax though, so I could do:
>
> ./manage.py test app_package**test_method
>
> That would allow you to be as targeted as you needed to be.
>
> Would you mind posting your patch somewhere? Reviewing code along with the
> description and seeing potential for changes would be cool.
>
> Josh
>
> --
> 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/0f9fc55e-9568-41d1-92f9-79effabd8e4b%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.



-- 

Cordialement, Coues Ludovic
+336 148 743 42

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

Re: I have a problem when linking two urls

[ludovic coues]

Without a bit more of information, it will be kinda hard to help you.
The full text of the error, the content on the template with the
button and the content on the related urls.py file would be a nice
start.


2016-03-29 23:09 GMT+02:00 Cristina Elena Stan
:
> Hello!
> I make the login page and the register. After the user logs in on the home
> page i have a "create prescription" button and when i press it it says ERROR
> page not found.
> So the only problem i have is that when i press "create prescription" from
> the home page it doesn;t show me the page.
> Can someone help me please?
>
>
>
> --
> 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/af7e39c1-0a7b-46c7-afe7-1ef85c259fee%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



-- 

Cordialement, Coues Ludovic
+336 148 743 42

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