deconstruct returns 3-tuple?

[Christian González]

Hi,

before I issue a bugreport, I'll ask here first.

On 
https://docs.djangoproject.com/en/3.2/topics/migrations/#adding-a-deconstruct-method 
I can read that deconstruct() returns a 3-tuple.


When I see the code in django.db.models.fields.__init__.py, 
Field.deconstruct() does a


return (self.name, path, [], keywords)

This is a 4-tuple, and even the clone() method written after it calls it 
with


name, path, args, kwargs =self.deconstruct()

So, is 3.2 documentation here on a <1.9 status? Am I understanding 
something not correctly?


Thanks,

Christian

--
Dr. Christian González
https://nerdocs.at

--
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/84db36b4-dc6a-fcc7-28e4-4810d152d2fb%40nerdocs.at.

Re: deconstruct returns 3-tuple?

[Andrew Godwin]

As the note in that section explains, that is for custom *classes*, not for 
custom *fields*. Your observation is correct when applied to field 
deconstruction methods, but not for the system talked about there which lets 
you do it for arbitrary classes (as part of the values in field 
desconstructions, usually).

Andrew

On Sat, Sep 18, 2021, at 9:06 AM, Christian González wrote:
> Hi,
> 
> before I issue a bugreport, I'll ask here first.
> 
> On 
> https://docs.djangoproject.com/en/3.2/topics/migrations/#adding-a-deconstruct-method
>  I can read that deconstruct() returns a 3-tuple.
> 
> When I see the code in django.db.models.fields.__init__.py, 
> Field.deconstruct() does a
> 
> *return *(self.name, path, [], keywords)
>
> 
> This is a 4-tuple, and even the clone() method written after it calls it with
> 
> name, path, args, kwargs = self.deconstruct()
> So, is 3.2 documentation here on a <1.9 status? Am I understanding something 
> not correctly?
> 
> Thanks,
> 
> Christian
> 
> -- 
> Dr. Christian González
> https://nerdocs.at
> 
> 
> -- 
> 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/84db36b4-dc6a-fcc7-28e4-4810d152d2fb%40nerdocs.at
>  
> .

-- 
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/e4c9b368-3fa9-47f4-80c2-22998551cf28%40www.fastmail.com.

Re: deconstruct returns 3-tuple?

[Tim Graham]

That documentation is for serializing classes. There's a note box that 
says, "This return value is different from the deconstruct() method for 
custom fields 

 
which returns a tuple of four items."

On Saturday, September 18, 2021 at 11:06:41 AM UTC-4 Christian González 
wrote:

> Hi,
>
> before I issue a bugreport, I'll ask here first.
>
> On 
> https://docs.djangoproject.com/en/3.2/topics/migrations/#adding-a-deconstruct-method
>  
> I can read that deconstruct() returns a 3-tuple.
>
> When I see the code in django.db.models.fields.__init__.py, 
> Field.deconstruct() does a
>
> return (self.name, path, [], keywords)
>
> 
>
> This is a 4-tuple, and even the clone() method written after it calls it 
> with
>
> name, path, args, kwargs = self.deconstruct()
>
> So, is 3.2 documentation here on a <1.9 status? Am I understanding 
> something not correctly?
>
> Thanks,
>
> Christian
>
> -- 
> Dr. Christian Gonzálezhttps://nerdocs.at
>
>

-- 
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/069eb2d7-e406-4fb5-a736-bd1b8507f937n%40googlegroups.com.

Django Sockets Proposal

[Jet Ezra]

What if in django, we have a uniform way of handling server-side web 
sockets, built-in, not relying on external libraries?
Django Channels would be a deal, but they are broad and endup making us 
forget about the sockets alone, what-if? we have a way of emitting those 
events which can be responded to by the front-end??  

-- 
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/4695e446-011d-41c8-a52c-37cc3057d884n%40googlegroups.com.

Idea

[Jet Ezra]

I know this may not be necessary at the moment because we are comfortable 
depending on front-end frameworks, but I have my two ideas here:

1. what if django alone without any framework can be used to design 
progressive web apps, with routers that do not reload the page, we 
currently have one of the best routing but what if they support SPAs this 
time?

2. what if we could instead of Javascript in the templates, we write 
python, case in example is forexample how we write C# in .NET withing our 
templates not writing JavaScript. Currently Django is requiring its 
developer to again go ahead and learn JS too, what if we remove that??

-- 
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/bdefe58e-b26f-434e-a83f-36917b81f936n%40googlegroups.com.

More boilerplate, less confusion, more harmony.

[Jet Ezra]

Hello, if this was already discussed before, let me know otherwise, I have 
experienced a problem formally faced with other languages where everyone 
has their own of naming their application.

By default creating a django creates a boilerplate that includes apps.py, 
admin.py, models.py, views.py and the rest but leaving out forms.py, 
signals.py, urls.py and modules.py but most developers endup creating these 
files for their specific uses.
The problem comes in only one instance where someone names these 
differently from the convetional way, and it becomes hard to traceback 
their source code.

I suggest they be added with some little docstring for begginers to know 
what can be done in these files just like in the main urls.py of the 
project.

thank you.

-- 
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/e862c598-abf3-4695-9327-5c81a910f389n%40googlegroups.com.