Re: Oracle backend and passing data as is.

[Jani Tiainen]

Unfortunately problem seem to lie somewhere in standard Oracle backend 
and it's way to handle arguments and argument types. Most probably it's 
FormatStylePlaceholderCursor object that does it.


On 18.05.2016 00:09, Claude Paroz wrote:

Hello Jani,

I'm not familiar with the Oracle backend, but you probably have to 
play with the
OracleSpatialAdapter / WKTAdapter stuff to achieve what you need. Good 
luck!


Claude

Le mardi 17 mai 2016 14:53:28 UTC+2, Jani Tiainen a écrit :

I'm toying around Oracle and latest cx_Oracle feature that allows
putting real objects through cx_Oracle to database. One use case
is GIS
which is way faster than trying to transfer WKT over queries.

I just have one problem - how I can tell in the backend that one
particular query parameter and it's must be kept as is, and it's type
set automatically (or not to set at all on Django side).

Currently I always end up having "Expecting MDSYS.SDO_GEOMETRY got
NCHAR" error.

-- 


Jani Tiainen

--
You received this message because you are subscribed to the Google 
Groups "Django developers (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1da65293-721c-4790-ae76-b146d580d22d%40googlegroups.com 
.

For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups "Django 
developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/573BF445.2070109%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Oracle backend and passing data as is.

[Claude Paroz]

Hello Jani,

I'm not familiar with the Oracle backend, but you probably have to play 
with the 
OracleSpatialAdapter / WKTAdapter stuff to achieve what you need. Good luck!

Claude

Le mardi 17 mai 2016 14:53:28 UTC+2, Jani Tiainen a écrit :
>
> I'm toying around Oracle and latest cx_Oracle feature that allows 
> putting real objects through cx_Oracle to database. One use case is GIS 
> which is way faster than trying to transfer WKT over queries. 
>
> I just have one problem - how I can tell in the backend that one 
> particular query parameter and it's must be kept as is, and it's type 
> set automatically (or not to set at all on Django side). 
>
> Currently I always end up having "Expecting MDSYS.SDO_GEOMETRY got 
> NCHAR" error. 
>
> -- 
>
> Jani Tiainen 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1da65293-721c-4790-ae76-b146d580d22d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [RFC] Test methods filtering on tests run

[Journeyman]

On 17/05/2016 02:32, Josh Smeaton wrote:


I have the same problem when running tests in Django's test suite. When
there's a failure, I have to copy the test path, paste that, then copy
the failing test.


Now that you mention it, another improvement could be to compose a 
ready-to-copy-and-paste "url" for the output of failing tests. Instead of:



ERROR: test_method_1 (mydjangoapp.app_one.tests.test_module.TestClass)
Test docstring


we could tweak printErrorList() into something along the line of:


ERROR: test_method_1 (mydjangoapp.app_one.tests.test_module.TestClass)
Test docstring
url: mydjangoapp.app_one.tests.test_module.TestClass.test_method_1



Would you mind posting your patch somewhere? Reviewing code along with
the description and seeing potential for changes would be cool.


Sure, no problem.

http://paste.debian.net/686941/

It's somehow rough, I'm simply adding a new optional parameter to the 
Django Command that runs the tests; this parameter will force an 
iteration through the test suite and discard those methods whose name is 
not specified. I could not directly access the TestSuite objects to 
remove an item (which is funny since internally unittest.TestSuite uses 
a list).


It could be refactored somewhere else or improved like you suggested, 
provided some examples of what kind of globbing/regex you think it would 
be useful f.e. glob test methods only? Packages only? A dot separated 
syntax to specify both? Etc.


Concerning the suggestion of Ludovic of gathering the failing tests and 
re-run them, I agree that a dedicated tool like the juno-testrunner is 
better suited for the job.


Thanks for your comments.

Antonio

--
You received this message because you are subscribed to the Google Groups "Django 
developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/573B7196.6050902%40storiepvtride.it.
For more options, visit https://groups.google.com/d/optout.

Re: Should we require pytz for timezone support in Django?

[Michael Manfre]

I can't recall the last Django project I worked on that didn't require
pytz. It makes sense to me to require it.

Regards,
Michael Manfre

