Re: structural & functional review of django documentation

[Doug Epling]

Hi Scot --

Search terms would be another really great source of information.  
collecting these and somehow relating them to user's ensuing journey 
through the documentation could be very helpful.

thanks,

On Monday, January 4, 2016 at 2:45:56 AM UTC-5, Scot Hacker wrote:
>
> The written quality of the Django docs has been a selling point for years, 
> but discoverability has never been great. I wanted to add two notes:
>
> 1) The front page of the docs says docs are organized into four sections 
> (Tutorials, Topic Guides, Reference Guides,  How-To Guides). And it's been 
> proposed that we add a fifth docstring-generated API Reference as well. But 
> remember that most people looking to solve a problem under deadline start 
> with search, not taxonomy. Search results do *seem* to be labeled with the 
> section of the docs they come from, but the sections referenced don't 
>  actually correspond to the four sections we say use!  If I search for 
> "forms" I get results that claim to come from "API Reference," "Using 
> Django," "Release Notes," which don't match the names of our four sections. 
>  I propose that A) search results clearly indicate the doc sections that we 
> claim we use for organization; B) Search results be grouped by type (e.g. 
> show all results from Using Django first, followed by all results from API 
> Reference)... or whatever. Or a user could use checkboxes to select which 
> section of the docs they want to search. Or faceted search results so users 
> can quickly toggle or filter the sources of the search results? There are a 
> lot of ways to solve this - just pointing out that our search experiences 
> could be  sharper and more customizable.
>
> 2) I've encountered a number of situations where search didn't help 
> because I didn't yet know enough to search for the right thing. I remember 
> early in my Django experience trying to figure out how to have a "global 
> variable" for my project and that search string not turning up what I 
> needed to know... because what I really should have been searching for was 
> "context processors".* I think we could make strides in search-ability 
> through the indication of a tagging system. Tags could either be controlled 
> through commits, or dynamic (users could tag topics on the fly, and a 
> weighting system would apply to search results). 
>
> * Even today, searching the docs for "context processor" does not take me 
> quickly to a clean example of how to implement a context processor - I 
> really have to dig for this information. 
>
> ./s
>
>

-- 
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/f772dd19-967b-48a5-9926-9bf723b698a3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Request for Input: WSGI 2.0

[Andrew Godwin]

Hi Cory,

I'll reply on the Web-SIG mailing list too, but as I've outlined elsewhere,
I don't think ASGI would be a suitable replacement for WSGI in the current
form; in particular, I suspect it will have a performance disadvantage,
though I've not quantified yet.

That said, if Django Channels does become the primary method for
communication with web clients, the only thing we would want out of WSGI 2
would be something that could easily plug into ASGI - that is, something
that supports WebSockets, can handle simultaneous connections with many
clients in the same thread via cooperative multitasking or similar, and
allows raw access to sockets. Given those things, an ASGI HTTP/WebSocket
protocol server could simply be a WSGI 2 application, allowing much better
code reuse.

I still believe in the ASGI model for protocols other than HTTP/WS, and for
background task handling, so I don't think I'd want to throw it away and
adopt WSGI 2 directly if it came along, but Django would definitely keep a
direct-WSGI mode for that as it always has.

Andrew

On Mon, Jan 4, 2016 at 9:14 AM, Marc Tamlyn  wrote:

