Re: Channels is now an official Django project!

[Abdulrahman Alotaibi]

Congratulations

On Fri, Sep 9, 2016, 11:08 AM Tim Graham  wrote:

> Could you please share the information that you submitted to the technical
> board as per the DEP: "The Shepherd will submit the project, the list of
> people signed up for the Maintenance Team, and the collated arguments to
> the Technical Board for decision."
>
> In hindsight, I expected that information to be shared on this mailing
> list before project is submitted to the technical board. Would it make
> sense to do that in the future?
>
>
> On Friday, September 9, 2016 at 10:58:24 AM UTC-4, Andrew Godwin wrote:
>>
>> Hi everyone,
>>
>> The Technical Board approved Channels as an official Django project as
>> per DEP 7, and so the repositories have been moved under the django/
>> project on GitHub, as well as a few other things the DEP requires, and
>> improving the contribution guidelines and triaging tickets.
>>
>> You can read more in the announcement:
>> https://www.djangoproject.com/weblog/2016/sep/09/channels-adopted-official-django-project/
>>
>> If you have any questions about what this means, I'm happy to answer them
>> here! I'm aiming for a 1.0 release reasonably soon, after one or two minor
>> breaking changes that need to be done (there'll be deprecation warning code
>> in there so things don't mysteriously break on upgrade).
>>
>> Andrew
>>
> --
> 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/d8e29c3b-1cc4-4329-a3ec-968b73417b6f%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Sincerely,
Abdulrahman Alotaibi

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

dumpdata --natural-primary --natural-foreign not serializing pointers to parents in multi-table inheritance

[João Sampaio]

Hello!

I have these classes:

class SuperClassManager(models.Manager):
def get_by_natural_key(self, identifier):
return self.get(identifier=identifier)


class SuperClass(models.Model):
objects = SuperClassManager()

identifier = models.CharField(max_length=31, unique=True)

def natural_key(self):
return (self.identifier, )


class SubClass(SuperClass):
*pass*


*class* SubClassTwo(SuperClass):
pass

When I do

./manage.py dumpdata --natural-foreign --natural-primary --indent 4 app

I get:

[
{
"model": "app.superclass",
"fields": {
"identifier": "one",
}
},
{
"model": "app.superclass",
"fields": {
"identifier": "two",
}
},
{
"model": "app.subclass",
"fields": {}
},
{
"model": "app.subclasstwo",
"fields": {}
}
]

The problem is: superclass of identifier one is a subclass or a
subclasstwo? There's no way to tell. Shouldn't the output be

[
{
"model": "app.superclass",
"fields": {
"identifier": "one",
}
},
{
"model": "app.superclass",
"fields": {
"identifier": "two",
}
},
{
"model": "app.subclass",
"fields": {
"superclass_ptr": [
"one"
]
}
},
{
"model": "app.subclasstwo",
"fields": {
"superclass_ptr": [
"two"
]
}
}
]

Now you can tell that superclass of identifier "two" is actually a
subclasstwo!

Now, I did the homework. I digged into the code. :-)

Happens that *OneToOneFields* that are *parent_links* are marked as
*serialize=False*, so they never get serialized! Even if you create the
field manually in the model, if will still be marked as serialize=False.

Shouldn't *OneToOneFields* that point to parents in *multi-table
inheritance* be serialized? Otherwise, how can you tell which subclass is
the superclass in the serialized output?

What do you think? Do you think this is an issue to be resolved and, if so,
can I submit a pull request?

Thanks.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAO_YKa329BsBTfd%2BeVh45ceMdLLPYFu3FMrzEMDrRFYxm1x2-A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: dumpdata --natural-primary --natural-foreign not serializing pointers to parents in multi-table inheritance

[charettes]

Hi João,

It seems like this is an already reported bug[1] with an existing stale 
PR[2]
you might want to work on.

Cheers,
Simon

[1] https://code.djangoproject.com/ticket/24607
[2] https://github.com/django/django/pull/4473

