Re: Revisiting multiline tags
+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
> depend on exactly what you're doing -- the approaches are functionally
> equivalent, but that doesn't mean that they're equivalent from a logical
> perspective. Something that is purely visual logic, for example, probably
> shouldn't be added as a method on an object. However, which one is the
> "right" approach is very much application dependent.
>
> Yours,
> Russ Magee %-)
>
>
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 t
Re: Revisiting multiline tags
+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(tm).
>>
>> 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
>> depend on exactly what you're doing -- the approaches are functionally
>> equivalent, but that doesn't mean that they're equivalent from a logical
>> perspective. Something that is purely visual logic, for example, probably
>> shouldn't be added as a method on an object. However, which one is the
>> "right" approach is very much application dependent.
>>
>> Yours,
>> Russ Magee %-)
>>
>>
> On Wednesday, July 17, 2013 1:48:38 AM UTC+1, Russell Keith-Magee wrote:
>
>>
>> On Tue, Jul 16, 2013 at 9:41
Proposal: update_fields shortcut
Hello everyone,
While developing standard web applications one thing I frequently do is
updating just one field of a model instance and save it after that. The best
way to do that today (if you want to avoid the update in all the fields) is
with the code bellow.
product.name = 'Name changed again' product.save(update_fields=['name'])
I want to propose a shortcut for this kind of operation. I came up with two
solutions.
Solution One
product.save(update_fields={'name': 'Name changed again'})
Solution Two (My preferred)
product.update_fields(name='Name changed again')
What do you guys think about this?
[]’s
Paulo Poiati
blog.paulopoiati.com
--
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/af689c4f-4526-4b08-ade2-9044181e3950%40Paulos-iMac.local.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Proposal: update_fields shortcut
On Wed, Mar 5, 2014 at 2:05 PM, Paulo Poiati wrote:
> Hello everyone,
>
> While developing standard web applications one thing I frequently do is
> updating just one field of a model instance and save it after that. The best
> way to do that today (if you want to avoid the update in all the fields) is
> with the code bellow.
>
> product.name = 'Name changed again'
> product.save(update_fields=['name'])
>
>
> I want to propose a shortcut for this kind of operation. I came up with two
> solutions.
>
> Solution One
>
> product.save(update_fields={'name': 'Name changed again'})
>
>
> Solution Two (My preferred)
>
> product.update_fields(name='Name changed again')
>
>
Solution Three (existing)
Product.objects.filter(pk=product.pk).update(name='Name changed again')
?
Cheers
Tom
--
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/CAFHbX1%2Bxf77_vMPK881gaQuE9EKf6uyKiZHEMS%2BMPev3hWzQNw%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.
[GSOC] Introduction and task proposal
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? 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. 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. Also, it would be nice if I could have some suggestions on what to read and if there are some specific parts of the code I should be directed to. Please let me know, Daniel Pyrathon -- 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/0b1cc1e7-063a-48ea-9c92-eaa0344d396d%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Proposal: update_fields shortcut
The solution three is also a really nice feature Tom, but it’s a different think, IMO. The update() is a QuerySet method and it does not call the save() method or trigger any of the signals. This is very important, specially for third party packages support. The django-model-utils for example… ... from model_utils.fields import MonitorField class Invoice(model.Model): ... paid_at = MonitorField(monitor='paid') def pay(self): self.update_fields(paid=True) []’s Paulo Poiati blog.paulopoiati.com -- 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/f5acf03d-7a90-4e34-9cae-80411abba580%40Paulos-iMac.local. For more options, visit https://groups.google.com/groups/opt_out.
Re: Testing parameters in database settings
Hi, I've put up https://github.com/django/django/pull/2400 for review. It makes the changes discussed -- test settings go into a 'TEST' dictionary in the database settings, with a deprecation warning for old settings. While at it, I added (in a separate commit) a renaming of two Oracle-specific settings -- because I don't like current names, and this is a good opportunity to change them. At some future point, I want to make "CREATE_DB" available to all backends, so this renaming is not just an Oracle issue. There is documentation, but no tests -- database settings are impossible to test automatically. I want this to go in before the beta; it's a rather small PR. If there are no comments, I'll probably commit it tomorrow or the day after. Have fun, Shai. -- 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/201403052141.58101.shai%40platonix.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Django 1.7: modelformset_factory() vs formset_factory()
On Sun, Mar 2, 2014 at 8:27 PM, Tim Graham wrote: > Yes, see https://code.djangoproject.com/ticket/17642. If you can bring > the patch up to date in the next day or two, I'll try to help review and > commit it. > A day after "the next day or two" :) but I just supplied an updated patch. If you can help review it, I would appreciate it and make any required adjustments quickly. Cheers, Anders -- 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/CAC35HNmibUDRLADKqdn6irusFnsj%3DHVgxhKzQ2iMz0JXp1_6bA%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: 1.6 reverse() escapes unreserved chars in path components
On Sunday, 2 March 2014 05:58:37 UTC-8, Sam Lai wrote:
>
> It seems like the fix makes it easier for 90% of the uses, but
> explicitly blocks the other 10% (i.e. uses involving the use of
> 'reserved' characters as permitted by the RFC).
>
Yes. I'm bringing this up because it breaks certain OAuth 1 clients against
Bitbucket.
In some places we redirect to URLs whose path segment contains a ":". Prior
to us upgrading to 1.6 the response's location header preserved that colon,
but now it gets escaped, changing the URL
(e.g.
https://api.bitbucket.org/2.0/repositories/david/django-storages/pullrequests/51/diff
redirecting to
https://api.bitbucket.org/2.0/repositories/david/django-storages/diff/regadas/django-storages%3A069fd1d01fbf..f153a70ba254)
In OAuth 1, requests are signed, including the request URL, but the
RFC-5849 does not mandate any pre-processing of the URL. For several OAuth
clients (including requests-oauthlib and python-oauth2) that means they
compute the signature over a string that contains "%3A" instead of ":".
On the server however, the request path automatically gets unquoted before
it hits the middlewares and views. As our OAuth layer is a middleware that
reconstructs the signature, it ends up computing over ":", yielding a
different signature than the client, breaking authentication.
This might be addressable by changing these OAuth clients to perform
unquoting on the path segment, but a better solution would seem to make
urlresolvers.py:RegexURLResolver respect the reserved characters for path
segments and not escape what does not need to be escaped.
I'll follow up with a pull request, unless there are string feelings, or
unwanted consequences of that approach.
Cheers,
Erik
> The relevant django-developers discussion is here -
>
> https://groups.google.com/forum/#!searchin/django-developers/13260/django-developers/Gofq5y40mYA/v_4yjrBItWkJ
>
> The final post addresses this issue, but doesn't seem to have been
> taken into account when the patch was accepted.
>
> On 2 March 2014 12:28, Erik van Zijst >
> wrote:
> > On Sat, Mar 1, 2014 at 2:41 PM, Sam Lai >
> wrote:
> >> The relevant commit and issue -
> >>
> >>
> https://github.com/django/django/commit/31b5275235bac150a54059db0288a19b9e0516c7
>
> >> https://code.djangoproject.com/ticket/13260
> >
> > Yes I saw that, but I'm confused. I thought these characters are
> > allowed unescaped in path segments.
> >
> >
> >> On 1 March 2014 17:26, Erik van Zijst >
> wrote:
> >>> Django's django.core.urlresolvers.reverse() seems to have changed its
> >>> behavior in 1.6. It now runs the arguments through quote(), without
> >>> specifying the safe characters for path components. As a result:
> >>>
> >>> on 1.4.10:
> >>> In [2]: reverse('test', args=['foo:bar'])
> >>> Out[2]: '/foo:bar'
> >>>
> >>> but on 1.6.2:
> >>> In [2]: reverse('test', args=['foo:bar'])
> >>> Out[2]: '/foo%3Abar'
> >>>
> >>> It would seem to me that this is a regression, as ":@-._~!$&'()*+,;="
> are
> >>> all allowed unescaped in path segments AFAIK.
> >>>
> >>> Cheers,
> >>> Erik
> >>>
> >>> --
> >>> 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-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.
> >>> To view this discussion on the web visit
> >>>
> https://groups.google.com/d/msgid/django-developers/064ba557-a722-484f-93bf-423048b51b14%40googlegroups.com.
>
>
> >>> For more options, visit https://groups.google.com/groups/opt_out.
> >>
> >> --
> >> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers" group.
> >> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/ZLGk7T4mJuw/unsubscribe.
>
> >> To unsubscribe from this group and all its topics, 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.
> >> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CABxbXqXKhcKFPS8ufmYDGmgHU_QjBuFUb%3DaFXk3FROJyzAJw5A%40mail.gmail.com.
>
>
> >> For more options, visit https://groups.google.com/groups/opt_out.
> >
> > --
> > 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-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.
>
Re: Testing parameters in database settings
Mentioned on the PR already, but writing some thoughts here too. I like the change. Moving test settings into their own sub-dict makes a lot of sense. Missing are settings for creating the datafile and datafile size for Oracle though. I'm unsure if a separate patch should be submitted for those new settings or not. I'd really like if those new settings could be added for 1.7, to enable oracle test databases to be created by the test runner. Currently, Oracle GIS can't be tested without first creating the test database (due to the datafile size). Similarly, the test runner can not create the database for Oracle RAC because of the datafile name. Regards, Josh On Thursday, 6 March 2014 06:41:57 UTC+11, Shai Berger wrote: > > Hi, > > I've put up https://github.com/django/django/pull/2400 for review. It > makes > the changes discussed -- test settings go into a 'TEST' dictionary in the > database settings, with a deprecation warning for old settings. > > While at it, I added (in a separate commit) a renaming of two > Oracle-specific > settings -- because I don't like current names, and this is a good > opportunity > to change them. At some future point, I want to make "CREATE_DB" available > to > all backends, so this renaming is not just an Oracle issue. > > There is documentation, but no tests -- database settings are impossible > to > test automatically. > > I want this to go in before the beta; it's a rather small PR. If there are > no > comments, I'll probably commit it tomorrow or the day after. > > Have fun, > Shai. > -- 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/a408612c-3bd3-4302-8ceb-a5e5a96c5570%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Testing parameters in database settings
Hi Josh, Thanks for your comments. The missing parameters are kinda a separate issue, with mush narrower audience. Yes, I'd like to have them in 1.7 too, and I doubt I'll have time to fix it myself -- so, PRs welcome. Cheers, Shai. On Wednesday 05 March 2014 14:07:02 Josh Smeaton wrote: > Mentioned on the PR already, but writing some thoughts here too. > > I like the change. Moving test settings into their own sub-dict makes a lot > of sense. Missing are settings for creating the datafile and datafile size > for Oracle though. I'm unsure if a separate patch should be submitted for > those new settings or not. I'd really like if those new settings could be > added for 1.7, to enable oracle test databases to be created by the test > runner. > > Currently, Oracle GIS can't be tested without first creating the test > database (due to the datafile size). Similarly, the test runner can not > create the database for Oracle RAC because of the datafile name. > > Regards, > > Josh > > On Thursday, 6 March 2014 06:41:57 UTC+11, Shai Berger wrote: > > Hi, > > > > I've put up https://github.com/django/django/pull/2400 for review. It > > makes > > the changes discussed -- test settings go into a 'TEST' dictionary in the > > database settings, with a deprecation warning for old settings. > > > > While at it, I added (in a separate commit) a renaming of two > > Oracle-specific > > settings -- because I don't like current names, and this is a good > > opportunity > > to change them. At some future point, I want to make "CREATE_DB" available > > to > > all backends, so this renaming is not just an Oracle issue. > > > > There is documentation, but no tests -- database settings are impossible > > to > > test automatically. > > > > I want this to go in before the beta; it's a rather small PR. If there are > > no > > comments, I'll probably commit it tomorrow or the day after. > > > > Have fun, > > > > Shai. -- 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/21148374.ArGxevycoQ%40deblack. For more options, visit https://groups.google.com/groups/opt_out.
Re: 1.6 reverse() escapes unreserved chars in path components
On Wednesday, 5 March 2014 14:04:51 UTC-8, Erik van Zijst wrote:
>
> I'll follow up with a pull request, unless there are string feelings, or
> unwanted consequences of that approach.
>
https://github.com/django/django/pull/2401
Cheers,
Erik
>> The relevant django-developers discussion is here -
>>
>> https://groups.google.com/forum/#!searchin/django-developers/13260/django-developers/Gofq5y40mYA/v_4yjrBItWkJ
>>
>> The final post addresses this issue, but doesn't seem to have been
>> taken into account when the patch was accepted.
>>
>> On 2 March 2014 12:28, Erik van Zijst wrote:
>> > On Sat, Mar 1, 2014 at 2:41 PM, Sam Lai wrote:
>> >> The relevant commit and issue -
>> >>
>> >>
>> https://github.com/django/django/commit/31b5275235bac150a54059db0288a19b9e0516c7
>>
>> >> https://code.djangoproject.com/ticket/13260
>> >
>> > Yes I saw that, but I'm confused. I thought these characters are
>> > allowed unescaped in path segments.
>> >
>> >
>> >> On 1 March 2014 17:26, Erik van Zijst wrote:
>> >>> Django's django.core.urlresolvers.reverse() seems to have changed its
>> >>> behavior in 1.6. It now runs the arguments through quote(), without
>> >>> specifying the safe characters for path components. As a result:
>> >>>
>> >>> on 1.4.10:
>> >>> In [2]: reverse('test', args=['foo:bar'])
>> >>> Out[2]: '/foo:bar'
>> >>>
>> >>> but on 1.6.2:
>> >>> In [2]: reverse('test', args=['foo:bar'])
>> >>> Out[2]: '/foo%3Abar'
>> >>>
>> >>> It would seem to me that this is a regression, as ":@-._~!$&'()*+,;="
>> are
>> >>> all allowed unescaped in path segments AFAIK.
>> >>>
>> >>> Cheers,
>> >>> Erik
>> >>>
>> >>> --
>> >>> 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-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.
>>
>> >>> To view this discussion on the web visit
>> >>>
>> https://groups.google.com/d/msgid/django-developers/064ba557-a722-484f-93bf-423048b51b14%40googlegroups.com.
>>
>>
>> >>> For more options, visit https://groups.google.com/groups/opt_out.
>> >>
>> >> --
>> >> You received this message because you are subscribed to a topic in the
>> Google Groups "Django developers" group.
>> >> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/django-developers/ZLGk7T4mJuw/unsubscribe.
>>
>> >> To unsubscribe from this group and all its topics, 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.
>> >> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/CABxbXqXKhcKFPS8ufmYDGmgHU_QjBuFUb%3DaFXk3FROJyzAJw5A%40mail.gmail.com.
>>
>>
>> >> For more options, visit https://groups.google.com/groups/opt_out.
>> >
>> > --
>> > 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-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.
>> > To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/CA%2B69USsj%2BuWHJJfw7-Fr8SFq34Xq0TLThR3Bq2t3r66K9oAFrw%40mail.gmail.com.
>>
>>
>> > For more options, visit https://groups.google.com/groups/opt_out.
>>
>
--
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/5b5f3ece-d746-4699-8c02-b5a209ccfbaa%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Callable LazyObject?
I recently had a need for a LazyObject which was callable. The __call__ meta method isn't forwarded to _wrapped, so it's an error to call, even if the underlying _wrapped does support it. In my case, was trying to do the following: User = SimpleLazyObject(lambda: get_user_model()) User()... I patched LazyObject to make it happy: def _a_call_(self, *args, **kwargs): if self._wrapped is empty: self._setup() return self._wrapped(*args, **kwargs) LazyObject.__call__ = _a_call_.__get__(User) Unfortunately, I then ran into a related problem -- by making LazyObject callable, anyone passing a lazy user, e.g. request.user, to the ORM would fall into the callable(value) branch: https://github.com/django/django/blob/b77f26313cddbfde20dcf2661e9bd35458c2d1bd/django/db/models/sql/query.py#L1043 That then caused a new User to be constructed rather than using the request.user.pk. I see that callable criteria are deprecated there, but was wondering how people would feel about adding a branch before that: if ... elif isinstance(value, LazyObject): pass elif callable(value): ... That would allow request.user to still be used (as it no doubt widely is) even after LazyObject grows a callable (if its underlying object has one). -- 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/CAM0i3f7hshHzW9XsuRkJaT%2BaVEMetTKkzD7nUiDqMF9%2BzAR4rw%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [GSOC] Introduction and task proposal
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 know when the errors that are being returned are unhelpful. A "green" Django user *could* do this, but they're going to spend a lot more time trying to find problems that need to be fixed. Approaching the project from the Werkzeug angle is an interesting idea, but you're not starting with a pre-blessed project -- your first step is to convince the core team that the idea is worth pursuing. Given the compressed timeframe for submitting applications, it might not be possib
Re: Proposal: update_fields shortcut
On Wed, Mar 5, 2014 at 10:05 PM, Paulo Poiati wrote:
> Hello everyone,
>
> While developing standard web applications one thing I frequently do is
> updating just one field of a model instance and save it after that. The
> best way to do that today (if you want to avoid the update in all the
> fields) is with the code bellow.
>
> product.name = 'Name changed again'
> product.save(update_fields=['name'])
>
>
> I want to propose a shortcut for this kind of operation. I came up with
> two solutions.
>
> *Solution One*
>
> product.save(update_fields={'name': 'Name changed again'})
>
>
> *Solution Two (My preferred)*
>
> product.update_fields(name='Name changed again')
>
>
> What do you guys think about this?
>
Sorry - can't say I'm a fan of either.
If I had to pick one, I'd pick solution 1; solution 2 strikes me as
introducing a second way to save models, which the Zen of Python counsels
against. However, this at the "would you rather be shot in the knee or shot
in the ankle" level of support. The only problem I see with your original
"problem" syntax is that there is the potential to set an attribute and
then forget it in the update_fields list; however, the price you pay for
this is converting save() from a simple "commit" operation into a "modify
and commit" operation.
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/CAJxq84_%2B6e7BkjM1z2FhaEQOUOJAo_47j64H1oP2yc4SfcYauQ%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Proposal: update_fields shortcut
Thanks for your feedback Russel. I understand and agree with your points, every solution has a drawback. I just think that the Zen of Python “There should be one-- and preferably only one --obvious way to do it.” shouldn’t be taken so seriously. What I mean is, isn’t QuerySet#get just a shortcut for a use case of QuerySet#filter? Isn’t QuerySet#first() just sugar to QuerySet[0]? What about the django.shortcuts module? Don’t get me wrong, I enjoy the python philosophy, but I think it’s more a guideline than a law. []’s Paulo Poiati blog.paulopoiati.com -- 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/858a6597-2a8d-4ac3-816b-aa3065a6fd4d%40Paulos-MacBook-Air.local. For more options, visit https://groups.google.com/groups/opt_out.
[GSoC] Dynamic, rule-based ModelForms
Hi Django devs, I want to share an idea with you and get some feedback in order to know if it makes sense, if it could solve a common problem and maybe evolve into an official GSoC proposal. Some years ago I was working on a printing on demand website using Django 1.2 and some model forms. Our front-end guy designed a HTML form that had: - A *paper type* tag with options: A4, A5 - A *color* tag with options: B&W, COLORS The form must follow some business rules: - B&W available only for A4 - COLORS available only for A5 (actually the original problem was a bit more complicated, but I'll keep it short...) The solution I adopted was made of the following components. - A classic Django *model* and a *ModelForm* to manage and render the *paper type* and *color* form fields. Plus a Django *model* to implement the 2 rules. - A minimal *Javascript* code to detect an interaction of the user with the *paper type* or *color* field: when the user changed the selected value of *paper type* to f.i. A4, the entire form was sent back to Django using a AJAX request. - After receiving the edited form, Django checked the rules, disabled the unavailable options, COLORS in our case (by setting COLORS), rendered the form to HTML and sent it back to the AJAX request. This behavior was implemented with a custom *form widget*. With this solution users had a clear visual feedback on what the rules were. Do you think this was a good design? Is there a better solution nowadays? Do you believe this could be a solution to a common problem? Could this idea evolve to a GSoC proposal (from myself of course)? Or maybe this idea is more likely a third-party library so it does not fit GSoC? And about GSoC: this idea could maybe go together with the suggested "Finishing off Form Templates", which actually challenges me, but scares me at the same time since I'm not super experienced, plus the idea is marked as hard and someone already failed last year... PS: That printing on demand website website is still up and running, so if I couldn't manage to be clear enough, I can link it here (I haven't done it because I don't want to spam) Cheers, Paolo -- 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/93f058ca-ba15-46ab-b49c-35b62c61f712%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
