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 p
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 requ
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 faili
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 20
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:/
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 an
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.b
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 wi
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 te
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 depende
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
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
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 y
Hi Simon,
On 05/17/2016 07:28 AM, 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
On 05/17/2016 01:33 AM, Claude Paroz wrote:
> 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?
Yes, it's certainly possible that we could address this with a new API
in the te
Am Dienstag, 10. Mai 2016 02:07:30 UTC+2 schrieb Kevin Tran:
>
> Thomas, did you ever find a solution to your problem? I'm having similar
> thoughts and am looking for an answer.
>
>
Carl Meyer has worked out an enhancement proposal, here is the
pull-request: https://github.com/django/django/
16 matches
Mail list logo