Le samedi 10 septembre 2016 10:32:01 UTC-4, João Sampaio a écrit :
>
> Hello!
>
> I have these classes:
>
> class SuperClassManager(models.Manager):
> def get_by_natural_key(self, identifier):
> return self.get(identifier=identifier)
>
>
> class SuperClass(models.Model):
> objects = SuperClassManager()
>
> identifier = models.CharField(max_length=31, unique=True)
>
> def natural_key(self):
> return (self.identifier, )
>
>
> class SubClass(SuperClass):
> *pass*
>
>
> *class* SubClassTwo(SuperClass):
> pass
>
> When I do
>
> ./manage.py dumpdata --natural-foreign --natural-primary --indent 4 app
>
> I get:
>
> [
> {
> "model": "app.superclass",
> "fields": {
> "identifier": "one",
> }
> },
> {
> "model": "app.superclass",
> "fields": {
> "identifier": "two",
> }
> },
> {
> "model": "app.subclass",
> "fields": {}
> },
> {
> "model": "app.subclasstwo",
> "fields": {}
> }
> ]
>
> The problem is: superclass of identifier one is a subclass or a 
> subclasstwo? There's no way to tell. Shouldn't the output be
>
> [
> {
> "model": "app.superclass",
> "fields": {
> "identifier": "one",
> }
> },
> {
> "model": "app.superclass",
> "fields": {
> "identifier": "two",
> }
> },
> {
> "model": "app.subclass",
> "fields": {
> "superclass_ptr": [
> "one"
> ]
> }
> },
> {
> "model": "app.subclasstwo",
> "fields": {
> "superclass_ptr": [
> "two"
> ]
> }
> }
> ]
>
> Now you can tell that superclass of identifier "two" is actually a 
> subclasstwo!
>
> Now, I did the homework. I digged into the code. :-)
>
> Happens that *OneToOneFields* that are *parent_links* are marked as 
> *serialize=False*, so they never get serialized! Even if you create the 
> field manually in the model, if will still be marked as serialize=False.
>
> Shouldn't *OneToOneFields* that point to parents in *multi-table 
> inheritance* be serialized? Otherwise, how can you tell which subclass is 
> the superclass in the serialized output?
>
> What do you think? Do you think this is an issue to be resolved and, if 
> so, can I submit a pull request?
>
> Thanks.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5ef1c557-8364-488a-9462-764d4db4f6fa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: dumpdata --natural-primary --natural-foreign not serializing pointers to parents in multi-table inheritance

[João Sampaio]

Great! I've been wanting to contribute to Django for a long time, so I'll
take a shot at this, hopefully I can help.

On Sat, Sep 10, 2016 at 11:56 AM, charettes  wrote:

