Re: Combine localflavor apps again

[Horst Gutmann]

On Sun, May 26, 2013 at 8:07 PM, Jannis Leidel  wrote:

>
> On 24.05.2013, at 19:28, Trey Hunner  wrote:
>
> > On Tuesday, May 21, 2013 5:51:11 AM UTC-7, Jannis Leidel wrote:
> > So what I propose to fix this is simple:
> >
> > - combine the localflavor packages into one Python package again, call
> it django-localflavor
> > - give all the individual country maintainers also access to that package
> > - have a central documentation, e.g. django-localflavor.readthedocs.org
> > - update the Django docs to point to that package
> > - ask the maintainers of the 7 already released packages to point to the
> newly created django-localflavor
> >
> > I am also for this.
>
> Great to hear, as you're one of the people that successfully released one
> of the standalone apps to PyPI.
>
> > However, if the django-localflavor merge doesn't occur, at a minimum the
> django-localflavor-* ecosystem needs:
> >
> > - A procedure for requesting access to maintain a django-localflavor-*
> variant
> > - A project for maintaining suggestions and guidelines for
> django-localflavor maintainers (e.g. use PyPI, add South rules, use tox)
> > - Relevant links to procedures and guidelines in every
> django-localflavor-* README file
> >
> > I volunteer help merge changes for the django-localflavor-us variant if
> help is needed.
>

Same, of course, from me for localflavor-at. If there is anything I can do
to help, please let me know :-)

Cheers,
Horst


>
> Thanks, much appreciated, I've started the work on merging the apps again,
> and hope to have a ready version the coming week.
>
> Jannis
>
> --
> 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?hl=en
> .
> 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Handling tests in django-localflavor-*

[Horst Gutmann]

Hi :-)

I'm currently looking through the test-integration of the localflavor
packages and due to the structure used here it looks like (as Erik found
out before me) it kind of lends itself to something like nose as testrunner.

For this we both integrated test_settings module into the respective
packages.

Given that the execution of the tests itself isn't really covered by
this alone I was also thinking about adding a tox.ini file to the
package testing it with whatever versions of Python and Django are still
officially supported.

Given that Django itself externalizes multi-variant testing to Jenkins
I'd like to know if adding the tox.ini would be acceptable to you :-)

Cheers,
Horst

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: I'm interested in maintaining localflavor-at

[Horst Gutmann]

Thank you :-)

> Aymeric Augustin <mailto:aymeric.augus...@polytechnique.org>
> May 21, 2013 5:10 PM
> 2013/5/21 Horst Gutmann <ho...@zerokspot.com <mailto:ho...@zerokspot.com>>
>  
>
> If nobody else volunteers, I'd like to help by maintaining the
> localflavor-at package.
>
>
> You now have commit access. Welcome on board! 
>
> -- 
> Aymeric.
> -- 
> 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?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>  
>  
> Horst Gutmann <mailto:ho...@zerokspot.com>
> May 21, 2013 4:26 PM
> Hi :-)
>
> If nobody else volunteers, I'd like to help by maintaining the
> localflavor-at package.
>
> First working order should be to get it it somehow onto PyPI (depending
> on the outcome of Jannis' proposal).
>
> Username on IRC and Github: zerok
>
> Best wishes,
> Horst

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

I'm interested in maintaining localflavor-at

[Horst Gutmann]

Hi :-)

If nobody else volunteers, I'd like to help by maintaining the
localflavor-at package.

First working order should be to get it it somehow onto PyPI (depending
on the outcome of Jannis' proposal).

Username on IRC and Github: zerok

Best wishes,
Horst

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: facebook/twitter sharing, and testing

[Horst Gutmann]

Hi :-)

Please ask such questions on the django-users mailinglist.
https://groups.google.com/forum/?fromgroups#!forum/django-users

This here is for discussions about the development of django itself :-)

Cheers,
Horst


On Wed, Apr 10, 2013 at 4:35 PM, sara ismail wrote:

> im new to django, and i am working on a project, a selling and buying
> website, where a user can post about a product that he/she wants to sell,
> and my part right now is sharing posts from the site with facebook, and
> twitter. i was wondering how to test such a thing, like unit testing,
> knowing that i implemented front end only, just an HTML file.
> and i have another question, how can i take a post url, and make it the
> link to be shared with facebook/twitter, for example, a facebook/twitter
> share button is located under or next to each post, and each button when
> pressed on, redirects to fb sharing, and has that specific post's link
> appearing. how to do that?
>
> check the attached image, instead of facebook dialogs and the flowers img,
> i wasnt the post link, and probably an img too.
>
> thanks in advance!
>
> --
> 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?hl=en
> .
> 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Django 1.5 with Python 3.2

