Thanks Markus for the detailed report.
On a conceptual level I think we should aim for:
- django.db.* only relies on get_internal_type().
- django.* only relies on field flags.
To address the immediate regressions I suggest we backport
https://github.com/django/django/pull/4002/files as far bac
I don't like the idea of extended usage of field.get_internal_type(). The
problem is that we haven't defined what the internal_type means, and it is
actually used for different meanings in different places of code currently.
As an example, AutoFields have internal type as AutoField. The AutoFiel
Some ideas. (which still require approval of the core developers):
* Improve database backend base API and related features(including
introspection feature used by inspectdb), so that it is less complicated to
add in the future support the specific features of some backends. eg
multiple databa
Hi Fabio,
Thank you for your project ideas. I'm going to follow the ideas from
https://code.djangoproject.com/wiki/SummerOfCode2015
for your babel porting probably Aymeric Augustin's template refactor
project have some plan with babel integration, but I'm willing to work on
reduce decoupling/Imp
Hi all,
I had a working 1.7.4 (using geodjango) on windows 7 install, no issues.
I'm using osgeo4w to manage all the gdal/gis libraries. When I install the
django 1.8a release or off git master, I get the following traceback:
$ ./manage.py shell
Traceback (most recent call last):
File "./manag
Hi Josh,
There are two technical problems that need to be solved in order to make
this happen.
- Implement the packaging definitions to allow for multiple packages.
- Clean up dependencies between components. Despite the best of
intentions, there are some interesting dependencies between
>
> I suspect it has to do with {% if %} being interpreted at runtime while
> {% block %} is interpreted at compile time.
>
> I never investigated this fully. If someone does, I’m interested :-)
>
> --
> Aymeric.
>
I took a look at how this works. The issue comes from a naive approach to
ho
The description of that project needs to be updated as I don't think it
accurately reflects a direction we want to go. A goal might be the ability
to use django.forms without the rest of Django, but there's no need to
break django.forms into a separate repository to make this possible. In
fact
On Mon, Feb 2, 2015 at 11:39 PM, Fabio Caritas Barrionuevo da Luz <
bna...@gmail.com> wrote:
> Some ideas. (which still require approval of the core developers):
>
>
> * Improve database backend base API and related features(including
> introspection feature used by inspectdb), so that it is less
On Mon, Feb 2, 2015 at 11:58 PM, Asif Saifuddin wrote:
> Hi Fabio,
>
> Thank you for your project ideas. I'm going to follow the ideas from
> https://code.djangoproject.com/wiki/SummerOfCode2015
>
While this is definitely a safe option, don't rule out a
'not-on-the-official-list' project. The GS
Hi,
In the interest of security, I recently started using meta referrer
tags in my HTML [0]. To share the least amount of data as possible, I
opted for the "none" policy [1].
This new HTML5 feature breaks Django POST views. The reason: the CSRF
mechanism checks that, when serving over HTTPS, that
This has bee brought up before, see:
https://code.djangoproject.com/ticket/16870
I am not aware of any change in this area that would affect the decision
made in that ticket.
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Djang
12 matches
Mail list logo