> Hi João,
>
> It seems like this is an already reported bug[1] with an existing stale
> PR[2]
> you might want to work on.
>
> Cheers,
> Simon
>
> [1] https://code.djangoproject.com/ticket/24607
> [2] https://github.com/django/django/pull/4473
>
>
> Le samedi 10 septembre 2016 10:32:01 UTC-4, João Sampaio a écrit :
>>
>> Hello!
>>
>> I have these classes:
>>
>> class SuperClassManager(models.Manager):
>> def get_by_natural_key(self, identifier):
>> return self.get(identifier=identifier)
>>
>>
>> class SuperClass(models.Model):
>> objects = SuperClassManager()
>>
>> identifier = models.CharField(max_length=31, unique=True)
>>
>> def natural_key(self):
>> return (self.identifier, )
>>
>>
>> class SubClass(SuperClass):
>> *pass*
>>
>>
>> *class* SubClassTwo(SuperClass):
>> pass
>>
>> When I do
>>
>> ./manage.py dumpdata --natural-foreign --natural-primary --indent 4 app
>>
>> I get:
>>
>> [
>> {
>> "model": "app.superclass",
>> "fields": {
>> "identifier": "one",
>> }
>> },
>> {
>> "model": "app.superclass",
>> "fields": {
>> "identifier": "two",
>> }
>> },
>> {
>> "model": "app.subclass",
>> "fields": {}
>> },
>> {
>> "model": "app.subclasstwo",
>> "fields": {}
>> }
>> ]
>>
>> The problem is: superclass of identifier one is a subclass or a
>> subclasstwo? There's no way to tell. Shouldn't the output be
>>
>> [
>> {
>> "model": "app.superclass",
>> "fields": {
>> "identifier": "one",
>> }
>> },
>> {
>> "model": "app.superclass",
>> "fields": {
>> "identifier": "two",
>> }
>> },
>> {
>> "model": "app.subclass",
>> "fields": {
>> "superclass_ptr": [
>> "one"
>> ]
>> }
>> },
>> {
>> "model": "app.subclasstwo",
>> "fields": {
>> "superclass_ptr": [
>> "two"
>> ]
>> }
>> }
>> ]
>>
>> Now you can tell that superclass of identifier "two" is actually a
>> subclasstwo!
>>
>> Now, I did the homework. I digged into the code. :-)
>>
>> Happens that *OneToOneFields* that are *parent_links* are marked as
>> *serialize=False*, so they never get serialized! Even if you create the
>> field manually in the model, if will still be marked as serialize=False.
>>
>> Shouldn't *OneToOneFields* that point to parents in *multi-table
>> inheritance* be serialized? Otherwise, how can you tell which subclass
>> is the superclass in the serialized output?
>>
>> What do you think? Do you think this is an issue to be resolved and, if
>> so, can I submit a pull request?
>>
>> Thanks.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/django-developers/5ef1c557-8364-488a-9462-
> 764d4db4f6fa%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/CAO_YKa0NPFTFQWXGriUC6FdLGdfeR-G60H62Bt4591ZHSscDow%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Feature Request: An easier way to pass the parent object to the form of an InlineModelAdmin

[Al Johri]

Hi All,

Within the Django Admin, I'm trying to pass the current object from 
the ModelAdmin to the InlineModelAdmin. While I've come up with a few 
solutions, I'm finding them all to be extremely hacky and hopefully a 
better solution is possible, perhaps via the addition of a feature. I 
apologize if this is more relevant to Django Users.

*Solution 1 (doesn't work in all cases)*

The cleanest solution  seems 
to override the __init__ method of the InlineModelAdmin's ModelForm class 
which allows access to the current inline instance. Because the current 
inline instance must by definition have a foreign key relationship to the 
parent, one is able to access the page's current object. However, this does 
not work for new inline forms.

class MyInlineModelForm(forms.ModelForm):
def __init__(self, *args, **kwargs):
super().__init__(*args, **kwargs)
self.fields['group'].queryset = 
Car.objects.filter(some_filtering_here=*self.instance.parent*)


*Solution 2*

Another solution , is to 
override the formfield_callback within the ModelAdmin as we still have 
access to the obj parameter at this point. We pass the obj parameter 
through to the formfield_for_dbfield function allowing a particular field 
to change its queryset depending on the page's current obj (i.e filtering a 
select box).

class MyInlineModelAdmin(admin.StackedInline):
def get_formset(self, request, obj=None, **kwargs):
kwargs['formfield_callback'] = partial(self.formfield_for_dbfield, 
request=request, obj=obj)
return super().get_formset(request, obj, **kwargs)

def formfield_for_dbfield(self, db_field, **kwargs):
obj = kwargs.pop('obj', None)
formfield = super().formfield_for_dbfield(db_field, **kwargs)
if db_field.name == "group" and person:
formfield.queryset = Car.objects.filter(some_filtering_here=obj)
return formfield


*Solution 3*

Yet another solution 

 
is to run a regex on the url and utilize the formfield_for_foreignkey to 
filter a select box using the current obj id. This is definitely the 
hackiest and only allows for filtering a select box, not setting initial 
parameters on the inline ModelForm based its the parent object.