On Tue, May 17, 2016 at 6:07 AM Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> The reasoning was based on:
>
> - our reluctance to add dependencies back then (Django 1.4)
> - sqlite3 not being strictly needed in all circumstances (and probably
> being needed in fewer circumstances originally)
>
> I’ll try to find time to make a more detailed answer later.
>
> --
> Aymeric.
>
> On 17 May 2016, at 12:01, Marc Tamlyn  wrote:
>
> It would seem reasonable to me to require it. I wonder whether the
> reasoning is based on distro packaging or similar?
>
> On 17 May 2016 at 01:21, Josh Smeaton  wrote:
>
>> While writing timezone tests for
>> https://github.com/django/django/pull/6243 I ran into some issues where
>> pytz seemed to be required for just about every database and platform
>> combination except postgres on linux. The docs for timezone support (
>> https://docs.djangoproject.com/en/dev/topics/i18n/timezones/) say:
>>
>> Installing pytz  is highly recommended,
>>> but may not be mandatory depending on your particular database backend,
>>> operating system and time zone. If you encounter an exception querying
>>> dates or times, please try installing it before filing a bug.
>>
>>
>> I tried to find some documentation on the broader internet that would
>> more accurately describe when and for what platforms pytz is actually
>> required for timezone support, but was unable to find anything. I've opened
>> a new ticket https://code.djangoproject.com/ticket/26622 to clarify more
>> explicitly when pytz is required.
>>
>> However, I'm wondering if we should just go all-in on pytz and require it
>> for timezone support. I've not run a Django site with timezone support
>> without pytz, so I'm not sure what exact limitations exist or why you'd
>> want to use timezone support without pytz. I'd be interested in hearing use
>> cases for not requiring pytz if there are any. Explicitly requiring pytz
>> will make test writing a lot easier, and will remove any doubt about
>> whether or not pytz is required for users.
>>
>> Josh
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/cb513e96-e75f-462f-a8ca-b5d916ad8eef%40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAMwjO1H_n%3DGzAFZ%2BR07Qf2qnbmY8_dpy5FhdaBEXrQRB0gJ9sQ%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/E0E058F8-7842-4F57-B7C2-A5BA2C2FD4D4%40polytechnique.org
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to 

Re: Template-based widget rendering

[Tim Graham]

I'm not feeling particularly inspired about a solution for the 
backwards-compatibility issue, and unless someone can work some magic today 
in completing the patch, I think we'll defer this from 1.10.

On Tuesday, May 17, 2016 at 9:28:59 AM UTC-4, charettes wrote:
>
> Did we consider defining a template loader that knows where to load the 
> widget
> templates from instead of requiring 'django.forms' in INSTALLED_APPS with
> 'APP_DIRS': True in TEMPLATES?
>
> Something along theese lines make more sense to me:
>
> TEMPLATES = {
> {   
> 'BACKEND': 'django.template.backends.django.DjangoTemplates',
> 'DIRS': [], 
> 'APP_DIRS': True,
> 'OPTIONS': {
> 'loaders': [
> 'django.forms.templates.loader.WidgetTemplateLoader',
> ]
> },
> },
> }
>
> Simon
>
> Le samedi 14 mai 2016 10:03:57 UTC-4, Tim Graham a écrit :
>>
>> While testing this, I ran into a shortcoming with the fallback strategy 
>> for backwards-compatibility. 
>>
>> If you have a DjangoTemplates backend configured with 'APP_DIRS': True 
>> (as in the tutorial) and you try to visit /admin/auth/user/#/change/ which 
>> renders the ReadOnlyPasswordHashWidget, the template system will crash with 
>> TemplateDoesNotExist because it can find the widget's template using the 
>> app_directories loader but not the 'django/forms/widgets/attrs.html' 
>> template that the first template includes. Since the first template is 
>> found using what's configured in TEMPLATES (which doesn't know about any of 
>> the built-in form templates), the standalone engine needed to find the 
>> built-in templates is ignored.
>>
>> I guess it will affect every project that uses the admin. I can't think 
>> of a simple solution other than adding a system check upgrade warning to 
>> detect this situation ('django.contrib.admin' in INSTALLED_APPS but not 
>> 'django.forms') and advise the user to add 'django.forms' to 
>> INSTALLED_APPS. Thoughts?
>>
>> On Thursday, May 12, 2016 at 1:17:23 PM UTC-4, Carl Meyer wrote:
>>>
>>> On 05/12/2016 09:39 AM, Tim Graham wrote: 
>>> > So this discussion doesn't stall the rest of the patch, I suggest 
>>> > keeping the fallbacks for now and deprecation them later if they cause 
>>> > confusion or other problems. 
>>>
>>> Yes, I think that makes sense. 
>>>
>>> Carl 
>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/35252aa9-ae85-4c5f-9718-58da4530dbad%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

GSoC community bonding period Update

[akki]

Hi

The community bonding period of GSoC is about to end and here is an update 
of my work during the community bonding period. I have taken the 
opportunity to use this time to research about the various things that 
would help me during the coding period of GSoC and also to help the 
community with the bug reporting/solving/reviewing process.