[Horst Gutmann]

This is documented here:
https://docs.djangoproject.com/en/dev/topics/python3/#str-and-unicode-methods:-)

Cheers,
Horst


On Mon, Apr 8, 2013 at 4:42 PM, L Radhakrishna Rao
wrote:

> I was following tutorials of django book, where python 2.7 version is used.
>
> I am using python 3.2 version and django 1.5.
>
> The django book chapter 5 'Adding Model String Represenations' needs to be
> changed while publishing book for python 3.x version.
>
> The 'def__unicode__(self)' does not work if Python3.x version is used.
>
> When I implemented the same code with  'def __str__(self):', the model
> string got retrieved.
>
> If the change is done, please discard my thread.
>
> Thanks
>
> --
> 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?hl=en
> .
> 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Re-design "proposal" for djangoproject.com

[Horst Gutmann]

On Sat, May 19, 2012 at 6:06 PM, Giovanni Collazo  wrote:
> Hi,
>
> So, I spend a few hours working on the re-design following Idan's
> Guidelines. Any feedback and further direction from the core team would be
> greatly appreciated.
>
> G.
>

Hi :-)

Looks nice! A few points though:

* Do we really need the pony?

* IMO the "Meet Django" section might be better one step up since the
line "Django makes it easier..." might not be enough to quickly
explain what Django actually is.

* "Meet Django" and "The Django Framework" sections have more or less
the same objective and should IMO be combined to make it possible to
put the community section slightly higher in the structure.

* Regarding prominent actions: Perhaps you could place some action
buttons where the pony is right now. Like something for developers,
something for novices and something for project managers.

* For the quickstart I'm personally not really a fan of lightboxes.
They should provide supplementary information, not primary info.

Best regards,
Horst

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Localization on User model

[Horst Gutmann]

On Thu, Sep 22, 2011 at 1:52 PM, Aymeric Augustin
 wrote:
> 2011/9/22 lvella :
>> What about changing this in future versions? Maybe simply a
>> "true_name" field would do? Or maybe a way to customize the fields in
>> the User model.
>
> Hi lvella,
>
> This issue should be viewed in the context of:
> https://code.djangoproject.com/wiki/SummerOfCode2011#Enhancedauth.user
> Unfortunately, this GSoC didn't happen this summer.
>
> The canonical ticket for this issue is
> https://code.djangoproject.com/ticket/3011 — there's a lot of
> background over there.
>
> Best regards,
>
> --
> Aymeric Augustin.
>

Another great resource on that topic is the article "Personal names
around the world" [1] on the w3c's website.

[1]: http://www.w3.org/International/questions/qa-personal-names

Best regards,
Horst

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: settings.py should have way to hide key/values even when debug set True

[Horst Gutmann]

On Mon, Jan 31, 2011 at 5:02 PM, Matteius  wrote:
> I think it would be really useful to have a way (possibly a decorator
> such as @hide_setting) such as to protect deployed sites when they
> switch over to debug mode.  To me this would be a most useful setting
> to have, especially when protecting secret key settings.  Please be
> advised.
>

If I remember correctly, settings starting with SECRET_ are not shown
on the debug page.

-- Horst

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Proposal for inclusion of two additional default template tags.

[Horst Gutmann]

On Fri, Jan 7, 2011 at 5:41 PM, Jonathan S  wrote:
>> Regarding the macro-tag I think the idea is valid but I'd personally
>> prefer a more flexible approach regarding variables being  provided
>> for the macro block. Something like Jinja's macro comes to mind where
>> I can define parameters for each macro and then pass them in as needed
>
> Jinja's approach does not work with the Django templates.
> - The whitespace in the template tags does not work well.
> - Calling the macro method as a Variable instead of using a template
> tag can probably not be done without rewriting compile_filter
> (variable resolving from context) from scratch. I'm not sure about
> this.

Absolutely. I never implied that the implementation should mirror
Jinja's syntax but merely be *perhaps* a bit more flexible especially
since otherwise it would syntactically not offer much advantage
compare to the example you gave with the with-include/with-callmacro
combination :-) That being said, I'm +1 on this. Explicit passing of
variables might be a nice feature but also without it IMO the
macro/callmacro tags would be a nice addition.

>
> I think passing variables to includes has been discussed before, and
> if we implement the {% macro %} tag, it should be done in a consistent
> way.
>
> Currently, you would do:
>
> {% with "var" as variable %}
>  {% callmacro "macro_name" %}
> {% endwith %}
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Proposal for inclusion of two additional default template tags.

[Horst Gutmann]

