Re: Making startproject's settings more 12-factor-y

[Bobby Mozumder]

If you at least don’t separate all variables that are dependent on the 
environment from the settings.py, then you’re going to have to edit your 
settings.py file anyways, defeating the purpose of this. Database and Cache 
connection settings are clearly dependent on the environment.

-bobby

> On Jun 25, 2020, at 1:51 PM, Kit La Touche  wrote:
> 
> Wow, `distutils.util.strtobool` is great to know about!
> 
> So, can we refocus this conversation? This is starting to look like previous 
> conversations on this topic, which pull in a lot of possibilities but don't 
> lead to a change. How do we go about generating a DEP or other 
> consensus-building tool on what we want here?
> 
> It seems to me this conversation has historically gotten stuck by trying to 
> bite off a bigger bite. Therefore, I would recommend a minimal change that 
> gestures towards the direction we want to explore.
> 
> Personally, I think that at minimum providing Django-builtin "get from env"  
> helpers would be great; beyond that, I'd love to have them be included around 
> `DEBUG` and `SECRET_KEY` with the current values as defaults, so they're 
> optional. Once we see how this gets used, we can see about passing it a file 
> instead of `os.environ`, or borrowing other ideas from any of the various 
> supporting projects that have been suggested.
> 
> It's clear that different people have different use-cases and different 
> needs, but regardless, I think that it's clear also that including values 
> like DEBUG and SECRET_KEY as hard coded values in settings by default does 
> not point people towards good practices. What "good practices" are is likely 
> to differ in each person's case, but I think that suggesting one option 
> (again, my vote is "look in the environment") will at least help newer devs 
> understand that this is a topic they should learn more about.
> 
> Thanks,
> 
> --Kit
> 
> On Thu, Jun 25, 2020 at 11:16 AM Javier Buzzi  <mailto:buzzi.jav...@gmail.com>> wrote:
> Hi Bobby, yes, thank you, this looks around the line of what i would like us 
> to implement in Django. 
> 
> Side note: i saw this config('DEBUG', default=False, cast=bool) and thought 
> "there is NO WAY that works", that led me to from distutils.util import 
> strtobool, absolute mind blown! Thanks!
> 
> -Buzzi
> 
> On Thursday, June 25, 2020 at 1:03:19 PM UTC-4, Bobby Mozumder wrote:
> There’s also python-decouple that I use that I haven’t seen mentioned in this 
> thread. It lets you set specific environment variables in a separate .env 
> file or INI file: https://github.com/henriquebastos/python-decouple 
> <https://github.com/henriquebastos/python-decouple>
> 
> -bobby
> 
>> On Jun 25, 2020, at 4:47 AM, Javier Buzzi > wrote:
>> 
>> Hey Tom, cool project haven't heard of it, looks to me more inline with 
>> validating and converting user input from an api/form. I could really see 
>> myself using this in my personal projects, however this looks like we'd be 
>> going back to the class based configuration that im trying to avoid. 
>> Nonetheless thank you for the share!
>> 
>> - Buzzi
>> 
>> On Thursday, June 25, 2020 at 4:34:11 AM UTC-4, Tom Carrick wrote:
>> Javier, I just wanted to point out another option for configuration: 
>> pydantic <https://pydantic-docs.helpmanual.io/> - it offers a very slick and 
>> intuitive interface for settings management across environments, seamless 
>> handing of environment variables by using type hints, and so on. I wouldn't 
>> recommend it for anything other than large sites with complex 
>> configurations, but it does work well for those, once you grapple with how 
>> to integrate it with django's settings so they're all exposed as 
>> `settings.FOO`, and so on.
>> 
>> I don't think I would want to integrate anything like this into Django 
>> proper, but it might deserve a mention in the documentation.
>> 
>> Tom
>> 
>> On Wed, 24 Jun 2020 at 23:52, Javier Buzzi > wrote:
>> This makes sense, I have a project that has a lot of settings files that get 
>> activated depending on the value of DJANGO_SETTINGS_MODULE. The solution i 
>> outlined above takes your reservations under consideration, if you want to 
>> use it, great, if not also great -- its a supplement not a requirement.
>> 
>> - Buzzi
>> 
>> On Wednesday, June 24, 2020 at 5:24:35 PM UTC-4, Dan Davis wrote:
>>  tMost of the world is not as seamless as heroku.  My DevOps won't give me 
>> any more than a handful of environment variables.  I wanted something like 
>> DATABASE_URL, but all I have is DJANGO_LOG_DIR

Re: Making startproject's settings more 12-factor-y

[Bobby Mozumder]

There’s also python-decouple that I use that I haven’t seen mentioned in this 
thread. It lets you set specific environment variables in a separate .env file 
or INI file: https://github.com/henriquebastos/python-decouple

-bobby

> On Jun 25, 2020, at 4:47 AM, Javier Buzzi  wrote:
> 
> Hey Tom, cool project haven't heard of it, looks to me more inline with 
> validating and converting user input from an api/form. I could really see 
> myself using this in my personal projects, however this looks like we'd be 
> going back to the class based configuration that im trying to avoid. 
> Nonetheless thank you for the share!
> 
> - Buzzi
> 
> On Thursday, June 25, 2020 at 4:34:11 AM UTC-4, Tom Carrick wrote:
> Javier, I just wanted to point out another option for configuration: pydantic 
>  - it offers a very slick and intuitive 
> interface for settings management across environments, seamless handing of 
> environment variables by using type hints, and so on. I wouldn't recommend it 
> for anything other than large sites with complex configurations, but it does 
> work well for those, once you grapple with how to integrate it with django's 
> settings so they're all exposed as `settings.FOO`, and so on.
> 
> I don't think I would want to integrate anything like this into Django 
> proper, but it might deserve a mention in the documentation.
> 
> Tom
> 
> On Wed, 24 Jun 2020 at 23:52, Javier Buzzi > wrote:
> This makes sense, I have a project that has a lot of settings files that get 
> activated depending on the value of DJANGO_SETTINGS_MODULE. The solution i 
> outlined above takes your reservations under consideration, if you want to 
> use it, great, if not also great -- its a supplement not a requirement.
> 
> - Buzzi
> 
> On Wednesday, June 24, 2020 at 5:24:35 PM UTC-4, Dan Davis wrote:
>  tMost of the world is not as seamless as heroku.  My DevOps won't give me 
> any more than a handful of environment variables.  I wanted something like 
> DATABASE_URL, but all I have is DJANGO_LOG_DIR and DJANGO_SETTINGS_MODULE, 
> and so I need many, many settings files. I think that happens a lot, and 
> maybe a common pattern.
> 
> From a 12factor perspective, I would like to get it down to local settings 
> (development) and production settings - yet for a lot of users, DevOps is not 
> really supporting a full PaaS-like experience any way.
> 
> So - all of this has to be optional, which seems to rule out making it part 
> of the starting project template.  For sure, I've got my personal template, 
> and work has an on-premise template and a Cloud template as well - but the 
> department of developers doesn't always use these.  I find databases 
> containing the tables for other projects, long after the models and 
> migrations are gone, indicating a start by copy mode.
> 
> On Wed, Jun 24, 2020 at 1:35 PM Kit La Touche > wrote:
> Carlton—thanks very much for the feedback. Javier—likewise. In particular, 
> the imagined API you describe above is very appealing to me: start with 
> `from_env` and then if you learn more about this and want to, add in some 
> `EnvFileLoader`.
> 
> I want to make clear my motivation and agenda here: I have recently had some 
> conversations with newer devs about their experiences with deployment of apps 
> they're working on, and with a friend at Heroku about his informal research 
> into the problems people have with the same. One recurring friction point 
> (and this is not just on Heroku at all, to be clear) is that there are a 
> number of things that people don't know they need to configure for a working 
> deployment.
> 
> There are four settings that are recurring particular gotchas that people 
> miss: the secret key, debug, static files, and databases. Static files seems 
> big and out of scope, databases seems adequately handled by dj-database-url 
> for most cases, and if your case is more complex, you'll learn it, but the 
> other two (secret key and debug) seemed easy enough to flag as "you probably 
> need to configure these!" with this sort of change to settings. This would be 
> a first step towards shortening the distance from `startproject` to a working 
> deployment.
> 
> Newer devs in particular have, based on my conversations and this friend's 
> research, been unlikely to (a) know that there are different `startproject` 
> templates, and (b) feel equipped to choose one, if they do know.
> 
> My hope is to make the smallest possible change to just start us moving 
> towards more clearly flagging, especially for newer devs, "these are things 
> that will need additional configuration in order to move from 'works on my 
> machine' to 'deployed'."
> 
> Towards that end, I thought that adding a "you might want to get this from 
> the env" helper would be a clear indication to a new dev that this is a 
> matter to even consider. Adding other configuration-getting options like 
> different secret-store file backends seems like a 

Re: Making startproject's settings more 12-factor-y

[Bobby Mozumder]

I also have my own version of “startproject" that creates several additional 
files, including my web server config file (I use H20 web server, not Nginx) as 
well as a uWSGI vassals config file. I create the following preconfigured files 
and directories using a command-line Python script:

.gitignore
.env
h2o.conf
uwsgi.ini
create_db.sql
manifest.json
browserconfig.xml
robots.txt
requirements.txt
/static
/static/icons
/static/icons/*various_icons.png
/media
/venv
/log

Basically as much as I can possibly create to launch a new project and have it 
ready to deploy on my main web server.  I’m adding more items as well, 
including fonts, CSS and JS templates.

There are so many little things that are needed to deploy. I wish Django had it 
built in, but yes my configuration is pretty custom, with H20 instead of Nginx 
or Apache.

Is this something of interest for Django directly?

-bobby

> On Jun 23, 2020, at 9:08 PM, Kit La Touche  wrote:
> 
> I saw what you added; I tried to make this a minimal change, and was 
> conscious also Carl's expressed preference (which I share, tbh) in the linked 
> discussion for less-magic. I figured a function that just parsed values out 
> of the env would be the smallest possible first step, so I'm inclined to keep 
> with this, for now.
> 
> On Tue, Jun 23, 2020 at 4:15 PM Javier Buzzi  > wrote:
> I think its great, but id add a little more customizability. I've added an 
> example to your PR.
> 
> -- 
> 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/8dc94197-fa0c-442a-8f97-3d7990a3a2c2o%40googlegroups.com
>  
> .
> 
> -- 
> 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/CAFcS-hD4RFMt%2BwQCCkt6TB5P3rEjarD9Bc9WcArvdaKBzxiYEw%40mail.gmail.com
>  
> .

-- 
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/3E3ED051-F766-4F0E-BD83-49503C11662A%40gmail.com.

django-admin startproject settings.py has some security holes

[Bobby Mozumder]

In particular, they include settings that shouldn’t be stored in a git repo 
such as SECRET_KEY and database passwords. You’ll find these kinds of settings 
in git repos all the time.

Really the default django-admin startproject shouldn’t have a single 
settings.py that people include in their git repos, but instead a python 
settings module, with a base.py, development.py, staging.py, and production.py. 
An __init__.py reads base.py and one of development/staging/production based on 
ENV variables (defaulting to development if no ENV variable).

Additionally, startproject should add a .gitignore in the root directory to not 
include development/staging/production settings files.

I get that this might not be absolutely necessary but I think these are the 
kinds of defaults that make practical real-world use more secure, as well as 
standardizing workflow for more advanced production usage.

Is this something agreeable? I can put together a solution if people like this.

-bobby
   

-- 
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/320B70FD-BDC1-445D-B72B-0CD0BA736B88%40gmail.com.

Why not just use Python for templating smart components?

[Bobby Mozumder]

I’ve been testing out some custom Python classes for Django templating, due to 
Python 3.6’s addition of F-strings. In addition, templates now have the full 
capability to be programmed in Python itself, with the possibility of creating 
smart templates and components based on Python classes.

Instead of the template language (copying and pasting just a typical Django 
template here):

{% extends "base.html" %}

{% block content %}


  
  



{% for item in items %}

  
  




  
  
https://mdbootstrap.com/img/Photos/Horizontal/E-commerce/Vertical/12.jpg; 
class="card-img-top"
  alt="">

  

  
  

  
  


  Shirt


  
{{item}}
  NEW

  



  120$


  
  




  
  
{% endfor %}




  
  

{% endblock content %}

I have something like (example from a different project):


base_css = """
body {
margin: 2% auto 5% auto;
background: #fdfdf2;
color: #111;
font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, 
Helvetica, Arial, sans-serif;
font-size: 16px;
line-height: 1.8;
text-shadow: 0 1px 0 #ff;
max-width: 73%;
}
h1, h2, h3, h4 {
line-height:1.2
}
h2, h3 {
color: #777
}
code {
background: white;
}
a {
border-bottom: 1px solid #44;
color: #44;
text-decoration: none;
}
a:hover {
border-bottom: 0;
}
.fixed {
white-space: nowrap;
vertical-align:top;
}
"""

class viewIndexHead(Block):

css = base_css

vary = []

def generateHTML(self,page):
return f'Bobby Mozumder Homepagemozumder.net'

class viewArticleHead(Block):

css = base_css

vary = ['id']

def generateHTML(self,page):
return f'{page.data.title}mozumder.net'


class article_body(Block):
vary = ['id']

def generateHTML(self,page):
html = 
f'{page.data.headline}{page.data.subheadline}{page.data.date_published:%B
 %d, %Y}{page.data.body}'
return html

class article_list(Block):
sql = 'get_view_headlines_fragment'
components = [
table()
]
def generateHTML(self,page):
page.articles_list = self.fetchall(page.request.session.session_key)
return super().generateHTML(page)
def fetchall(self,session):
self.c.execute('EXECUTE ' + self.sql + '(%s);', [session])
result = self.c.fetchall()
return result

With blocks generated from components:
class tableHTML(code):
def __iter__(self,page=None):
yield ""
if page:
if page.request.user.is_authenticated:
for row in page.articles_list:
yield f'{row.date_published:%B %d, 
%Y}{row.title}editdelete'
else:
for row in page.articles_list:
yield f'{row.date_published:%B %d, %Y}{row.title}'
yield ""

class tableCSS(code):
def __iter__(self,page=None):
yield "table {border:0};"

class table(Component):
def __init__(self):
super().__init__()
self.html = tableHTML()
self.css = tableCSS()


With pages created by combining these block classes:


class viewArticle(UnchainedTemplate):

blocks = [viewArticleHead, article_body]

class index(UnchainedTemplate):

blocks = [viewIndexHead, article_list]


There are lots of properties of each class that I don’t show. Each Block class 
has properties for SQL, CSS, Header JS, Body initial JS, Body after JS. The 
UnchainedTemplate page classes do things like generate the HTML by combining 
each blocks from classes as well as reading in common HTML header/closer 
fragments from files.

It also calculates things like Content Security Policy headers for each piece 
of JS/CSS, and GZip compress each block BEFORE it goes to Redis cache - 
increasing my Redis cache size by 10x and speeding up page reads by not having 
to recompress it for every lookup. I also minimize CSS/JS from the class 
properties.

In the very long term, it’s entirely possible to create smart component-based 
UI classes that not only generate HTML/CSS/JS, but also things like iOS Swift 
UI classes, if you wanted to make a native iOS app from this, or a desktop UI 
app. Ideally there would be a library of pre-built smart components that a 
developer could use to rapidly make an app. I was inspired by Qt, which I loved 
and programmed in 10+ years ago. Qt has an interesting sockets/slots mechanism 
for event modeling.

Anyways is this something that’s interesting for a long-term Django 

Re: Shouldn't manage.py call python3 instead of python?

[Bobby Mozumder]

In any case you’re going to see a lot of Django 2.0 developers on Mac OS hit 
this problem when they install to default Python or use standard Python install 
convention where Python 3.5 is installed as “python3".

-bobby

> On Apr 10, 2018, at 3:46 PM, Aymeric Augustin 
>  wrote:
> 
>> On 10 Apr 2018, at 17:43, Florian Apolloner > > wrote:
>> 
>> On Tuesday, April 10, 2018 at 1:28:33 PM UTC+2, Tim Allen wrote:
>> Since `django-admin startproject my_project` is created on the fly from 
>> templates, couldn't we dynamically create the `manage.py` executable based 
>> on some system introspection and an agreed upon priority
>> 
>> Wouldn't that result in something along the lines of "works on my system" 
>> and breaks elsewhere? after all manage.py is committed into git more often 
>> than not.
> 
> ... which directs us to the correct solution: setting PYTHONPATH and 
> DJANGO_SETTINGS_MODULE correctly and using django-admin instead of manage.py. 
> 
> pip / setuptools rewrites the shebang line appropriately when it installs the 
> django-admin script. (I'm not sure how this happens exactly.)
> 
> My point is — there's no perfect solution. At best we can aim for a less 
> imperfect solution than the status quo.
> 
> -- 
> 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/C36A8494-1094-4A03-A402-618BB999F927%40polytechnique.org
>  
> .
> 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/CADE6613-965B-4A27-885A-EAE5651014A6%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Shouldn't manage.py call python3 instead of python?

[Bobby Mozumder]

I never really liked the idea of using VirtualEnv or HomeBrew over the default 
installation in Mac OS.  (FreeBSD has the same naming issues).  

Having beginners use VirtualEnv or HomeBrew always struck me as a huge obstacle 
to getting a beginners Django developer's environment operational, as well as 
being a huge pain-in-the-ass of always setting VirtualEnvs for each shell.  So, 
I personally don’t use them anymore, and just use the base system now.

I wish there was a process of running Django out-of-the-box from a default Mac 
OS install.

-bobby

> On Apr 8, 2018, at 8:27 AM, Tom Forbes <t...@tomforb.es> wrote:
> 
> This only seems to be an issue when you are using the base system interpreter 
> to run manage.py. installing Django and other dependencies there is not 
> recommended for a variety of reasons, and this isn't a problem when using a 
> virtualenv, it doesn't seem like there is much to fix IMO.
> 
> 
> On Sun, 8 Apr 2018, 08:19 Bobby Mozumder, <bmozum...@gmail.com 
> <mailto:bmozum...@gmail.com>> wrote:
> Is it OK to reopen that ticket?
> 
> The problem is that python2 and python3 need to coexist in most systems, and 
> you can’t just rename python3 to python.
> 
> -bobby
> 
>> On Apr 6, 2018, at 8:30 PM, Tim Graham <timogra...@gmail.com 
>> <mailto:timogra...@gmail.com>> wrote:
>> 
>> It was tried in https://code.djangoproject.com/ticket/27878 
>> <https://code.djangoproject.com/ticket/27878> but it caused problems, 
>> particularly on Windows.
>> 
>> On Friday, April 6, 2018 at 6:35:50 PM UTC-4, Josh Smeaton wrote:
>> I think you're right and PEP394 is the relevant text: 
>> https://www.python.org/dev/peps/pep-0394/ 
>> <https://www.python.org/dev/peps/pep-0394/>
>> 
>> TL;DR
>> 
>> For now, python should refer to python2 and python3 should be used to refer 
>> to python 3.
>> 
>> On Saturday, 7 April 2018 07:07:35 UTC+10, Bobby Mozumder wrote:
>> The header of manage.py has: #!/usr/bin/env python
>> 
>> Shoudn’t it be: #!/usr/bin/env python3
>> 
>> Since 2.0 is now only Python3. Both my Mac OS & FreeBSD environments have 
>> Python 3.5+ as “python3". (I’m not sure about Linux or other environments).
>> 
>> Is that a bug I need to file?
>> 
>> -bobby
>> 
>> -- 
>> 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 
>> <mailto:django-developers+unsubscr...@googlegroups.com>.
>> To post to this group, send email to django-developers@googlegroups.com 
>> <mailto:django-developers@googlegroups.com>.
>> Visit this group at https://groups.google.com/group/django-developers 
>> <https://groups.google.com/group/django-developers>.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/7cdf48bb-ab0b-449d-8f33-a4c6d369%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/django-developers/7cdf48bb-ab0b-449d-8f33-a4c6d369%40googlegroups.com?utm_medium=email_source=footer>.
>> For more options, visit https://groups.google.com/d/optout 
>> <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 
> <mailto:django-developers+unsubscr...@googlegroups.com>.
> To post to this group, send email to django-developers@googlegroups.com 
> <mailto:django-developers@googlegroups.com>.
> Visit this group at https://groups.google.com/group/django-developers 
> <https://groups.google.com/group/django-developers>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/E1881F92-2D8C-45D8-8315-E5D72D0D7B6E%40gmail.com
>  
> <https://groups.google.com/d/msgid/django-developers/E1881F92-2D8C-45D8-8315-E5D72D0D7B6E%40gmail.com?utm_medium=email_source=footer>.
> For more options, visit https://groups.google.com/d/optout 
> <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-dev

Re: Shouldn't manage.py call python3 instead of python?

[Bobby Mozumder]

Is it OK to reopen that ticket?

The problem is that python2 and python3 need to coexist in most systems, and 
you can’t just rename python3 to python.

-bobby

> On Apr 6, 2018, at 8:30 PM, Tim Graham <timogra...@gmail.com> wrote:
> 
> It was tried in https://code.djangoproject.com/ticket/27878 
> <https://code.djangoproject.com/ticket/27878> but it caused problems, 
> particularly on Windows.
> 
> On Friday, April 6, 2018 at 6:35:50 PM UTC-4, Josh Smeaton wrote:
> I think you're right and PEP394 is the relevant text: 
> https://www.python.org/dev/peps/pep-0394/ 
> <https://www.python.org/dev/peps/pep-0394/>
> 
> TL;DR
> 
> For now, python should refer to python2 and python3 should be used to refer 
> to python 3.
> 
> On Saturday, 7 April 2018 07:07:35 UTC+10, Bobby Mozumder wrote:
> The header of manage.py has: #!/usr/bin/env python
> 
> Shoudn’t it be: #!/usr/bin/env python3
> 
> Since 2.0 is now only Python3. Both my Mac OS & FreeBSD environments have 
> Python 3.5+ as “python3". (I’m not sure about Linux or other environments).
> 
> Is that a bug I need to file?
> 
> -bobby
> 
> -- 
> 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 
> <mailto:django-developers+unsubscr...@googlegroups.com>.
> To post to this group, send email to django-developers@googlegroups.com 
> <mailto:django-developers@googlegroups.com>.
> Visit this group at https://groups.google.com/group/django-developers 
> <https://groups.google.com/group/django-developers>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/7cdf48bb-ab0b-449d-8f33-a4c6d369%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/django-developers/7cdf48bb-ab0b-449d-8f33-a4c6d369%40googlegroups.com?utm_medium=email_source=footer>.
> For more options, visit https://groups.google.com/d/optout 
> <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/E1881F92-2D8C-45D8-8315-E5D72D0D7B6E%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Shouldn't manage.py call python3 instead of python?

[Bobby Mozumder]

The header of manage.py has: #!/usr/bin/env python

Shoudn’t it be: #!/usr/bin/env python3

Since 2.0 is now only Python3. Both my Mac OS & FreeBSD environments have 
Python 3.5+ as “python3". (I’m not sure about Linux or other environments).

Is that a bug I need to file?

-bobby

-- 
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/C158A05A-0DA3-485D-861E-B72DA11E5074%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Add custom autoreload file tracking options setting

[Bobby Mozumder]

> On Jan 4, 2017, at 5:40 PM, Adam Johnson <m...@adamj.eu> wrote:
> 
> How do people serve development Javascript & CSS files?  These days 
> Javascript & CSS involves a large build process.  Are we forced to manually 
> restart the development server every time Javascript changes?
> 
> Django just serves them from the filesystem, and doesn't cache them itself. 
> You reload the page in your browser, and Django serves the files from disk
> 
> Does the Django development server restart if you edit Templates?  Because it 
> should also do that.
> 
> Similarly, by default templates aren't cached, so on each view the dev server 
> loads the templates from disk, parses them, and renders them.
>  

Does it do the same under production environments - read and interpret each 
template file on every request?  

Is there interest in making a much faster version of this flow?

> 
> On 4 January 2017 at 22:31, Bobby Mozumder <bmozum...@gmail.com 
> <mailto:bmozum...@gmail.com>> wrote:
> 
> > On Jan 4, 2017, at 4:47 PM, Aymeric Augustin 
> > <aymeric.augus...@polytechnique.org 
> > <mailto:aymeric.augus...@polytechnique.org>> wrote:
> >
> > Hello Bobby,
> >
> >> On 4 Jan 2017, at 22:25, Bobby Mozumder <bmozum...@gmail.com 
> >> <mailto:bmozum...@gmail.com>> wrote:
> >>
> >> It’s actually called once on app startup during DB connection via a Signal.
> >
> > Unless I missed something, since the development server creates a new 
> > connection to the database for each request — Python’s threaded socket 
> > server creates a new thread for each connection and database connections 
> > are thread local in Django — prepared statements will be refreshed for each 
> > request. So I don’t think you need autoreloading here.
> 
> Hmm I thought the test server used permanent connections if CONN_MAX_AGE was 
> set to None?  Could have sworn it was that way for a while?
> 
> In any case, I just tried the Javascript & CSS Makefile with a simple one 
> line change to one file, and it took 4 seconds.  That’s going to be way too 
> long to do on each request.
> 
> How do people serve development Javascript & CSS files?  These days 
> Javascript & CSS involves a large build process.  Are we forced to manually 
> restart the development server every time Javascript changes?
> 
> I think it should be just like changing Python files and it autoreloads 
> Javascript & CSS as it changes.
> 
> Also, I haven’t used the Django Template system or Jinja in over a year.  
> Does the Django development server restart if you edit Templates?  Because it 
> should also do that.
> 
> This is what I’m getting at with this autoreload.. it should include the full 
> system, not just the Python files.
> 
> >
> >> (This whole process helps speed up the view response generation times.  I 
> >> can generate a full page in about 4ms, and that includes GZip.)
> >
> > Off topic, but I’m jealous…
> >
> 
> Also, my average page generates in 1-2ms, and fully cached html serves in 200 
> microseconds, and that include Gzip, since I cache Gzip (which makes my cache 
> 10x bigger).   There’s lots that I can contribute here, including 
> non-blocking analytics stored in teh database.  If I can make it “generic” 
> enough I’ll try to publish it, but the code is really manual.  Maybe instead 
> of a formal toolset, I could post a methodology manual?  It’s really tedious 
> though, involving materialized database views & all sorts of other techniques.
> 
> BTW My site is at http://www.futureclaw.com <http://www.futureclaw.com/>
> 
> > 
> >
> > I still believe we should stop maintaining an autoreloader as soon as 
> > possible. Django’s autoreloader is annoyingly slow, highly inefficient, 
> > moderately well designed, and a gigantic pain to maintain. I’m more scared 
> > of django.utils.autoreload than of django.db.models.related before it was 
> > cleaned up.
> >
> > I wish one day someone will take the time to write a good autoreloading dev 
> > server based on watchman. This would solve the problem discussed here 
> > because watchman watches all files in the current directory. The correct 
> > way to do this is to throw away the current design and start from scratch.
> >
> > Watchman is smart enough to wait until you’ve finished a git operation to 
> > trigger a reload. Once such polished tech has become available, trying to 
> > compete with a thread that checks the mtime of all known files every second 
> > isn’t funny anymore. In fact it’s just sad.
> >
> > 
> &g

Re: Add custom autoreload file tracking options setting

[Bobby Mozumder]

> On Jan 4, 2017, at 4:47 PM, Aymeric Augustin 
> <aymeric.augus...@polytechnique.org> wrote:
> 
> Hello Bobby,
> 
>> On 4 Jan 2017, at 22:25, Bobby Mozumder <bmozum...@gmail.com> wrote:
>> 
>> It’s actually called once on app startup during DB connection via a Signal.
> 
> Unless I missed something, since the development server creates a new 
> connection to the database for each request — Python’s threaded socket server 
> creates a new thread for each connection and database connections are thread 
> local in Django — prepared statements will be refreshed for each request. So 
> I don’t think you need autoreloading here.

Hmm I thought the test server used permanent connections if CONN_MAX_AGE was 
set to None?  Could have sworn it was that way for a while?

In any case, I just tried the Javascript & CSS Makefile with a simple one line 
change to one file, and it took 4 seconds.  That’s going to be way too long to 
do on each request.

How do people serve development Javascript & CSS files?  These days Javascript 
& CSS involves a large build process.  Are we forced to manually restart the 
development server every time Javascript changes?  

I think it should be just like changing Python files and it autoreloads 
Javascript & CSS as it changes.

Also, I haven’t used the Django Template system or Jinja in over a year.  Does 
the Django development server restart if you edit Templates?  Because it should 
also do that.

This is what I’m getting at with this autoreload.. it should include the full 
system, not just the Python files.

> 
>> (This whole process helps speed up the view response generation times.  I 
>> can generate a full page in about 4ms, and that includes GZip.)
> 
> Off topic, but I’m jealous…
> 

Also, my average page generates in 1-2ms, and fully cached html serves in 200 
microseconds, and that include Gzip, since I cache Gzip (which makes my cache 
10x bigger).   There’s lots that I can contribute here, including non-blocking 
analytics stored in teh database.  If I can make it “generic” enough I’ll try 
to publish it, but the code is really manual.  Maybe instead of a formal 
toolset, I could post a methodology manual?  It’s really tedious though, 
involving materialized database views & all sorts of other techniques.  

BTW My site is at http://www.futureclaw.com 

> 
> 
> I still believe we should stop maintaining an autoreloader as soon as 
> possible. Django’s autoreloader is annoyingly slow, highly inefficient, 
> moderately well designed, and a gigantic pain to maintain. I’m more scared of 
> django.utils.autoreload than of django.db.models.related before it was 
> cleaned up.
> 
> I wish one day someone will take the time to write a good autoreloading dev 
> server based on watchman. This would solve the problem discussed here because 
> watchman watches all files in the current directory. The correct way to do 
> this is to throw away the current design and start from scratch.
> 
> Watchman is smart enough to wait until you’ve finished a git operation to 
> trigger a reload. Once such polished tech has become available, trying to 
> compete with a thread that checks the mtime of all known files every second 
> isn’t funny anymore. In fact it’s just sad.
> 
> 
> 
> While I don’t care much about django.utils.autoreloader because I want to 
> kill it, I’m reluctant to add public APIs such as the proposed setting, which 
> may not make sense with an hypothetical better autoreloader.
> 
> I’m -0 on the change. I could move to +0 if I understood why the use case 
> described here requires watching additional files.
> 

I guess I could just use Watchman to restart the Django development server as 
needed?

I’m OK with that.. my only goal is to make sure I don’t have to restart Django 
manually every time I edit CSS/Javascript/SQL/HTML.

Is that the recommended workflow for this?  I never looked into outside tools 
to manage this, but it seems it would be a lot easier to add a list of files or 
directories to our settings and have Django manage autoreload, than to bring in 
an outside tool.  (I can add directories to watch to the pull request if needed)

> Best regards,
> 
> -- 
> 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/BAAB82B3-974C-4240-

Re: Add custom autoreload file tracking options setting

[Bobby Mozumder]

That’ll make development server access times really slow.  There’s a pretty 
long Makefile also that builds Javascript.  We really shouldn’t have to rebuild 
Javascript on every page view, especially since I call interactive API requests 
with these views.

-bobby

> On Jan 4, 2017, at 4:18 PM, Adam Johnson <m...@adamj.eu> wrote:
> 
> For that use case I'd suggest just re-executing prepare_db_queries on every 
> page view when DEBUG=True. This is similar to how Django's template loaders 
> work without the cached loader wrapping them.
> 
> On 4 January 2017 at 21:12, Bobby Mozumder <bmozum...@gmail.com 
> <mailto:bmozum...@gmail.com>> wrote:
> OK here is some example code snippet where I load prepared SQL statements:
> 
> 
> class FastDetailView(DetailView,FastView):
> 
> c = connection.cursor()
> 
> SQL_VIEW_DIRS = {
> 'fashion': (
> 'include/sql/materializedviews/headlines',
> 'include/sql/materializedviews/latestCollections',
> 'include/sql/materializedviews/allSeasons',
> 'include/sql/materializedviews/fullSeason',
> 'include/sql/materializedviews/gallery',
> 'include/sql/materializedviews/indexView',
> 'include/sql/materializedviews/cover',
> 'include/sql/materializedviews/latestSeasonView',
> 'include/sql/materializedviews/seasonView',
> 'include/sql/materializedviews/collectionView',
> 'include/sql/materializedviews/latestCollectionsJSON',
> 'include/sql/materializedviews/collectionCardJSON',
> 'include/sql/materializedviews/indexJSON',
> 'include/sql/materializedviews/categoryJSON',
> 'include/sql/materializedviews/articleJSON',
> 'include/sql/triggers/globals',
> 'include/sql/triggers/brand',
> 'include/sql/triggers/collection',
> 'include/sql/triggers/collectionlookassignment',
> 'include/sql/triggers/cover',
> 'include/sql/triggers/look',
> 'include/sql/triggers/photo',
> 'include/sql/triggers/season',
> 'include/sql/triggers/fashion_headlinesviewmat',
> 'include/sql/triggers/fashion_latestcollectionsviewmat',
> 'include/sql/triggers/fashion_allseasonsviewmat',
> 'include/sql/triggers/fashion_fullseasonviewmat',
> 'include/sql/triggers/fashion_galleryviewmat',
> 'include/sql/triggers/fashion_coverviewmat',
> 'include/sql/triggers/fashion_indexviewmat',
> 'include/sql/triggers/fashion_latestseasonviewmat',
> 'include/sql/triggers/fashion_seasonviewmat',
> 'include/sql/triggers/fashion_collectionviewmat',
> 'include/sql/triggers/fashion_collectioncardjsonviewmat',
> ),
> 'analytics': (
> 'include/sql/analytics',
> ),
> }
> 
> MATERIALIZED_VIEWS = True
> 
> @classmethod
> def prepare_db_queries(self):
> logger.info <http://logger.info/>('Reading fashion prepared SQL 
> statements')
> cursor = connection.cursor()
> for sql_view_dir in SQL_VIEW_DIRS['fashion']:
> file_name = sql_view_dir + '/prepare.sql'
> try:
> with open(file_name, 'r') as file:
> sql_prepare=file.read().strip()
> if sql_prepare:
> cursor.execute(sql_prepare)
> except (OSError, IOError) as e:
> pass
> except e:
> logger.info <http://logger.info/>('Error reading SQL file: 
> %s' % file_name)
> raise e
> if MATERIALIZED_VIEWS:
> file_name = sql_view_dir + '/prepare_materialized.sql'
> try:
> with open(file_name, 'r') as file:
> sql_prepare=file.read().strip()
> if sql_prepare:
> cursor.execute(sql_prepare)
> except (OSError, IOError) as e:
> pass
> except e:
> logger.info <http://logger.info/>('Error reading SQL 
> file: %s' % file_name)
> raise e
> 
> 
> It’s a custom view class that basically reads SQL from a separate list of 
> files on initialization, and executes those SQL files.  
> 
> If I edit these SQL files, it won't restart the development server.
> 
> -bobby
> 
>> On Jan 4, 2017, at 4:03 PM, Tim Graham <timogra...@gmail.com 
>> <mailto:timogra...@gmail.com>> wrote:
>> 
>

Re: Add custom autoreload file tracking options setting

[Bobby Mozumder]

It’s actually called once on app startup during DB connection via a Signal.

Here is my app.py:

from django.apps import AppConfig
from .signals import *
from django.utils import autoreload

class FashionAppConfig(AppConfig):
name = 'fashion'
verbose_name = "Fashion"

And here is my signals.py:

from django.dispatch import receiver
from django.db.backends.signals import connection_created
from .page import factory as pageFactory
from .api import APIFactory


@receiver(connection_created, dispatch_uid="dbConnectionInitiated")
def prepareSQL(sender, **kwargs):
pageFactory.prepare_db_queries()
APIFactory.prepare_db_queries()
pass


My FastDetailView class is a subclass of factory , and this is where 
prepare_db_queries happens.

I also have separate code that loads in Javascript into this FastDetailView 
class.

Basically I don’t read html from the template at all during the 
Request/Response cycle.  I instead pre-load all my DB Queries and Javascript.

(This whole process helps speed up the view response generation times.  I can 
generate a full page in about 4ms, and that includes GZip.)

-bobby

> On Jan 4, 2017, at 4:17 PM, Tim Graham <timogra...@gmail.com> wrote:
> 
> When is prepare_db_queries() called? During a request/response cycle? I 
> doesn't look like any caching is happening so I still doesn't see why the 
> server needs to restart to pickup changes to the SQL files.
> 
> On Wednesday, January 4, 2017 at 4:12:27 PM UTC-5, Bobby Mozumder wrote:
> OK here is some example code snippet where I load prepared SQL statements:
> 
> 
> class FastDetailView(DetailView,FastView):
> 
> c = connection.cursor()
> 
> SQL_VIEW_DIRS = {
> 'fashion': (
> 'include/sql/materializedviews/headlines',
> 'include/sql/materializedviews/latestCollections',
> 'include/sql/materializedviews/allSeasons',
> 'include/sql/materializedviews/fullSeason',
> 'include/sql/materializedviews/gallery',
> 'include/sql/materializedviews/indexView',
> 'include/sql/materializedviews/cover',
> 'include/sql/materializedviews/latestSeasonView',
> 'include/sql/materializedviews/seasonView',
> 'include/sql/materializedviews/collectionView',
> 'include/sql/materializedviews/latestCollectionsJSON',
> 'include/sql/materializedviews/collectionCardJSON',
> 'include/sql/materializedviews/indexJSON',
> 'include/sql/materializedviews/categoryJSON',
> 'include/sql/materializedviews/articleJSON',
> 'include/sql/triggers/globals',
> 'include/sql/triggers/brand',
> 'include/sql/triggers/collection',
> 'include/sql/triggers/collectionlookassignment',
> 'include/sql/triggers/cover',
> 'include/sql/triggers/look',
> 'include/sql/triggers/photo',
> 'include/sql/triggers/season',
> 'include/sql/triggers/fashion_headlinesviewmat',
> 'include/sql/triggers/fashion_latestcollectionsviewmat',
> 'include/sql/triggers/fashion_allseasonsviewmat',
> 'include/sql/triggers/fashion_fullseasonviewmat',
> 'include/sql/triggers/fashion_galleryviewmat',
> 'include/sql/triggers/fashion_coverviewmat',
> 'include/sql/triggers/fashion_indexviewmat',
> 'include/sql/triggers/fashion_latestseasonviewmat',
> 'include/sql/triggers/fashion_seasonviewmat',
> 'include/sql/triggers/fashion_collectionviewmat',
> 'include/sql/triggers/fashion_collectioncardjsonviewmat',
> ),
> 'analytics': (
> 'include/sql/analytics',
> ),
> }
> 
> MATERIALIZED_VIEWS = True
> 
> @classmethod
> def prepare_db_queries(self):
> logger.info <http://logger.info/>('Reading fashion prepared SQL 
> statements')
> cursor = connection.cursor()
> for sql_view_dir in SQL_VIEW_DIRS['fashion']:
> file_name = sql_view_dir + '/prepare.sql'
> try:
> with open(file_name, 'r') as file:
> sql_prepare=file.read().strip()
> if sql_prepare:
> cursor.execute(sql_prepare)
> except (OSError, IOError) as e:
> pass
> except e:
> logger.info <http://logger.info/>('Error reading SQL file: 
> %s' % file_name)
> raise e
> if MATERIALIZED_VIEWS:
> file_name = sql_view_dir + '/prepare_materialized.sql'
> try:
>

Re: Add custom autoreload file tracking options setting

[Bobby Mozumder]

OK here is some example code snippet where I load prepared SQL statements:


class FastDetailView(DetailView,FastView):

c = connection.cursor()

SQL_VIEW_DIRS = {
'fashion': (
'include/sql/materializedviews/headlines',
'include/sql/materializedviews/latestCollections',
'include/sql/materializedviews/allSeasons',
'include/sql/materializedviews/fullSeason',
'include/sql/materializedviews/gallery',
'include/sql/materializedviews/indexView',
'include/sql/materializedviews/cover',
'include/sql/materializedviews/latestSeasonView',
'include/sql/materializedviews/seasonView',
'include/sql/materializedviews/collectionView',
'include/sql/materializedviews/latestCollectionsJSON',
'include/sql/materializedviews/collectionCardJSON',
'include/sql/materializedviews/indexJSON',
'include/sql/materializedviews/categoryJSON',
'include/sql/materializedviews/articleJSON',
'include/sql/triggers/globals',
'include/sql/triggers/brand',
'include/sql/triggers/collection',
'include/sql/triggers/collectionlookassignment',
'include/sql/triggers/cover',
'include/sql/triggers/look',
'include/sql/triggers/photo',
'include/sql/triggers/season',
'include/sql/triggers/fashion_headlinesviewmat',
'include/sql/triggers/fashion_latestcollectionsviewmat',
'include/sql/triggers/fashion_allseasonsviewmat',
'include/sql/triggers/fashion_fullseasonviewmat',
'include/sql/triggers/fashion_galleryviewmat',
'include/sql/triggers/fashion_coverviewmat',
'include/sql/triggers/fashion_indexviewmat',
'include/sql/triggers/fashion_latestseasonviewmat',
'include/sql/triggers/fashion_seasonviewmat',
'include/sql/triggers/fashion_collectionviewmat',
'include/sql/triggers/fashion_collectioncardjsonviewmat',
),
'analytics': (
'include/sql/analytics',
),
}

MATERIALIZED_VIEWS = True

@classmethod
def prepare_db_queries(self):
logger.info('Reading fashion prepared SQL statements')
cursor = connection.cursor()
for sql_view_dir in SQL_VIEW_DIRS['fashion']:
file_name = sql_view_dir + '/prepare.sql'
try:
with open(file_name, 'r') as file:
sql_prepare=file.read().strip()
if sql_prepare:
cursor.execute(sql_prepare)
except (OSError, IOError) as e:
pass
except e:
logger.info('Error reading SQL file: %s' % file_name)
raise e
if MATERIALIZED_VIEWS:
file_name = sql_view_dir + '/prepare_materialized.sql'
try:
with open(file_name, 'r') as file:
sql_prepare=file.read().strip()
if sql_prepare:
cursor.execute(sql_prepare)
except (OSError, IOError) as e:
pass
except e:
logger.info('Error reading SQL file: %s' % file_name)
raise e


It’s a custom view class that basically reads SQL from a separate list of files 
on initialization, and executes those SQL files.  

If I edit these SQL files, it won't restart the development server.

-bobby

> On Jan 4, 2017, at 4:03 PM, Tim Graham <timogra...@gmail.com> wrote:
> 
> Could you give us a code snippet (sample view, perhaps) demonstrating how 
> this caching happens?
> 
> On Wednesday, January 4, 2017 at 3:57:31 PM UTC-5, Bobby Mozumder wrote:
> Hi, 
> 
> Right now, Django only tracks Python module files for autoreload during 
> development. As a project starts to include more custom include files, such 
> as Javascript, SQL, Makefiles, etc.., the autoreload function doesn't apply 
> to these. 
> 
> For my use case, I have custom view functions that call in separate SQL & 
> Javascript files.  (I don’t use the template system.) 
> 
> If I edit these Javascript & SQL files, the Django server doesn’t autoreload. 
> 
> So, I made a pull-request where we can add a manual list of files to track 
> for autoreload: https://github.com/django/django/pull/7791 
> <https://github.com/django/django/pull/7791> 
> 
> In your project's settings.py file, assign a variable TRACK_FILES containing 
> a list of full file paths to track. This will track files to autoreload the 
> development run server as these files are updated. 
> 
> Is this OK?  This pull request is a basic option and I’m sure it can get more 
> complicated than that (directory tracki

Add custom autoreload file tracking options setting

[Bobby Mozumder]

Hi,

Right now, Django only tracks Python module files for autoreload during 
development. As a project starts to include more custom include files, such as 
Javascript, SQL, Makefiles, etc.., the autoreload function doesn't apply to 
these.

For my use case, I have custom view functions that call in separate SQL & 
Javascript files.  (I don’t use the template system.)

If I edit these Javascript & SQL files, the Django server doesn’t autoreload. 

So, I made a pull-request where we can add a manual list of files to track for 
autoreload: https://github.com/django/django/pull/7791

In your project's settings.py file, assign a variable TRACK_FILES containing a 
list of full file paths to track. This will track files to autoreload the 
development run server as these files are updated.

Is this OK?  This pull request is a basic option and I’m sure it can get more 
complicated than that (directory tracking, Makefiles, Javscript builds, etc..)

-bobby

-- 
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/77BE6024-04E1-4DC1-89BD-24091F151FFC%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Any inerest in Zlib pre-compressed HTML generator responses?

[Bobby Mozumder]

> On Aug 16, 2016, at 2:16 AM, Curtis Maloney <cur...@tinbrain.net> wrote:
> 
> On 16/08/16 09:10, Bobby Mozumder wrote:
>> Hi,
>> 
>> I also use generators for my views, and I use Django’s streaming views
>> with my generators to stream responses, so that the web browser receives
>> early responses and start rendering immediately before the view is
>> completely processed.  The web browser receives the first HTML fragment
>> before I even hit the database.
> 
> The hazard here is if anything raises an exception you've already sent 
> headers to say it didn't... typically this results in pages terminating part 
> way through.
> 
> Other than this, it is certainly a great way to overlap some transport 
> latency with work.  I've done the same with a generator-based JSON serialiser.
> 

I do have the option to query the database once to check if a URL is valid, 
before returning a response. This would also read most of the page’s data in 
the same query.  But right now I’m just letting the URL resolver figure out if 
the page is valid before it hits the database, which can lead to incorrect 
responses given a mangled URL.

All other queries after the primary query are for secondary data - the 
“additional links”, the “categories”, the “further headlines” type of data, and 
those queries would only work if the primary query works as well.  

-bobby

-- 
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/19C8C0A2-76B7-4807-A2F9-06DCB5ED26E2%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Any inerest in Zlib pre-compressed HTML generator responses?

[Bobby Mozumder]

I’ll look into what it would take to make it a separate package, to make it 
more generic and usable by all.

I was pushing for this to be part of the core to overcome Django’s 
“slow-by-default” impression.  My first version of this site had access times 
in the several second range, and it took a while to get that down using things 
like select_related and other optimizations.  

This was especially a problem since i came to Django as a replacement to speed 
up our old PHP-based site that went down during a high-traffic moment.   I 
finally had to toss out the Django the template system and ORM for something 
custom.  

Django really should be “high-speed-out-of-the-box” by default.

-bobby

> On Aug 16, 2016, at 2:14 AM, Jani Tiainen <rede...@gmail.com> wrote:
> 
> Hi,
> 
> To me it looks like this can live just fine outside Django core as a separate 
> package since it doesn't look that it requires any changes to Django core 
> itself. So for the community it doesn't need to be within Django core, you 
> can already do it for all existing and future versions - which would provide 
> nice ground to prove that your solution is good and useful for others as well.
> 
> On 16.08.2016 02:10, Bobby Mozumder wrote:
>> Hi,
>> 
>> I’ve been using zlib compression on my custom view responses on my site 
>> (https://www.futureclaw.com <https://www.futureclaw.com/>).  I do this 
>> before I even cache, and I store the compressed responses in my Redis cache. 
>>  This effectively increases my Redis cache size by about 10x.  It also 
>> reduces response times from my HTTP server by 10s of milliseconds, since my 
>> web server doesn’t have to compress on-the-fly for cached responses - the 
>> view fragments are served directly from the Redis cache.
>> 
>> I also use generators for my views, and I use Django’s streaming views with 
>> my generators to stream responses, so that the web browser receives early 
>> responses and start rendering immediately before the view is completely 
>> processed.  The web browser receives the first HTML fragment before I even 
>> hit the database.
>> 
>> Ultimately my page load times are ridiculously fast, especially for a fully 
>> graphically intensive site.  For full cache miss, it might take 15ms to 
>> generate a page.  For a cache hit, it might take .3ms.  For a full page load 
>> end-user, which loads all fonts and graphics, I'm down to 381ms, faster than 
>> 98% of all sites (it was several seconds before).  See: 
>> https://tools.pingdom.com/#!/cHCL3d/https://www.futureclaw.com 
>> <https://tools.pingdom.com/#%21/cHCL3d/https://www.futureclaw.com>
>> 
>> (BTW I plan on reducing the full-page load times down to the 100-200ms range 
>> using HTTP/2 server push)
>> 
>> Anyways, is this feature of interest to the Django community for perhaps the 
>> next version?
>> 
>> Here is the relevant portion directly lifted from my code as an example.  I 
>> made this earlier this year, and I’m not sure how much this needs to be 
>> changed for use by Django itself, especially considering I don’t use the 
>> Django template system or ORM:
>> 
>> class ZipView(View):
>> 
>> level = 9
>> wbits = zlib.MAX_WBITS | 16
>> 
>> decompressor = zlib.decompressobj(wbits=wbits)
>> 
>> @staticmethod
>> def store(compressor,key,data,time=9,end=False):
>> zData = compressor.compress(data)
>> if end == False:
>> zData += compressor.flush(zlib.Z_FULL_FLUSH)
>> else:
>> zData += compressor.flush(zlib.Z_FINISH)
>> cache.set(key, zData, time)
>> return zData
>> 
>> def inflate(self,decompressor,data):
>> return self.decompressor.decompress(data)
>> 
>> pageData = []
>> 
>> def getPageData(self,slug=None):
>> pass
>> 
>> def generator(self,request,slug=None,compress=True):
>> tuple = []
>> compressor = False
>> decompressor = False
>> 
>> zData = cache.get('pStart')  #pStart contains zlib header.  Header 
>> is needed.
>> if zData is None:
>> html = bytes(self.get_page_start_stream(),'utf-8')
>> compressor = zlib.compressobj(level=self.level, wbits=self.wbits)
>> zData = self.store(compressor,'pStart',html,time=None)
>> else:
>> if compress == False:
>> decompressor = zlib.decompressobj(wbits=self.wbits)
>> html = decompressor.decompress(z

Any inerest in Zlib pre-compressed HTML generator responses?

[Bobby Mozumder]

Hi,

I’ve been using zlib compression on my custom view responses on my site 
(https://www.futureclaw.com).  I do this before I even cache, and I store the 
compressed responses in my Redis cache.  This effectively increases my Redis 
cache size by about 10x.  It also reduces response times from my HTTP server by 
10s of milliseconds, since my web server doesn’t have to compress on-the-fly 
for cached responses - the view fragments are served directly from the Redis 
cache.

I also use generators for my views, and I use Django’s streaming views with my 
generators to stream responses, so that the web browser receives early 
responses and start rendering immediately before the view is completely 
processed.  The web browser receives the first HTML fragment before I even hit 
the database.

Ultimately my page load times are ridiculously fast, especially for a fully 
graphically intensive site.  For full cache miss, it might take 15ms to 
generate a page.  For a cache hit, it might take .3ms.  For a full page load 
end-user, which loads all fonts and graphics, I'm down to 381ms, faster than 
98% of all sites (it was several seconds before).  See: 
https://tools.pingdom.com/#!/cHCL3d/https://www.futureclaw.com

(BTW I plan on reducing the full-page load times down to the 100-200ms range 
using HTTP/2 server push)

Anyways, is this feature of interest to the Django community for perhaps the 
next version?

Here is the relevant portion directly lifted from my code as an example.  I 
made this earlier this year, and I’m not sure how much this needs to be changed 
for use by Django itself, especially considering I don’t use the Django 
template system or ORM:

class ZipView(View):

level = 9
wbits = zlib.MAX_WBITS | 16

decompressor = zlib.decompressobj(wbits=wbits)

@staticmethod
def store(compressor,key,data,time=9,end=False):
zData = compressor.compress(data)
if end == False:
zData += compressor.flush(zlib.Z_FULL_FLUSH)
else:
zData += compressor.flush(zlib.Z_FINISH)
cache.set(key, zData, time)
return zData

def inflate(self,decompressor,data):
return self.decompressor.decompress(data)

pageData = []

def getPageData(self,slug=None):
pass

def generator(self,request,slug=None,compress=True):
tuple = []
compressor = False
decompressor = False

zData = cache.get('pStart')  #pStart contains zlib header.  Header is 
needed.
if zData is None:
html = bytes(self.get_page_start_stream(),'utf-8')
compressor = zlib.compressobj(level=self.level, wbits=self.wbits)
zData = self.store(compressor,'pStart',html,time=None)
else:
if compress == False:
decompressor = zlib.decompressobj(wbits=self.wbits)
html = decompressor.decompress(zData)
if compress == False:
zData = html
yield zData

pageKey = self.getPageKey(slug)
zPageData = cache.get(pageKey)
if zPageData is None:
expire = 3600
zPage = b''
self.getPageData(slug)

#Fragment tuples contain HTML generator & associated parameters, as 
well as cache settings for each fragment.
for tuple in self.fragments(request):
if tuple[2]:
if tuple[2] < expire:
expire = tuple[2]
k = tuple[0]+str(tuple[1])
zData = cache.get(k)
if zData is None:
func = tuple[3]
html = bytes(func(*tuple[4:]),'utf-8')
if compressor == False:
compressor = zlib.compressobj(level=self.level, 
wbits=self.wbits)
self.store(compressor,'zHeader',b"")
zData = self.store(compressor,k,html,tuple[2])
else:
if compress == False:
if decompressor == False:
decompressor = zlib.decompressobj(wbits=self.wbits)
html = decompressor.decompress(zData)
zPage += zData
if compress == False:
zData = html
yield zData
zData = cache.get('pEnd')
if zData is None:
html = bytes(self.get_closing_stream(),'utf-8')
if compressor == False:
compressor = zlib.compressobj(level=self.level, 
wbits=self.wbits)
self.store(compressor,'zHeader',b"")
zData = self.store(compressor,'pEnd',html,time=None,end=True)
else:
if compress == False:
if decompressor == False:
decompressor = zlib.decompressobj(wbits=self.wbits)
html = decompressor.decompress(zData)

Should tutorial start with minimal Django?

[Bobby Mozumder]

Hi,

Here’s an example of minimal Django, where one can output run an full site from 
a single file:
 https://github.com/rnevius/minimal-django

The author made the comparison to Flask.

I believe the tutorial should start out with this, as the initial Part 0, to 
introduce the audience to the framework, before introducing 
apps/models/subdirectories/etc.  I think a lot of people are turned off by the 
heavy-handed immediate introduction of many files and directories of a Django 
setup - I know I was when I first started with Django.

Anyways just putting this out there.

-bobby

-- 
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/33F74D49-8220-4F74-96A8-1AD4740A7D88%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Add an optional parameter to values() that returns a nested dictionary for foreign keys

[Bobby Mozumder]

A useful overall target for the next Django version would be to try and get all 
these feature up so that high-speed REST API development becomes easier.  
(really need to be able to push thousands of requests per second)

I’d like to directly go from Query to Response:  

response = JsonResponse(Articles.objects.get(id=1).values(’title’, ’author’, 
‘body'))   

While still having things like aliased fields, nested trees, and value 
formatting.

-bobby

> On Nov 25, 2015, at 10:43 AM, Tim Graham <timogra...@gmail.com> wrote:
> 
> There's an accepted ticket for adding aliasing to values(): 
> https://code.djangoproject.com/ticket/16735
> 
> The current patch there hijacks values() **kwargs for the mapping of renamed 
> fields which would prevent adding other kwargs like "nested" without 
> disallowing those values as aliases. I guess we may want to rethink that 
> approach.
> 
> On Wednesday, November 25, 2015 at 10:20:37 AM UTC-5, Bobby Mozumder wrote:
> I could also use a couple of enhancement to this:
> 
> 1) Allow renaming of keys, instead of using the database column names.  
> 2) Allow callbacks functions (or lambdas) to convert output values to another 
> format if needed.
> 
> With this, I could send the queries results right to JSON outputs.
> 
> -bobby
> 
>> On Nov 25, 2015, at 9:05 AM, Moenad <moe.i...@gmail.com > wrote:
>> 
>> Currently, after calling values() and the query executes, the output is a 
>> single level dictionary, including foreign keys. I propose adding an extra 
>> parameter for values, or at least values_list, where if it's set to true, a 
>> nested dictionary will be returned when there's a foreign key.
>> 
>> Example:
>> 
>> Person model with the following fields: first_name, last_name and hometown 
>> (foreign key)
>> Hometown model with the following fields: name
>> 
>> A single record from Person.objects.values() will looks like this
>> 
>> {"id": 1
>>  "first_name": "first name",
>>  "last_name": "last name",
>>  "hometown__id": 1,
>>  "hometown__name": "town name",
>> }
>> 
>> 
>> I propose adding a nested optional parameter to values, where a single 
>> record from Person.objects.values(nested=True) will look like
>> 
>> {"id": 1
>>  "first_name": "first name",
>>  "last_name": "last name",
>>  "hometown": {
>>   "id": 1,
>>   "name": "town name"
>>   }
>> }
>> 
>> 
>> This feature is needed given that most APIs these days are nested, while 
>> it's simple to implement, I think it's much better to have it a built-in 
>> django feature.
>> 
>> 
>> -- 
>> 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-develop...@googlegroups.com .
>> To post to this group, send email to django-d...@googlegroups.com 
>> .
>> Visit this group at http://groups.google.com/group/django-developers 
>> <http://groups.google.com/group/django-developers>.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/8e5cbc9a-0317-40d3-8038-5b4300738b90%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/django-developers/8e5cbc9a-0317-40d3-8038-5b4300738b90%40googlegroups.com?utm_medium=email_source=footer>.
>> For more options, visit https://groups.google.com/d/optout 
>> <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 
> <mailto:django-developers+unsubscr...@googlegroups.com>.
> To post to this group, send email to django-developers@googlegroups.com 
> <mailto:django-developers@googlegroups.com>.
> Visit this group at http://groups.google.com/group/django-developers 
> <http://groups.google.com/group/django-developers>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/369843ca-7b82-49b9-b7f5-e2f7fa578ca7%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/django-developers/369843ca-7b82-49b9-b7f5-e2f7fa578ca7%40googlegroups.com?utm_medium=em

Re: Add an optional parameter to values() that returns a nested dictionary for foreign keys

[Bobby Mozumder]

I could also use a couple of enhancement to this:

1) Allow renaming of keys, instead of using the database column names.  
2) Allow callbacks functions (or lambdas) to convert output values to another 
format if needed.

With this, I could send the queries results right to JSON outputs.

-bobby

> On Nov 25, 2015, at 9:05 AM, Moenad  wrote:
> 
> Currently, after calling values() and the query executes, the output is a 
> single level dictionary, including foreign keys. I propose adding an extra 
> parameter for values, or at least values_list, where if it's set to true, a 
> nested dictionary will be returned when there's a foreign key.
> 
> Example:
> 
> Person model with the following fields: first_name, last_name and hometown 
> (foreign key)
> Hometown model with the following fields: name
> 
> A single record from Person.objects.values() will looks like this
> 
> {"id": 1
>  "first_name": "first name",
>  "last_name": "last name",
>  "hometown__id": 1,
>  "hometown__name": "town name",
> }
> 
> 
> I propose adding a nested optional parameter to values, where a single record 
> from Person.objects.values(nested=True) will look like
> 
> {"id": 1
>  "first_name": "first name",
>  "last_name": "last name",
>  "hometown": {
>   "id": 1,
>   "name": "town name"
>   }
> }
> 
> 
> This feature is needed given that most APIs these days are nested, while it's 
> simple to implement, I think it's much better to have it a built-in django 
> feature.
> 
> 
> -- 
> 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 http://groups.google.com/group/django-developers 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/8e5cbc9a-0317-40d3-8038-5b4300738b90%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/2719FB24-E00F-4C85-BD9A-FF1FB2EB3799%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Request: initialize fields with built-in class defaults

[Bobby Mozumder]

> On Jun 15, 2015, at 1:42 PM, Rick van Hattem (wolph) <wolp...@gmail.com> 
> wrote:
> 
> While I understand the rationale, it's not really possible due to the 
> underlying Python object:
> >>> import datetime
> >>> datetime.date()
> Traceback (most recent call last):
>   File "", line 1, in 
> TypeError: Required argument 'year' (pos 1) not found
> >>> datetime.datetime()
> Traceback (most recent call last):
>   File "", line 1, in 
> TypeError: Required argument 'year' (pos 1) not found
> 

A custom Django field would either assign initial values to classes that need 
it, or use classes that have their own initial values.  The point is that the 
class itself should always exist in the field.

> Note that you can easily support it by having something like this:
> 
> class Question(models.Model):
>  pub_date = models.DateField(default=datetime.date.today, blank=True)
> 
> 

Right.  I’m trying to avoid this situation, as this adds a lot of code - I have 
dozens of custom fields instantiated hundreds of times in an app, with a lot of 
initialization data each.  It also requires the knowledge of which internal 
class that the field uses.  So, I have a common get/set interface for each 
custom field, so I don’t need to know which class that a field uses, as long as 
I interface with it properly.

-bobby

> 
> ~wolph
> 
> On Monday, June 15, 2015 at 7:52:13 AM UTC+2, Bobby Mozumder wrote:
> Hi all,
> 
> Here’s an issue of usability that if fixed could make usage of custom fields 
> simpler.
> 
> Right now fields don’t allow a built-in defaults, and you need to explicitly 
> set the default parameter for model fields.  The problem is that this adds a 
> ton of boilerplate code.
> 
> Using the Polls tutorial example, if I do:
> 
> >>> from polls.models import Question, Choice
> >>> q = Question()
> 
> By default it’s always :
> 
> >>> type(q.pub_date)
> 
> 
> The pub_date should always be a type .  If this 
> was defined in the model constructor, then we could start to access the 
> datetime.datetime class immediately, to assign data.  If I had a custom 
> datetime.datetime class, I could possibly do this immediately:
> 
> >>> q = Question()
> >>> q.pub_date.month = 11
> >>> q.pub_date.day = 26
> >>> q.pub_date.year = 2016
> >>> q.save()
> 
> But right it would give the following error:
> 
> >>> q.pub_date.year = 2016
> Traceback (most recent call last):
>   File "", line 1, in 
> AttributeError: 'NoneType' object has no attribute 'year'
> 
> Is this a reasonable request?  
> 
> I’m able to do something like this now with my own custom fields that derive 
> from models.SubfieldBase, but that class is deprecated, and the new 1.8 model 
> initializer doesn’t do this anymore.
> 
> Thank you,
> 
> -bobby
> 
> -- 
> 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 
> <mailto:django-developers+unsubscr...@googlegroups.com>.
> To post to this group, send email to django-developers@googlegroups.com 
> <mailto:django-developers@googlegroups.com>.
> Visit this group at http://groups.google.com/group/django-developers 
> <http://groups.google.com/group/django-developers>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/43d136dd-b8d7-45fe-91af-1863cb5aa205%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/django-developers/43d136dd-b8d7-45fe-91af-1863cb5aa205%40googlegroups.com?utm_medium=email_source=footer>.
> For more options, visit https://groups.google.com/d/optout 
> <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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CD62262A-302A-41F0-AF26-A1F34EC45D34%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Request: initialize fields with built-in class defaults

[Bobby Mozumder]

Hi all,

Here’s an issue of usability that if fixed could make usage of custom fields 
simpler.

Right now fields don’t allow a built-in defaults, and you need to explicitly 
set the default parameter for model fields.  The problem is that this adds a 
ton of boilerplate code.

Using the Polls tutorial example, if I do:

>>> from polls.models import Question, Choice
>>> q = Question()

By default it’s always :

>>> type(q.pub_date)


The pub_date should always be a type .  If this was 
defined in the model constructor, then we could start to access the 
datetime.datetime class immediately, to assign data.  If I had a custom 
datetime.datetime class, I could possibly do this immediately:

>>> q = Question()
>>> q.pub_date.month = 11
>>> q.pub_date.day = 26
>>> q.pub_date.year = 2016
>>> q.save()

But right it would give the following error:

>>> q.pub_date.year = 2016
Traceback (most recent call last):
  File "", line 1, in 
AttributeError: 'NoneType' object has no attribute 'year'

Is this a reasonable request?  

I’m able to do something like this now with my own custom fields that derive 
from models.SubfieldBase, but that class is deprecated, and the new 1.8 model 
initializer doesn’t do this anymore.

Thank you,

-bobby

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1EBED647-BBA2-422B-A907-C9FBD6BC50F8%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature: Support a javascript template language on the server

[Bobby Mozumder]

> On Jun 2, 2015, at 2:43 AM, Emil Stenström <e...@kth.se> wrote:
> 
> On Tuesday, 2 June 2015 05:19:43 UTC+2, Bobby Mozumder wrote:
> At this point it’s probably easiest for Django to provide templates only for 
> Javascript front-end, and for Django to only serve API endpoints. 
> 
> We really don’t need Django to serve HTML pages anymore, except for the 
> initial page-load. 
> 
> In 2012, Twitter posted in their engineering blog about their conclusions of 
> trying to move all rendering to the client. It was just too slow. The answer, 
> and what is considered "best practice" now, is to render everything on the 
> server the first load, and render all subsequent page loads to the client. 
> This also means you get a nice fallback for clients that don't support 
> javascript.
> 

Yes, my expectation is that Django still only serves API endpoints, with 
something like Node.js & Ember Fastboot serving pages.

Ember's Fastboot would make for an ideal candidate as a starting point for a 
new design for Django’s template view layer.

-bobby

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/6C44F42E-9BDD-4DEE-A6F0-937E95D55C5E%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature: Support a javascript template language on the server

[Bobby Mozumder]

At this point it’s probably easiest for Django to provide templates only for 
Javascript front-end, and for Django to only serve API endpoints.

We really don’t need Django to serve HTML pages anymore, except for the initial 
page-load.

I believe this is where the web is headed for the long-term.

It may be possible to develop a Python syntax that analogous to HTML templates, 
with Django translating that for Javascript templating.

Now, whether Django serves these templates in Angular/Ember/React/whatever or 
develop some new framework (or even new HTML standards that operates on APIs 
directly...), is another question.  

-bobby

> On Jun 1, 2015, at 12:08 PM, Javier Guerra Giraldez  
> wrote:
> 
> On Sun, May 31, 2015 at 5:21 PM, Emil Stenström  wrote:
>> Are you saying you prefer implementing all templates in two languages, since
>> implementing views twice is too much work? The time you save being able to
>> reuse the same templates in the client side is huge, and avoids the
>> maintenance burden of keeping two identical things in sync.
>> 
>> I'm also not saying you should implement views twice. Each time you click a
>> link that request can go to the exact same server side view, get the correct
>> data back (only the data), and re-render only the parts that changed.
>> 
>>> 
>>> Also the need to reimplement django.shortcuts.render is unneded. Add in
>>> the base tpl a {% if request.is_ajax %} then wrap the result in a entire
>>> html tpl for regular http calls and the new content only in the other case.
>> 
>> 
>> I'm not sure I follow here. Are you saying I should just go through all my
>> templates and split them in two? What do you mean by "new content" here? My
>> suggestion is that you would send only the new DATA, and that the client
>> would use that data, and the templates, to re-render the page.
> 
> 
> first advice when discussing things on the internet:  don't take it personal.
> 
> I think that Enrique means that having "the same" template language is
> a non-goal.  the "cognitive burden" of two languages is not so heavy;
> and since these two environments are so different, there would be
> different considerations that make some features unpractical on one
> side or the other; or maybe some choice could be "the best" on one and
> too awkward or badly supported on the other.
> 
> personally, i mostly agree: i do use templating on JS, and it doesn't
> look at all like Django templates.  That means sometimes i render some
> things in the server, other things in the front end, and a few things
> (very few) on both, leading to mostly duplicate code.  would it be
> nice to have some code that works equally well on either side? yes,
> but it's a relatively small gain.
> 
> if "using the same language" was so important, we would all be using 
> node.js...
> 
> -- 
> Javier
> 
> -- 
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/CAFkDaoSOYOoyX0w_m0ERzhiJmVPXWGr6pB29AongesG43gOw1w%40mail.gmail.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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/77987679-053A-452B-98B1-920B6D09263A%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: ANN: Django website redesign launched

[Bobby Mozumder]

For the Documentation, one suggestion I have is that the body font that’s more 
different from the source code font.

It looks like you’re using Roboto (a Helvetica clone) for the body text and 
Incosolota for the source code. They’re a little too similar.  Also, Roboto 
isn’t a good font for descriptive sentences and paragraphs.  It’s more of a 
short text font for titles, subheadline, and captions.

You generally don’t write long paragraphs with Helvetica, and you shouldn’t do 
that in Roboto either.

-bobby

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/DE43C262-BD64-4140-B82A-A046308F2EE2%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: ANN: Django website redesign launched

[Bobby Mozumder]

Looks great.  Thanks.

Will this same look apply to the admin backend?

-bobby


> On Dec 16, 2014, at 11:09 AM, Jannis Leidel  wrote:
> 
> Hi everyone,
> 
> We're incredibly proud to share with you the new design of the Django 
> website, the documentation and the issue tracker.
> 
> This is a long time coming and we couldn't be happier to finally ship it :)
> 
> As you can imagine, there will be bugs, so please bear with us and report 
> issues to the issue tracker at 
> https://github.com/django/djangoproject.com/issues
> 
> More infos about the redesign and its history can be found in the blog post:
> 
>  
> https://www.djangoproject.com/weblog/2014/dec/15/announcing-django-website-redesign/
> 
> Happy coding, everyone!
> 
> Jannis
> 
> -- 
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/EE1A1FDE-4750-4CED-A450-F2BB0F579FC1%40gmail.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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/C76CB2DE-D6D2-4154-8B78-F096B392FEF9%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

django.db.models.field.subclassing issue

[Bobby Mozumder]

In the file subclassing.py, should the following:


def make_contrib(superclass, func=None):
"""
Returns a suitable contribute_to_class() method for the Field subclass.

If 'func' is passed in, it is the existing contribute_to_class() method on
the subclass and it is called before anything else. It is assumed in this
case that the existing contribute_to_class() calls all the necessary
superclass methods.
"""
def contribute_to_class(self, cls, name):
if func:
func(self, cls, name)
else:
super(superclass, self).contribute_to_class(cls, name)
setattr(cls, self.name, Creator(self))

return contribute_to_class

instead be:

def make_contrib(superclass, func=None):
"""
Returns a suitable contribute_to_class() method for the Field subclass.

If 'func' is passed in, it is the existing contribute_to_class() method on
the subclass and it is called before anything else. It is assumed in this
case that the existing contribute_to_class() calls all the necessary
superclass methods.
"""
def contribute_to_class(self, cls, name):
if func:
func(self, cls, name)
else:
super(superclass, self).contribute_to_class(cls, name)
setattr(cls, self.name, Creator(self))

return contribute_to_class

Should the setattr() should be called only when there isn’t a 
contribute_to_class() method. 

I ask because in my own custom field, I have a  contribute_to_class() function 
as well:

def contribute_to_class(self, cls, name):
super(myCustomField, self).contribute_to_class(cls, name)
setattr(cls, self.name, myCustomCreator(self))

But, because of the setattr() in the SubfieldBase metaclass, my own setattr() 
gets overwritten by the default set_attr().. I therefore can’t have my own 
field of the same name with my own custom Creator().

Is this expected behavior?

-bobby



-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/B459F14E-F899-4972-BB04-F9AA95326FD7%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Django views/templates vs. Javascript MVC Front-ends

[Bobby Mozumder]

It seems that the MVC Javascript systems like Angular and Ember are winning the 
front-end.  They're very responsive compared to being served files from the 
back-end - no need to wait for server responses, since there's a local cache 
subset of the database in the browser.

It would probably be useful to move the Django front-end view 
controller/template systems to something like that over the long-term.  Right 
now there's a lot of repetition, of recreating the django models within the 
front-end database models cache, as well as recreating the templates itself, 
when we try to integrate a front-end framework with Django.

Also, I'm pretty sure that if django doesn't come up with a front-end 
javascript MVC framework, then the Angular or Ember guys are going to come up 
with a back-end solution.

Anyways, just some ideas.  Maybe this was already discussed and rejected?  
Don't know.

Thank you,

-bobby

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/105A09AE-D18D-4AE9-8813-D9CF90323DA4%40gmail.com.
For more options, visit https://groups.google.com/d/optout.