Re: [GSOC] Django-based project for the neuroinformatics community: neurostars.org

[Paolo Coffetti]

Hi Roman,

I'm a software engineer currently working on my master thesis. I've been 
working with Python and Django for some years, in particular in the Open 
Access field, and I'm interested in NeuroStars project. Give me a day to 
read more about it and formulate my idea, then I will contact you again!

Cheers,
Paolo

Il giorno giovedì 6 marzo 2014 13:53:12 UTC+1, Roman Valls Guimerà ha 
scritto:
>
> Hello Django-ers,
>
> I have been wondering if it would be appropiate to announce this here, but 
> since it's about Django and GSoC I thought about giving it a try, excuse me 
> if it's not.
>
> At http://incf.org, we launched a Stackoverflow-like website to engage 
> the neuroscientific community, you can have a look at some ideas we came up 
> with if someone is interested:
>
>
> http://www.incf.org/gsoc/2014/proposals/#neurostars--a-question-and-answer-site-for-the-neuroinformatics-community
>
> We are still open for student proposals, feel free to contact me if you 
> need more details!
>
> Best regards,
> Roman
>

-- 
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/489c13aa-c9ba-47a7-be48-12f642fb84df%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [GSOC] Django-based project for the neuroinformatics community: neurostars.org

[Russell Keith-Magee]

On Thu, Mar 6, 2014 at 8:53 PM, Roman Valls Guimerà  wrote:

> Hello Django-ers,
>
> I have been wondering if it would be appropiate to announce this here, but
> since it's about Django and GSoC I thought about giving it a try, excuse me
> if it's not.
>
> At http://incf.org, we launched a Stackoverflow-like website to engage
> the neuroscientific community, you can have a look at some ideas we came up
> with if someone is interested:
>
>
> http://www.incf.org/gsoc/2014/proposals/#neurostars--a-question-and-answer-site-for-the-neuroinformatics-community
>
> We are still open for student proposals, feel free to contact me if you
> need more details!
>
> Hi Roman,

The better list for this would be Django-users, not Django-dev. Django has
it's own GSoC program, with it's own projects; the sort of students you're
looking for are more likely to be on the Users list than the Developers
list.

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_CjDBWVo%3DNBvQN4Lwq11Q6T%3D_MFYh6%3D3Q%3DGu2_%2BqyHJA%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

DRY date_format and datetime objects

[Jon Dufresne]

Hi,

I am using Django 1.6. I find myself using date_format semi-regularly
to convert datetime objects to strings in the DATE_FORMAT format. I
feel like I am repeating myself quite a bit and need to remember to do
this, else I receive the format -MM-DD, which, in my opinion, is
less pleasant to read.

I am considering a pull request that extends Python's datetime class
that overrides the __str__, __unicode__ methods to always return the
date formatted with the configured DATE_FORMAT. Then all uses
throughout the Django code could use this extended datetime instead of
Python's datetime.

Any thoughts on this? If I do the work, is this something that has a
chance of being accepted?

Cheers,
Jon

-- 
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/CADhq2b6SE4a1JxfLpdNi415pkuBMYu7rfSP%2BfvWhBNkBDwpE1w%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Revisiting multiline tags

[Andre Terra]

+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
>>> 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, 

Re: Callable LazyObject?

[Jeremy Dunck]

(It's a change in the DB code, not the template, but your point stands.)

I think I agree with you that changing LazyObject is risky when there's a
workaround and it would be difficult to address the risk of
callable(LazyObject()) becoming true.

OK, thanks for feedback.


On Thu, Mar 6, 2014 at 8:12 AM, Luke Plant  wrote:

> On 05/03/14 23:05, Jeremy Dunck wrote:
>
> > if ...
> > elif isinstance(value, LazyObject):
> >   pass
> > elif callable(value):
> >   ...
>
> My gut instinct is that if Django's template code has to be patched and
> special cased to accommodate this change, there will be lots of other
> code that needs to be patched too.
>
> LazyObject is already pretty hairy without trying to get it to support
> more things.
>
> Also, it seems that normally there should be other solutions. In many
> cases, instead of:
>
>   User = SimpleLazyObject(lambda: get_user_model())
>
> you could use:
>
>   User = lambda **kwargs: get_user_model()(**kwargs)
>
> ...assuming that the only thing you need 'User' to do is to produce User
> instances when you call it. (If you need it to be an actual class for
> some reason, then this won't work - but in most cases I'd suggest that
> the consuming code shouldn't need an actual class).
>
> Regards,
>
> Luke
>
>
> --
> "God demonstrates his love towards us in this, that while we were
> still sinners, Christ died for us." (Romans 5:8)
>
> Luke Plant || http://lukeplant.me.uk/
>
> --
> 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/53189E5F.7010306%40cantab.net
> .
> 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/CAM0i3f4Li3Bqsz6sd1d3LURZzeOH_gQ05gK4XUdF_7GsdAL%2B8A%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Callable LazyObject?

[Luke Plant]

On 05/03/14 23:05, Jeremy Dunck wrote:

> if ...
> elif isinstance(value, LazyObject):
>   pass
> elif callable(value):
>   ...

My gut instinct is that if Django's template code has to be patched and
special cased to accommodate this change, there will be lots of other
code that needs to be patched too.

LazyObject is already pretty hairy without trying to get it to support
more things.

Also, it seems that normally there should be other solutions. In many
cases, instead of:

  User = SimpleLazyObject(lambda: get_user_model())

you could use:

  User = lambda **kwargs: get_user_model()(**kwargs)

...assuming that the only thing you need 'User' to do is to produce User
instances when you call it. (If you need it to be an actual class for
some reason, then this won't work - but in most cases I'd suggest that
the consuming code shouldn't need an actual class).

Regards,

Luke


-- 
"God demonstrates his love towards us in this, that while we were
still sinners, Christ died for us." (Romans 5:8)

Luke Plant || http://lukeplant.me.uk/

-- 
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/53189E5F.7010306%40cantab.net.
For more options, visit https://groups.google.com/groups/opt_out.

[GSOC] Django-based project for the neuroinformatics community: neurostars.org

[Roman Valls Guimerà]

Hello Django-ers,

I have been wondering if it would be appropiate to announce this here, but 
since it's about Django and GSoC I thought about giving it a try, excuse me 
if it's not.

At http://incf.org, we launched a Stackoverflow-like website to engage the 
neuroscientific community, you can have a look at some ideas we came up 
with if someone is interested:

http://www.incf.org/gsoc/2014/proposals/#neurostars--a-question-and-answer-site-for-the-neuroinformatics-community

We are still open for student proposals, feel free to contact me if you 
need more details!

Best regards,
Roman

-- 
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/2a9f40c9-f1c8-4646-8580-4a348685cbd5%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.