I found and went through discussions of various tickets to get an idea of 
the various issues that we are facing and that can be solved via my GSoC 
project . They are listed below:
https://code.djangoproject.com/ticket/20581
​
https://code.djangoproject.com/ticket/20888
​
https://code.djangoproject.com/ticket/23577
​
​
https://code.djangoproject.com/ticket/24082
https://code.djangoproject.com/ticket/24530
​
https://code.djangoproject.com/ticket/25752
https://code.djangoproject.com/ticket/26610 (reviewed only).

There was also a discussion on the mailing list which was also helpful:
https://groups.google.com/forum/#!topic/django-developers/7pMxh2JF1lo

Here I have prepared of the basic queries for creating and deleting indexes 
in the various backends we support which would helpful while writing code 
in the schema - 
https://gist.github.com/akki/73e7b0b7098e32594237749eb79a0960



Other than that, I was trying to solve a couple of bugs that I had found 
(but haven't found the fix); one of which I have reported recently - 
https://code.djangoproject.com/ticket/26624.
I will report the other one as well soon.

I worked on some already existing issues as well:
https://code.djangoproject.com/ticket/21523 - PR: 
https://github.com/django/django/pull/6468
https://code.djangoproject.com/ticket/15220 - WIP version: 
https://github.com/akki/django/tree/ticket_15220

​​
​Regards​
akki

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ce1a1e7a-9049-4b00-aae7-3a883528c00a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Template-based widget rendering

[charettes]

Did we consider defining a template loader that knows where to load the 
widget
templates from instead of requiring 'django.forms' in INSTALLED_APPS with
'APP_DIRS': True in TEMPLATES?

Something along theese lines make more sense to me:

TEMPLATES = {
{   
'BACKEND': 'django.template.backends.django.DjangoTemplates',
'DIRS': [], 
'APP_DIRS': True,
'OPTIONS': {
'loaders': [
'django.forms.templates.loader.WidgetTemplateLoader',
]
},
},
}

Simon

Le samedi 14 mai 2016 10:03:57 UTC-4, Tim Graham a écrit :
>
> While testing this, I ran into a shortcoming with the fallback strategy 
> for backwards-compatibility. 
>
> If you have a DjangoTemplates backend configured with 'APP_DIRS': True (as 
> in the tutorial) and you try to visit /admin/auth/user/#/change/ which 
> renders the ReadOnlyPasswordHashWidget, the template system will crash with 
> TemplateDoesNotExist because it can find the widget's template using the 
> app_directories loader but not the 'django/forms/widgets/attrs.html' 
> template that the first template includes. Since the first template is 
> found using what's configured in TEMPLATES (which doesn't know about any of 
> the built-in form templates), the standalone engine needed to find the 
> built-in templates is ignored.
>
> I guess it will affect every project that uses the admin. I can't think 
> of a simple solution other than adding a system check upgrade warning to 
> detect this situation ('django.contrib.admin' in INSTALLED_APPS but not 
> 'django.forms') and advise the user to add 'django.forms' to 
> INSTALLED_APPS. Thoughts?
>
> On Thursday, May 12, 2016 at 1:17:23 PM UTC-4, Carl Meyer wrote:
>>
>> On 05/12/2016 09:39 AM, Tim Graham wrote: 
>> > So this discussion doesn't stall the rest of the patch, I suggest 
>> > keeping the fallbacks for now and deprecation them later if they cause 
>> > confusion or other problems. 
>>
>> Yes, I think that makes sense. 
>>
>> Carl 
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/b9de7eac-9412-482f-9e79-809d1293f6eb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Oracle backend and passing data as is.

[Jani Tiainen]

I'm toying around Oracle and latest cx_Oracle feature that allows 
putting real objects through cx_Oracle to database. One use case is GIS 
which is way faster than trying to transfer WKT over queries.


I just have one problem - how I can tell in the backend that one 
particular query parameter and it's must be kept as is, and it's type 
set automatically (or not to set at all on Django side).


Currently I always end up having "Expecting MDSYS.SDO_GEOMETRY got 
NCHAR" error.


--

Jani Tiainen

--
You received this message because you are subscribed to the Google Groups "Django 
developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/573B143B.5050400%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [RFC] Test methods filtering on tests run

[Steve Jalim]

On Tuesday, May 17, 2016 at 11:06:43 AM UTC+1, ludovic coues wrote:
>
> I might be saying something stupid, but rather than filtering test, 
> would it not be better to have a flag to rerun all the test that 
> failed in the previous run ? 
>
>
That's why we extende DiscoverRunner to make 
https://pypi.python.org/pypi/django-juno-testrunner 