class MyInlineModelAdmin(admin.StackedInline):
def formfield_for_foreignkey(self, db_field, request, **kwargs):
if db_field.name == "group":
try:
parent_obj_id = request.resolver_match.args[0]
kwargs["queryset"] = 
Car.objects.filter(some_filtering_here=parent_obj_id)
except IndexError:
pass
return super().formfield_for_foreignkey(db_field, request, **kwargs)


*Expansion on Solution 2 and Summary*

*The root of the issue is the ModelForm has no idea of its current context 
as an inline form within the parent ModelAdmin.*

I've found Solution 2 be the cleanest at this point, but it still has its 
issues.

For example, my child object has a foreign key field (myfield) which needs 
to be filled out based on a relationship to the parent object. I would 
ideally like to just override the save method of the model form and add the 
myfield parameter but I can't since I don't have access to the parent 
object. Instead, I need to pass it in via a hidden input field to the form.

def formfield_for_dbfield(self, db_field, **kwargs):
obj = kwargs.pop('obj', None)
formfield = super().formfield_for_dbfield(db_field, **kwargs)
if db_field.name == "myfield" and obj:
formfield = forms.CharField(initial=*obj.some_relationship.id*, 
widget=forms.HiddenInput())
return formfield


Ideally I could just add the HiddenInput widget and set the initial 
attribute on the formfield but apparently that doesn't work with the 
ModelChoiceField. Instead, I have to completely override the formfield with 
a CharField.

However, because its now a CharField I need to "clean" the parameter in the 
ModelForm to convert it back into a model. (hacky!)

def clean_myfield(self):
data = self.cleaned_data['myfield']
return MyModel.objects.get(id=int(data))


There *must* be an easier way to do all of this! What am I missing? Any 
help would be appreciated.

Thanks,

Al

-- 
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/159b0599-91c1-42c9-8dc4-db0451e50a10%40googlegroups.com.
For more options, vi

Re: Logging config tries too hard

[Cristiano Coelho]

I had troubles understanding the logging setup the first time, but after 
that, its quite simple on every project. I usually end up copy/pasting some 
console and db logger class and just add it to the config, I don't really 
think it is that difficult

El martes, 6 de septiembre de 2016, 9:57:16 (UTC-3), Ivan Sagalaev escribió:
>
> Hello everyone,
>
> It's been a while since I last posted here, please forgive if I break any 
> new rules inadvertently.
>
> I'd like to revisit a decision made in [18993][]. My use case is very 
> simple and obvious: I want all logging going into stdout.
>
> As currently implemented, I can't do it easily with a custom `LOGGING` 
> setting, because:
>
> - If I leave existing Django loggers enabled it ties me to the behavior 
> chosen by Django, which doesn't necessarily match what I want. For example, 
> Django won't log debug and info messages if `DEBUG = False`. And with 
> `DEBUG = True` I will be having two log messages for every log into the 
> 'django' logger: one from the Django's own handler, and another after it 
> propagates to my root logger.
>
> - If I disable existing Django loggers, I effectively disable all logging 
> from Django (and from 'py.warnings' for good measure).
>
> In fact, the idea of providing a default logging configuration which a 
> user can then *build upon* isn't really workable with Python logging: you 
> can either fully reuse or fully discard what's been provided, but you can't 
> meaningfully define a consistent configuration. Also, I have my doubts that 
> this "build upon" use case is based on any real demand. In my experience 
> there are only two approaches to configuring logging: "logging? huh, didn't 
> think about it" and "get your hands off my logging, I know what I'm doing!"
>
> The latter, incidentally, is what the old way was doing: define a sensible 
> default value for `LOGGING` and let users to overwrite it completely. 
> Currently, the default logging configuration is hard-coded in 
> `django.utils.log`.
>
> Also, I couldn't find the actual reasoning for the current behavior in the 
> original ticket. It starts talking about having a more useful default, not 
> about changing the way how this default configuration is applied.
>
> [18993]: https://code.djangoproject.com/ticket/18993
>

-- 
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/f5b99bf1-ab67-412b-86e5-546d3a88dc2e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Fellow Report - September 10, 2016

[Tim Graham]

Triaged

---

https://code.djangoproject.com/ticket/27173 - Permit import statements to 
be longer than 80 characters (wontfix)

https://code.djangoproject.com/ticket/27186 - Cannot change DateTimeField 
with default via Admin since Django 1.10.1 (accepted)

https://code.djangoproject.com/ticket/27180 - Check for sql_mode fails 
during migration with special database connections (accepted)

https://code.djangoproject.com/ticket/27178 - ImageField when default 
provided in model, it's impossible to change the value. (accepted)

https://code.djangoproject.com/ticket/27181 - Sites framework does not 
normalize domains with trailing "." (accepted)

https://code.djangoproject.com/ticket/27184 - Test client crashes when 
uploading TemporaryFile on Unix (accepted)

https://code.djangoproject.com/ticket/27188 - Allow using unique=True with 
FileField

https://code.djangoproject.com/ticket/27190 - Internet explorer 9 fails to 
load Roboto-Regular.woff font (wontfix)

https://code.djangoproject.com/ticket/27192 - Allow pluralizing admin URLs 
(wontfix)

https://code.djangoproject.com/ticket/27198 - QueryDict getlist allows data 
to be mutated (accepted)

https://code.djangoproject.com/ticket/27199 - Integer inputs marked as 
type="text" instead of type="number" (accepted)

https://code.djangoproject.com/ticket/27202 - Investigate RenameMethodsBase 
effect on yaml serialization (accepted)

https://code.djangoproject.com/ticket/27197 - Document how blank=True 
affects the migrations questioner (wontfix)

https://code.djangoproject.com/ticket/26524 - Change foreign key id 
list_display reference to display only the id (reopened due to regression)

Authored



https://github.com/django/django/pull/7217 - Fixed #27186, #27178 -- Fixed 
model form default fallback for MultiWidget and FileInput.

https://github.com/django/django/pull/7224 - Fixed #27204 -- Made clashing 
m2m intermediary table checks ignore unmanaged models.

https://github.com/django/djangosnippets.org/pull/49 - Update to Python 
3.5.2

https://github.com/django/djangosnippets.org/pull/50 - Add Django 1.10 to 
versions choices

Reviewed/committed

--

https://github.com/django/django/pull/7216 - Fixed #27180 -- Fixed a crash 
in MySQL checks where SELECT @@sql_mode doesn't return a result.

https://github.com/django/django/pull/7206 - Fixed #27170 -- Eased 
subclassing DatabaseWrapper by adding class attributes for helper classes.

https://github.com/django/django/pull/7215 - Fixed #27191 -- Fixed error 
reports for requests with 'items' in GET/POST/COOKIES/FILES.

https://github.com/django/django/pull/7176 - Fixed #27143 -- Allowed 
combining SearchQuery with more than one & or | operators.

https://github.com/django/django/pull/7220 - Fixed #27199 -- Made 
AdminIntegerFieldWidget use NumberInput.

https://github.com/django/django/pull/5667 - Fixed #27062 -- Eased 
implementing select_for_update() on MSSQL.

https://github.com/django/django/pull/7112 - Fixed #27083 -- Added support 
for weak ETags.

https://github.com/django/django/pull/6031 - Fixed #26097 -- Added 
password_validators_help_text_html to UserCreationForm.

Reviews of core dev work



https://github.com/django/django/pull/6979 - Fixed #26956 -- Allow 
redirecting to safe external hosts in LoginView and LogoutView.

https://github.com/django/django/pull/7208 - Fixed #27175 -- Deprecated 
silencing exceptions from the {% include %} template tag

https://github.com/django/django/pull/7132 - Fixed #27098 -- Deprecated 
DatabaseIntrospection.get_indexes().
https://github.com/django/django/pull/7188 - Fixed #26401 -- Added 
BaseAuthConfig to use auth without database tables.

-- 
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/b74b873e-f05b-4120-adb8-8b4dd04ef9ee%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.