On Fri, Jan 7, 2011 at 5:18 PM, Dougal Matthews  wrote:
> On Friday, 7 January 2011 at 16:11, Jonathan S wrote:
>
> ** And a {% decorate %} template tag:
> http://paste.pocoo.org/show/316593/
>
> I think they are generic enough to be included.
> {% decorate %} implements a commonly used design pattern. (Also known
> by XAML programmers.) It avoids the need of having to split a template
> into a head.html and footer.html, which is a bad practice, because it
> separates matching opening and closing tags over two files.
>
> Can you explain what advantage the decorate tag has over regular old
> template inheritance?
> I don't think I've ever felt the need to use head.html and footer.html
> Dougal
>

Regarding the macro-tag I think the idea is valid but I'd personally
prefer a more flexible approach regarding variables being  provided
for the macro block. Something like Jinja's macro comes to mind where
I can define parameters for each macro and then pass them in as needed
[1]. This would also provide a use-case that template includes don't
really try to solve.

[1] http://jinja.pocoo.org/templates/#macros

- Horst

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: parse xml

[Horst Gutmann]

I so hope this response was the result of some translation gone wrong.
If not, you shouldn't really expect anyone to answer your (highly off-
topic) question with that attitude...

On Oct 15, 7:56 pm, kostia  wrote:
> Give me the answer and do what you want.
>
> On Oct 15, 8:45 pm, Alex Gaynor  wrote:
>
>
>
>
>
>
>
> > On Fri, Oct 15, 2010 at 1:38 PM, kostia  wrote:
> > > I have xml file:
> > > 
> > > 
> > >        5
> > > 
>
> > > I want to get the value of n (= 5) inside my python program, I'm
> > > doing this:
>
> > > import xml.dom.minidom
> > > from xml.dom.minidom import Node
> > > doc = xml.dom.minidom.parseString("boolean_width.xml")
> > > n = doc.getElementsByTagName("root")[0].firstChild.nodeValue.strip()
> > > print n
>
> > > and it is failed. How to get the value? Please, help.
>
> > > --
> > > You received this message because you are subscribed to the Google Groups 
> > > "Django developers" group.
> > > To post to this group, send email to django-develop...@googlegroups.com.
> > > To unsubscribe from this group, send email to 
> > > django-developers+unsubscr...@googlegroups.com.
> > > For more options, visit this group 
> > > athttp://groups.google.com/group/django-developers?hl=en.
>
> > Hi,
>
> > The django-developers mailing list is for discussion about the
> > development of Django itself, not discussion about development with
> > Django.  For that you'd want django-users (or in this case probably
> > python-list, aka comp.lang.python).
>
> > Alex
>
> > --
> > "I disapprove of what you say, but I will defend to the death your
> > right to say it." -- Voltaire
> > "The people's good is the highest law." -- Cicero
> > "Code can always be simpler than you think, but never as simple as you
> > want" -- Me

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Regression problem on admin date format

[Horst Gutmann]

On Tue, Jul 13, 2010 at 9:48 AM, Jannis Leidel <jan...@leidel.info> wrote:
>
> Am 13.07.2010 um 01:35 schrieb Russell Keith-Magee:
>
>>> On Sun, Jul 11, 2010 at 10:36 AM, Antoni Aloy <antoni.a...@gmail.com> wrote:
>>>> Hi,
>>>>
>>>> I have confirmed the bug with other non speaking people and I have
>>>> sent an e-mail to django-i18n group to point out the problem.
>>>>
>>>> I have also contacted Marc and he has confirmed that the problem exists.
>>>>
>>>> Sorry for the insistence but in my opinion this is a blocker bug.
>>
>> On Tue, Jul 13, 2010 at 4:01 AM, Horst Gutmann <ze...@zerokspot.com> wrote:
>>> Did the patch that is attached to this issue work for you? It would
>>> really be nice to get some feedback on it :-) From what I've heard in
>>> other posts on this and the django-users list so far it seems to do
>>> the job.
>>
>> Ok - I'll put this on my list of things to look at. I've been fairly
>> busy at work over the last couple of weeks, and what time I've had
>> left has been consumed keeping feature discussions going. Once things
>> settle down, I'll have more time to put into bugs.
>
> FYI, I planned to have a look at it this week, too.
>
> Jannis
>

With the help of Jannis I fixed and simplified the patch at EuroPython
and afterwards. The latest version (available in the ticket and on
https://gist.github.com/ef8bce46d233c81df9d5 ) includes a change to
the admin formfield generator. In my opinion, if USE_L10N=True,
formfields should receive the localize=True flag by default for the
admin. Would this be an acceptable change?

Thank you :-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Regression problem on admin date format

[Horst Gutmann]

Did the patch that is attached to this issue work for you? It would
really be nice to get some feedback on it :-) From what I've heard in
other posts on this and the django-users list so far it seems to do
the job.

-- Horst

P.S.: Sorry if this mail reaches you a second time. Somehow Google
Groups and GMail acting up again for me :-(

On Sun, Jul 11, 2010 at 10:36 AM, Antoni Aloy  wrote:
> Hi,
>
> I have confirmed the bug with other non speaking people and I have
> sent an e-mail to django-i18n group to point out the problem.
>
> I have also contacted Marc and he has confirmed that the problem exists.
>
> Sorry for the insistence but in my opinion this is a blocker bug.
>
> Best regards,
>
> --
> Antoni Aloy López
> Blog: http://trespams.com
> Site: http://apsl.net
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Class based generic views in 1.3?

[Horst Gutmann]

On Sat, May 29, 2010 at 11:06 PM, Ben Firshman  wrote:
> Luke, you're absolutely right that changing the definition of a view is a bad 
> idea, it just seemed the best solution then.
>
> But don't worry, we've changed our minds again! If __call__() creates a copy 
> of self and calls methods on the copy, as far as I can see it solves all our 
> problems. No boilerplate, and it's really hard to make it unsafe thread-wise.
>
> An example of how it could work:
>
> http://github.com/bfirsh/django-class-based-views/blob/master/class_based_views/base.py
>
> Thanks
>
> Ben

Hi :-)

I'm not really sure about that approach. As with __new__, __call__
comes (at least for me) with a bunch of expectations. For me it
executes and operates on one single instance of an object. Sure, this
could be interpreted as using the instance as a factory for usually
you'd use class methods for something like that, but still.

On the other hand I can definitely see the merit in it since you could
then easily programmatically modify the "view" factory by just
modifying "yet another object".

-- Horst

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Date format localization problem (Django displays dates in format it doesn't accept)

[Horst Gutmann]

Did you already try the patch I attached at
http://code.djangoproject.com/ticket/13621 ? Perhaps this solves your
problem too :-)

On Fri, May 28, 2010 at 4:50 PM, Ludwik Trammer  wrote:
> Hi,
>
> There is quite a serious problem with Django 1.2's format localization
> and forms. At first I noticed Djnago ignores L10N date formats when
> displaying dates in form fields, but calendar widgets in admin don't.
> So when you try using the calendar, date format goes back and forth
> between localized and unlocalized versions. I opened a ticket couple
> of days ago (#13591) calling it an "usability" problem (because it is
> utterly confusing to have a date format changing, when the only thing
> you expected to be changed was a date).
>
> It turned out however, that the issue is much more serious (and not
> contained to Django Admin only). Look at the StackOverflow question:
>
> http://stackoverflow.com/questions/2929388/django-1-2-dates-in-admin-forms-dont-work-with-locales-i10ntrue
>
> It turnes out date formats for some countries, shipped with Django,
> doesn't include the "universal" -MM-DD formats as accepted date
> format (DATE_INPUT_FORMATS). Which at first seems logical, but in
> conjunction with the fact that Django always uses the -MM-DD
> format to display dates in forms, ignoring localization settings, the
> result is people are getting form validating errors, when trying to
> edit their models. In other words Django populates form fields with
> data in format it doesn't accept itself.
>
> Ludwik Trammer
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Proposal for 1.2: built-in logging with django.core.log

[Horst Gutmann]

Definitely a +1 from me.

-- Horst

On Thu, Sep 17, 2009 at 10:25 AM, Simon Willison
 wrote:
>
> I think we should add logging to Django in version 1.2, implemented as
> a light-weight wrapper around the Python logging module
> (django.core.log maybe?) plus code to write errors to the Apache error
> log under the mod_python handler and environ['wsgi.errors'] under WSGI
> (meaning mod_wsgi will write to the Apache error log as well).
>
> Benefits of logging as a core Django service
> 
>
> Adding logging to Django core would provide the following benefits:
>
> 1. We'll be able to de-emphasise the current default "e-mail all
> errors to someone" behaviour, which doesn't scale at all well.
>
> 2. Having logging in the core framework will mean people start
> actually using it, which will make it easier for people to debug their
> Django apps. Right now adding "print" statements to a Django app is a
> common debugging technique, but it's messy (you have to remember to
> take them out again) and error prone - some production environments
> throw errors if an app attempts to write to stdout. It's also not
> obvious - many developers are surprised when I show them the
> technique.
>
> 3. Logging in Django core rather than a 3rd party app will encourage
> reusable applications to log things in a predictable way, standard
> way.
>
> 4. 3rd party debugging tools such as the debug toolbar will be able to
> hook in to Django's default logging behaviour. This could also lead to
> plenty of additional 3rd party innovation - imagine a tool that looks
> out for logged SQL that took longer than X seconds, or one that groups
> together similar log messages, or streams log messages to IRC...
>
> 5. Built-in support for logging reflects a growing reality of modern
> Web development: more and more sites have interfaces with external web
> service APIs, meaning there are plenty of things that could go wrong
> that are outside the control of the developer. Failing gracefully and
> logging what happened is the best way to deal with 3rd party problems
> - much better than throwing a 500 and leaving no record of what went
> wrong.
>
> 6. Most importantly from my point of view, when a sysadmin asks where
> Django logs errors in production we'll have a good answer for them!
>
> 7. As a general rule, I believe you can never have too much
> information about what's going on with your web application. I've
> never thought to myself "the problem with this bug is I've got too
> much information about it". As for large log files, disk space is
> cheap - and pluggable backends could ensure logs were sensibly
> rotated.
>
> Places logging would be useful
> ==
>
> - Unhandled exceptions that make it up to the top of the Django stack
> (and would cause a 500 error to be returned in production)
> - The development web server could use logging for showing processed
> requests (where currently these are just printed to stdout).
> - Failed attempts at signing in to the admin could be logged, making
> security audits easier.
> - We could replace (or complement) django.connection.queries with a
> log of executed SQL. This would make the answer to the common question
> "how do I see what SQL is being executed" much more obvious.
> - Stuff that loads things from INSTALLED_APPS could log what is being
> loaded, making it much easier to spot and debug errors caused by code
> being incorrectly loaded.
> - Likewise, the template engine could log which templates are being
> loaded from where, making it easier to debug problems stemming from an
> incorrectly configured TEMPLATE_DIRS setting.
> - We could use logging to address the problems with the template
> engine failing silently - maybe some template errors (the ones more
> likely to be accidental than just people relying on the fail-silent
> behaviour deliberately) should be logged as warnings.
>
> Most of the above would be set to a low log level which by default
> would not be handled, displayed or stored anywhere (logging.info or
> similar). Maybe "./manage.py runserver --loglevel=info" could cause
> such logs to be printed to  the terminal while the development server
> is running.
>
> Problems and challenges
> ===
>
> 1. The Python logging module isn't very nicely designed - its Java
> heritage shines through, and things like logging.basicConfig behave in
> unintuitive ways (if you call basicConfig twice the second call fails
> silently but has no effect). This is why I suggest wrapping it in our
> own higher level interface.
>
> 2. There may be some performance overhead, especially if we replace
> mechanisms like django.connection.queries with logging. This should be
> negligble: here's a simple benchmark:
>
> # ("hello " * 100) gives a 600 char string, long enough for a SQL
> statement
 import timeit, logging
 t = timeit.Timer('logging.info("hello " * 100)', 'import 

Re: EuroPython Sprints

[Horst Gutmann]

Same here. If I can make it to EuroPython I'll try really hard to be
there for the sprints.

-- Horst

On Wed, May 20, 2009 at 11:59 AM, Robert Lofthouse
 wrote:
>
> I'm scheduled to give a talk there and if I can definitely make it
> then I'll be going to the sprints as well.
>
> Rob
>
> On May 19, 8:40 am, Sergio Oliveira  wrote:
>> Is there someone going to EuroPython (Birmingham - UK)?
>> I've just saw that Django is in the top of the proposed sprints 
>> list:http://wiki.europython.eu/Sprints
>>
>> Cheers,
>>
>> --
>> Sergio Oliveira
>>
>> If builders built buildings the way programmers wrote programs, then the
>> first woodpecker that came along would destroy civilization.
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Dropping Python 2.3 compatibility for Django 1.1

[Horst Gutmann]

Big +1 from me.
Finally real decorators, generators and not to forget sets as built-in type :D

-- Horst

On Tue, Nov 25, 2008 at 7:04 PM, Brian Rosner <[EMAIL PROTECTED]> wrote:
>
> On Tue, Nov 25, 2008 at 10:08 AM, Jacob Kaplan-Moss
> <[EMAIL PROTECTED]> wrote:
>>
>> Hi folks --
>>
>> I'd like to officially drop Python 2.3 support in Django 1.1. Discuss.
>
> +1. This needs to happen. Python 2.3 is getting pretty old and I would
> imagine that most people have at least 2.4 available to them or they
> can hang out in 1.0 land until they are able to upgrade. Remember
> PyCon 2008? :)
>
> --
> Brian Rosner
> http://oebfare.com
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---