Re: Ticket 16317 https://code.djangoproject.com/ticket/16317

On Friday, March 16, 2012 7:00:32 AM UTC-7, Marcob wrote: > > The ticket 16317 has a very nice 4 months old patch (it's has a two > lines fix, remainder are just test fixes). > It was marked for 1.3 version but now it's better to change it to 1.4 > version. > As I really hate to patch django

Re: auth.User refactor: reboot

> > > > On Tuesday, March 20, 2012 7:08:49 AM UTC-7, Tom Evans wrote: > >> On Tue, Mar 20, 2012 at 1:37 PM, Russell Keith-Magee >> wrote: >> > >> > On 20/03/2012, at 8:38 PM, Tom Evans wrote: >> >> >> > Personally, I'd be in favor of option (3), mostly because what the last >> 6 years has

Re: Allowing Reverse, Single Inlines in Admin

On Friday, March 30, 2012 11:44:29 AM UTC-7, Tyler Kocheran wrote: There's really no reason for an `Address` to know of itself what it is > owned by, it could be owned by multiple different objects. > Not if you are using a OneToOneField... I think you are just looking for a FK to an

Re: Allowing Reverse, Single Inlines in Admin

On Friday, March 30, 2012 1:58:08 PM UTC-7, Tyler Kocheran wrote: > > > The real point is that I shouldn't be getting errors if I want to have a > OneToOneField inline of an Address on a Person. No matter what side the > relation is declared on, inlines should just work™. Maybe it's not the

Re: GitHub migration done!

On Saturday, April 28, 2012 12:46:53 PM UTC-7, Yuval Adam wrote: > > I think this issue should be dealt with sooner rather than later. > > Django will start getting lots of orphan pull requests with no > matching trac ticket, and a policy of how community members should > contribute via

Re: Proposal: Add some extensibility / decoupling features to Django templates

On Sunday, June 24, 2012 3:02:05 PM UTC-7, Alex_Gaynor wrote: > > > > On Sun, Jun 24, 2012 at 2:50 PM, Jacob Kaplan-Moss wrote: > >> On Sat, Jun 23, 2012 at 7:17 PM, Yo-Yo Ma >> wrote: >> > Without changing any of the existing functionality or

Re: Development GUI

This falls pretty squarely in the category of 3rd party project in the Django ecosphere. While it is a tool oriented for Django, it would not be part of what Django itself does as a web framework. -Preston On Thursday, September 6, 2012 9:38:24 PM UTC-4, Timothy Clemans wrote: > > Hi, > >

Re: Improve Django markdown rendering.

On Thursday, September 6, 2012 10:48:30 PM UTC-4, waylan wrote: > > If instead, improvements are only going to be made to the markdown > filter, then I would suggest a complete overhaul allowing access to > all of markdown's features [2]. > In fact the plan is to deprecate the markup contrib

New predicate functionality for Q objects

I've implemented predicate test like functionality for Q objects. https://code.djangoproject.com/ticket/18931 In brief, this lets you define a condition in a Q object and then test whether a model instance matches the condition. I believe this to be a relatively complete patch, and would

Re: New predicate functionality for Q objects

that being in core offers. Thanks to everyone who has participated in the discussion so far - most of which is occurring on the PR, not the ticket: https://github.com/django/django/pull/388 -Preston On Saturday, September 22, 2012 12:55:26 PM UTC-7, ptone wrote: > > I've implemented predicat

Re: Feature request: collectstatic shouldn't recopy files that already exist in destination

so after scanning this thread and the ticket again - it is still unclear that there could be a completely universal solution. While it would be nice if the storage API had a checksum(name) or md5(name) method - not all custom storage backends are going to support a single checksum standard.

Re: Feature request: collectstatic shouldn't recopy files that already exist in destination

On Monday, October 8, 2012 8:49:58 AM UTC-7, Dan Loewenherz wrote: > > > > On Mon, Oct 1, 2012 at 12:47 AM, Jannis Leidel > > >> wrote: >> Then, frankly, this is a problem of the storage backends, not Django's. >> The S3BotoStorage backend *does* have a modified_time

Re: A.objects.getdefault

So basically you want: https://docs.djangoproject.com/en/dev/ref/models/querysets/#get-or-create but without the create part - just an empty(), unsaved, object? This existing method is so close to what you want - that I'd be inclined to explore whether it could be modified to do more. In

Re: A.objects.getdefault

Unsurprisingly - this has come up before: Earlier discussion https://groups.google.com/forum/?fromgroups=#!topic/django-developers/Saa5nbzqQ2Q tickets: https://code.djangoproject.com/ticket/17546 https://code.djangoproject.com/ticket/2659 https://code.djangoproject.com/ticket/11352 All the

Re: Django 1.5: AUTH_USER_MODEL and GeoManager

On Thursday, October 11, 2012 12:51:07 AM UTC-7, Max wrote: > > Hi there, > this is my first post here; hope I'm posting to the right group. > I'm currently working on getting to run an 1.4-application (using a > profile model) on 1.5dev, using the the new (eagerly awaited by me) > custom user

Re: Update on localflavor move

On Friday, October 12, 2012 3:21:16 PM UTC-7, Adrian Holovaty wrote: > > * If you have any existing Trac tickets for localflavor, please close > them and open a pull request on the appropriate django-localflavor-* > project. > Correct me if I'm wrong in interpreting this - Trac won't be

Re: contrib.markup deprecation

On Saturday, October 13, 2012 10:35:10 AM UTC-7, Luke Plant wrote: > > Hi all, > > https://code.djangoproject.com/ticket/18054 > > I just came across this, and it seems slightly hasty. Most deprecations > of entire contrib modules would require some discussion on django-devs, > I would have

Re: [ANN] Django 1.4.2 and 1.3.4 remedy security issues

Seems to be there: http://pypi.python.org/pypi/Django/1.3.4 and pip installs it fine. pypi will always favor the latest version -Preston On Wednesday, October 17, 2012 4:37:12 PM UTC-7, Ross Poulton wrote: > > Django==1.3.4 doesn't appear to be on Pypi, is it likely to be there soon? > > On

Re: How to test patch

Thanks Jan for the contributions. I'll add a couple bits to Russ's excellent reply. I generally will run just a specific test, or a subset of the tests while developing the patch initially, this is much faster and can let you iterate much more quickly. Julien has put together a great tool for

Re: Possible deprecation of depth= in select_related

On Wednesday, November 7, 2012 1:48:09 AM UTC-8, Marc Tamlyn wrote: > > It seems there had been a little confusion as to exactly what the initial > proposal was. I had assumed it was just about removing the `depth` argument > but it was still possible to pass *no* arguments to get the implicit

Re: proposal: post-collectstatic signal

On Sunday, November 11, 2012 8:09:23 AM UTC-8, Justin Holmes wrote: > > My sense is that there are a growing number of use cases, but the one that > I currently have in mind is for django-coldbrew. I want to be able to > compile all the coffeescript in a project during the collectstatic

Re: Improved ajax support idea

On Saturday, November 24, 2012 9:11:17 AM UTC-8, is_null wrote: > > Hello everybody, > > > I can understand most of the points made here, expect just one, please > bare with me. Several hackers on this list stated that it has "obviously > not its place in Django". I don't understand why

Re: Django 2.0 - a case for a customizable pony

I think you can see one pilot of future decoupling with what is happening with the localflavors being split into separate repos - what we learn from this process will be valuable when/if considering decoupling other parts of Django. Another major step is the pretty-far-along schema migration

Re: Proposal: Django Admin Site and "pretty" app name

be done so with due consideration. -Preston On Friday, December 7, 2012 8:09:22 PM UTC-8, Russell Keith-Magee wrote: > > It's Preston Holme's app-loading branch - the Github branch Ramiro > referenced earlier in this thread. > > https://github.com/ptone/django/tree/app-loading > >

Re: Where is the authentication backend used?

On Sunday, December 16, 2012 12:39:13 AM UTC-8, Michael Anckaert wrote: > > Hello everyone > > I've tried getting my question answered by the folks over django-users but > when searching the archives I didn't feel that I would get a sufficient > response there. > This list is not the place

Re: #14633 - organization of settings docs

Looks good overall Tim - I do think that the primary reference should be kept alphabetical within core - this is most useful when you have a setting you need to look up. But I do think that a 'by-topic' cross reference index could also be very useful for discovering or learning about all

Re: About Understanding of source code

You might want to attempt to write a patch for an open issue - reading the source code is one thing and you may learn a bit. But dissecting the source code when you have the purpose to fix a problem, gives you a much better understanding of how things are working - as you NEED to understand

Re: Simplify the default project template

Aymeric, I think this is a great start. I particularly like inserting the links to docs in the form of docs.djangoproject.com/en/{{ docs_version }}/* I actually think these sorts of links could be added to admin.py and views.py as well. And at least one other could be made more specific (the

Re: Ticket #17093 -- quarantine global state in django.template

On Monday, January 28, 2013 9:30:44 AM UTC-8, Christopher Medrela wrote: > > Hello everybody. > > 1. I'm working on ticket #17093 [1]. You can see progress of work at > github [2]. It's about rewritting django.template so it won't use global > state. I wrote this post to tell you what I did

Re: The threat of the incompletely initialized django instance

On Saturday, April 13, 2013 5:03:16 PM UTC-7, Russell Keith-Magee wrote: > > > On Sat, Apr 13, 2013 at 11:53 PM, Pakal > wrote: > >> Hello, >> >> since version 1.2, there has been no changes about this issue, which >> still bothers me: >>

Re: The threat of the incompletely initialized django instance

On Monday, April 15, 2013 4:51:24 AM UTC-7, Pakal wrote: > > (my previous answer disappeared in googlemail, I hope that one will > survive the sending...) > > Thanks for the feedback, > > Preston, since ticket #3591 ticket and related discusions are partially > obsolete compared to your

Re: websockets

On Wednesday, April 17, 2013 2:31:48 AM UTC-7, Aymeric Augustin wrote: > > 2013/4/17 Daniel Swarbrick > >> On the pure Django side of things, one of the challenges I encountered >> was "IDLE IN TRANSACTION" hanging DB connections in the long-running >> WebSocket views.

Re: Changing deferred model attribute behavior

On Thursday, April 25, 2013 2:37:10 PM UTC-7, Anssi Kääriäinen wrote: > > On 25 huhti, 23:44, Alex Ogier wrote: > > On Thu, Apr 25, 2013 at 2:10 PM, Florian Apolloner < > f.apollo...@gmail.com>wrote: > > > > > On Thursday, April 25, 2013 7:06:06 PM UTC+2, Adrian

Re: Remote participation in sprints

On Wednesday, May 15, 2013 10:31:36 AM UTC-7, Daniele Procida wrote: > > On Wed, May 15, 2013, Shai Berger > wrote: > > >Hi all, > > > >This saturday and sunday there are supposed to be sprints in DjangoCon EU > in > >Warsaw. To my regret, I could not be present at

Re: Perception of attitude in tickets

On Wednesday, May 15, 2013 3:20:41 AM UTC-7, Luke Plant wrote: > > Hi Joe, > > > On 14/05/13 00:55, Joe Tennies wrote: > > As a fellow lurker (sorry I've been using Flask more recently), I think > > this could simply be fixed via a form response. Here's a simple example: > > > > This bug is

Re: Combine localflavor apps again

On Tuesday, May 21, 2013 5:51:11 AM UTC-7, Jannis Leidel wrote: > > Hi all, > > I'd like propose to combine all the django-localflavor-* packages - that > were moved out of contrib a while ago - into a new "django-localflavor" > package. None of the current maintainers would lose the commit

Re: RFC: "universal" view decorators

I've always been convinced this is the way to go: https://github.com/ptone/django/compare/mixin-decorators -P -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails fr

Re: Username Independence in Auth Forms

Really what you are proposing is an extension of the scope #19353, and I do feel that if the built in forms are to be made more usable with custom users, then both the hardcoding of auth.User and the username field should be addressed together. One thing not addressed in your authtools

Re: Change username field widget in AuthenticationForm based on USERNAME_FIELD

This seems like a reasonable change. I don't love the fact that the contrib.auth built in forms quasi support custom user models, as it leads to a less clear delineation about what parts of contrib.auth are tightly coupled auth the default User model.

Re: [discussion] communication guidelines in django

On Monday, September 9, 2013 3:30:41 AM UTC-7, Jorge C. Leitão wrote: > > > Specifically, my suggestion is to add a new section, probably in > https://docs.djangoproject.com/en/dev/internals/contributing/new-contributors/, > > on how to communicate in this project (which should be similar to

Speeding up test running

This is probably just a curiosity, but I was playing with ways to test the raw power of my new 8-core mac pro and was looking at how to apply this to testing. By using multiprocessing I was able to reduce the running of the current trunk tests from 6 minutes to 3. Because a test case needs to be

admin action breakage with changeset 12525

changeset 12525 added code that would prematurely exit from the reponse_action method of ModelAdmin if it detected that the "Go" button was not pressed. However this meant the "delete selected" action would not be performed because the view was being posted to from the confirmation screen. I've

re: Allow context processors access to current version of context

On Jul 4, 2:17 pm, Mitar wrote: > Hi! > > I have opened a ticket and would like some feedback on it. Do you > think it is a good idea? > > Ticket description: > > Allow context processors access to current version of context so that > they can change values and not just

Re: Inclusion of easy-thumbnails into Django Contrib

On Sep 16, 9:43 am, Patrick Altman wrote: > Another "community voice" contribution on this thread... > > I am of the opposite opinion.  I think it would be better for Django as a > whole if django.contrib approached zero.  In fact, I would have no problem > with seeing it

Re: Speed testing Django

On Sep 16, 12:43 am, Russell Keith-Magee wrote: > Do we have a continuous performance benchmark at present? No. > > Would it be worth having one? Certainly. > > There's a long standing ticket proposing just such a change: > > http://code.djangoproject.com/ticket/8949 >

is it time to start deprecating parts of contrib

At DjangoCon.us there was positive reception to Jacob's thoughts that Django core could be leaner - people liked the kernel analogy. Talk of reducing contrib has been around a long time. Per policy, it takes 3 minor versions to remove something from Django - near as I can tell, a

Re: RFC: "universal" view decorators

On Sep 21, 8:44 am, Donald Stufft wrote: > > The goal is to provide a Mixin for class based views, a decorator for class > based views, a decorator for methods, and a decorator for functions, all from > the same codebase. > > Currently I have the decorator for

Re: deprecation vs removal

On Oct 1, 9:10 am, Luke Plant wrote: > Hi all, > > The Django deprecation timeline [1] is very inconsistent in its usage of > the terminology 'deprecated'. For example, the 1.5 section often says > "is  deprecated" or "has been deprecated", when what they mean is "will >

Re: deprecation vs removal

On Oct 1, 9:10 am, Luke Plant wrote: > Hi all, > > The Django deprecation timeline [1] is very inconsistent in its usage of > the terminology 'deprecated'. For example, the 1.5 section often says > "is  deprecated" or "has been deprecated", when what they mean is "will >

login_required decorator and user.is_active (yes, again)

13125 was wontfixed by Jacob at the end of the summer, this relates to the login_required decorator not checking for user.is_active I had opened a duplicate ticket 16996 before catching it as a dupe I'm going to dredge this one back up. At a minimum, the current, counter-intuitive behavior of

Re: Cleaning up manage.py and import paths

On Oct 12, 7:59 am, Luke Plant wrote: >  $ mkdir foo >  $ cd foo >  $ hg init > >  # OK, now what am I going to put in it? Oh, a Django project. > > In fact, it might be good idea to encourage use of VCS by mentioning it. > If I remember SVN correctly, you would actually

Re: Check-in #7 / Multiple timezone support for datetime representation

I just did an initial scan through: https://bitbucket.org/aaugustin/django/compare/..django/django and this looks like a great piece of work. I do think a better label than "value" could be used for the thread.local for the current timezone, as this is really a thread global - something less

Re: TemplateResponse and loader should handle request

Just wanted to point those in this thread to this ticket: https://code.djangoproject.com/ticket/17093 Such a refactor of the template system as outlined could eventually incorporate some of these ideas. -Preston -- You received this message because you are subscribed to the Google Groups

'default' option for FileField - potential feature, bug, or lack of documentation?

This is somewhat of a design decision needed. Currently it seems that FileField doesn't do anything interesting with the "default" option to the field. It certainly could, but there is nothing in the documentation about what default means in the context of a FileField. It seems rather

Wiki page on global state

Following several discussions on IRC where I realized my understanding of the issue was far from complete, I did some reading and have done my best to summarize what I understand to be the current state of affairs: https://code.djangoproject.com/wiki/GlobalState The idea is that this page could

Re: Error in formfield in django.db.models.field

On Nov 13, 11:55 pm, Ric wrote: > the field class define this code > >     def formfield(self, form_class=forms.CharField, **kwargs): >         """ >         Returns a django.forms.Field instance for this database Field. >         """ >         defaults =

Re: Anonymous session carries over to authenticated session

On Nov 15, 10:44 am, Byron Ruth wrote: > > How would everyone feel about making this a setting, e.g. > SESSION_FLUSH_AT_LOGIN? If false, it would behave as it does now > otherwise it would flush the non-auth session. I do think the current behavior is worth a note in the

Re: load template tag library

On Nov 16, 1:12 am, Roald wrote: > Hi all, > > Can anybody explain why template tag libraries are loaded from > *inside* a template? The more I work with them, the more I get the > feeling that specifying which template tags are available in a > template should be specified

Re: Django 1.4 roadmap

On Nov 28, 4:40 am, Russell Keith-Magee wrote: > Any practical suggestions on how we can improve on this situation will > be gratefully accepted. Core has grown, but it seems to me there is a fair amount of cultural and procedural knowledge that more veteran core

Re: Documentation for CBV's?

Victor, This is an area where I've done some work, though there is still much to do. I started with https://code.djangoproject.com/ticket/16807 at the sprints, and need to wrap that up. As far as an outline of modular, relatively atomic changes to the docs that would be good to see: * The