Re: [Django] #4136: CharField(null=True, blank=True, unique=True)

[Django]

#4136: CharField(null=True, blank=True, unique=True)
-+-
 Reporter:  David Cramer |Owner:
  |
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  1.3-rc
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by claudep):

 * owner:  aashu_dwivedi =>
 * status:  assigned => new
 * needs_docs:  1 => 0
 * needs_tests:  1 => 0
 * needs_better_patch:  1 => 0


--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/090.d0611e0010bd592d4d00a09ce6b7da9c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26623: Customizing environment variable for RemoteUserMiddleware requires subclass (was: Customizing environment variable for for RemoteUserMiddleware requires subclass)

[Django]

#26623: Customizing environment variable for RemoteUserMiddleware requires 
subclass
--+--
 Reporter:  adelton   |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  contrib.auth  |  Version:  1.9
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Unreviewed
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.4a835d0fa7bdf87a95f315c243596f58%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #26640: class_prepared is not a ModelSignal and differs from documentation

[Django]

#26640: class_prepared is not a ModelSignal and differs from documentation
--+
 Reporter:  AlexHill  |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  master
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  1
Easy pickings:  0 |  UI/UX:  0
--+
 A few minor issues with class_prepared:

 1. it's documented as a model signal, and so able to be called with lazy
 references, but it isn't one and can't be.

 > Model signals sender model can be lazily referenced when connecting a
 receiver by specifying its full application label.

 2. it's documented as being sent after the model is registered, but it's
 actually sent just before

 > Sent whenever a model class has been “prepared” – that is, once model
 has been defined and registered with Django’s model system.

 In `ModelBase.__new__()`:

 {{{#!python
 ...
 new_class._prepare()  # class_prepared.send() is called at the end
 of this method
 new_class._meta.apps.register_model(new_class._meta.app_label,
 new_class)
 return new_class
 }}}

 3. it's instantiated with `providing_args=["class"]`, but it doesn't
 provide a `class` argument

 All three addressed in PR 6628.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/051.aa926fa04501ebc71917bca691908cf5%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26421: ModelSignal should use Apps.lazy_model_operation

[Django]

#26421: ModelSignal should use Apps.lazy_model_operation
-+-
 Reporter:  AlexHill |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"2ff7ef15b0a1d41e3f121e96cb72a383863046c0" 2ff7ef15]:
 {{{
 #!CommitTicketReference repository=""
 revision="2ff7ef15b0a1d41e3f121e96cb72a383863046c0"
 Refs #26421 -- Refactored Apps.lazy_model_operation() for better checks
 and tests
 }}}

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.90298764a5f386db786abca7a9a01e6f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26421: ModelSignal should use Apps.lazy_model_operation

[Django]

#26421: ModelSignal should use Apps.lazy_model_operation
-+-
 Reporter:  AlexHill |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 In [changeset:"779bb82f519420418a711f7ae75e71d600de3224" 779bb82f]:
 {{{
 #!CommitTicketReference repository=""
 revision="779bb82f519420418a711f7ae75e71d600de3224"
 Fixed #26421 -- Refactored ModelSignal to use Apps.lazy_model_operation()
 }}}

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.bd98e1d6479f7984a0c89134c99aa16d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25612: django.contrib.auth should include support for 2fa out of the box

[Django]

#25612: django.contrib.auth should include support for 2fa out of the box
--+
 Reporter:  alex  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  contrib.auth  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by edmorley):

 * cc: emorley@… (added)


--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/062.d6521be7ae2d5244b0fd2e32932368dc%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26639: Default to ASCIIUsernameValidator (instead of UnicodeUsernameValidator) in Django 1.10

[Django]

#26639: Default to ASCIIUsernameValidator (instead of UnicodeUsernameValidator) 
in
Django 1.10
-+-
 Reporter:  davidtgq |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  contrib.auth |  Version:  1.9
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  users, username, | Triage Stage:
  unicode, ascii |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * status:  new => closed
 * needs_better_patch:   => 0
 * resolution:   => wontfix
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 Please read the [https://groups.google.com/d/topic/django-
 developers/MBSWXcQBP3k/discussion django-developers discussion] and add
 your view there if you disagree with the conclusions. Thanks.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.ff81007a3579109f5811c41fe8e26f2d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #26639: Default to ASCIIUsernameValidator (instead of UnicodeUsernameValidator) in Django 1.10

[Django]

#26639: Default to ASCIIUsernameValidator (instead of UnicodeUsernameValidator) 
in
Django 1.10
-+-
 Reporter:  davidtgq |  Owner:  nobody
 Type:  New feature  | Status:  new
Component:   |Version:  1.9
  contrib.auth   |
 Severity:  Normal   |   Keywords:  users, username, unicode, ascii
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+-
 Would Django devs please consider using ASCIIUsernameValidator as the
 default, and leave UnicodeUsernameValidator as an opt-in option?

 I don't have the experience in this industry to provide a solid list of
 technical reasons or arguments for why this should be done, but perhaps I
 can try to provide a reason for Django usability from a user standpoint:

 A Django user who is trying to save time and get a product out the door
 isn't going to focus on finer details such as Unicode usernames, and will
 be in for a shock when he finds out a bunch of his users have registered
 themselves with Egyptian hieroglyphics. He may be very frustrated,
 eventually figuring out that he must subclass the User model and set
 `username_validator = ASCIIUsernameValidator()` to get the functionality
 he expected. And what is he to do with the existing Unicode users, delete
 all their accounts?

 Whereas a technologically forward user might be friendlier towards Unicode
 usernames, and would be well-informed on these capabilities within Django.
 Furthermore, the technologically forward user will be more likely to
 already have a custom user model, and won't find it cumbersome to
 explicitly enable Unicode usernames. Enabling Unicode usernames isn't
 destructive like disabling it would be (no need to figure out what to do
 with the existing users offending the validation), so users can simply
 start using it immediately.

 Thanks!

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/051.f558202835b2447d34657423be24d0e7%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26638: Allow callable in defaults argument for QuerySet.get_or_create

[Django]

#26638: Allow callable in defaults argument for QuerySet.get_or_create
-+-
 Reporter:  mlorant  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Description changed by mlorant:

Old description:

> It would be nice if `get_or_create` handles callable in the `defaults`
> parameter so the defaults value are not computed at each selection.
> Indeed, if your default values for insertion contains selection of
> related object or any long computation, it is done at each call, even if
> the object can be retrieved without insertion (and so the defaults
> parameter is not used).
>
> In term of code, I would like to do something like this:
>
> {{{
> SomeObject.objects.get_or_create(
>key1=value1,
>key2=value2,
>defaults={
>  'key3': lambda: long_processing_to_get_default(),
>  # or even
>  'key3': lambda:
> OtherModel.objects.get(pk=request.some_value)
>}
> )
> }}}
>

> For backward-compatibility and ease of writing, it should still accept
> values that are not callables. See the patch attached (unit tests are
> missing so it is not complete!)

New description:

 It would be nice if `get_or_create` handles callable in the `defaults`
 parameter so the defaults value are not computed at each selection.
 Indeed, if your default values for insertion contains selection of related
 object or any long computation, it is done at each call, even if the
 object can be retrieved without insertion (and so the defaults parameter
 is not used).

 In term of code, I would like to do something like this:

 {{{
 SomeObject.objects.get_or_create(
key1=value1,
key2=value2,
defaults={
  'key3': lambda: long_processing_to_get_default(),
  # or even
  'key3': lambda: OtherModel.objects.get(pk=request.some_value)
}
 )
 }}}


 For backward-compatibility and ease of writing, it should still accept
 values that are not callables. ~~See the patch attached (unit tests are
 missing so it is not complete!)~~ My patch is wrong in fact: it computes
 the value before the selection and it consider the dict as a whole
 callable instead of a single key of the dict... Anyway the implementation
 inside the `except DoesNotExist` should be easy :)