It's not the best code, but it works well for us. Maybe something in this 
pattern (ie, a flag to generate and consume a rerun log) might be another 
way?

Steve

 

> So the command would always be the same for testA, testB or even both, 
> and might be more user-friendly if there is a bunch of test failing. 
>
> 2016-05-17 2:32 GMT+02:00 Josh Smeaton : 
>
> > Hi Antonio 
> > 
> > I have the same problem when running tests in Django's test suite. When 
> > there's a failure, I have to copy the test path, paste that, then copy 
> the 
> > failing test. The entire path to the test isn't printed in the failures. 
> I'd 
> > be a big fan of *some* kind of implementation that allows me to filter 
> test 
> > methods. I think I'd prefer some kind of glob syntax though, so I could 
> do: 
> > 
> > ./manage.py test app_package**test_method 
> > 
> > That would allow you to be as targeted as you needed to be. 
> > 
> > Would you mind posting your patch somewhere? Reviewing code along with 
> the 
> > description and seeing potential for changes would be cool. 
> > 
> > Josh 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups 
> > "Django developers (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers. 
> > To view this discussion on the web visit 
> > 
> https://groups.google.com/d/msgid/django-developers/0f9fc55e-9568-41d1-92f9-79effabd8e4b%40googlegroups.com.
>  
>
> > 
> > For more options, visit https://groups.google.com/d/optout. 
>
>
>
> -- 
>
> Cordialement, Coues Ludovic 
> +336 148 743 42 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ed326169-0ec6-481d-bf12-8adb0a0d7d9d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Should we require pytz for timezone support in Django?

[Aymeric Augustin]

The reasoning was based on:

- our reluctance to add dependencies back then (Django 1.4)
- sqlite3 not being strictly needed in all circumstances (and probably being 
needed in fewer circumstances originally)

I’ll try to find time to make a more detailed answer later.

-- 
Aymeric.

> On 17 May 2016, at 12:01, Marc Tamlyn  wrote:
> 
> It would seem reasonable to me to require it. I wonder whether the reasoning 
> is based on distro packaging or similar?
> 
> On 17 May 2016 at 01:21, Josh Smeaton  > wrote:
> While writing timezone tests for https://github.com/django/django/pull/6243 
>  I ran into some issues where 
> pytz seemed to be required for just about every database and platform 
> combination except postgres on linux. The docs for timezone support 
> (https://docs.djangoproject.com/en/dev/topics/i18n/timezones/ 
> ) say:
> 
> Installing pytz  is highly recommended, but may 
> not be mandatory depending on your particular database backend, operating 
> system and time zone. If you encounter an exception querying dates or times, 
> please try installing it before filing a bug. 
> 
> I tried to find some documentation on the broader internet that would more 
> accurately describe when and for what platforms pytz is actually required for 
> timezone support, but was unable to find anything. I've opened a new ticket 
> https://code.djangoproject.com/ticket/26622 
>  to clarify more explicitly when 
> pytz is required.
> 
> However, I'm wondering if we should just go all-in on pytz and require it for 
> timezone support. I've not run a Django site with timezone support without 
> pytz, so I'm not sure what exact limitations exist or why you'd want to use 
> timezone support without pytz. I'd be interested in hearing use cases for not 
> requiring pytz if there are any. Explicitly requiring pytz will make test 
> writing a lot easier, and will remove any doubt about whether or not pytz is 
> required for users.
> 
> Josh 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/cb513e96-e75f-462f-a8ca-b5d916ad8eef%40googlegroups.com
>  
> .
> For more options, visit https://groups.google.com/d/optout 
> .
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/CAMwjO1H_n%3DGzAFZ%2BR07Qf2qnbmY8_dpy5FhdaBEXrQRB0gJ9sQ%40mail.gmail.com
>  
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/E0E058F8-7842-4F57-B7C2-A5BA2C2FD4D4%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: [RFC] Test methods filtering on tests run

[ludovic coues]

I might be saying something stupid, but rather than filtering test,
would it not be better to have a flag to rerun all the test that
failed in the previous run ?

So the command would always be the same for testA, testB or even both,
and might be more user-friendly if there is a bunch of test failing.

2016-05-17 2:32 GMT+02:00 Josh Smeaton :
> Hi Antonio
>
> I have the same problem when running tests in Django's test suite. When
> there's a failure, I have to copy the test path, paste that, then copy the
> failing test. The entire path to the test isn't printed in the failures. I'd
> be a big fan of *some* kind of implementation that allows me to filter test
> methods. I think I'd prefer some kind of glob syntax though, so I could do:
>
> ./manage.py test app_package**test_method
>
> That would allow you to be as targeted as you needed to be.
>
> Would you mind posting your patch somewhere? Reviewing code along with the
> description and seeing potential for changes would be cool.
>
> Josh
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/0f9fc55e-9568-41d1-92f9-79effabd8e4b%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.



