Class based views: A standard hook for http-method-independent code

oposal is pretty simple I think) but I thought I'd open it up for discussion first. Marc Tamlyn -- 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-dev

Re: Django's CVB - Roadmap?

There is a plan to do some work on the docs at the djangocon sprints - in particular trying to get some examples of when you 'could' and when you 'should not' use the generic CBVs. With regards to Zach's point about TDD testing - some of that may simply be familiarity. I don't know about you bu

Re: Draft branch: Swappable User models in contrib.auth

I believe changes to auth (and several other things) are waiting for contrib.migrations. It will be some time... On Sunday, 19 August 2012 03:02:51 UTC+1, Victor Hooi wrote: > > Hi, > > I'm just wondering, has there been any updates on the User model refactor? > > My understanding is that this is

Re: django 1.5 incompatibility at TemplateView

Hi Bernado, Template view passing params into the context rather than just passing the kwargs from the urlconf directly is actally somewhat older, and is kept as legacy from django.views.generic.simple.direct_to_template. The changes you refer to do actually introduce a subtle backwards incompa

Re: django 1.5 incompatibility at TemplateView

s behave the way I expect :) > > Bernardo > > Em domingo, 19 de agosto de 2012 06h44min03s UTC-3, Marc Tamlyn escreveu: >> >> Hi Bernado, >> >> Template view passing params into the context rather than just passing >> the kwargs from the urlconf

Re: Draft branch: Swappable User models in contrib.auth

Ah, thanks Russ, I'd missed the final resolution to that. M On Monday, 20 August 2012 00:12:18 UTC+1, Russell Keith-Magee wrote: > > On Sun, Aug 19, 2012 at 5:23 PM, Marc Tamlyn > > > wrote: > > I believe changes to auth (and several other things) are waiting for

Possible deprecation of depth= in select_related

Hi all, The issue #16855 [1] tracks some unexpected behaviour in the chaining of `Queryset.select_related`. It's been proving rather complex to get a patch for this which works, mainly because of the complexity added by the depth argument. It has been proposed (by Luke Plant) that depth be depr

Re: Possible deprecation of depth= in select_related

what the deprecation was (and we should get this sorted out for 1.5). Marc On Saturday, 3 November 2012 01:19:59 UTC, Russell Keith-Magee wrote: > > > On Fri, Nov 2, 2012 at 10:33 PM, Jacob Kaplan-Moss > > > wrote: > >> On Fri, Nov 2, 2012 at 9:29 AM, Marc Tam

Re: Could prefetch_related be modified to utilize select_related for ForeignKey relations?

A better way of achieving this functionality would be the API proposed in https://code.djangoproject.com/ticket/17001 Marc On Wednesday, 6 February 2013 00:29:15 UTC, Michal Novotný wrote: > > Hey, what about this > one: qs.prefetch_related('best_pizza__toppings__topping_type_*') > > It is intu

Re: Database pooling vs. persistent connections

+1 to django-postgrespool it works well for me. On Sunday, 17 February 2013 22:17:09 UTC, Carl Meyer wrote: > > On 02/17/2013 11:31 AM, Anssi Kääriäinen wrote: > > It seems SQLAlchemy has a mature pooling implementation. So, yet > > another approach is to see if SQLAlchemy's pooling implementati

Re: Moving database backends out of the core

Seems to me that if database backends were separate from Django then the postgres backend would get a long way ahead of the others as much as the other backends would get behind - it's bound to attract the most work and be adding custom fields like hstore, arrays, json... I think this would be

Re: Ticket 20147 - deprecate and replace request.META

I agree wholeheartedly with the introduction of request.HEADERS. I can see Carl's point regarding deprecating META, and I think it would be fine for it to exist as an alternative implementation in the same way as request.REQUEST does. -- You received this message because you are subscribed to t

Re: RFC: "universal" view decorators

I'm going to resurrect this old thread as I'd like to get it resolved in some fashion. I used to be very in favour of the class decorators approach. I've been using an implementation of `@class_view_decorator(func)` for some time and it works pretty well. That said my implementation at least wa

Re: ORM expressions DEP

I've had a proper read of the patch and the DEP. As far as I'm concerned, it's an extremely powerful and useful change. We may have some minor modifications to make to the implementation as issues are found, but the API decisions are good. On 27 October 2014 12:04, Anssi Kääriäinen wrote: > The

