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 o
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.
https://docs.djangoproject.com/en/1.5/topic
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 approach
c, ask and you shall receive.
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 a
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 bi
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
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 the conference. However
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 Holovaty wrote:
> >
> > >> A
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. I really ought to resea
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 current
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:
>> https://code.djangoproject.com/ticket/14916
>>
>> In s
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 so
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
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 them
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
setti
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 to
y have to
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/ap
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 wo
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 generic
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
>
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
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
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 Th
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 t
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 us
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
On Thursday, October 11, 2012 1:21:09 AM UTC-7, Russell Keith-Magee wrote:
>
>
> That said - could Django be faster? Sure. *Anything* can be improved.
>
> So, if you've got a suggestion, make it. If you think URL resolving is
> the source of the problem, propose a way to improve the speed of UR
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 ticke
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 forms
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 method:
>>
>>
>> http
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. S3
exposure
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
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 apprec
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 m
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,
>
> I'm
On Saturday, August 25, 2012 5:32:08 PM UTC-7, Russell Keith-Magee wrote:
>
> On Sat, Aug 25, 2012 at 4:24 PM, Aymeric Augustin
> > wrote:
> > On 25 août 2012, at 10:15, Russell Keith-Magee wrote:
> >
> >> We *could* just mark the affected tests that require auth.User as
> >> "skipUnless(use
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 settings in
>> Django,
>> > refactor the template
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 github
On Monday, April 2, 2012 8:35:28 AM UTC-7, Optimus Paul wrote:
>
> I've been running Django for quite a while without a "database", we
> use MongoDB, and it has worked well for us. We upgraded to 1.4 and
> found that suddenly a default database is required. Is there a reason
> for this? Or
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 bes
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 addres
On Monday, March 26, 2012 7:57:02 PM UTC-7, Nauho Zen wrote:
>
> I have reformated my proposal content on this group, any suggestion?
>
Thank your for taking the time to consider this project, hopefully you will
get some other feedback than just mine - I'm not sure that many projects
are wort
>
>
>
> 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 taught
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
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 above
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 members have not yet
transferr
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 in the view-code (or
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 docs - like you
say -
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 = {'required': not self.blank,
>
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 b
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 brain-dead
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
"Dja
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 amb
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 need to think about it
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
l
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
> be removed", which is wh
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
> be removed", which is wh
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 classes working, and the mixin
I saw enough +1 on deprecating databrowse that I've opened a ticket:
https://code.djangoproject.com/ticket/16907
further action can happen there.
-Preston
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email
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 PendingDeprecati
On Oct 4, 7:37 pm, Russell Keith-Magee
wrote:
> On Tue, Oct 5, 2010 at 10:02 AM, Laurent Luce wrote:
> > Thanks for those details. In case someone is using those commands and
> > is kind of happy with them, what would be the alternative? sql_reset =
> > sql_delete + sql_add but those commands a
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
>
> And there was a sprint
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 go away completely an
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 override them. This can b
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 o
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
66 matches
Mail list logo