-- 

Cordialement, Coues Ludovic
+336 148 743 42

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAEuG%2BTb1JiiTNjHiEgCST9NNgoWYhBku0mGvMCrvCRHPJGgLPg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Should we require pytz for timezone support in Django?

[Marc Tamlyn]

It would seem reasonable to me to require it. I wonder whether the
reasoning is based on distro packaging or similar?

On 17 May 2016 at 01:21, Josh Smeaton  wrote:

> While writing timezone tests for
> https://github.com/django/django/pull/6243 I ran into some issues where
> pytz seemed to be required for just about every database and platform
> combination except postgres on linux. The docs for timezone support (
> https://docs.djangoproject.com/en/dev/topics/i18n/timezones/) say:
>
> Installing pytz  is highly recommended, but
>> may not be mandatory depending on your particular database backend,
>> operating system and time zone. If you encounter an exception querying
>> dates or times, please try installing it before filing a bug.
>
>
> I tried to find some documentation on the broader internet that would more
> accurately describe when and for what platforms pytz is actually required
> for timezone support, but was unable to find anything. I've opened a new
> ticket https://code.djangoproject.com/ticket/26622 to clarify more
> explicitly when pytz is required.
>
> However, I'm wondering if we should just go all-in on pytz and require it
> for timezone support. I've not run a Django site with timezone support
> without pytz, so I'm not sure what exact limitations exist or why you'd
> want to use timezone support without pytz. I'd be interested in hearing use
> cases for not requiring pytz if there are any. Explicitly requiring pytz
> will make test writing a lot easier, and will remove any doubt about
> whether or not pytz is required for users.
>
> Josh
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/cb513e96-e75f-462f-a8ca-b5d916ad8eef%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1H_n%3DGzAFZ%2BR07Qf2qnbmY8_dpy5FhdaBEXrQRB0gJ9sQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Template-based widget rendering

[Claude Paroz]

Le mardi 17 mai 2016 08:03:52 UTC+2, Carl Meyer a écrit :
>
> On 05/16/2016 01:48 AM, Claude Paroz wrote: 
>
> > I'm still answering with my naive hat: isn't it possible to simply 
> > always consider forms in django.forms without requiring anything new in 
> > INSTALLED_APPS? What would be the problem? (Sorry if I missed a 
> > discussion about that). 
>
> This is certainly possible, it's just (as Tim says) not clear where 
> exactly one would implement it without introducing an ugly bidirectional 
> coupling between forms and templates. It's one thing for form rendering 
> to now depend on templates, but for template engines (which currently 
> are configured explicitly and only know about the template directories 
> you tell them about) to also automatically and unconditionally know 
> about django.forms (even if you maybe aren't using forms at all -- maybe 
> you're using the template engine standalone for something else entirely) 
> doesn't seem right at all. 
>

I can imagine that django.forms would then be responsible to tell the 
template engine to add the template source. Maybe this would need a new API 
in the template code?
It may be time for me to dive into the code to stop saying stupid things :-/

Claude 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/f30d6a06-7139-4ca0-bb9b-7714d50771a7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Template-based widget rendering

[Carl Meyer]

On 05/16/2016 01:48 AM, Claude Paroz wrote:
> Le samedi 14 mai 2016 16:03:57 UTC+2, Tim Graham a écrit :
> 
> (...)
> 
> I guess it will affect every project that uses the admin. I can't
> think of a simple solution other than adding a system check upgrade
> warning to detect this situation ('django.contrib.admin' in
> INSTALLED_APPS but not 'django.forms') and advise the user to add
> 'django.forms' to INSTALLED_APPS. Thoughts?
> 
> 
> I'm still answering with my naive hat: isn't it possible to simply
> always consider forms in django.forms without requiring anything new in
> INSTALLED_APPS? What would be the problem? (Sorry if I missed a
> discussion about that).

This is certainly possible, it's just (as Tim says) not clear where
exactly one would implement it without introducing an ugly bidirectional
coupling between forms and templates. It's one thing for form rendering
to now depend on templates, but for template engines (which currently
are configured explicitly and only know about the template directories
you tell them about) to also automatically and unconditionally know
about django.forms (even if you maybe aren't using forms at all -- maybe
you're using the template engine standalone for something else entirely)
doesn't seem right at all.

Carl

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/573AB437.6020607%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature