Re: [Django] #27685: Allow autoreloader to use watchman

2017-07-23 Thread Django 
#27685: Allow autoreloader to use watchman
--+
 Reporter:  Aymeric Augustin  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Utilities |  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 Tom):

 * cc: Tom (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/067.883d51624b3539b3930cbd6734020c82%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28163: Make the default settings.py pass pep8

2017-07-23 Thread Django 
#28163: Make the default settings.py pass pep8
-+-
 Reporter:  Yoni Lavi|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Core (Other) |  Version:  1.11
 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 Yoni Lavi):

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


Comment:

 Hi folks,
 I'm sorry to rehash this, but the current validator verbosity keeps
 bugging me on my own projects and I'm sure I'm not the only one. So I just
 wanted to ask if you would be open to a more flexible approach such as
 using this sort of utility function (to be included in django.utils?):

 {{{#!python
 def basic_password_validator(class_name, **kwargs):
 MODULE_PATH = 'django.contrib.auth.password_validation.'
 validator = {'NAME': '.'.join(MODULE_PATH, class_name)}
 validator.update(kwargs)
 return validator


 AUTH_PASSWORD_VALIDATORS = [
 basic_password_validator('UserAttributeSimilarityValidator'),
 basic_password_validator('MinimumLengthValidator',
  OPTIONS={'min_length': 9}),
 basic_password_validator('CommonPasswordValidator'),
 basic_password_validator('NumericPasswordValidator'),
 ]
 }}}

 So I'm just looking for feedback about whether this sort of approach might
 be deemed acceptable, and if so whether you have advice about the specific
 implementation. If not, I promise to stop spamming this ticket :)

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

Re: [Django] #27685: Allow autoreloader to use watchman

2017-07-23 Thread Django 
#27685: Allow autoreloader to use watchman
--+
 Reporter:  Aymeric Augustin  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Utilities |  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
--+

Comment (by Tom):

 For reference, flask has quite a nice reloading implementation that uses
 Watchdog:
 https://github.com/pallets/werkzeug/blob/master/werkzeug/_reloader.py

 Django obviously cannot bundle watchman as a Watchdog, so it will have to
 use a 'dumb' stat based implementation as it's base. While this is the
 lowest common denominator it is OK for tiny projects, we could detect when
 the number of watched files exceeds X and display a helpful message, like
 'install the `watchdog` package for fun and profit'. This seems to be the
 easiest way forward to improve the reloader in general, the current
 implementation is in great need of some improvements.

 I really like Watchman though (https://facebook.github.io/watchman/), a
 frontend frameworks that I use utilizes it. It has a socket API and runs
 as a service, so if it's available (there is an official API package) we
 could add this as a supported reloader.

 The reloading code in general is a bit of a black box, but it shouldn't
 be. If a re-implementation is on the cards then maybe it could be
 pluggable by third party apps that want to do something when files change
 during development. One interesting use case could be triggering a page
 reload when template files change.

-- 
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.9196fd7d91e40635f5fa3d24539c047f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28403: Improve the example for FORMAT_MODULE_PATH and add missing formats

2017-07-23 Thread Django 
#28403: Improve the example for FORMAT_MODULE_PATH and add missing formats
--+
 Reporter:  karyon|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.11
 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
--+

Comment (by karyon):

 to be specific, with "locale path" i meant the
 [https://docs.djangoproject.com/en/dev/ref/settings/#locale-paths
 LOCALE_PATHS setting] as far as i understand, the [
 
https://github.com/django/django/blob/550cb3a365dee4edfdd1563224d5304de2a57fda/django/utils/formats.py#L62
 code for determining the format locale locations] does not look into
 LOCALE_PATHS. so yes, as far as i understand one has to specify
 FORMAT_MODULE_PATH besides LOCALE_PATHS.

 i'm using LOCALE_PATHS for translations. initially i though that any
 project using FORMAT_MODULE_PATH also has translations and therefore uses
 LOCALE_PATHS anyways, but from a quick github search that doesn't seem to
 be the case. so now i wouldn't replace {{{formats}}} by {{{locale}}}, but
 rather simply mention that the locale structure can be used.

 actually from my point of view it would make sense to merge these
 settings. you specify where the locales are, and in there there might be
 translations and/or formats. or, one could at least make
 FORMAT_MODULE_PATH look into LOCALE_PATHS by default. however, the former
 is a python path while the latter is a normal path with slashes. but
 maybe, since this has been like that for 8 years according to git blame,
 maybe this doesn't need fixing :)
 
https://github.com/django/django/blob/550cb3a365dee4edfdd1563224d5304de2a57fda/django/utils/formats.py#L62

-- 
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/064.f9ba5f738fbac291261b5492961ca51e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28385: deserializers ignore natural keys when primary key has a default value

2017-07-23 Thread Django 
#28385: deserializers ignore natural keys when primary key has a default value
-+-
 Reporter:  Daniel Knell |Owner:  Irindu
 |  Indeera
 Type:  Bug  |   Status:  assigned
Component:  Core |  Version:  1.11
  (Serialization)|
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Dmytryi Striletskyi):

 {{{
 def build_instance(Model, data, db):
 obj = Model(**data)

 if obj.pk is None or (hasattr(Model, 'natural_key') and
   hasattr(Model._default_manager,
 'get_by_natural_key')):
 natural_key = obj.natural_key()
 try:
 obj.pk =
 Model._default_manager.db_manager(db).get_by_natural_key(*natural_key).pk
 except Model.DoesNotExist:
 pass
 return obj
 }}}

 I can provide this solution:
 > if obj.pk is None or (hasattr(Model, 'natural_key') and
 hasattr(Model._default_manager, 'get_by_natural_key')):

 If  `pk` is set - it is update model via `return obj` without `updating
 pk` logic.
 If `pk` isn't set, but `natural key` implementation exists - `if False or
 True` (return `True`) - go to `updating pk` logic.

 I did test manually, it seems to fix bug.
 Am I on right way, Daniel Knell?

-- 
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/069.2fc186c2afe44cd08061656708352355%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28385: deserializers ignore natural keys when primary key has a default value

2017-07-23 Thread Django 
#28385: deserializers ignore natural keys when primary key has a default value
-+-
 Reporter:  Daniel Knell |Owner:  Irindu
 |  Indeera
 Type:  Bug  |   Status:  assigned
Component:  Core |  Version:  1.11
  (Serialization)|
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Daniel Knell):

 When a models primary key has default set, and a fixture is loaded that
 does not have a pk attribute, then the serialisation code will refuse to
 update the existing instance and instead try to create a new record in the
 db.

 When the primary key attribute has a default value - such as models using
 UUID primary keys - the model will fill the pk attribute with that at
 instantiation time, and the check in build_instance will see that default
 value and refuse to goto the database to fetch the existing instance.

 This is against the expectations set in the docs, that when the
 model/manager implement the natural keys interfaces and the primary key is
 omitted, the framework will update the existing instance when
 deserialising.

-- 
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/069.03ae30f88f6cceb51592a112e61145b5%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28385: deserializers ignore natural keys when primary key has a default value

2017-07-23 Thread Django 
#28385: deserializers ignore natural keys when primary key has a default value
-+-
 Reporter:  Daniel Knell |Owner:  Irindu
 |  Indeera
 Type:  Bug  |   Status:  assigned
Component:  Core |  Version:  1.11
  (Serialization)|
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Dmytryi Striletskyi):

 Hello,

 I cannot reproduce this bug, i tried few ways, but got no error during
 `loaddata`.
 May my understanding is not clear, but how do we want to get `natural_key`
 if `Foo` model's `primary key` exists?

 From `build_instance` docstring:
 > If the model instance doesn't have a primary key and the model supports
 natural keys, try to retrieve it from the database.

 Clarify bug's space for me, please. I wanna resolve it. 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/069.c74e82c29fa0aa6763a3bb6e6714e54b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.