Re: An improved settings.py configuration (revisited)
Russ & Carl: Thanks for the course correction. I guess one tends to read what one wants to see, rather than what the writer wrote. Yes, this would make a good package, and I can do some different things with it that way. For example, I really want to type: >dj -s test_vernon rather than: >python manage.py --settings=myproject.preset.test_vernon I may call it something like django-quick-settings. Again, thank you for your always kind and valuable input. -- Vernon Cole On Saturday, March 8, 2014 5:01:30 PM UTC-7, Russell Keith-Magee wrote: > > > On Sun, Mar 9, 2014 at 3:14 AM, Carl Meyer > > wrote: > >> Hi Vernon, >> >> On 03/07/2014 07:44 PM, VernonCole wrote: >> > Several months ago, I floated an idea on this forum for re-structuring >> > the settings.py environment. >> > >> > It generated a fair amount of discussion. The consensus was that >> > something really ought to be done, but no one was sure just what. >> >> There was not consensus that "something really ought to be done." I was >> part of that discussion, and my opinion was (and still is) that nothing >> needs to be done (in Django core). >> >> (For reference, a link to that discussion: >> https://groups.google.com/d/topic/django-developers/O89Qb_9pwmo/discussion) >> >> Your proposed technique covers a lot of options - that's great. It works >> fine without any changes to Django, and you can package it up as a >> startproject template, use it, and promote it. >> >> I think the default startproject template should remain as simple as >> possible (that is, a single-file settings.py) and not try to provide all >> possible ways of handling multiple-deployment settings. >> > > I agree with Carl. It takes a very selective reading of that discussion to > say that there was consensus on anything. > > I also agree that the default start project template should be kept > simple, and any changes in project structure such as you have proposed > should be maintained on a per-project basis, depending on the needs of > individual projects. > > Yours, > Russ Magee %-) > > -- 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/e97b2c6e-566a-4fd5-924e-6f8b4f85e569%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Revisiting multiline tags
+1 for me too
On Thursday, March 6, 2014 3:28:59 PM UTC-5, Andre Terra wrote:
>
> +1, for one simple reason: practicality beats purity.
>
>
> On Wed, Mar 5, 2014 at 10:23 AM, Daniel Ellis
> > wrote:
>
>> +1 - I've had the same issue with sorl thumbnail.
>>
>>
>> On Wed, Mar 5, 2014 at 7:07 AM, Adam Serafini
>>
>> > wrote:
>>
>>> +1 for multiline template tags
>>>
>>> Regarding: "we want to discourage putting business logic in the template"
>>>
>>> Long template tags can happen even if they are logic-less, and they
>>> would read much nicer over several lines. For example:
>>>
>>> {% cloudinary main_image.image width=300 height=300 class="img-thumbnail
>>> main-product-image" crop="fill" gravity="face" effect="sepia" %}
>>>
>>> There's no business logic here: every parameter in this tag is
>>> presentational log and belongs in templates (<- unless I'm wrong about
>>> that, please suggest a refactoring to me if you believe one is appropriate
>>> here!)
>>>
>>>
>>>
>>> On Wednesday, July 17, 2013 1:48:38 AM UTC+1, Russell Keith-Magee wrote:
>>>
On Tue, Jul 16, 2013 at 9:41 PM, Daniel Ellis wrote:
> My grandfather was a developer in a nuclear plant that I was interning
> at. They used a Django-based web interface for internal operations.
>
> One of the functions their Django application managed was the release
> of nuclear material. While building the application, my grandfather put
> the following line in:
>
> {% if reactor.safe_to_release_deadly_radiation and
> reactor.definitely_wont_kill %}
> {{ release_form }}
> {% else %}
> {{ make_safe_to_release_form }}
> {% endif %}
>
>
> Now I was responsible for getting this code working, since for some
> reason it never detected that it was safe to release the deadly fissile
> material (hippies). So I put the following statement in:
>
> {% if reactor.safe_to_release_deadly_radiation and
> reactor.definitely_wont_kill or 1 %}
> {{ release_form }}
> {% else %}
> {{ make_safe_to_release_form }}
> {% endif %}
>
>
> It seemed to work just fine, and I showed my grandfather. Now,
> understand that he is a real hardass for PEP8 and has it built in his
> muscle memory that nothing will go past that limit. Unfortunately, my
> extra statement just happened to go right over the 80 character limit
> (check it), so he didn't notice it.
>
> Fast forward 2 months. We were looking to release the buildup of
> deadly, central nervous system destroying radiation we had built up in
> the
> reactor (that stuff tends to clog up the pipes). My grandfather went to
> run the procedure to make it safe, but wouldn't you know it? That debug
> statement was still there. Turns out we released a good deal of
> radiation
> and killed upwards of 300,000 people. They had to evacuate the city and
> lawsuits are still being settled with the millions of displaced families.
>
> Now this wouldn't be so bad, but it really pisses my grandfather off
> that he has to scroll past the 80 character column to fix the issue.
>
As amusing as your story is, hyperbole won't win the argument.
Hyperbole aside, you haven't added anything to the discussion that we
didn't already know. Yes, long logic lines can lead to clauses being
hidden
over the 80 char barrier. This isn't news.
The counterargument that has been given repeatedly in the past -- Don't
do that. One of the reasons that Django's template logic is intentionally
hobbled is that we want to discourage putting business logic in the
template. Not adding multiline tags is one of the contributors to this
hobbling. Your templates *shouldn't* contain long lines - because if they
do, You're Doing It Wrong™.
How should it be done? Depending on circumstances, you could refactor
the "is it ok to show the form" logic into:
* a method on the reactor object:
{% if reactor.ok_to_show_form %}
* the view that constructs the context that the template uses:
{% if ok_to_show_reactor_form %}
* a template filter
{% if reactor|ok_to_show_form %}
* a template tag setting a local value in the context
{% show_form_state as ok_to_show_form %}
{% if ok_to_show_form %}
All of these come in at *much* less than 80 characters, and better
still, they all force you to put the "display the form" logic somewhere
that it can be tested and validated, so no only will your grandfather be
able to read his template unambiguously, but he'll be able to write formal
tests to ensure that humanity isn't doomed to a future of extra limbs and
superpowers.
Which one of these approaches is the best for your circumstances will
de
Re: [GSOC] Introduction and task proposal
Hi Russel, Sorry for getting back now (I did not have notifications set up!). Thank you very much for the suggestions, I will have a look at models/options.py right away. Regards, Daniel Pyrathon On Thursday, March 6, 2014 12:03:04 AM UTC, Russell Keith-Magee wrote: > > Hi Daniel, > > On Wed, Mar 5, 2014 at 11:48 PM, Daniel Pyrathon > > > wrote: > >> Hi, >> >> My name is Daniel Pyrathon. I am currently a third year BSc student in >> Computer Science at the University of Plymouth. >> >> I love programming and I have always been active in the Open Source >> community (especially Python). In the past years I have written lots of >> Python, Javascript, Ruby, Java, and I am currently using C++ for many >> university projects. I have attended the last 3 EuroPython conferences and >> I have been a staff member of the conference for the last 2 years. >> >> I am currently looking for a way to contribute to Django. Working on >> Django would increase my knowledge of the framework as well as let me share >> my own experience. >> >> Reading the ideas list I found 2 of them that are very interesting for >> me, and so the reason behind this post is not only to present myself but >> also to discuss their feasibility. >> >> Formalizing the Meta object >> >> This task is very challenging because it digs in the internals of Django. >> I feel that I could learn a lot from it because I am very committed to >> refactoring and write most of my code in TDD. I have also experience with >> backwards compatibility. >> >> Do you have any resources (code) I should read to get up to date and to >> understand better how it is currently implemented? >> > > Unfortunately not; at least, not other than just trying to untangle the > mess that is django/db/models/options.py and the things that depend on it > (ModelForms and Admin in particular). This project really is the very model > of untangling a ball of string. The reason it's listed as a potential > project is specifically *because* there are no resources we can point you > at. > > If, after looking at the code, you feel it's a little "thin" for 12 weeks, > one way to bulk it out is to build a proof of concept alternate > implementation of Meta. Aside from the "it would be good to document this" > aspect, the practical reason for wanting to formalise Meta is that it would > allow people to build duck-typed implementations of Meta. If you can build > an alternate implementation of the Meta interface, then you should be able > to deploy your "duck" into a Django project and build a ModelForm, or > browse it in Admin. > > So, for example, you could build a wrapper around a NoSQL store, or around > an LDAP or email store, that *looked* like a Django model from the outside. > This means you could view your NoSQL data, or LDAP records, or emails in > Admin without needing to go through a SQL database. > > The aim of proof of concept wouldn't be to commit something to Django's > core - it would be to build an external, standalone proof-of-concept, > demonstrating that your documentation was complete and correct. Depending > on what backend you choose, it might turn into a fully viable project on > it's own. > > >> Improved error reporting >> >> The idea of making people’s lives better by improving error messages is >> fundamental. There would be a lot to discuss: what type of imports would we >> want to mask? I have read BetterErrorMessages and would be happy to get >> started soon. My idea behind this task would be to expand on this ticket: >> what would be great is to add a web console with live REPL support, similar >> to what Werkzeug debugger does. This could be a great starting point and >> would lead to a better use of Django. >> > > This is an interesting idea; however, I see two problems: > > 1) It would involve reinventing the wheel. Werkzeug exists, and does its > job well; a GSoC project to "duplicate Werkzeug" doesn't strike me as a > good use of GSoC resources. However, a project to integrate Werkzeug's live > debugging capabilities into Django might be more viable. > > 2) Security implications. Unfortunately, more than one site has been > launched with debug=True accidentally left on; all you need to do then is > stimulate a server error, and you have REPL shell access to the server. > This strikes me as a remarkably effective foot-gun :-) Before you get too > involved in the implementation, I'd want to know the security issues have > been locked down. > > >> Said this, I have to be very honest. I have never contributed to Django >> up till now and I want to hear your feedback on which proposal would suit >> me best. However I learn a lot through experience and I am attracted by >> new and challenging tasks. >> > > My suggestion would be that the Meta project is probably better suited to > a newcomer. The Error reporting project is a little vague - it relies on > someone having a bit of experience with Django to k
