Re: Update on localflavor move

2012-10-16 Thread David Winterbottom 
Here's another pull request for setting up testing, this time using tox as
per Russell's suggestion.
https://github.com/django/django-localflavor-gb/pull/2

AFAIK, tox requires the tests to be part of the package.  Hence I moved
tests.py into the django_localflavor_gb package as well as a test settings
module.  Using Django's testrunner also requires that the package has a
models.py so it is considered an app.  Is is possible to use tox and the
django testrunner so that the test can be separate, and the package doesn't
require a models.py?  That would be cleaner in my eyes.

Feedback welcome of course.  Hopefully this is a step in the right
direction for agreeing on a testing set-up for all the localflavors.

On 16 October 2012 04:55, Mahdi Yusuf  wrote:

> Hi,
>
> I have setup testing in a pull request 
> here
> .
>
> If this solution is acceptable. I can duplicate the process on the other
> local flavours.
>
> I would appreciate feedback.
>
> --
> Mahdi Yusuf
>
> On Mon, Oct 15, 2012 at 4:16 PM, Aymeric Augustin <
> aymeric.augus...@polytechnique.org> wrote:
>
>> Hi Adrian,
>>
>> Thanks for taking the lead on this! I reviewed related tickets in Trac
>> and I have a few suggestions.
>>
>>
>> 1) Can we move the fields defined in
>> django.contrib.localflavor.generic.forms to django.forms?
>>
>> Currently the US-biased fields are in django.forms and the non-biased
>> ones in django.contrib.localflavor.generic.forms — an interesting
>> perspective :)
>>
>> The alternative is to deprecate them entirely.
>>
>>
>> 2) There's a dozen Trac tickets for adding new countries: Bulgaria,
>> Nicaragua, Hungary, Malaysia, Venezuela, South Korea, Bangladesh, New
>> Zealand, Guatemala, Latvia, Iran, Singapore.
>>
>> Would it make sense to create these local flavors now — maybe after
>> asking the community to update the patches if they aren't ready?
>>
>>
>> 3) I'd like to see some guidelines on what features a local flavor is
>> expected to provide.
>>
>> Two examples:
>> - Are model fields that just inherit TextField and set a particular
>> form_class useful? (#10087)
>> - Are pluralization template filters a good idea? (#17632)
>>
>> I believe it's a good thing for the Django community to maintaining some
>> consistency among local flavors. Since we plan to defer to local
>> maintainers in each country, we should document the expectations and best
>> practices.
>>
>>
>> --
>> Aymeric.
>>
>>
>>
>> --
>> 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.
>>
>>
>
>
> --
> Mahdi Yusuf
>
>  --
> 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.
>



-- 
*David Winterbottom*
Head of Programming

Tangent Labs
84-86 Great Portland Street
London W1W 7NR
England, UK

-- 
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: Update on localflavor move

2012-10-16 Thread Łukasz Rekucki 
On 16 October 2012 11:21, David Winterbottom
 wrote:
> Here's another pull request for setting up testing, this time using tox as
> per Russell's suggestion.
> https://github.com/django/django-localflavor-gb/pull/2
>
> AFAIK, tox requires the tests to be part of the package.  Hence I moved
> tests.py into the django_localflavor_gb package as well as a test settings
> module.  Using Django's testrunner also requires that the package has a
> models.py so it is considered an app.  Is is possible to use tox and the
> django testrunner so that the test can be separate, and the package doesn't
> require a models.py?  That would be cleaner in my eyes.
>
> Feedback welcome of course.  Hopefully this is a step in the right direction
> for agreeing on a testing set-up for all the localflavors.
>
> On 16 October 2012 04:55, Mahdi Yusuf  wrote:
>>
>> Hi,
>>
>> I have setup testing in a pull request here.
>>
>> If this solution is acceptable. I can duplicate the process on the other
>> local flavours.
>>
>> I would appreciate feedback.
>>
>> --
>> Mahdi Yusuf

If we include some form of a test runner in every localflvour, I
suspect they will get out of sync quite quickly. Also, I don't think
there is a good reason for duplicating code.

Maybe we need something like django-localflavour-commons, which would
include the test harness, packaging logic (then in setup.py you can
just import it from there), etc. My first idea was to make it a
submodule, but that would still require making a commit to all repos
whenever we update the commons (althought, still simpler then applying
the same patch everywhere). We could instead put it on PyPI and make
all other packages always require it's latetest version.

-- 
Łukasz Rekucki

-- 
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: Django performance vs others

2012-10-16 Thread Moonlight 
another one:

http://mindref.blogspot.com/2012/10/python-web-reverse-urls-benchmark.html


On Thursday, October 4, 2012 10:50:35 AM UTC+3, Moonlight wrote:
>
> I found the following benchmarks recently:
> 1. http://mindref.blogspot.com/2012/09/python-fastest-web-framework.html
> 2. http://mindref.blogspot.com/2012/07/python-fastest-template.html
>
> It is interesting to see the performance boost using pypy.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/Tjquh3rqr6EJ.
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: URL dispatcher slow?

2012-10-16 Thread Moonlight 
static[0]   

 138017 function calls in 0.818 seconds

   Ordered by: internal time
   List reduced from 79 to 10 due to restriction <10>

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
 10000.0620.0000.4900.000 base.py:72(get_response)
 20000.0470.0000.1290.000 base.py:240(get_script_name)
 10000.0420.0000.7580.001 wsgi.py:210(__call__)
 10000.0400.0000.2470.000 urlresolvers.py:293(resolve)
 10000.0390.0000.1360.000 wsgi.py:129(__init__)
 20000.0310.0000.0520.000 
trans_real.py:212(get_language)
 70000.0310.0000.0440.000 functional.py:182(inner)
 30000.0290.0000.0880.000 encoding.py:54(force_unicode)
140020.0290.0000.0290.000 {isinstance}
 10000.0270.0000.0810.000 __init__.py:564(__init__)


static[-1]  

 1929017 function calls in 10.654 seconds

   Ordered by: internal time
   List reduced from 80 to 10 due to restriction <10>

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
   2010002.9980.0004.9280.000 
trans_real.py:212(get_language)
   201.2880.0008.3780.000 urlresolvers.py:195(resolve)
 10001.1750.0019.9730.010 urlresolvers.py:293(resolve)
   4080001.0850.0001.0850.000 {getattr}
   2060000.8790.0001.2310.000 functional.py:182(inner)
   2010000.8780.0006.5770.000 urlresolvers.py:153(regex)
   2010000.7550.0005.6820.000 __init__.py:128(get_language)
   2010000.5470.0000.5470.000 {method 'search' of 
'_sre.SRE_Pattern' objects}
   1990000.2900.0000.2900.000 {method 'append' of 'list' 
objects}
 10000.0940.000   10.2720.010 base.py:72(get_response)


dynamic[0]

 3745017 function calls in 20.459 seconds

   Ordered by: internal time
   List reduced from 80 to 10 due to restriction <10>

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
   4020006.0060.0009.8660.000 
trans_real.py:212(get_language)
   4010002.5280.000   16.7000.000 urlresolvers.py:195(resolve)
 10002.3010.002   19.7330.020 urlresolvers.py:293(resolve)
   812.1620.0002.1620.000 {getattr}
   4020001.7350.000   13.1070.000 urlresolvers.py:153(regex)
   4070001.7310.0002.4240.000 functional.py:182(inner)
   4020001.4890.000   11.3550.000 __init__.py:128(get_language)
   4020001.0980.0001.0980.000 {method 'search' of 
'_sre.SRE_Pattern' objects}
   400.5710.0000.5710.000 {method 'append' of 'list' 
objects}
 10000.1370.000   20.0760.020 base.py:72(get_response)


dynamic[-1]

 3916017 function calls in 29.633 seconds

   Ordered by: internal time
   List reduced from 80 to 10 due to restriction <10>

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
   4210008.6500.000   14.2670.000 
trans_real.py:212(get_language)
   423.6930.000   24.2790.000 urlresolvers.py:195(resolve)
 10003.2990.003   28.6060.029 urlresolvers.py:293(resolve)
   8480003.1120.0003.1120.000 {getattr}
   4260002.5520.0003.5920.000 functional.py:182(inner)
   4210002.5270.000   18.9930.000 urlresolvers.py:153(regex)
   4210002.1760.000   16.4430.000 __init__.py:128(get_language)
   4210001.6390.0001.6390.000 {method 'search' of 
'_sre.SRE_Pattern' objects}
   4190000.8050.0000.8050.000 {method 'append' of 'list' 
objects}
 10000.2110.000   29.1030.029 base.py:72(get_response)


seo[0]

 1941017 function calls in 14.737 seconds

   Ordered by: internal time
   List reduced from 80 to 10 due to restriction <10>

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
   2020004.1620.0006.8550.000 
trans_real.py:212(get_language)
   2010001.7870.000   11.5990.000 urlresolvers.py:195(resolve)
 10001.5940.002   13.7970.014 urlresolvers.py:293(resolve)
   411.4970.0001.4970.000 {getattr}
   2070001.2430.0001.7470.000 functional.py:182(inner)
   2020001.2300.0009.1640.000 urlresolvers.py:153(regex)
   2020001.0560.0007.9110.000 __init__.py:128(get_language)
   2020000.6930.0000.6930.000 {method 'search' of 
'_sre.SRE_Pattern' objects}
   200.4020.0000.4020.000 {method 'append' of 'list' 
objects}
 10000.1430.000   14.2210.014 base.py:72(get_response)


seo[-1]

 2022017 function calls in 15.401 seconds

   Ordered by: internal time
   List reduced from 80 to 10 due to restriction <10>

   ncalls  tottime  p

Re: Django performance vs others

2012-10-16 Thread Tom Christie 
Please.  As Jacob has already made clear, this thread isn't helping move 
anything forward.
Can we please respect his request and move on.

Django's community is absolutely interested in addressing practical steps 
towards improving performance and would no doubt welcome specific work 
towards profiling the request-response cycle or otherwise improving the 
codebase.

The intention may be well-meaning, but links to 3rd party benchmarks 
without context, comment, or thoughts on actionable tasks are clearly not 
adding anything to the discussion, and I'm quite sure the core devs have 
better things to do with their time than thread moderation.

  - Tom

On Tuesday, 16 October 2012 11:36:59 UTC+1, Moonlight wrote:
>
> another one:
>
> http://mindref.blogspot.com/2012/10/python-web-reverse-urls-benchmark.html
>
>
> On Thursday, October 4, 2012 10:50:35 AM UTC+3, Moonlight wrote:
>>
>> I found the following benchmarks recently:
>> 1. http://mindref.blogspot.com/2012/09/python-fastest-web-framework.html
>> 2. http://mindref.blogspot.com/2012/07/python-fastest-template.html
>>
>> It is interesting to see the performance boost using pypy.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/x-2TLNJUutgJ.
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: Update on localflavor move

2012-10-16 Thread Andre Terra 
This seems like the most reasonable approach. FWIW, why not name it just
django-localflavor?


Cheers,
AT

On Tue, Oct 16, 2012 at 7:00 AM, Łukasz Rekucki  wrote:

> Maybe we need something like django-localflavour-commons, which would
> include the test harness, packaging logic (then in setup.py you can
> just import it from there), etc. My first idea was to make it a
> submodule, but that would still require making a commit to all repos
> whenever we update the commons (althought, still simpler then applying
> the same patch everywhere). We could instead put it on PyPI and make
> all other packages always require it's latetest version.
>

-- 
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: Update on localflavor move

2012-10-16 Thread Carl Meyer 
On 10/16/2012 04:00 AM, Łukasz Rekucki wrote:
> If we include some form of a test runner in every localflvour, I
> suspect they will get out of sync quite quickly. Also, I don't think
> there is a good reason for duplicating code.

David's pull request seems pretty minimal to me - just a three-line
settings.py and a tox.ini. It would be nice to have some more-automatic
way to keep the tox.ini up to date.

> Maybe we need something like django-localflavour-commons, which would
> include the test harness, packaging logic (then in setup.py you can
> just import it from there), etc. My first idea was to make it a
> submodule, but that would still require making a commit to all repos
> whenever we update the commons (althought, still simpler then applying
> the same patch everywhere). We could instead put it on PyPI and make
> all other packages always require it's latetest version.

Be really careful with importing things in setup.py. A runtime
dependency is different from a can't-even-execute-setup.py-without-it
dependency; the latter means pip wouldn't even be able to install a
localflavor package unless you install the -commons package first (in a
separate step). (Setuptools has setup_requires to get around that, but
it's wonky with pip, as it won't respect any of pip's
index/mirror/find-links settings, and always goes to the main PyPI). I
don't think there's nearly enough common "packaging logic" in the
localflavors to justify any of this hassle.

A localflavor-dev package that includes requirements for running tests
on all localflavors (and has a dependency on tox, so the instructions
are still as simple as "pip install one thing and run one command")
might be ok, though the main duplication you'd want to save is in
tox.ini, and you'd need to write some extra code to help tox "inherit"
config files before you'd be able to save any redundancy there anyway.

Carl

-- 
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.