Re: Multiple template engines for Django - week 4 - DEP ready for review!

A few thoughts: I like OPTIONS, I think it's a good idea for the reasons Carl suggested. It would be preferable to have the backend configuration outside of `django.template`. `django.templating` seems reasonable, but even `django.template_backends` might be appropriate as it only contains backen

Re: Unicode SlugField design decision (#16501)

It feels to me more like an option to SlugField and I feel UnicodeSlugField is a bit ugly. If however we find an example where Michael's point is valid (an external 3rd party backend which uses ascii chars for SlugField now) then we should go with that. On 5 November 2014 03:20, Michael Manfre wr

Re: Next LTS version after 1.4?

The current plan appears to be that 1.8 will be the next LTS, with 1.4 keeping security support until 6 months after 1.8's release. We will be having a core meeting in 10 days in Amsterdam, I'll make sure it's finalised. Marc On 5 November 2014 14:55, Rob Yates wrote: > On Monday, August 25, 20

Re: Unicode SlugField design decision (#16501)

Even if the backend is storing using an ascii backed data type, it should still return unicode data to Django anyway, so I'm not sure there would be a difference. Marc On 6 November 2014 01:18, Michael Manfre wrote: > > > On Wed, Nov 5, 2014 at 7:53 PM, Shai Berger wrote: > >> On Wednesday 05

Re: Why doesn't ModelChoiceField.queryset support slicing?

The dangers of fetching objects in the class definition is precisely why the extra `.all()` calls exist in `ModelChoiceField` and part of the reason why this does not work. The proposed code from Thomas is dangerous, and even putting that code in the `__init__` will result in rather inefficient que

Re: Explicit relative imports

I agree wholeheartedly. (Sorry, not much else to say...) On 11 November 2014 21:51, Aymeric Augustin < aymeric.augus...@polytechnique.org> wrote: > Hello, > > We’ve started using explicit relative imports in newer parts of the Django > source tree. They’re short and readable. That’s good. > > I w

Re: Explicit relative imports

Whilst I think it's a bit nicer to be explicit in smaller projects, there are a few places where django's structure can result in long import paths - e.g. django.contrib.gis.db.backends where I think relative imports would actually add clarity. I tend to separate the relative section as the last b

Re: Backend-specific lookups

The test failures on the CI would suggest that overriding `get_db_prep_lookup` is a problem! There are changes on my ranges branch which move the % sign addition out of `Field.get_db_prep_lookup` and into the relevant lookup. This makes overriding certain lookups (e.g. contains, startswith etc) mu

Re: Adding hard dependencies to Django's test suite

I agree. Anyone wanting to contribute to Django should be able to run a pip install -r test_requirements.txt. Marc On 28 November 2014 at 04:03, Fabio Caritas Barrionuevo da Luz < bna...@gmail.com> wrote: > python 2.7.9 rc1 include a backported version of python3 ensurepip > > see: > > https://h

Re: Internationalise GET parameters?

I'm afraid I have to agree the gain does not merit the effort. To the average user, I think the query string already looks like it's weird code stuff (with &=?) so I don't think it being in a different language would improve things that much. Marc On 28 Nov 2014 13:36, "Florian Apolloner" wrote:

Re: DB Migrations: Proposed fix for "Index name collisions after objects are renamed then re-created"

I intend the new indexes to have customisable names, and to deconstruct their name into the migration. This means that any changes in the name (if the name is autogenerated) would be detected. It should be possible to do renames. It is worth noting that mysql (and sqlite obviously) do not support

Re: Status of #15619: logout via POST, but not GET

>From a brief look, the changes in the pull request do not appear to consider backwards compatibility at all, which would be important. The argument that it's ok because it would now just show a confirmation page is insufficient as if someone had built a confirmation page there would now be two. A

Re: Should annotations allow model field constraints?

I think this should be an error personally - I'm not sure how we check that effectively and efficiently. It reminds me of asking postgres to cast a certain type to another one - it will throw an error if any record it tries to cast can't be done. Is it possible with say a CharField to not have a

Re: Experimental APIs DEP

I'm going to agree with Tim, it's a good idea but it is hard to agree on its impact without the specifics. On 8 December 2014 at 15:04, Tim Graham wrote: > I am skeptical like Carl, but it seems to me the time to introduce and > discuss this DEP is when there is an actual feature that we think c

Re: Vendoring XRegexp

I'm certainly in favour of not reinventing the wheel here. As a side note, I would love to have the javascript slugify functionality easily usable outside the admin. On 20 December 2014 at 04:51, Berker Peksağ wrote: > > While I'm working on #3729 [1], I had to update current regexes to > match u

Re: simplifying the default template context_processors

I like it from a purity point of view, but I'm dreading updating through it and replacing every instance of `{{ STATIC_URL }}` in my templates... I also have a number of small projects which add a custom context processor which add a certain queryset into the context every time because they form a

Re: Can't login after upgrading to 1.7.3, and workaround

I think therefore you could resolve the issue by doing save(update_fields=['count']) in your code. On 15 January 2015 at 06:31, Horacio G. de Oro wrote: > Yeap. Removing the save() done in solved the issue. > > And some component is doing and update() - not a save(). I see in the > Postgresql l

Re: Settings: lists or tuples?

I think Florian's point would be that you can still do: from django.conf import settings settings.TEMPLATE_DIRS += ('foo',) if it is a tuple, so I don't really see how it being a tuple is making it necessarily more safe than a list - is the above code really much different to: from django.conf i

Re: Support SECRET_KEY and Database creds as callables

I'm not sure what the benefit here would be - the settings are evaluated at start up time, not on every request and the server would need to be restarted for it to change. A patch to db.connections which allows the username and password to be looked up on each new connection might be interesting,

Re: GSOC 2015 project ideas suggestion

Anything not done from previous years is likely to be suitable yes. It would also be very beneficial to familiarise yourself with the contributing guidelines for Django[1] and take on some small fixes, perhaps in related areas to your interests for GSOC. Marc [1] https://docs.djangoproject.com/e

Re: importing threading and dummy_threading

Given that it already doesn't worth without full threading in the previous LTS, I don't think we need to worry about it. On 28 January 2015 at 14:32, Tim Graham wrote: > Here's a 9 year old ticket referencing freebsd5.1... > > https://code.djangoproject.com/ticket/2052 > > > On Wednesday, Januar

Re: automated import sorting and better pull request checks

Would it be possible to use travis for flake8/docs checks? That would hopefully automatically show up as two separate flags on the status API. Of course it would be really nice if the docs and flake8/isort and tests all displayed separately. An alternative could be to use code climate which curren

Re: Feature proposal: Conditional block tags

I personally don't see any problem with the existing syntax and find it much easier to understand. On 31 January 2015 at 12:43, Aymeric Augustin < aymeric.augus...@polytechnique.org> wrote: > Hello, > > That’s a rather specialized behavior for the general purpose {% block %} > tag. > > I’m not co

Re: Postgres specific fields and third party apps.

I would strongly disagree with supporting these on SQLite, in any format. A fully supported version would be complex to support and enormously inefficient, and I'm not in favour of Django shipping half baked features with major holes in them. I certainly don't have the motivation to build this. Ma

Re: discontinue shipping tests with contrib apps?

+1 to removing tests from contrib itself, so long as they remain obviously separated in the test section in case of future removals from core. On 9 February 2015 at 15:44, Preston Timmons wrote: > I think the "need" is mainly conceptual--whether tests are more > appropriately grouped with their

Re: Relations to non-trivial fields

This issue is that the foreign key field (i.e. the foo_id field) does not have its db_converters called, if they are defined in the backend rather than in the field itself. I've added a pull request (https://github.com/django/django/pull/4134) with a possible approach to the problem. We may be abl

Psycopg2 version support

Hi all, Related ticket - https://code.djangoproject.com/ticket/24335 Django 1.8 will necessarily be the first version with a true minimum requirement on psycopg2 version. Historically we have never documented a required version. - The new UUIDField requires at least 2.0.9 - Some code which is cu

Re: Drop the TEMPLATE_DEBUG setting

+1 to removing it On 15 Feb 2015 14:16, "Aymeric Augustin" wrote: > Hello, > > During the multiple template engines refactor, I didn’t touch > TEMPLATE_DEBUG. > The only purpose of this setting is to control whether Django stores the > information required to display stack traces for exceptions t

Re: Support for DATABASES['default'] = {}

It would seem more sensible to me to try to support DATABASES={}. There's no reason why a Django site should have to run a database - a microservice using redis or something similar is perfectly reasonable and you could want to use Django for other reasons (e.g. shared templates). Marc On 24 Febr

Re: Support for DATABASES['default'] = {}

tting that does not include `default`. > > On Tuesday, February 24, 2015 at 2:43:51 PM UTC+1, Marc Tamlyn wrote: >> >> It would seem more sensible to me to try to support DATABASES={}. There's >> no reason why a Django site should have to run a database - a microservice

Re: Support for DATABASES['default'] = {}

multi-db setups > might be using that. I can't think of a scenario where it hurts to have a > default database. I'm easily swayed on this matter, though. > > On Tuesday, February 24, 2015 at 2:52:47 PM UTC+1, Marc Tamlyn wrote: >> >> In that case your proposal sou

Re: django admin: open popups as modals instead of windows

I would suggest that a good modal implementation for these should still support "open in new tab/window" properly, with control/command click not detected by the overriding JavaScript. It may be possible to do this and keep the popup functionality passing the new id back to the parent window. >Fro

Re: enum fields in django

I kinda like the idea of enum fields, but I feel they are likely better in theory than in practice. In theory I said I would introduce one as part of contrib.postgres, but I've been putting it off as I'm unconvinced whether it is necessarily ideal anyway when compared to choices or reference tables

Re: enum fields in django

nce an >> enum will save you a couple of joins per table lookup. >> >> >> It depends what you guys want to do. I'm happy to put in the work to >> make the implementation generic, but I'm not going to push for you >> guys to implement something you d

Re: Extending the URL Dispatcher (GSoC 2015 proposal)

A collection of thoughts: I think allowing the url dispatcher to inspect the database for the existence of certain objects is potentially somewhat dangerous. However, good support for a view raising a "continue resolving" exception along the lines of https://github.com/jacobian-archive/django-mult

Re: Suggestion: add default "registration/login.html" to django.contrib.auth

I can see the merit of including our documented example as an actual template as a starting point. It's unlikely to be used exactly as is very often but it reduces getting started friction for some users - "huh this view doesn't work, better go read the docs" I'd perhaps be inclined to include it

Re: Suggestion: add default "registration/login.html" to django.contrib.auth

hat template when > login.html isn't found. > > -- > Aymeric. > > Le 3 mars 2015 à 15:25, Marc Tamlyn a écrit : > > I can see the merit of including our documented example as an actual > template as a starting point. It's unlikely to be used exactly as is very >

Re: Composite fields

I think `Model._meta` may well always want all the concrete underlying fields included somehow, especially for migrations work. A possibility for your external `MoneyField` could be to add other fields using `contribute_to_class`, though this may be a bad idea... On 5 March 2015 at 14:47, Thomas S

Re: Adding an option on db_index to not create text/varchar_pattern_ops

I have some plans (see https://github.com/django/deps/pull/6) to rework more widely how indexes are managed and allow finer control over them. It pretty much includes all the things mentioned by Alex. I'm intending on doing some work on it over the next few weeks. Marc On 20 March 2015 at 02:27,

Re: Two phase cleaning of models/forms

In particular it is worth noting the addition of form.add_error[1] in Django 1.7 which makes long clean methods much nicer to handle. [1] https://docs.djangoproject.com/en/1.7/ref/forms/api/#django.forms.Form.add_error On 25 March 2015 at 16:11, Carl Meyer wrote: > Hi Thomas, > > On 03/25/2015

Re: Pre-DEP: community support of unmaintained versions of Django

Sounds broadly good to me. I'd be happy for it to be pushed to pypi under django-legacy or similar name. Marc On 27 Mar 2015 16:36, "Tim Graham" wrote: > Sounds good to me. > > On Friday, March 27, 2015 at 12:28:09 PM UTC-4, Carl Meyer wrote: >> >> Hi Christian, >> >> On 03/26/2015 05:11 PM, Chr

Re: Using AbstractBaseUser without django.contrib.auth

Moving them into another module won't make much difference as their definition requires Permission and Group and therefore they'd still need to import Permission and Group. We'd need an "AbstractAbstractBaseUser" which would be silly. Of course, there is no requirement to use AbstractBaseUser for

Re: Using AbstractBaseUser without django.contrib.auth

Apologies, I was confusing abstract base user and abstract user there. Seems your proposal should work. Have you opened a ticket? On 2 April 2015 at 14:28, Dan Watson wrote: > On Thursday, April 2, 2015 at 2:27:51 AM UTC-4, Marc Tamlyn wrote: >> >> Moving them into another mo

Re: Fate of sql* management commands

As far as I'm aware, we have some code paths which still work in 1.9 which generate tables directly from the models. We use this when running Django's own test suite, and it is also used now by djangobench. I haven't looked into exactly how to turn this into logged SQL rather than run SQL but it sh

Re: 1.9 release planning

This looks like a good plan to me. The main reason for shortening it before as far as I could tell was the lengthy alpha to final process, which hasn't happened this time and hopefully will be rather less frequent in future. Marc On 7 April 2015 at 00:21, Tim Graham wrote: > With a 9 month sche

Re: render_to_response in Django 1.8 missing a request parameter?

This is probably a slight error in the documentation, however what you really want to use is the `render()` function when you want a request context. See https://docs.djangoproject.com/en/1.8/topics/http/shortcuts/#render On 7 April 2015 at 11:28, Stephen Brooks wrote: > I note from the release

Re: render_to_response in Django 1.8 missing a request parameter?

that case the render_to_response shortcut has little value and should > probably be removed in Django 2.0 ?? > > On Tuesday, 7 April 2015 11:31:24 UTC+1, Marc Tamlyn wrote: >> >> This is probably a slight error in the documentation, however what you >> really want to use is the `re

Re: Django Admin New Look

Django's master is the correct branch for 1.9 development now. Flat icons would be good, and I agree personally with your earlier suggestion to use font awesome icons. I do think this is a separate issue we could add later. The primary questions to establish answers to before a possible merge in

Re: Django Admin New Look

20597 >> > > Thanks Collin. > > > On Tuesday, 7 April 2015 20:25:57 UTC+5, Marc Tamlyn wrote: >> >> The primary questions to establish answers to before a possible merge in >> my opinion are: >> - Do we ship both, or just the new one and release the old one

Re: Removing global database converters and adapters for datetimes

I think this is likely a good plan. There are a number of other places where we globally register converters/adapters (at least in postgres land) rather than explicitly registering them on each connection. I'm not sure if they're an issue in the same way though. Marc On 13 April 2015 at 20:11, Ca

Re: Why deprecate the ability to reverse using the Python path?

Hi Thomas, I appreciate your concern, and it's a significant change for your application, which is obviously very large and has been in development for some time. I've been involved with similarly painful processes such as the transition to the {% url %} tag requiring a string. First a note on th

Re: CSRF_COOKIE_HTTPONLY is misleading and not useful

I'm not a security expert, but one thing I could suggest is that this setting does mean that only javascript on a page with a POST form can access the CSRF token. Depending on the nature of your site, this could be a significant proportion of pages. On 17 April 2015 at 21:22, Gavin Wahl wrote: >

Re: Writing some tests for new feature

It's quite possible this is an area which is untested - partly because when it was originally written we didn't have the mock library to prevent the external url call. Adding tests would be wonderful. Marc On 22 April 2015 at 17:29, ST LEON wrote: > I want to contribute one new feature to Djang

Re: Idea/request for help: Django Developers Community Survey

I would suggest IRC and/or Github should be options on the "I follow Django development" question. I'd also suggest we ask a couple of open ended questions along the line of "What's your favourite thing about Django" and "What's your least favourite thing about Django". I've found interesting resp

Re: one patch to fix a Django 1.8 issue for merging legacy database

The automatic ID field would not be added if you have a primary key. I'm not sure if inspectdb does pick up primary keys, I believe it does though. I feel this discussion may be more suited to django-users, our forum for helping debugging user issues. Marc On 28 April 2015 at 07:48, Ben L wrote

Re: Guessable entry points

Yes to python -m django No to django as another alias for django-admin. After all, someone who is just "guessing" will probably type dj and get django-admin[.py] anyway. On 1 May 2015 at 15:03, Aymeric Augustin wrote: > On 1 mai 2015, at 15:51, Enrique Paredes wrote: > > > So along this line of

Re: Improving Test Speed for Projects that use django.contrib.postgres

One of the main questions is to work out what is slow. You can often gain a lot by using the new --keep-db option which maintains the test database between runs meaning you don't have the DDL time each run. A brute force approach which can have an impact is to install postgres on a RAM disk, this

Re: An easier path to upgrade from one LTS release to another

I'm not sure that would be a wise move - for people who don't keep up with deprecation warnings but otherwise move one version at a time it would make upgrading from an LTS to the following release 3 times harder than normal, encouraging stagnation. This also affects third party applications who wi

Re: An easier path to upgrade from one LTS release to another

ted. Then again, I don't work in an LTS environment, and no one has been working in such a setup with django through several LTS versions to see what happens. On 7 May 2015 at 12:41, Anssi Kääriäinen wrote: > On Thu, May 7, 2015 at 11:34 AM, Marc Tamlyn > wrote: > > I'm not

Re: Is improving Django's communication with Oracle databases on the roadmap?

I can't comment on the specifics of this issue, but I would like to mention that there is no roadmap for Django development in general. Oracle expertise is an area we struggle with compared to other backends, and all outside enthusiasm for improving the Oracle backend is gratefully received! On 15

Re: Proposal: Manually login without authenticate

Here is a related ticket for doing this in tests, where frankly I don't care about authentication. https://code.djangoproject.com/ticket/20916 On 22 May 2015 at 17:30, Paulo Gabriel Poiati wrote: > Good point James, > > It make sense if you could login the user without the credentials > (proposa

Re: Proposal: Manually login without authenticate

> > If the backend is inferred by a single value in the settings and not > stored alongside the user ID, what would happen to existing users who are > already logged in when a second backend is added to the settings and > deployed? Django would no longer know which backend to use to fetch the > aut

Re: Feature request - models.TextInAParagraphField

Hi Reiner. You'll get answers to questions like this on the django-users email list, < django-developers@googlegroups.com> - the web interface is < https://groups.google.com/forum/#!forum/django-users>. The list you've posted to is django-developers, which is for the discussion of the development

Re: Deprecate internal syncdb in 1.9 ?

Maintaining some ability for test applications to have no migrations is very important for Django's own test suite and also other tools such as djangobench. If we're going to maintain some form of code path for that, we should expose it publicly as well. Marc On 3 June 2015 at 14:29, Markus Holte

Re: Provide free, simple, small-scale hosting for new users

Heroku also offers free hosting of a sort. The DSF has nowhere near the financial muscle or human resources to provide such a service. There could be an argument to document possible free hosting platforms, but the django project generally avoids advertising any particular company (or third party p

Re: Extending contrib.admindocs functionality

This seems like a good idea to me. I'm not convinced that the original use case for admin docs (documenting features which only work in templates for the template author) is valid any more - especially with a Django in which you can use jinja2 easily where function calls are allowed. The separation

Re: Django Admin - ModelAdmin exclude

I don't think we should add this. Exclude is passed to the form, and we already have a way of changing the form based on the request. I'd rather see changes made to reduce some of the many many ways to select fields in the admin. By my count at present we have: ModelAdmin.fields ModelAdmin.get_fie

Re: Making management forms for formsets optional

I believe the complaint is mostly that an invalid formset will raise a 500 whereas an invalid form (should) never. There was a patch to display an error if not. My complaint is that this error can only occur if the dev has rendered the form by hand missing the management form. It's likely they woul

Re: how to deal with inspect.getargspec() deprecation?

I'm not sure how similar the return values are, is it possible to write (and contribute upstream) a six move? Perhaps this is impossible without funcsigs though. Marc On 10 June 2015 at 20:09, Carl Meyer wrote: > On 06/10/2015 12:49 PM, Tim Graham wrote: > > inspect.getargspec() was deprecated

Re: Django Admin - list_display default value

Agree this is not an appropriate default, although I could see an argument for supporting __all__ like in forms. This isn't very hard as a third party solution though so I'm not super keen on that idea. M On 15 Jun 2015 22:03, "Shai Berger" wrote: > (I received the message I'm replying to here w

Re: Password validation in Django revisited

This seems like a great example of something which can live as an external package, and you document how to use it with `AUTH_PASSWORD_VALIDATORS`. You could add a minimum entropy parameter as an option which can be passed in the dict. On 17 June 2015 at 03:38, Alex Becker wrote: > Hi Erik, > >

Re: 1.9 release planning

+1 to 1.11 It was an arbitrary decision not to use 2.0 in the first place because we were not going to do special version numbers. Now Y.0 is a special version (dropping backwards compat after the LTS) it makes more sense. Marc On 22 Jun 2015 19:28, "Tim Graham" wrote: > Done that in https://gi

Re: Config file for startproject.

You may also want to look into cookiecutter as a way of managing more complex templates for projects. Marc On 23 Jun 2015 05:26, "Hiroki Kiyohara" wrote: > Thanks, Josh. > > * I thought the config (.djangorc) should be included in project template > it's own. > * bash alias is OK, but it's not e

Re: [django.contrib.postgres] Would this be accepted and how hard would it be to do?

In that case the ability to support it would depend on the support in psycopg2 and how safe we consider their implementation. Marc On 29 Jun 2015 16:01, "Collin Anderson" wrote: > I think XMLField was removed because the security of xml parsing and > validating is hard to get right. > > On Sunda

Re: Inheritance in admin classes

It's a symptom of the poor design of ModelAdmin (especially compared to View). It is just "normal" python classes, but it has methods on it which feel request specific so it's very easy to fall into the trap of thinking of it as a request level object not a process level object. Model instances, fo

Re: Django 1.9 - JSONField

Agreed, as other databases catch up with the feature set offered in contrib.postgres I think moving this field into core is likely - it's a field that a number of databases are working on adding. It's worth noting that the PG implementation is 9.4+ only, the 9.2/9.3 implementation of json should no

Re: And again about permission to view

A general can_view permission not respected by the admin is not a good idea. However an easy way to add a general permission to every model in the system in one go would be interesting - a hook into https://github.com/django/django/blob/7da3923ba0c569aa23d0ab0a47a124af60a18f5b/django/contrib/auth/

Re: URL dispatcher API

+100 for django.urls. resolving and reversing functions should be located in the same namespace. M On 10 Jul 2015 15:55, "Marten Kenbeek" wrote: > Hi James, > > Thanks for taking a look at this, I really appreciate it. > > *Major bug:* the `request` object needs to be passed into `resolve()` >>

Re: Proposal: deprecate and remove egg template loader

+1 On 12 July 2015 at 15:53, James Bennett wrote: > There's not much to this, really, except what's in the subject line of > this message. > > The problem of providing a single-file, no-build-step format for > distributing and installing Python packages has been solved by wheels, and > wheels al

Re: Major features for 1.9

That one has already landed On 17 July 2015 at 18:43, Christian Schmitt wrote: > Didn't you missed jsonb from Marc Tamlyn aswell? It's one of the greatest > features for Postgresql > > Am Freitag, 17. Juli 2015 19:19:38 UTC+2 schrieb Tim Graham: >> >> Currentl

Re: A modest proposal - more blocks in admin templates

I actually think documenting which blocks we have is a good way to be able to change them ironically - we currently don't allow much change in admin templates to avoid breakage elsewhere, this would give us at least a way to say "the HTML generated in block X in template Y is changing". There could

Re: Django Admin New Look

Font Awesome is not GPL - the code is MIT and the font itself is SIL OFL both of which are fine to include with Django. On 29 July 2015 at 12:13, elky wrote: > Hi guys, > > I'm glad to say I finished work on replacing image icons with font. I used > Font > Awesome

Re: default values on database level

Debatably this situation should throw an error at model validation time - assuming the expression does error out when trying to build that database. Otherwise it will error at migrate time. I would like this - it would be very good for UUID as PK On 29 July 2015 at 16:42, Podrigal, Aron wrote:

Re: Django Admin New Look

One thing that might be nice to do with the admin, especially in the context of the fonts but also with jQuery, is to give an easy override to use CDN versions of the files. Django still needs to bundle them for offline work, and the default should be to include Django's own ones, but it would be g

Re: future of QuerySet.extra()?

I don't know about unmaintained, but I think there's a consensus that .extra() has a horrible API and we should do away with it eventually. That said I think there are still enough things that can't be done without it at present. A lot fewer now we have expressions, but still some. I'd be happy to

Re: future of QuerySet.extra()?

in Anderson wrote: >> >> I wonder if there's a way in the docs we can deprecate it as in "we don't >> recommend you use it", but not actually schedule it for removal. >> >> On Friday, July 31, 2015 at 2:01:20 PM UTC-4, Marc Tamlyn wrote: >>&g

  1   2   3   4   >