> Hi Cory,
>
> [Disclaimer - I don't suppose to speak for the whole community here, this
> is a personal opinion of how I see things]
>
> Django's wsgi handling code has remained largely unchanged for many years,
> so to answer the question of "what does Django itself need from new wsgi,
> ignoring channels", I'd suggest the answer is nothing - wsgi as is works
> well for me. As an application developer, I'd also mention that I've never
> had a need to dip into the wsgi objects at all, so I can't say I need a
> wsgi2 either. In short, the idea of wsgi2 doesn't excite me at all. Perhaps
> you could reiterate what the benefits would be to a common garden web
> developer?
>
> However, when you bring channels in it changes the topic quite
> significantly. I would definitely like channels' communication with the
> outside world to be as based on a stable, external python platform as
> possible, if only for the volume of code we need to maintain in Django.
>
> I hope that helps a bit..
>
> Marc
> On 4 Jan 2016 1:15 p.m., "Cory Benfield"  wrote:
>
>> All,
>>
>> An effort has begun over in the PSF Web-SIG special interest group to
>> come up with a new version of the WSGI specification.
>>  The
>> goal is to develop a successor to WSGI that will be more useful in the
>> development of modern, asynchronous web applications, with the goal of
>> making available all of the improvements in both HTTP and Python that have
>> come through in the years since PEP 333.
>>
>> As Django is one of the major users of WSGI, any attempt to specify a new
>> version without getting input from the Django community and development
>> team would be extremely foolish! This is therefore a request for input: I'd
>> like it very much if the Django development team could come up with a
>> response to the email linked earlier, indicating what the Django team would
>> like from a new version of WSGI and what you believe the priorities should
>> be. For obvious reasons there may not be consensus around this issue
>> amongst the Django developers, and that's fine: multiple submissions from
>> Django would be entirely acceptable.
>>
>> Trying to improve something as well-established as WSGI is going to be
>> extremely difficult, and it'll only work if communities like Django's step
>> up to help build something that we can all be proud of. I hope that you're
>> as excited by that idea as I am!
>>
>> A side note: I'm very aware of Andrew Godwin's work with channels, and it
>> may be that the Django community believes that that model is the future of
>> web programming in Python. If that's the case, then please *let us know*.
>> I personally don't believe that it's the right direction for WSGI, but I
>> may be wrong (I've been wrong before!).
>>
>> If you have any questions, please don't hesitate to ask. I'm looking
>> forward to working with you all!
>>
>> Cory
>>
>> --
>> 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/aea5f21c-20c7-49ab-a1ca-2376ca0b92f2%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 

Re: Request for Input: WSGI 2.0

[Marc Tamlyn]

Hi Cory,

[Disclaimer - I don't suppose to speak for the whole community here, this
is a personal opinion of how I see things]

Django's wsgi handling code has remained largely unchanged for many years,
so to answer the question of "what does Django itself need from new wsgi,
ignoring channels", I'd suggest the answer is nothing - wsgi as is works
well for me. As an application developer, I'd also mention that I've never
had a need to dip into the wsgi objects at all, so I can't say I need a
wsgi2 either. In short, the idea of wsgi2 doesn't excite me at all. Perhaps
you could reiterate what the benefits would be to a common garden web
developer?

However, when you bring channels in it changes the topic quite
significantly. I would definitely like channels' communication with the
outside world to be as based on a stable, external python platform as
possible, if only for the volume of code we need to maintain in Django.

I hope that helps a bit..

Marc
On 4 Jan 2016 1:15 p.m., "Cory Benfield"  wrote:

> All,
>
> An effort has begun over in the PSF Web-SIG special interest group to come
> up with a new version of the WSGI specification.
>  The
> goal is to develop a successor to WSGI that will be more useful in the
> development of modern, asynchronous web applications, with the goal of
> making available all of the improvements in both HTTP and Python that have
> come through in the years since PEP 333.
>
> As Django is one of the major users of WSGI, any attempt to specify a new
> version without getting input from the Django community and development
> team would be extremely foolish! This is therefore a request for input: I'd
> like it very much if the Django development team could come up with a
> response to the email linked earlier, indicating what the Django team would
> like from a new version of WSGI and what you believe the priorities should
> be. For obvious reasons there may not be consensus around this issue
> amongst the Django developers, and that's fine: multiple submissions from
> Django would be entirely acceptable.
>
> Trying to improve something as well-established as WSGI is going to be
> extremely difficult, and it'll only work if communities like Django's step
> up to help build something that we can all be proud of. I hope that you're
> as excited by that idea as I am!
>
> A side note: I'm very aware of Andrew Godwin's work with channels, and it
> may be that the Django community believes that that model is the future of
> web programming in Python. If that's the case, then please *let us know*.
> I personally don't believe that it's the right direction for WSGI, but I
> may be wrong (I've been wrong before!).
>
> If you have any questions, please don't hesitate to ask. I'm looking
> forward to working with you all!
>
> Cory
>
> --
> 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/aea5f21c-20c7-49ab-a1ca-2376ca0b92f2%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/CAMwjO1HHJ35a3cXpUMmRGxKxUOXLrxutdLWuGOJJ72uAbW2ERg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Docs and search : Split the results by category

[Tim Graham]

A similar thing was proposed in another thread: 
https://groups.google.com/d/msg/django-developers/QW06ctKbFKA/Yg-zE3RSEQAJ

I don't disagree that the search could be better, so feel free to prototype 
something to get feedback.

On Monday, January 4, 2016 at 10:25:54 AM UTC-5, Joachim Jablon wrote:
>
> Hello,
>
> (not sure the question should be asked there or as a ticket of 
> djangoproject.com)
>
> Seing this 
> 
>  answer 
> by Daniele Procida explaining how docs are organized made me realize that 
> often, when searching for something in the docs, I know if I'm searching 
> for an how-to doc, a reference doc or a topic doc. I'd find helpful to have 
> the search results splitted into several categories, so that I can ignore 
> (at first) the information that will be too low or high level for what I'm 
> looking for. Am I the only one thinking this ? If not, I can try making it.
>
> What I'd have in mind : the 2 or 3 first results of each category plus a 
> link to have more results for each category, and a link to have all results 
> mixed, as it works now.
>
> (I'm not sure but I believe that at some point a while ago, I searched for 
> "input" and the HowTo for "Form" was somewhere about the 10ish result. I'd 
> like to check with the docs search but it seems the search is down for now)
>
> Yours,
>
> ewjoachim
>

-- 
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/1b17df96-1750-48b6-93ce-5ef8cc5209f4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Docs and search : Split the results by category

[Joachim Jablon]

Hello,

(not sure the question should be asked there or as a ticket of 
djangoproject.com)

Seing this 

 answer 
by Daniele Procida explaining how docs are organized made me realize that 
often, when searching for something in the docs, I know if I'm searching 
for an how-to doc, a reference doc or a topic doc. I'd find helpful to have 
the search results splitted into several categories, so that I can ignore 
(at first) the information that will be too low or high level for what I'm 
looking for. Am I the only one thinking this ? If not, I can try making it.

What I'd have in mind : the 2 or 3 first results of each category plus a 
link to have more results for each category, and a link to have all results 
mixed, as it works now.

(I'm not sure but I believe that at some point a while ago, I searched for 
"input" and the HowTo for "Form" was somewhere about the 10ish result. I'd 
like to check with the docs search but it seems the search is down for now)

Yours,

ewjoachim

-- 
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/d1b550f1-55b5-4a43-971f-636d39510a24%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Request for Input: WSGI 2.0

[Cory Benfield]

All,

An effort has begun over in the PSF Web-SIG special interest group to come 
up with a new version of the WSGI specification. 
 The 
goal is to develop a successor to WSGI that will be more useful in the 
development of modern, asynchronous web applications, with the goal of 
making available all of the improvements in both HTTP and Python that have 
come through in the years since PEP 333.

As Django is one of the major users of WSGI, any attempt to specify a new 
version without getting input from the Django community and development 
team would be extremely foolish! This is therefore a request for input: I'd 
like it very much if the Django development team could come up with a 
response to the email linked earlier, indicating what the Django team would 
like from a new version of WSGI and what you believe the priorities should 
be. For obvious reasons there may not be consensus around this issue 
amongst the Django developers, and that's fine: multiple submissions from 
Django would be entirely acceptable.

Trying to improve something as well-established as WSGI is going to be 
extremely difficult, and it'll only work if communities like Django's step 
up to help build something that we can all be proud of. I hope that you're 
as excited by that idea as I am!

A side note: I'm very aware of Andrew Godwin's work with channels, and it 
may be that the Django community believes that that model is the future of 
web programming in Python. If that's the case, then please *let us know*. I 
personally don't believe that it's the right direction for WSGI, but I may 
be wrong (I've been wrong before!).

If you have any questions, please don't hesitate to ask. I'm looking 
forward to working with you all!

Cory

-- 
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/aea5f21c-20c7-49ab-a1ca-2376ca0b92f2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: URL dispatching framework: feedback requested

[Aymeric Augustin]

On 4 janv. 2016, at 13:24, Tim Graham  wrote:

> It looks to me like the rationale for the existing organization is that 
> everything in that module is designed to be used in a URLconf.

I believe it is. However, as I said on the pull request, most users won’t 
reverse engineer this subtlety. I think it would just be simpler for everyone 
if all URL-related functions were importable from django.urls.

-- 
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/CD872D51-50B3-4880-B192-0AA4FED0D248%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: URL dispatching framework: feedback requested

[Tim Graham]

It looks to me like the rationale for the existing organization is that 
everything in that module is designed to be used in a URLconf. Do you 
propose to make everything importable from "django.urls" or from 
"django.urls.conf" or some other organization?

If we remove urls from django.conf, then the next logical step could be to 
rename "django.conf" to "django.settings" as it's not left with much else. 
I'm not advocating for that, but it's something I noticed.

On Sunday, January 3, 2016 at 3:32:41 PM UTC-5, Marten Kenbeek wrote:
>
> A quick question: Aymeric suggested to merge django.conf.urls into 
> django.urls as well. Does anyone think we should not make this move?
>
> If no one disagrees, I will proceed with a new PR to make the move.
>

-- 
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/c08c513b-4370-40e6-8eb5-ba533360d8d9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Help needed with the MySQL max index length problem for Django 1.10

[Adam Johnson]

This has always been an error on MySQL afaik, it would allow broken data 
integrity if it were just a warning.

Moving the length below 191 does seem to be the safest fix.

On Wednesday, December 30, 2015 at 1:52:27 PM UTC, Collin Anderson wrote:
>
> I think mysql used to just give a warning and maybe now it's an error? It 
> can currently be reproduced with just a blank project (using django master, 
> mysql 5.5.46-0ubuntu0.14.04.2):
>
> mysql -e'create database mb4test charset utf8mb4'
> django-admin startproject mb4test
> cd mb4test
> vi mb4test/settings.py  # set up db settings
> ./manage.py migrate
>
> Operations to perform:
>   Apply all migrations: auth, admin, sessions, contenttypes
> Running migrations:
>   Rendering model states... DONE
>   Applying contenttypes.0001_initial... OK
>   Applying auth.0001_initial... OK
>   Applying admin.0001_initial... OK
>   Applying admin.0002_logentry_remove_auto_add... OK
>   Applying contenttypes.0002_remove_content_type_name... OK
>   Applying auth.0002_alter_permission_name_max_length... OK
>   Applying auth.0003_alter_user_email_max_length... OK
>   Applying auth.0004_alter_user_username_opts... OK
>   Applying auth.0005_alter_user_last_login_null... OK
>   Applying auth.0006_require_contenttypes_0002... OK
>   Applying auth.0007_alter_validators_add_error_messages... OK
>   Applying auth.0008_alter_user_username_max_length...Traceback (most 
> recent call last):
>   File "/home/collin/django1.10/django/db/backends/utils.py", line 64, in 
> execute
> return self.cursor.execute(sql, params)
>   File "/home/collin/django1.10/django/db/backends/mysql/base.py", line 
> 112, in execute
> return self.cursor.execute(query, args)
>   File 
> "/home/collin/mb4test/lib/python3.4/site-packages/MySQLdb/cursors.py", line 
> 226, in execute
> self.errorhandler(self, exc, value)
>   File 
> "/home/collin/mb4test/lib/python3.4/site-packages/MySQLdb/connections.py", 
> line 36, in defaulterrorhandler
> raise errorvalue
>   File 
> "/home/collin/mb4test/lib/python3.4/site-packages/MySQLdb/cursors.py", line 
> 217, in execute
> res = self._query(query)
>   File 
> "/home/collin/mb4test/lib/python3.4/site-packages/MySQLdb/cursors.py", line 
> 378, in _query
> rowcount = self._do_query(q)
>   File 
> "/home/collin/mb4test/lib/python3.4/site-packages/MySQLdb/cursors.py", line 
> 341, in _do_query
> db.query(q)
>   File 
> "/home/collin/mb4test/lib/python3.4/site-packages/MySQLdb/connections.py", 
> line 280, in query
> _mysql.connection.query(self, query)
> _mysql_exceptions.OperationalError: (1071, 'Specified key was too long; 
> max key length is 767 bytes')
>
> The above exception was the direct cause of the following exception:
>
> Traceback (most recent call last):
>   File "./manage.py", line 10, in 
> execute_from_command_line(sys.argv)
>   File "/home/collin/django1.10/django/core/management/__init__.py", line 
> 349, in execute_from_command_line
> utility.execute()
>   File "/home/collin/django1.10/django/core/management/__init__.py", line 
> 341, in execute
> self.fetch_command(subcommand).run_from_argv(self.argv)
>   File "/home/collin/django1.10/django/core/management/base.py", line 290, 
> in run_from_argv
> self.execute(*args, **cmd_options)
>   File "/home/collin/django1.10/django/core/management/base.py", line 339, 
> in execute
> output = self.handle(*args, **options)
>   File 
> "/home/collin/django1.10/django/core/management/commands/migrate.py", line 
> 177, in handle
> executor.migrate(targets, plan, fake=fake, fake_initial=fake_initial)
>   File "/home/collin/django1.10/django/db/migrations/executor.py", line 
> 92, in migrate
> self._migrate_all_forwards(plan, full_plan, fake=fake, 
> fake_initial=fake_initial)
>   File "/home/collin/django1.10/django/db/migrations/executor.py", line 
> 121, in _migrate_all_forwards
> state = self.apply_migration(state, migration, fake=fake, 
> fake_initial=fake_initial)
>   File "/home/collin/django1.10/django/db/migrations/executor.py", line 
> 198, in apply_migration
> state = migration.apply(state, schema_editor)
>   File "/home/collin/django1.10/django/db/migrations/migration.py", line 
> 123, in apply
> operation.database_forwards(self.app_label, schema_editor, old_state, 
> project_state)
>   File 
> "/home/collin/django1.10/django/db/migrations/operations/fields.py", line 
> 201, in database_forwards
> schema_editor.alter_field(from_model, from_field, to_field)
>   File "/home/collin/django1.10/django/db/backends/base/schema.py", line 
> 482, in alter_field
> old_db_params, new_db_params, strict)
>   File "/home/collin/django1.10/django/db/backends/base/schema.py", line 
> 634, in _alter_field
> params,
>   File "/home/collin/django1.10/django/db/backends/base/schema.py", line 
> 110, in execute
> cursor.execute(sql, params)
>   File "/home/collin/django1.10/django/db/backends/utils.py", line 79, in 
> execute
> return