--

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.ff9eb705227f86df33c0659e2f9cee09%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24100: Make `post_migrate` dispatch the migration plan.

[Django]

#24100: Make `post_migrate` dispatch the migration plan.
-+-
 Reporter:  charettes|Owner:  MarkusH
 Type:  New feature  |   Status:  closed
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Simon Charette ):

 In [changeset:"05a9f3a09a5a2334fe1d1675f46ea524240999b3" 05a9f3a0]:
 {{{
 #!CommitTicketReference repository=""
 revision="05a9f3a09a5a2334fe1d1675f46ea524240999b3"
 Refs #24100 -- Fixed a test failure on MySQL related to non-transactional
 DDL.

 Thanks Tim for the report.
 }}}

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.d1aa8bd741b6cc51557b9965450b9e78%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26638: Allow callable in defaults argument for QuerySet.get_or_create

[Django]

#26638: Allow callable in defaults argument for QuerySet.get_or_create
-+-
 Reporter:  mlorant  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by mlorant):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


Old description:

> It would be nice if `get_or_create` handles callable in the `defaults`
> parameter so the defaults value are not computed at each selection.
> Indeed, if your default values for insertion contains selection of
> related object or any long computation, it is done at each call, even if
> the object can be retrieved without insertion (and so the defaults
> parameter is not used).
>
> In term of code, I would like to do something like this:
>
> {{{
> SomeObject.objects.get_or_create(
>key1=value1,
>key2=value2,
>defaults={
>  'key3': long_processing_to_get_default(),
>  # or even
>  'key3': lambda:
> OtherModel.objects.get(pk=request.some_value)
>}
> )
> }}}
>

> For backward-compatibility and ease of writing, it should still accept
> values that are not callables. See the patch attached (unit tests are
> missing so it is not complete!)

New description:

 It would be nice if `get_or_create` handles callable in the `defaults`
 parameter so the defaults value are not computed at each selection.
 Indeed, if your default values for insertion contains selection of related
 object or any long computation, it is done at each call, even if the
 object can be retrieved without insertion (and so the defaults parameter
 is not used).

 In term of code, I would like to do something like this:

 {{{
 SomeObject.objects.get_or_create(
key1=value1,
key2=value2,
defaults={
  'key3': lambda: long_processing_to_get_default(),
  # or even
  'key3': lambda: OtherModel.objects.get(pk=request.some_value)
}
 )
 }}}


 For backward-compatibility and ease of writing, it should still accept
 values that are not callables. See the patch attached (unit tests are
 missing so it is not complete!)

--

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.ac7ceb71e977ac72786a0a570a2da79d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26638: Allow callable in defaults argument for QuerySet.get_or_create

[Django]

#26638: Allow callable in defaults argument for QuerySet.get_or_create
--+
 Reporter:  mlorant   |  Owner:  nobody
 Type:  New feature   | Status:  new
Component:  Database layer (models, ORM)  |Version:  master
 Severity:  Normal| Resolution:
 Keywords:|   Triage Stage:  Unreviewed
Has patch:  0 |  Easy pickings:  1
UI/UX:  0 |
--+
Changes (by mlorant):

 * Attachment "patch26638.txt" added.


--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.4b3986a9319e212a0deaf43ec4160b06%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #26638: Allow callable in defaults argument for QuerySet.get_or_create

[Django]

#26638: Allow callable in defaults argument for QuerySet.get_or_create
--+
 Reporter:  mlorant   |  Owner:  nobody
 Type:  New feature   | Status:  new
Component:  Database layer (models, ORM)  |Version:  master
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  1 |  UI/UX:  0
--+
 It would be nice if `get_or_create` handles callable in the `defaults`
 parameter so the defaults value are not computed at each selection.
 Indeed, if your default values for insertion contains selection of related
 object or any long computation, it is done at each call, even if the
 object can be retrieved without insertion (and so the defaults parameter
 is not used).

 In term of code, I would like to do something like this:

 {{{
 SomeObject.objects.get_or_create(
key1=value1,
key2=value2,
defaults={
  'key3': long_processing_to_get_default(),
  # or even
  'key3': lambda: OtherModel.objects.get(pk=request.some_value)
}
 )
 }}}


 For backward-compatibility and ease of writing, it should still accept
 values that are not callables. See the patch attached (unit tests are
 missing so it is not complete!)

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/050.255494caa2aff15f3c25e775d75cab34%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26621: simplify_regex having problems with named capture groups

[Django]

#26621: simplify_regex having problems with named capture groups
---+--
 Reporter:  cancan101  |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Old description:

> For example using the regex from [http://www.django-rest-framework.org
> /api-guide/versioning/ here]:
>

> {{{
> simplify_regex(r'^(?P(v1|v2))/bookings/(?P[0-9]+)/$')
>
> '//bookings//'
> }}}
>
> Escaping the `/` does not seem to help.

New description:

 For example using the regex from [http://www.django-rest-framework.org
 /api-guide/versioning/ here]:


 {{{
 simplify_regex(r'^(?P(v1|v2))/bookings/(?P[0-9]+)/$')

 '//bookings//'
 }}}

 Escaping the `/` does not seem to help.

 EDIT: Somehow I pasted the wrong output. I come out as
 `'/)/bookings//'` which is clearly broken.

--

Comment (by cancan101):

 Somehow I pasted the wrong output. I come out as
 `'/)/bookings//'`

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.f2232e727e981697b12149a94ce37a50%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26621: simplify_regex having problems with named capture groups

[Django]

#26621: simplify_regex having problems with named capture groups
---+--
 Reporter:  cancan101  |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by akki):

 * needs_better_patch:   => 0
 * version:  1.9 => master
 * needs_tests:   => 0
 * needs_docs:   => 0


Old description:

> For example using the regex from [here](http://www.django-rest-
> framework.org/api-guide/versioning/):
>

> {{{
> simplify_regex(r'^(?P(v1|v2))/bookings/(?P[0-9]+)/$')
>
> '/)/bookings//'
> }}}
>
> Escaping the `/` does not seem to help.

New description:

 For example using the regex from [http://www.django-rest-framework.org
 /api-guide/versioning/ here]:


 {{{
 simplify_regex(r'^(?P(v1|v2))/bookings/(?P[0-9]+)/$')

 '//bookings//'
 }}}

 Escaping the `/` does not seem to help.

--

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.ba9140a5dfad82f9b681c6928d99eb7b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26515: trim_joins bug with nested related models using ForeignObject

[Django]

#26515: trim_joins bug with nested related models using ForeignObject
-+-
 Reporter:  ornoone  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  ForeignObject,   | Triage Stage:  Accepted
  trim_join, orm |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 In [changeset:"a7ad473ad27995736b07750ac64e2651ff790529" a7ad473a]:
 {{{
 #!CommitTicketReference repository=""
 revision="a7ad473ad27995736b07750ac64e2651ff790529"
 Fixed #26515 -- Fixed Query.trim_joins() for nested ForeignObjects.
 }}}

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.d8aa68305b37825f3e3b3efe87f9adf9%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26637: Docs says Sphinx 1.0.2 is required but code says 1.3

[Django]

#26637: Docs says Sphinx 1.0.2 is required but code says 1.3
---+--
 Reporter:  adelton|Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Documentation  |  Version:  master
 Severity:  Normal |   Resolution:  fixed
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by Tim Graham ):

 In [changeset:"d1c6e063ffa69df6e8408151bd5d78408b81d8f5" d1c6e06]:
 {{{
 #!CommitTicketReference repository=""
 revision="d1c6e063ffa69df6e8408151bd5d78408b81d8f5"
 [1.9.x] Fixed #26637 -- Removed obsolete note in
 docs/internals/contributing/writing-documentation.txt

 Backport of 2e1d44e46d1ea3d8c9fdc5c323a127f51006f6c3 from master
 }}}

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.903ac50741fa8e0b22fe61ec1ec916f0%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26637: Docs says Sphinx 1.0.2 is required but code says 1.3

[Django]

#26637: Docs says Sphinx 1.0.2 is required but code says 1.3
---+--
 Reporter:  adelton|Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Documentation  |  Version:  master
 Severity:  Normal |   Resolution:  fixed
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Tim Graham ):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 In [changeset:"2e1d44e46d1ea3d8c9fdc5c323a127f51006f6c3" 2e1d44e]:
 {{{
 #!CommitTicketReference repository=""
 revision="2e1d44e46d1ea3d8c9fdc5c323a127f51006f6c3"
 Fixed #26637 -- Removed obsolete note in docs/internals/contributing
 /writing-documentation.txt
 }}}

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.d4cff9aa9b4e7630dfdc70676abb5443%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26637: Docs says Sphinx 1.0.2 is required but code says 1.3

[Django]

#26637: Docs says Sphinx 1.0.2 is required but code says 1.3
---+--
 Reporter:  adelton|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Documentation  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by adelton):

 * needs_better_patch:   => 0
 * has_patch:  0 => 1
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 Filed https://github.com/django/django/pull/6625.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.2afd841c4e4bbb15d400f27946294257%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #26637: Docs says Sphinx 1.0.2 is required but code says 1.3

[Django]

#26637: Docs says Sphinx 1.0.2 is required but code says 1.3
---+
 Reporter:  adelton|  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Documentation  |Version:  master
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 The https://docs.djangoproject.com/en/dev/internals/contributing/writing-
 documentation/ says:

Note
Building the Django documentation requires Sphinx 1.0.2 or newer.

 When I install python-sphinx-1.2.3-4.fc23.noarch and run ```make html```,
 I get

Making output directory...
Running Sphinx v1.2.3
Sphinx version error:
This project needs at least Sphinx v1.3 and therefore cannot be built
 with this version.

 Indeed, docs/conf.py has

needs_sphinx = '1.3'  # Actually 1.3.4, but micro versions aren't
 supported here.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/050.b3adbbfd2976bc72fb9d7ddd0d5daf17%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26635: "memory_cost" of Argon2PasswordHasher

[Django]

#26635: "memory_cost" of Argon2PasswordHasher
-+-
 Reporter:  danielfeng   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  contrib.auth |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by danielfeng):

 Replying to [comment:2 bwesterb]:
 > This is an inconsistency in the reference C implementation itself.  The
 specification and the reference C implementation ''do not'' limit
 themselves to power of two memory_cost's.  For some unknown reason, the
 commandline util which is shipped, does limit itself to power of two.  In
 the source code of the commandline util (src/run.c) we find
 >
 > {{{
 > m_cost = ARGON2_MIN(UINT64_C(1) << input, UINT32_C(0x));
 > }}}
 >
 > I see two possible solutions.
 >
 > The first one is to use power-of-two memory_cost's in Argon2.  We should
 then also rename memory_cost to memory_cost_exp to reduce confusion the
 other way around.  A big drawback is that we loose fine-grained control
 over the running time of Argon2.  Every increase in memory_cost_exp will
 (at the very least) double the running time of the hash.  (Recall that it
 is strongly advised to increase memory_cost instead of time_cost, to
 strengthen the hash.)
 >
 > The second solution is to ask the Argon2 developers to change their util
 and add a second option -M which allows one to specify an arbitrary
 memory_cost.

 Thanks for the investigation.  Another possible issue is that the
 '''hash_len''' is currently harded-coded to use
 '''argon2.DEFAULT_HASH_LENGTH''', which is '''16''' for now.  I'm not sure
 if such value could change / may be changed in the future, and if that
 happens, would the validation fail.  Haven't looked into validation logic
 thus don't know if the hash value needs to be 100% match.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.93f851f90dbfa2ebe442b37f5214fc96%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.