Re: [discussion] communication guidelines in django

[ptone]

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 other 
> open source projects).
>

I think there is room for some small targeted improvements to that doc.

There is no link anywhere on that page to this mailing list - so the 
mention of it in the FAQ could be made a link.

This page has most of the current guidelines about when posting to this 
list is warranted (with links):

https://docs.djangoproject.com/en/dev/internals/contributing/triaging-tickets/

As far as other additions, the docs, like the code goes through a process 
of submitting a ticket and patch - so if you have an idea, I would start 
that discussion on the ticket tracker. Things don't usually require a 
pre-discussion here unless it is something contentious. I will say that you 
will need to consider the practical side that contributor docs need to be 
concise, too wide a scope of "how to communicate on the internet" will 
create its own barrier via sheer mass of docs, so understand there is a 
line to tread.

-Preston

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Change username field widget in AuthenticationForm based on USERNAME_FIELD

[ptone]

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/topics/auth/customizing/#custom-users-and-the-built-in-auth-forms

This doesn't warrant a backport for 1.6 though - as it is currently easy to 
override this in your own form, and 1.6 is in feature-freeze beta.

-Preston

On Friday, August 2, 2013 9:20:58 AM UTC-7, Anders Steinlein wrote:
>
> Hi all,
>
> I have implemented a custom user model that extends AbstractBaseUser, 
> where an EmailField is set as the USERNAME_FIELD. Logging in with a default 
> auth login view and AuthenticationForm works nicely, however, the username 
> field is still a CharField and thus rendered as a regular input field. I'm 
> using Django 1.6 where I was expecting a type='email' input field.
>
> How about we change the widget of the username field in 
> AuthenticationForms __init__ method based on USERNAME_FIELD? If yes, would 
> it be too late to sneak this into 1.6 given the new use of HTML5 input 
> types? I'm happy to provide a patch.
>
>
> *Anders Steinlein*
> *Eliksir AS*
> http://e5r.no
>
> E-post: and...@e5r.no 
> Mobil: +47 926 13 069
> Twitter: @asteinlein
>  

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Username Independence in Auth Forms

[ptone]

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 that is done in the 
current RegexField of the builtin form is handling regex validation of 
valid usernames - if your custom user requires some other sort of 
validation, you have to hook up some sort of custom validator like you've 
done, which seems like more work than just creating a custom form where you 
can define the fields as you need them. Also you may not need or want all 
REQUIRED_FIELDS in your form - this is a somewhat unfortunate label for 
this property - as it is really more specific to the management command 
prompts (ie, you can specify a field as required in the model, but not 
include it in that list, or vs versa).

A good step here might be a little DDD, write the docs to cover the cases 
where you may need to work around this proposed flexible approach - if it 
seems like it gets too complicated to explain, perhaps just leaving it 
documented as requiring the author to create new forms (which is more work, 
but maybe more straightforward) - may still be the best choice.

If this can be done in a way that maximizes win, I'm all for it, but if it 
is trading less work in some cases, for more in others, I'm less sure.

-Preston


On Monday, June 3, 2013 11:48:40 AM UTC-7, Gavin Wahl wrote:
>
> > The current code assumes that if you write a custom model, you'll also 
> write the corresponding custom forms.
>
> Right. This is what I am proposing be fixed.
>
>
> On Mon, Jun 3, 2013 at 12:31 PM, Aymeric Augustin <
> aymeric@polytechnique.org > wrote:
>
>> On 3 juin 2013, at 20:01, gavi...@gmail.com  wrote:
>>
>> > Some of the built-in auth forms only work on user models whose 
>> `USERNAME_FIELD` is `username`.
>>
>> Hi Gavin,
>>
>> The current code assumes that if you write a custom model, you'll also 
>> write the corresponding custom forms.
>>
>> You may want to have a look at 
>> https://code.djangoproject.com/ticket/19353 which describes the same 
>> problem (as far as I can tell).
>>
>> --
>> Aymeric.
>>
>>
>>
>>
>> --
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "Django developers" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/django-developers/XxaZ50SxPj4/unsubscribe?hl=en
>> .
>> To unsubscribe from this group and all its topics, send an email to 
>> django-develop...@googlegroups.com .
>> To post to this group, send email to 
>> django-d...@googlegroups.com
>> .
>> Visit this group at 
>> http://groups.google.com/group/django-developers?hl=en.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: RFC: "universal" view decorators

[ptone]

On Saturday, May 18, 2013 5:57:49 AM UTC-7, Marc Tamlyn wrote:
>
> 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 was subject to a 
> notable flaw which is that if multiple parts of the hierarchy have the same 
> decorator applied to them then the check gets done twice. Mixins are much 
> cleverer than this because of MRO, so we avoid that problem.
>
> Mixins however have their own issues - it's "harder" (for some definition) 
> to ensure that all of your top-level permission checking happening in the 
> correct order. That said, I am certainly veering towards implementing this 
> using mixins (for each piece of functionality).
>
> I'd really like to have a look at Donald's implementation, sadly it seems 
> to no longer be on github. Do you still have then code somewhere, or can 
> you explain the implementation idea?
>

Marc, 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 and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Combine localflavor apps again

[ptone]

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 bit. I'm 
> ready to do the heavy lifting for that. 
>
>
>  

>
> What do you think? 
>

Clearly the current fragmentation has proven unworkable, so I think there 
is only upside in trying this approach.

I think there needs to be someone who will coordinate the version bumps and 
releases to PyPI  - perhaps just document that it will be released n times 
per year on dates a, b, c, d - and just roll whatever changes make it in by 
those dates? Maybe you are volunteering for that as well ;-)

so +1 from me.

-Preston

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Perception of attitude in tickets

[ptone]

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 being marked as "WONTFIX" because  
> > 
> > Please realize that every API/feature added to Django needs to be 
> > maintained across several versions. The more public APIs that are 
> > exposed to users, the more difficult it is to refactor and add other 
> > features. This request currently lacks enough merit to exceed the cost 
> > it will add to the maintenance of Django. 
> > 
> > ... 
>
> I think we need something shorter that developers can remember, i.e. 
> that we can type ourselves without resorting to a canned response, 
> 1which can be off-putting, especially if some of it doesn't apply. 
>
> So I've gone ahead and created a wiki page, which can be longer and more 
> friendly, and require a shorter response on the actual ticket, something 
> like this: 
>
>   Closing as WONTFIX because ... 
>
>   If you want to persuade us otherwise, please bring it up on the 
>   DevelopersMailingList 
>
> The page: 
>
> https://code.djangoproject.com/wiki/DevelopersMailingList 
>
> That's my draft, feel free to edit. We don't want it too long, as that 
> is intimidating by itself, but some of the points you make might would 
> be good additions 
>
> What do people think? 
>

Luke,

Thanks for taking a stab at improving things, I think one thing is not in 
question - everyone is willing to make improvements best we can.

I wonder if a slightly more concise version of this should be added to the 
triaging docs instead of a wiki page (fine place to draft it though).

https://docs.djangoproject.com/en/dev/internals/contributing/triaging-tickets/#closing-tickets

I feel that the wiki pages aren't very discoverable, and unless we are 
talking about patching trac to include this, such a comment won't carry the 
official weight of being in the project docs.

One line I do feel needs a tweak:

"while the suggestion is good in theory, it lacks enough merit to exceed 
the cost it will add to the maintenance of Django"

The truth is, there are some suggestions that are just flat out 
incompatible. I'm fine to be gracious and thankful for the time someone 
takes to offer a suggestion, but that doesn't mean that all suggestions are 
automatically meritorious.

Saying that in as kind a way as possible is tough - but only fair.

-Preston

 

>
> Luke 
>
> -- 
> "I asked mom if I was a gifted child. She said they certainly 
> wouldn't have paid for me." (Calvin and Hobbes) 
>
> Luke Plant || http://lukeplant.me.uk/ 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Remote participation in sprints

[ptone]

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, 
> >I may 
> >be able to set aside the two days and participate in the sprint remotely. 
> > 
> >Will there be an effective way to do this while communicating with the 
> >developers present at the sprint? IRC? Google hangout? IM? 
>
> #djangocon and #django-sprint on irc.freenode.net 
>
> Daniele 
>
>
Indeed, note that the bulk of the sprinting will be during Central European 
Time, UTC +1, also a reminder that #django-dev is another IRC channel that 
is always available to seek feedback on for contributions to Django - not 
just during conferences and sprints.

-Preston

 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Changing deferred model attribute behavior

[ptone]

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: 
> > 
> > >> Also, I should mention that this should be *optional* behavior, as 
> the 
> > >> current behavior is reasonable for the common case. The API for 
> specifying 
> > >> this "load everything" behavior is a separate discussion. Perhaps a 
> keyword 
> > >> argument like: User.objects.only('username', loadall=True). 
> > 
> > > I could imagine a Meta attribute which introduces so called "deferred 
> > > groups" like SA has 
> > >http://docs.sqlalchemy.org/en/latest/orm/mapper_config.html#deferred-..., 
>
> > > accessing one column of a group will load all columns of the group. 
> Not 
> > > sure if we want that level of control, but I thought it would be worth 
> to 
> > > look what SA can do in this regard. 
> > 
> > I think groups are a very good abstraction for this problem. The two 
> common 
> > cases are probably "Load this column alone, because it's potentially a 
> big 
> > honking blob of text or binary" and "Load everything we don't have on 
> this 
> > object, because we are actually using it actively". Groups let you solve 
> > both problems flexibly. The downside is that they might not be very DRY, 
> > having to repeat group="everything" over and over if you just want to 
> load 
> > it all on first access. 
>
> +1 to this approach. 
>
> IMO load everything is a better default than one field at a time. When 
> deferred field loading happens something has already gone wrong. In 
> almost every case it is better to try to minimize the amount of 
> queries than the amount of loaded fields. The cases where you have 
> deferred multiple fields, need only one of them later on, and there is 
> a field that you can't load due to potentially huge value are 
> hopefully rare. 
>
> But, I don't really care too much. If the objects come from DB queries 
> instead of something like the use case of Adrian then if you end up 
> doing deferred field loading you have already failed. So, even an 
> error on deferred field access would work for my use cases of defer... 
>
>  - Anssi 
>

A couple just quick observations.

defer and only are tasks/concepts used when doing a query based on 
knowledge of your dataset - adding them to the model itself expands the 
number of places where this concept is considered. This has some good and 
some bad.

What happens if you have defined a group on a model, and use only a single 
field for 'only' in a QS? Does it fetch the only one I've asked for, or 
does it trigger the group?

Why couldn't one just defined the group in the code using .only() and pass 
all the fields at the time you want.

In Adrian's case, there will always be at least 2 DB hits - one could 
define the group of "lazy fields" and do something like:

>>> u = User.objects.only(*lazygroup).get(id=u.id)

I guess for something like that to be more practical, we need to expose 
something on the model instance that makes it easy to see what fields are 
currently deferred? Something that could easily check whether the second 
load had been done, and the lazy fields were available or not.

These are mostly observations, I'm not against adding the idea of groups to 
the model definition, but do think that if it can be solved at the scope of 
the QS usage, where .only() and .defer() currently are used, that would be 
better - one less reason to check the model definition to see how it was 
set up.

-Preston

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: websockets

[ptone]

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 research a more elegant solution to 
>> this, but for now I'm just doing all my DB queries early in the view, then 
>> fairly brutally closing the DB connection before entering the long-running 
>> WS poll loop.
>>
>
> The new transaction management introduced in Django 1.6 may help with this 
> problem, but it isn't a good idea not to maintain one database connection 
> per websocket on a website with more than a few users anyway :)
>
> I believe you need a connection pooler and asynchronous database I/O if 
> you want to talk to the database from a websocket handler. I haven't looked 
> at this in detail.
>

A difficulty will be moving beyond simple demos to something that can be 
more widely and immediately useful and allow for moderate scale.

The first real challenges happen in scaling beyond one app server process, 
as you now start dealing with arbitrating state change collisions. These 
are less of an issue in more atomic, transaction based request response 
designs - where you expect state may change between page refreshes.

I've got a bunch more research to do, but I've been making some notes in 
this area - some fun geek concepts that are potentially involved: paxos, 
operational transformation, software transactional memory, vector clocks 
etc.

Relying only on the ORM and stock backends will be challenging to support 
distributed concurrency.

Here is a micro manifesto on my thoughts of Django and realtime:

Many/most sites don't need all pages/views to be realtime backed, so for 
many projects traditional Django usage will continue to work just fine, 
this is Django's heritage and strength. Making use of Django components 
(ORM, templates?) in a realtime context should be facilitated.

Django should continue to focus on making the common cases relatively easy, 
while not getting in the way of the more elaborate or complex needs.

Django shouldn't ship any stock solution initially in core, and if/when it 
does ship something, it should be built on clean and fundamental 
 abstracted layers that allow others to continue to innovate without 
needing to reinvent the truly common low level parts.

In my own digging, I haven't found anything so far at the low level that 
would need to be added to Django itself. The possible exception is the 
predicate stuff, and I do still hope to get that work in after Anssi's 
lookup refactor work is completed. 
 
There is the issue of how much model logic gets moved to Javascript, and 
how integrated vs loosely coupled the JS should be from the Python code. On 
one end would be just standardizing on a wire protocol like Meteor's DDP or 
something similar. At the other end would be building on top of that and 
having something that let you declare a ModelForm like class in Python, 
which when used via a special template tag, would magically become a client 
side representation in the browser and automatically set up all the 
realtime data exchanges to the Django model. Those obviously don't have to 
be mutually exclusive ideas - in fact the latter should be based on 
something like the former.

So we need to continue the period of exploration - I do think Tulip looks 
promising enough to start planning a future on - but there will be many 
design components that won't need to exist at the tulip calling level, or 
would be relatively easy to port.

To paraphrase something Jacob said after the Meteor keynote at DjangoCon `I 
know that in  years, I'll be using something that works like Meteor - I 
hope that something can be Django'.

-Preston

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: The threat of the incompletely initialized django instance

[ptone]

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 works, may I just know if your current 
> evolution will automatically reproduce the auto init() of the devserver 
> (i.e loading models from each installed app) ? Because being able to use 
> the same several times, or to set its human name, are cool features, but 
> imo the most critical part at the moment is that difference between dev and 
> prod inits, which can bite hard the unwary djangoer.
>
>
The approach would be more along the lines of defining a place that is 
guaranteed to run at as distinct a time as possible in the startup process 
- rather than trying to guarantee that all code gets imported in some 
coherent way with the aim to trigger module level import code. The latter 
is what we want to move away from.

-Preston
 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: The threat of the incompletely initialized django instance

[ptone]

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 summary, the django dev server loads models.py of every INSTALLED_APP, 
>> and thus (somehow) ensures proper initialization of models and signals. 
>>
>> But in production, web servers do NOT load more than the strict minimum 
>> required by the requests they serve, so it opens the door to very subtle 
>> and deadly bugs, where the first requests of every new django process might 
>> miss a good part of the whole workflow, because miscellaneous "hooks" have 
>> not been registered properly.
>> Doesn't this advocate a global import of all installed_apps' models.py, 
>> at process setup ?
>>
>> And more generally, people have no idea where to put their django setup 
>> code, so there are tons of forum threads and workarounds about this, using 
>> mod_wsgi's start script, or code in urls.py/settings.py, or even 
>> dedicated on-shot middelwares (
>> http://www.allbuttonspressed.com/projects/django-autoload).
>> Wouldn't it be worth offering a place, in a project and/or in each django 
>> app, which will be called AFTER all models/signals are initialized, but 
>> BEFORE the first request is served ? Same behaviour as the "fake 
>> middleware" trick, but without its ugliness.
>>
>
> The reason there hasn't been any update to ticket #14916 is that it has 
> been closed as a duplicate of #3591. Which it is.
>
> The ticket title may not make this obvious, but if you read the full 
> ticket history and/or search for #3591 on mailing lists, you'll quickly 
> find mention of an "app refactor". The purpose of the app refactor is to 
> provide a wrapper object that can encompass application-specific 
> configuration -- including things like application startup logic and signal 
> registration -- and to provide a guaranteed and consistent order for 
> startup.
>
> There are some draft patches floating around for the app refector; as I 
> understand it, the code was *almost* ready to be merged for 1.5, but there 
> were some last minute concerns, so it was postponed. I don't think there 
> have been any major discussion since then.
>

The work continues.  Jannis and I continue to work on this project - and a 
set of defined "startup" hooks are one of the key features. The work will 
be scaled back in scope from some of the past ideas floated on #3591, some 
were technically not feasible, and others can be added in with later 
additions.

At the DjangoCon sprints in Sept Russ and I did a big review of the branch 
that I had worked on last summer. There were some productive conversations 
with other core devs at that time.

More details to follow hopefully in the following weeks-months.

-Preston

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

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

[ptone]

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 far, what issues I deal 
> with and to discuss them. I hope that we will gain valuable experience in 
> splitting Django into smaller parts. 
>

While I agree with Carl that there is some danger of this being a change 
that flirts with "is it worth it" in the specific sense - there is a 
certain value in exploring the process of making Django less monolithic, 
and in the long run I think Django HAS to go that way. So bravo for taking 
this on. I've only skimmed the code so far - but will try to make a couple 
comments.


>
> 3. The goal is to write TemplateEngine class to encapsulate global state. 
> For backward-compatibility, there will be one global instance of 
> TemplateEngine and all functions like loader.get_template should delegate 
> to the instance. Tests need to be rewritten. 
>

A global instance is probably unavoidable, but by itself doesn't result in 
less global state - it just wraps it all in one global object. Functions 
that need Engine state should be passed an engine instance explicitly 
wherever possible - not importing default_engine at module level. 


> 4. What I did so far? I created base.TemplateEngine class and 
> base.default_engine global instance. Some functions (mostly from loader 
> module: get_template, find_template, select_templates and from base module: 
> add_to_builtins, get_library, compile_string) delegates to appropriate 
> methods of default_engine. I also partially rewrote tests (only 
> tests/regressiontests/templates/tests.py) so they don't use default_engine 
> directly. 
>

Since your TemplateEngine class represents the current snapshot of features 
 you may want to make rename your current TemplateEngine to 
BaseTemplateEngine, and then call TemplateEngineWithBuiltins just 
TemplateEngine.

Any internal method that uses default_engine needs to allow for an explicit 
engine instance, or be deprecated with a suggestion to use an alternate API 
that can support an explicit engine. Anything much less is just shuffling 
chairs without actually removing the dependency on global state.


> 5. The one issue is that the engine is needed everywhere. For example, 
> consider creating base.Template instance. At the time of creation the 
> template source is being compiled. The template may load a library, so the 
> compilation cannot be done without list of all libraries defined in the 
> engine. To sum up, we cannot just type Template(source), because this 
> depends on template engine. I solved this issue by passing engine instance 
> to Template constructor. In order not to break everything, I renamed 
> Template class to _Template and created function called Template that does 
> "return _Template(default_engine, **kwargs)". 
>

could this just be handled with a kwarg of engine=default_engine?


>
> 10. As I said I'm trying to rewrite tests from tests.py file so they won't 
> use the default engine. There left some sources of dependency on default 
> engine. One of them are include tags in tests which load templates at the 
> time of importing module [3] (or the source of problems is in 
> base.Library.inclusion_tag?). Another one are template.response module [4] 
> and all other test files (i. e. callables.py, custom.py). I didn't dig into 
> these issues deeply yet since I wanted to publish my results and take some 
> feedback. 
>

The shim point for all of these IMO should be your get_default_engine 
function - and although the following suggestion requires some more 
thought/discussion - the default_engine instance might as well live on the 
settings object, where the setting itself could be the default engine 
class. Killing the global state doesn't mean killing the state - but it is 
a process of gathering it from all the scattered places, and consolidating 
it into piles, then gather those piles into one (or very few) pile and 
creating that only in the entry point(s) so that it is in fact local state. 
If there is a candidate for the one pile, it is settings. But I'm waxing 
now ;-)

The testing environment is both a great design testbed, and eventual 
benefactor of reduced global state. It will help surface all the template 
related API that is making global assumptions, and those places will need 
to be modified in a way to take an explicit engine instance, using the 
default if one is not passed.



> 11. A small issue is test 
> regressiontests.views.tests.debug.DebugViewTests.test_template_loader_postmortem.
>  
> The problem is in method 
> django.views.debug.ExceptionReporter.get_traceback_data. It uses 
> template_source_loaders global state which was removed. We can just use 
> default_engine. I wonder when a Django developer uses a custom template 
> engi

Re: Simplify the default project template

[ptone]

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 "see documentation" 
note for DATABASES).

This combined with Tim's recent doc improvements will result in some solid 
improvements for settings.

-Preston

On Monday, January 28, 2013 1:54:46 PM UTC-8, Aymeric Augustin wrote:
>
> Hello,
>
> I know I'm treading in contentious territory, but -- I figured I'd try 
> anyway :)
>
>
> We regularly hear complaints about the default settings file. I've noticed 
> the following patterns:
>
> 1) Beginners
> a) Frustration. They skim the comments, tweak the settings and it doesn't 
> work as expected. The comments are fairly detailed, but they don't provide 
> context like the docs.
> b) Confusion. There's too much information at once. "What am I supposed to 
> configure? Is STATICFILES_FINDERS important?"
>
> 2) Experienced users
> a) Boredom. "Why do I have to make the same changes in every new project 
> to enable the admin?"
> b) Doubt. "Is using STATICFILES_DIRS the current best practice? It's in 
> the default settings file."
>
> Custom templates have improved the situation for advanced users, allowing 
> us to focus on making the default project template as simple and 
> straightforward as possible.
>
>
> For this purpose, I've created a branch with the following changes:
>
> 1) Add links to the documentation. Remove comments. Documentation goes in 
> the docs, not in comments.
> 2) Keep only the most relevant settings in the default settings.py.
> 3) Various improvements along the way.
>
> Compare view: 
> https://github.com/aaugustin/django/compare/simplify-project-template
>
> Right now the branch shows that the default settings file can be trimmed 
> to 80 lines. I'm reasonably satisfied with the project and app template. I 
> still have to synchronize the docs with the changes, especially the 
> tutorial.
>
>
> Questions:
> - In general, do you think this is a good idea? Or am I misguided?
> - In detail, are there commits in the branch that seem wrong with regard 
> to the current best practices? I don't claim to know them all.
>
>
> Thanks,
>
> -- 
> Aymeric.
>
> PS: I've purposefully avoided the concept of BASE_DIR because I feel we 
> can't reach a consensus on this right now.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: About Understanding of source code

[ptone]

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 in 
order to properly fix/extend them. Just reading through it allows you to 
too easily skip over things you don't really understand.

FWIW,

-Preston


On Sunday, January 6, 2013 8:57:23 PM UTC-8, Mayur Patil wrote:
>
> Hello there,
>
>   I want to understand how to get deep insight into Django code?
>
>   Thank You.

-- 
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-developers/-/kV3hLOhjrwoJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: #14633 - organization of settings docs

[ptone]

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 
settings.  Such an index could be at the bottom of the page, and include 
the topics suggested, as well as the deprecated settings - settings that 
apply to more than one topic could be duplicated in such an index, and 
deprecated settings could be duplicated under a topic, and under a 
"deprecated" heading in such an index. This is a case where more 
organization is only good, and there is no reason we have to choose an 
either or.

-Preston


On Monday, January 7, 2013 1:02:49 PM UTC-8, Tim Graham wrote:
>
> I'd appreciate feedback on 
> #14633- "Organize settings 
> reference docs". So far I've broken out the settings 
> for each contrib app into their own sections. The one comment on the pull 
> request suggests further breaking up the settings listed in the "Core 
> settings" section, e.g. logging, caches, globalization (i18n/l10n), email, 
> file uploads/media, storages, and security. I don't feel strongly about 
> this proposal: it could be useful, but it could also be ambiguous as to 
> which section a particular settings belongs in.
>
> The pull request also suggests organizing the default settings.py in a 
> similar fashion.  While it may be outside of the scope of this ticket, it 
> could be worthwhile to discuss that suggestion as well.
>

-- 
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-developers/-/6cpcbfEsyzQJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Where is the authentication backend used?

[ptone]

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 attempt second tier support requests, it is 
limited to the development of Django itself. Even custom auth backends are 
a use of Django, not development of Django, albeit advanced.

This topic is in fact covered in the docs
https://docs.djangoproject.com/en/dev/topics/auth/#specifying-authentication-backends

-Preston

-- 
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-developers/-/s9wJYoUyiuEJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

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

[ptone]

Just to add a quick update here.

Not much has happened on the branch since Djangocon - but we had some 
valuable discussions. I'm hoping to get some time over the holidays to get 
this back up to a more current form.

Russ and Karen gave some great feedback, and there is some straightforward 
but somewhat tedious cleanup - mostly involving backing out the metaclass 
pattern for app objects.

The crux will be a way to introduce this in form that provides some 
limited, targeted benefits such as the verbose app name, without opening 
too much of a pandora's box of enabling a range of unintended "features" 
centered on abuse  of the app-cache.

As Russ said - this has always had the potential to be a ginormous 
bike-shed, and if any Django specific interfaces on a application class 
that go beyond "its just a Python class" are to be introduced, they 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/app-loading
>
> Yours,
> Russ Magee %-)
>
> On Sat, Dec 8, 2012 at 12:02 PM, Pedro J. Aramburu 
> 
> > wrote:
>
>> Which one is the branch? I can't seem to find it.
>>
>> On Friday, December 7, 2012 10:41:16 PM UTC-3, Russell Keith-Magee wrote:
>>
>>>
>>> On Sat, Dec 8, 2012 at 9:29 AM, Pedro J. Aramburu >> > wrote:
>>>
>>>> Ramiro, I've read the ticket but it seems stuck. I just want it to go 
>>>> forward because I think it's a major UI/UX issue for non-programmers the 
>>>> lack of "pretty" app names. But I want it to be done right with a proper 
>>>> app metadata handling.
>>>
>>>
>>> You won't get any argument from me, or anyone else in the core team. 
>>> This *is* an important issue. The problem is that the issue *isn't* 
>>> entirely cosmetic. It's very easy to say that we "just" need to attach a 
>>> configurable name to applications -- but in order to do this, you need to 
>>> address the more fundamental issue of what an application *is*. In having 
>>> that discussion, you hit a whole raft of *other* problems that are related 
>>> to Django's definition of apps. That's why this patch has taken so long to 
>>> come to fruition.
>>>
>>> The thing is that there isn't any consensus about the way to go so I'm 
>>>> terrified of starting with my ideas without anyone accepting them and also 
>>>> because I don't know if anyone is already working on them (as the tickets 
>>>> are open) but there seems to be no constant activity on them. That's why I 
>>>> need some guidance from someone experienced with the process.
>>>>
>>>
>>> There's plenty of consensus about the broad strokes. The disagreement is 
>>> about the little details. There's no constant activity because it's a big 
>>> problem; that means we've gone through multiple maintainers over time, and 
>>> the activity level rises and falls as attention is drawn onto other 
>>> priorities (such as bug fixing for the 1.5 release).
>>>
>>> I last looked at Preston's Github branch during the DjangoCon US 
>>> sprints, and at that time, it was extremely close to being ready for 
>>> merging -- it mostly just needed eyeballs, testing, and documentation. If 
>>> you want to help out, I'd suggest grabbing that code, and trying to (a) get 
>>> it up to date, and (b) testing it with your own projects, and © helping to 
>>> stub out documentation.
>>>
>>> I'd very much like to see this patch land as part of the 1.6 cycle -- 
>>> App name translations aren't a big issue for me personally, but all the 
>>> other related features -- such as having a reliable startup sequence, a 
>>> place for application-level configuration, and a place for one-time 
>>> initialisation -- *are* an issue for me, and fixing these problems are all 
>>> side effects of adding an application configuration object.
>>>
>>> Yours,
>>> Russ Magee %-)
>>>
>>  -- 
>> 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-developers/-/KqGTJ8TPPgcJ.
>>
>> To post to this group, send email to 
>> django-d...@googlegroups.com
>> .
>> To unsubscribe from this group, send email to 
>> django-develop...@googlegroups.com .
>> For more options, visit this group at 
>> http://groups.google.com/group/django-developers?hl=en.
>>
>
>

-- 
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-developers/-/cFPu8nmwE1cJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Django 2.0 - a case for a customizable pony

[ptone]

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 work from 
Andrew, which will allow for the potential of schema changes in upgrade 
scripts.

I disagree that working on cleanly factoring and decoupling components "in 
place" isn't worth doing, in fact when you can add backends/plugability 
somewhere, and ship a BC version as the default - you've just fixed one of 
your "underlying problems"

See for example:

https://code.djangoproject.com/ticket/17093

There is no reason changes like that have to be part of a "2.0" departure, 
and in general talking about anything as being 2.0 related ultimately feels 
more distracting than productive.

Anyway - as you say - progress has been made - lets do more of that ;-)

-Preston

On Tuesday, December 4, 2012 11:14:50 AM UTC-8, Yo-Yo Ma wrote:
>
> This morning read the SQLAlchemy proposal made by Luke Plant in June. I 
> then decided that this would be a good time to rant about abstraction, 
> extensibility, and decoupling.
>
> Background
> 
>
> For years, Django has been forced to deal with most implementation issues 
> from within, including the ORM, templates, etc. Even things like JSON 
> support and basic timezones (for the new timezone module) were or are built 
> right into the framework, in order to handle heterogeneous environments and 
> Python versions, and to minimize external dependencies. This strategy 
> contributed to the success of Django, in part because finding nice, well 
> supported libraries was tough, and installing dependencies was too.
>
> The Python community has grown and its processes have matured nicely. 
> Nowadays, for a given problem, there are typically multiple solutions, many 
> listed on services like www.djangopackages.com. Installing packages is 
> easy, thanks to things like pip, and pypi. Collaboration is simpler, thanks 
> to services like GitHub. This trend can be summarized as abstraction, which 
> is a good thing. Handling things at a proper abstraction level is always a 
> time and heartache saver, and is of course the reason for using a framework 
> like Django in the first place.
>
> The Problem
> -
>
> Solving too many problems from the top down, and coupling things too 
> tightly in a project leads to code rot, because implementations all have to 
> be written by somebody who is intimate with many other parts of the 
> framework, then they have to be vetted others who are intimate with many 
> parts of the framework, and then the code has to be maintained. Coupling 
> becomes an inevitability, simply because it is possible. Backwards 
> compatibility becomes more and more difficult and costly to maintain, and 
> prohibits growth. Projects built atop the framework eventually run into 
> problems for which the solution is to make changes to implementation 
> details (usually via subclassing, but in some cases, via monkey patches), 
> which leads to code debt in a project, and subsequent contention in the 
> community when implementation details are changed in a way that breaks 
> backwards compatibility for those "power users".
>
> This means that the issue of "We can't do that because it'll break things" 
> isn't really the problem that Django has. It's a symptom of another 
> problem, which is that Django is not nearly extensible enough (it's parts 
> are not pluggable enough, and or are not well enough abstracted to be 
> quickly changed and/or moved).
>
> So, what?
> -
>
> So, Django has evolved toward being a more decoupled, less monolithic 
> framework over the past couple years (e.g., the removal of auth's coupling 
> to things like messages, customizable user models, etc.), but there is a 
> lot left to be desired. I consider a Python web framework to be a minimum 
> of A) request handling, B) URL routing to something callable (a view), and 
> C) response handling. However, certain other things are good ideas to bake 
> in, such as cookie handling, security related features (CSRF, click 
> jacking, etc.), and probably a few others. Anything else should be 
> completely pluggable, and completely decoupled from everything else.
>
> Some examples which make me smile:
>
> Sessions - 
> Cache - includes support for plugging in a back-end and only defines a 
> simple interface (cache.set, cache.get, etc.)
> Mail - includes support for writing / plugging the back-end of your 
> choice, only defines a simple interface (send_mail, send_mass_mail, etc.)
>
> Some examples which make me sad:
>
> Templates - unpluggable (importing a third party template library and 
> using it in your view is not plugging it in, since this isn't compatible 
> with 3rd party or contrib apps)
> ORM - I'll defer to the complexities that ar

Re: Improved ajax support idea

[ptone]

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 non ajax views 
> would have a their place in django, and ootb ajax support would not. But 
> I'm really curious.
>
> It would be great if someone could elaborate on that, because from what I 
> understand:
>
> - django has generic views, you are free to use them, you can use your 
> own, or you can use those that are provided by external apps,
> - if django had generic views with ajax support, you would be free to use 
> the ajax support, or use your own, or use those that are provided by 
> external apps.
>

One distinction is that generic views don't provide anything in the way of 
default templates.  They help with the data pattern on the Django side, and 
you choose how it goes to the browser in a template.  In an ajax response, 
the data is returned directly to the JS code in the browser.  Because 
different JS frameworks may expect data in different arrangements - you end 
up coupling the generic ajax code to some expectation set by the browser JS 
code.

More relevant to such an effort would be whether there was anything in the 
CBVs that stood in the way fundamentally. The current thought is that there 
isn't, but one couldn't be sure until there was an attempt.

-Preston

-- 
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-developers/-/VGMl8ei_U-gJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: proposal: post-collectstatic signal

[ptone]

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 
> process.  Currently, we have a management command, "collect_coldbrew" - but 
> I'd like to allow users to have this occur automatically during 
> collectstatic.
>

Why not have your collect_coldbrew wrap collectstatic - then you have one 
command?

While there are parts of the staticfiles API that should probably be opened 
more some day - for now it is a relatively private API.  What Bruno has 
suggested uses technically private API.

Such a signal as proposed would seem to be a way around 
https://code.djangoproject.com/ticket/15213 - and introducing a signal for 
such a narrow use is gonna be the wrong way to address this.

There are a couple other alternatives:

A custom storage backend (public API) that does the compiling before 
writing the file (this could feel unintuitive).

or use django-compressor which handles this action via template tags:

http://django_compressor.readthedocs.org/en/latest/settings/#django.conf.settings.COMPRESS_PRECOMPILERS

-Preston


> I'm not sure if the best timing for the signal is at the end of the 
> complete collectstatic process or at the end of each iteration (ie, one 
> signal for each static directory that django finds).
>
>
> On Sun, Nov 11, 2012 at 4:55 AM, Alex Gaynor 
> > wrote:
>
>> What's the use case?
>>
>> Alex
>>
>>
>> On Sat, Nov 10, 2012 at 8:48 PM, Justin Holmes 
>> 
>> > wrote:
>>
>>> Currently, our only built-in management signal is post-syncdb.
>>>
>>> I propose (and, notwithstanding objection, will build) 
>>> post-collectstatic.  
>>>
>>> Is this reasonable?  Is there another, less invasive way to hook logic 
>>> into collectstatic?
>>>
>>>
>>> -- 
>>> Justin Holmes
>>> Chief Chocobo Breeder, slashRoot
>>>
>>> slashRoot: Coffee House and Tech Dojo
>>> New Paltz, NY 12561
>>> 845.633.8330
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Django developers" group.
>>> To post to this group, send email to 
>>> django-d...@googlegroups.com
>>> .
>>> To unsubscribe from this group, send email to 
>>> django-develop...@googlegroups.com .
>>> For more options, visit this group at 
>>> http://groups.google.com/group/django-developers?hl=en.
>>>
>>
>>
>>
>> -- 
>> "I disapprove of what you say, but I will defend to the death your right 
>> to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
>> "The people's good is the highest law." -- Cicero
>>
>>  -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers" group.
>> To post to this group, send email to 
>> django-d...@googlegroups.com
>> .
>> To unsubscribe from this group, send email to 
>> django-develop...@googlegroups.com .
>> For more options, visit this group at 
>> http://groups.google.com/group/django-developers?hl=en.
>>
>
>
>
> -- 
> Justin Holmes
> Chief Chocobo Breeder, slashRoot
>
> slashRoot: Coffee House and Tech Dojo
> New Paltz, NY 12561
> 845.633.8330
>  

-- 
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-developers/-/ae2y0-BLq4UJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Possible deprecation of depth= in select_related

[ptone]

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 
> "follow everything" behaviour. In fact Luke was suggesting that we remove 
> this behaviour as well, requiring the user to pass in some field names. 
> This has various knock on effects within Django (mostly in the admin), but 
> they're not particularly difficult to fix. My concern is that I've seen 
> "blank" select related calls quite often in the wild (although never seen 
> depth=), so it may break a few more things. Then again, blank select 
> related calls are pretty risky, and although it's not documented are 
> actually equivalent to `depth=5`. I'm not really against deprecating this 
> but I thought it should be made clear exactly what the deprecation was (and 
> we should get this sorted out for 1.5).
>
> Marc
>
>
I agree deprecating select_related() in favor of select_related(*fields) is 
a whole 'nother ball of wax over just deprecating depth kwarg (which has 
now been done).

While using *fields explicitly may be the better way to go in most cases, 
and we can document that more strongly - it feels like eliminating the 
historically simple version, which can still be useful in simple, shallow 
cases goes a bit far - but I'm more of a -0 than -1 on it.

-Preston

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 Tamlyn  wrote:
>>> > If anyone has any major objections to the deprecation of depth, you 
>>> should
>>> > shout now. If there are no objections and people think it's ok to push 
>>> this
>>> > deprecation in now, then I'll get a patch done on Monday.
>>>
>>> No objections here. Depth was a simple protection we added before we
>>> got select_related(*fields); the *fields form is a ton more useful. +1
>>> on deprecating depth.
>>>
>>>  
>> Sounds good to me too. +1.
>>
>> Russ %-)
>>
>

-- 
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-developers/-/6Fj-Dft7feQJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: How to test patch

[ptone]

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 running the full test suite  - 
allowing you to test more python versions including the GIS stuff:

https://github.com/jphalip/djangocore-box

Finally - note that for some work, you will occasionally hit test 
interaction issues, where global state causes unintended failures to happen 
in apparently unrelated tests. Hopefully this won't happen, but if it does 
and you're stumped, reach out for help.

-Preston

On Saturday, October 27, 2012 4:33:35 PM UTC-7, Jan Bednařík wrote:
>
> Hi all,
>
> I'm using Django for more than four years and last week I started 
> contributing.
>
> In docs about contributing I didn't find how detailed should be my testing 
> while I'm writing or reviewing patch? Is enough to run tests only for 
> patched module? Or should I run full test suite for each patch? Which 
> combinations of Python versions and database engines are mandatory?
>
> So far I was running Python 2.7 & SQLite3 for development/review testing 
> of module. Python 3.2 & SQLite3, Python 2.7 & PostgreSQL for patched module 
> and in the end Python 2.7 & SQLite3 full test suite (with selenium, etc.). 
> Is this workflow ok?
>
> Jan Bednařík aka Architekt
>

-- 
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-developers/-/8OZSXc4ujgoJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

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

[ptone]

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 Thursday, 18 October 2012 09:38:49 UTC+11, James Bennett wrote:
>>
>> Django 1.4.2 and 1.3.4 have just been released in response to a 
>> security issue reported to us. 
>>
>> Details are here: 
>>
>> https://www.djangoproject.com/weblog/2012/oct/17/security/ 
>>
>> Everyone is encouraged to upgrade. 
>>
>

-- 
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-developers/-/AHesja4nyhQJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: contrib.markup deprecation

[ptone]

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 thought. 
>

That seems entirely reasonable, but if it is the convention, I wasn't aware 
of it - sorry.  The ticket got some relatively quick traction just in trac.

This goes to the heart of defining the purpose, current and future, of 
contrib.

I believe in shrinking in contrib - but I do think it has to be done 
mindfully.

There was some *brief* conversation at DjangoCon about phasing 
contrib.markup out in a fashion similar to localflavor - but it seemed to 
end unresolved in a discussion of submodules, namespace, and other 
imperfect solutions.

On this issue of markup I do think the answer should lie in a strong 3rd 
party option. 

 I agree we could provide better migration docs and maybe we shouldn't do 
an accelerated deprecation to give a better migration option the chance to 
be developed?

-Preston

-- 
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-developers/-/xprtiUsPQv4J.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Update on localflavor move

[ptone]

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 used for 
localflavor and we should delete that component.

contributions to localflavor repos will go direct to pull requests - most 
of them no warranting "issues/tickets"

I'll volunteer to update our contributing docs on these points including 
our CONTRIBUTING root level doc - which is highlighted by github when pull 
requests are opened. 

-Preston

-- 
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-developers/-/0fSXdLtnTe4J.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Django 1.5: AUTH_USER_MODEL and GeoManager

[ptone]

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 model.
> I used django.contrib.gis.db.GeoManager with my former profile-Model and 
> so I wanted to use it with my new custom user model, too.
> The following exception was thrown:
>
> " 'GeoManager' object has no attribute 'get_by_natural_key' "
>
> Hacking contrib/gis/db/models/manager.py and making GeoManager subclass 
> 'django.contrib.auth.models.UserManager' 
>
> instead of 'Manager' solved it for the moment.
>
> Maybe this is something that hasn't been thought of yet.
>
> I felt like I should post this.
>
>
Custom user objects require a custom manager that inherits from at least 
django.contrib.auth.models.BaseUserManager, which defines the 
get_by_natural_key method

Because the GeoManager defines a completely non-conflicting set of methods 
- you should be able to define your manager as:

class MyCustomGeoUserManager(BaseUserManager, GeoManager):

and then defining create_user and create_superuser per the docs

-Preston 

-- 
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-developers/-/4MpY9sSn164J.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: URL dispatcher slow?

[ptone]

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 URL 
> resolvers. If you think the template language is the problem, propose 
> a fix. 
>

To do my part to increase the signal:noise.

I'll point out that just as writing a failing test is a great way to 
augment a bug report - contributing or improving a benchmark for:

https://github.com/jacobian/djangobench

would be a good way to contribute to a discussion around a particular 
performance improvement you're interested in seeing happen.

-Preston

-- 
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-developers/-/kI7jNl7gYwEJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: A.objects.getdefault

[ptone]

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 ticket's were wontfixed

-- 
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-developers/-/XrgxWInpLJgJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: A.objects.getdefault

[ptone]

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 we already have the .save(commit=False) pattern - so it is not 
without reason that we could adopt that for the notion of 'create' on that 
method.

Because get_or_create takes an open list of kwargs, we can't just use 
'commit' - but we could use '__commit'

So it would look like:

obj, created = A.objects.get_or_create(slug="hello", __commit=False)

what the value of created should be in this case is tricky - arguments 
could be made either way.

so I'm far from certain this sort of overloading of get_or_create is 
workable, but if a method were added, but if  method were to be added, I'd 
argue it should follow the get_or_* naming pattern.

This is so easy to do in a custom manager or queryset, the question is 
whether this is a common enough need to bake into the default.

-Preston


On Tuesday, October 9, 2012 7:05:17 AM UTC-7, Ole Laursen wrote:
>
> Hi!
>
> What do people think of
>
>   A.objects.getdefault(slug="hello")  # returns None if slug doesn't exist
>   A.objects.getdefault(slug="hello", default=A())  # returns empty object 
> if slug doesn't exist
>
> I find that in practice, most of the time it would be better to get None 
> back instead of the DoesNotExist exception, but changing .get() is of 
> course impossible without breaking the API.
>
> I do think that
>
>   A.objects.get(slug="hello", default=None)
>
> is more elegant, but it might break some code. Although it does seem 
> really unlikely anyone would add a field named "default" to their model and 
> then use it to locate a unique object.
>
> The only related info I found in the issue tracker and on this list was a 
> thread from 2006.
>
> Ole
>

-- 
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-developers/-/XsLFfxITG7IJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

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

[ptone]

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:
>>
>>   
>> https://bitbucket.org/david/django-storages/src/1574890d87be/storages/backends/s3boto.py#cl-298
>>
>> What storage backend do you use that doesn't have a modified_time method?
>>
>
> I don't think you're seeing the problem I'm having. I'm working with a 
> distributed team using git. This means when we check out files, the local 
> modified time is the time at which I checked the files out, not the time 
> which the files were actually last modified.
>
> As a result, it's a questionable metric for figuring out if a file is the 
> same or not, since every team member's local machine thinks they were all 
> just created! We end up re-uploading the file every time.
>

While git may be common, and your problem not unique - this is still a 
condition of your dev environment rendering modification dates invalid. 
There might be other situations where this is the case (I've run into 
scripts that muck with modification dates based on camera/jpeg metadata).

So after some further discussion on IRC - it was determined that md5, while 
somewhat common, was far from a standard, and was likely not to be 
available as remote call for network based storage backends. And so the 
final resolution is to wontfix the ticket.

In the end - this lack of a universal fingerprint is just a limitation of 
our storage tools.

-Preston


> > This is a bit confusing...why call it last_modified when that's doesn't 
>> necessarily reflect what it's doing? It would be more flexible to create 
>> two methods:
>>
>> It's called modified_time, not last_modified.
>>
>
> Sorry, typo.
>  
>
>>
>> > def modification_identifier(self):
>> >
>> > def has_changed(self):
>> >
>> > Then, any backend could implement these however they might like, and 
>> collectstatic would have no excuse in uploading the same file more than 
>> once. Overloading last_modified to also do things like calculate md5's 
>> seems a bit hacky to me, and confusing for any developer maintaining a 
>> custom storage backend that doesn't support last modified.
>>
>> I disagree, modified_time is perfectly capable of handling your use case.
>>
>
> No it does not address my needs, as I described above.
>
> Dan
>

-- 
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-developers/-/pCGNll2gjiYJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

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

[ptone]

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 doesn't explicitly support MD5 (apparently it 
unofficially does through ETags).  Without a universal checksum - you can't 
use it to compare files across arbitrary backends.

I do agree that hacking modified_time return value is a little ugly - the 
API is clearly documented as "returns a datetime..." - so returning a M55 
checksum there is, well, hacky.

If you are passionate about moving this forward, here is what I'd suggest.

Implement, document, and test .md5(name) as a standard method on storage 
backends - like modified_time this would raise NotImplementedError if not 
available - this could easily be its own ticket. md5 is probably the 
closest you'll get to a checksum standard.

Once you have an md5 method defined for backends - you could support a 
--md5 option to collectstatic that would use that as the target/source 
comparison.

Another workaround is to just use collectstatic locally - and rsync 
--checksum to your remote if it supports rsync.

-Preston


On Sunday, October 7, 2012 8:59:16 PM UTC-7, Dan Loewenherz wrote:
>
> This issue just got me again tonight, so I'll try to push once more on 
> this issue. It seems right now most people don't care that this is broken, 
> which is a bummer, but in which case I'll just continue using my working 
> solution.
>
> Dan
>
> On Sat, Oct 6, 2012 at 10:48 AM, Dan Loewenherz 
> > wrote:
>
>> Hey Jannis,
>>
>> On Mon, Oct 1, 2012 at 12:47 AM, Jannis Leidel 
>> > wrote:
>>
>>>
>>> On 30.09.2012, at 23:41, Dan Loewenherz > 
>>> wrote:
>>>
>>> > Many backends don't support last modified times, and even if they all 
>>> did, it's incorrect to assume that last modified time is an accurate 
>>> heuristic for whether a file has already been uploaded or not.
>>>
>>> Well but it's an accurate way to decide whether a file has been changed 
>>> on the filesystem, and that's what collectstatic cares about. The storage 
>>> backend *is* the API to extend that when needed, so feel free to use it.
>>>
>>
>> It's accurate *only* in certain situations. And on a distributed 
>> development team, I've run into a lot of issues with developers re-upload 
>> files that have already been uploaded because they just recently updated 
>> their repo.
>>
>> A checksum is the only true accurate method to determine if a file has 
>> changed.
>>
>> Additionally, you didn't address my point that I quoted from. Storage 
>> backends don't just reflect filesystems--they could reflect files stored in 
>> a database, S3, etc. And some of these filesystems don't support last 
>> modified times.
>>  
>> > It might be a better idea to let the backends decide when a file has 
>>> been changed (instead of just calling the backend's last modified method).
>>>
>>> I don't understand, you can easily implement exactly that in the 
>>> last_modified method if you'd like.
>>>
>>
>> This is a bit confusing...why call it last_modified when that's doesn't 
>> necessarily reflect what it's doing? It would be more flexible to create 
>> two methods:
>>
>> def modification_identifier(self):
>>
>> def has_changed(self):
>>
>> Then, any backend could implement these however they might like, and 
>> collectstatic would have no excuse in uploading the same file more than 
>> once. Overloading last_modified to also do things like calculate md5's 
>> seems a bit hacky to me, and confusing for any developer maintaining a 
>> custom storage backend that doesn't support last modified.
>>  
>> Dan
>>
>
>

-- 
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-developers/-/weKD2x1XY4oJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: New predicate functionality for Q objects

[ptone]

So a number of issues have come up in the review of this feature that I'd 
like to summarize here.

The first boils down to feature basically being another case of an:

http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch

That is, the idea of a lookup matching against an instance in memory, will 
never completely mimic the behavior of that lookup when generating a DB 
query through the ORM.  It is a situation where most of the common use 
cases can probably be handled - but there are probably a number of edge 
cases lurking that would add some degree of maintenance burden were this 
feature to land.

The second issue is that this adds more code that relies on a currently 
imperfect lookup system.  Current query_terms, and now, for predicates, 
matching_functions live as part of the query object - a non-public object 
that, in part, determines what is a valid lookup.  This all could be 
refactored to be more associated with the fields themselves.  This is 
mostly an internal issue, as I feel the feature could always be refactored 
to take advantage of improvements to the internals without changing the 
public API of the predicate feature.  While explicit manager passing would 
probably no longer be required with improved internals - it could still be 
supported/ignored, and the explicit use of a manager is already in and of 
itself a pretty uncommon edge case requirement in the current 
implementation.

For a ticket that tracks the lookup refactoring ideas, see: 
https://code.djangoproject.com/ticket/16187

Finally - along with the ORM mismatch issue, there exists some potential 
for abuse of this feature that would result in very poor performance.  This 
is a case of: can the documentation make this clear enough that reasonable 
people won't shoot themselves in the foot. I'm not overly concerned about 
giving people enough rope to hurt themselves - but even a reasonable dev 
not doing any profiling could find themselves using this feature with 
either large arrays of instances, or with extensive conditions that follow 
deep relationships where the ORM and querysets would do a better job 
leveraging your database.  Exactly where that line exists depends on too 
many factors to lay out out clearly in documentation.

So that is an update on where this feature stands

If it does not make it into 1.5 - I can probably factor out most of the 
improvements back into the external django-predicate package, with a couple 
somewhat ugly hacks to support the GIS related matches.  There was some 
brief debate on IRC about how Django can best unearth edge case bugs in 
features that are candidates for inclusion into core, without the 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 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 appreciate any 
> review people can offer.
>
> To be clear, a review of the documentation as a user is also helpful, so 
> don't be shy ;-)
>
> I'm hoping to land this for 1.5
>
> Thanks,
>
> -Preston
>
>

-- 
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-developers/-/T1mOyjTIjKUJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

New predicate functionality for Q objects

[ptone]

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 appreciate any 
review people can offer.

To be clear, a review of the documentation as a user is also helpful, so 
don't be shy ;-)

I'm hoping to land this for 1.5

Thanks,

-Preston

-- 
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-developers/-/8wlcybZBdEoJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Improve Django markdown rendering.

[ptone]

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 module entirely

https://code.djangoproject.com/ticket/18054 

finishing and getting landed the patch is on my todo list for the sprints 
at Djangocon.

The overhaul you suggest is a great opportunity for someone to offer an 
improved replacement version available outside of Django.

-Preston

-- 
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-developers/-/7kMd5U9gv6UJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Development GUI

[ptone]

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 developing a web-based development GUI for Django. See 
> https://github.com/timothyclemans/djangomodelcg for a simple code 
> generator for models I wrote today.
>
> Should I develop this for inclusion in Django, fork of Django, or third 
> party library?
>

-- 
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-developers/-/bCc1FF-CBHQJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Yak shaving the test framework on the way to pluggable user models (#3011)

[ptone]

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(user model == auth.User)", but that would mean some 
> >> projects would run the tests, and some wouldn't. That seems like an 
> >> odd inconsistency to me -- the tests either should be run, or they 
> >> shouldn't. 
> > 
> > FWIW it doesn't seem odd to me. If a project doesn't use Django's 
> > built-in User model then you don't need to test it in that project's 
> > test suite. 
>
> A possible miscommunication here -- I don't think it's odd that the 
> tests wouldn't be run; I only think it would be odd to have those 
> tests report as "skipped". It feels to me like they should be either 
> run or not run, not reported as skipped. 
>

Isn't it just semantic nuance at that point? Seems like not a heap of 
distinction between "not run" vs "skipped" when a condition isn't met such 
that the test would be applicable.

 -Preston

-- 
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-developers/-/TareOJMFXXkJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

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

[ptone]

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 system to use an ``Environment`` class (something 
>> akin
>> > to Jinja2's ``Environment``) which takes a list of loaders, and a 
>> number of
>> > other arguments. Then, instantiate this class, using the provided 
>> settings,
>> > and use it for all the default functionality (the admin, 
>> render_to_response,
>> > CBV template access, etc.). This would allow developers to make their 
>> own
>> > ``Environment`` instance with different arguments, request-specific or
>> > otherwise, and without having to do a lot of evil things.
>>
>> Sounds great - I'd love to see a patch!
>>
>> Jacob
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers" group.
>> To post to this group, send email to django-developers@googlegroups.com.
>> To unsubscribe from this group, send email to 
>> django-developers+unsubscr...@googlegroups.com.
>> For more options, visit this group at 
>> http://groups.google.com/group/django-developers?hl=en.
>>
>>
> This is a good idea, I think there's even a ticket (probably, but not 
> definitely filed by either myself or Carl Meyer) on this!
>
> Alex
>


Indeed there is:

https://code.djangoproject.com/ticket/17093

-Preston

-- 
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-developers/-/fXhEsNBSz58J.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: GitHub migration done!

[ptone]

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 should be in place. 
>
> As a side note, it is kind of a hassle to submit a pull request and 
> then go fill a new trac ticket. 
> For me, as a kind-of-involved user of Django, I simply won't go into 
> that burden. 


It is a small hassle, but I've done it several times (creating a pull and 
ticket with cross referencing links).  Writing tests can sometimes feel 
like a hassle.

Hopefully we will see some solutions and improvements in the trac-github 
space, but in the meantime - it shouldn't be a barrier to contributing - a 
few more clicks is all.

 -P


> On Apr 28, 10:03 am, Aymeric Augustin 
>  wrote: 
> > On 28 avr. 2012, at 05:08, Adrian Holovaty wrote: 
> > 
> > > * We're going to keep using Trac for tickets, but pull requests on 
> > > GitHub are also welcome. 
> > 
> > Hi everyone, 
> > 
> > For extra safety, I recommend you still create Trac tickets for each 
> suggested change, until we work out how pull requests integrate into the 
> triage workflow. 
> > 
> > Thanks, 
> > 
> > -- 
> > Aymeric.

-- 
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-developers/-/d9oL2HA1IXIJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Django 1.4 default database required?

[ptone]

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 is this a bug? 
>
> We get the error when importing  django.shortcuts.render_to_response, 
> which doesn't seem like the kind of place a database connection would 
> even be required.


Any chance you have an explicit empty DATABASES={} setting? Try deleting 
that setting entirely and see if it works.

As part of the removal of the backwards compatibility shim for the old 
DATABASE_* settings, the global settings contains a DATABASES setting that 
uses the dummy backend for the default database.  This global setting will 
silence the import errors, but still raise an error if you try to do 
anything that uses the DB. 

-Preston




-- 
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-developers/-/bAjgMbeYb-wJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Allowing Reverse, Single Inlines in Admin

[ptone]

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 best 
> idea for a data model, but if a user has this requirement, Django should be 
> flexible enough to meet it, and I do think it's a good idea.
>>
>>
>>
>
Now that I understand - I agree.  Looking at this briefly - it would be a 
matter of making the notion of "parent_model" in inlineformset_factory be 
valid on either side of the OneToOne.

This would be some form of letting SingleRelatedObjectDescriptor be as 
valid as a fk in django.forms.models._get_foreign_key()

This actually has very timely bearing on the auth discussion believe it or 
not...

-Preston

-- 
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-developers/-/OvzZO5iQBl8J.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Allowing Reverse, Single Inlines in Admin

[ptone]

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 address model on each of your 
other models.

-Preston

-- 
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-developers/-/1qyvaXw39QsJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: GSOC2012 Proposal for 'Finishing off the App Refactor'

[ptone]

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 worthy of *two* GSOC projects myself.

I believe that the baton was somewhat passed to tswicegood at pycon, see:

https://github.com/tswicegood/django/commit/241c455d9b8d03144a24f869f819efda031813ba
 

See some other comments below:


>
> Introduction 
> - 
>
> Because the purpose is to check if everything runs ok after merged, so 
> we should know what kind of features current app loading mechanism 
> supports and what kind of improvements 'future' advanced work has 
> made. 
>
> 1 current app loading features 
> 1) app can be reused in multiple projects 
>

not sure how this is related to app_loading, it is the case currently
 

> 2) reused app can be found by Django in INSTALLED_APPS of settings.py, 
> which is written in dotted path 
> 3) each string in INSTALLED_APPS should be a full Python path to a 
> Python package that contains a Django application, as created by 
> django-admin.py startapp 
>

While I think this should still be true, currently there is the option for 
an iterable for defining an app, there was an "APP_CLASSES" setting in the 
branch transiently, but is now gone.  I think it would be better to keep 
INSTALLED_APPS flat and introduce a new setting for configured apps - which 
could then add their flat representation to INSTALLED_APPS

4) app names must be unique 
>

This is, as far as I can tell from my review, and unresolved limitation in 
the current branch - that django.contrib.auth and mypackage.auth collide. 
Seems a duplicate of your #3 below.
 

>
> 2 'future' app loading features 
> 1) backward compatibility: 'future' app loading mechanism should 
> support current app loading features well 
>

This backwards compatibility is present currently as a set of module level 
functions at the old location in the db module
 

> 2) can deploy several instaces of the same application 
>

If you see the discussion here:

http://groups.google.com/group/django-developers/browse_thread/thread/4cca2086dd485879/5045645100f5b8ea?lnk=gst&q=app+loading#5045645100f5b8ea

It was determined that this feature was too problematic to tackle as part 
of app_loading
 

> 3) can deploy two applications with the same name,(not have the 
> requirements of unique app name) 
>

There remains some room for improvement and clarification about what an 
app_name is vs app_label vs fully qualified name
 

> 4) convenient interface for internationalizing application names  

5) good support to rename an application with a name that isn't 
> helpful from a UI 
> perspective 
>

Some of the above needs clarification.

I do think app_loading needs some sort of new push - but I'm dubious that a 
GSOC would be the way to go.

For your detailed plan, I would complete your items for week 1 and 2 before 
writing a final proposal, not as part of your proposal.

-Preston







>
> Detailed Plan: 
> Week 1: Read the source code corresponding with app loading of current 
> Django thoroughly, to know best what current app loading does and how 
> it does 
> Week 2: Read the source code of new app loading code, to check whether 
> it implement the new features interested developers proposed before 
> [4] 
> Week 3: Try to merge and check if old test cases can all be run 
> successfully, and make some necessary improvement work 
> Week 4-5: Establish good use cases to check if old app loading 
> features are all not been destroyed, meanwhile do necessary 
> modification work 
> Week 6: Check all new test cases can be run sucessfully or not, and 
> make some necessary work to help pass all tests 
> Week 7-8: Construct use cases to check how many new features have 
> already been implemented, and if there are some interesting features 
> that should be added, then I can do neccessary coding work 
> Week 9: make up current not well-done coding and tests work to make 
> app loading run perfectly 
> Week 10: Begin to create patches and create/write the documention 
> Week 11-12: Investigate the Django tickets host and contact with 
> corresponding and interested developers to know if there are some 
> necessary work or changes should be added , and if all is ok, try to 
> begin to submit the patches to Django 
>
>
> About me: 
> I am a student from China, and have about 3 years Python programming 
> skill and uses Django 
> for 2 years. I love this kind of activity Google has offered and am 
> very interested in 
> communicating with open source guys all over the world. Hope I can 
> make some contributions to Django through this wonderful activity. 
>
> Email: zenna...@gmail.com 
> IRC: zennauho 
>
>
> Links: 
>
> [1] https://code.djangoproject.com/wiki/SummerOfCode2010#Apploading 
> [2]https://github.com/jezdez/django/commi

Re: auth.User refactor: reboot

[ptone]

>
>
>
> 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 us is that no matter what we pick as field names/sizes, 
>> *someone* will be unhappy. However, I won't get too bent out of shape if 
>> Django ends up shipping at least 1 new concrete User model -- at the very 
>> least, it's a good way to prove we can eat our own dogfood.
>>
>> Right. So the conclusion to this is "Ship broken, allow people to fix it".
>>
>> Tom - did you read the paragraph that follows?  It seems to me to say 
that by default - new projects would get the improved auth model, because 
they would be specifying the app with the new app loading approach. 
 Doesn't that solve your main problem?
 

>  
>
>> >
>> > If we introduce 1-N new User classes, we could also take the 
>> opportunity to make one of the new User models the default user if you 
>> deploy auth using an App definition, but User the default otherwise. This 
>> means that any new projects would get the new SimpleUser class, but 
>> existing projects would get the older User class.
>>
>
>
>
>  
>
>> >
>> > The key point here is that we're not forcing every Django user to 
>> discover by accident that they need to run an ALTER TABLE statement in 
>> order for their projects to keep working. The opt-in nature of the change 
>> is key.
>>
>
>
>
I think the key is that if 

INSTALLED_APPS = (
...
'django.contrib.auth'
)

then user model is the old one

but if 

INSTALLED_APPS = (
app('django.contrib.auth' )
)

then auth model is an improved concrete class

If I'm understanding the meaning of an "App definition"

I basically agree with your main point, Django should ship the improvement 
as the new default, which isn't mutually exclusive with keeping backwards 
compat.

-Preston
 
PS most email clients should handle wrapping on the reading end, your 
emphasis on this technical detail feels out of place.

 

-- 
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-developers/-/t45LV8LL9B8J.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

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

[ptone]

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 I think my only solution is "to 
> lobby" this ticket here :-) 
> Is there anything else I can do? 
>

This is where the community can help the core about by:

- applying the patch and verifying that it applies cleanly to current trunk
- see if it fixes the issue as you understand it or are experiencing it
- do your best to review the tests and determine if docs would be needed

If all looks OK, comment that you have done the above and mark "Ready for 
checkin"

I think too few people realize that this last step is something they can 
do.  It is not a guarantee of a prompt checkin - but it certainly increases 
the chance it will be seen.  I'd say only after it has sat in that state 
for a bit, does it make sense to post a nudge here.

-Preston

Ciao. 
> Marco. 
> P.S. Someone said the putting your email in cc in a ticket isn't the 
> way to go. 
>

-- 
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-developers/-/3Delk-NooHsJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Documentation for CBV's?

[ptone]

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 work on 16807 split into 2 parts, some integrated into an
revamped introduction to views, and more technical bits into a CBV
specific doc.  This involves reworking the doc that introduce the very
concept of views, something that introduces the view contract,
function based views, then CBV.

* I've submitted an alternate/additional index to the reference
material that I think is clearer for users of the generic views in:
https://code.djangoproject.com/ticket/17378

* It would be great to see a CBV cookbook full of examples such as
auth login_required, Forms, etc

There are several CBV tickets I'm hoping to see closed for 1.4, which
while not documentation, will hopefully make CBV use a little clearer:

Tobias and I worked on https://code.djangoproject.com/ticket/16074 and
it is close to done

https://code.djangoproject.com/ticket/16744 follows easily after that
lands

and then https://code.djangoproject.com/ticket/17228 and
https://code.djangoproject.com/ticket/17381

those all help clean up the context story

It would be nice to see some resolution to 
https://code.djangoproject.com/ticket/14512,
I think the mixin approach is the best, but not sure the work can be
done to convert the rest of the stock decorators in time for 1.4?

Victor - are you interested in helping with this? Anyone else?

-Preston


On Dec 11, 10:27 pm, Victor Hooi  wrote:
> Hi,
>
> I might be stating the obvious, but the documentation for the newer CBV's
> is a little sparse:
>
> There's simple examples:
>
> https://docs.djangoproject.com/en/1.3/topics/class-based-views/
>
> As well as a generic list of mix-ins and in-built views:
>
> https://docs.djangoproject.com/en/1.3/ref/class-based-views/
>
> However, there's no fuller examples, or best practice notes. There's no
> explanation of any of the views beyond TemplateView, ListView and
> DetailView (e.g. UpdateView, DeleteView, RedirectView, or any of the
> date-based CBVs).
>
> Sure, if you trawl around, you'll find some examples:
>
> https://gist.github.com/1275204https://groups.google.com/d/topic/django-users/HdYBkywNeII/discussionhttp://stackoverflow.com/questions/5899810/class-based-view-extending...
>
> However, it would be awesome if there were examples in the official Django
> documentation that set out once and for all how to use these new-fangled
> CBV's. I would love to use them more extensively, but it seems like I'd
> need to spend hours on Google to work out all the nuances.
>
> Is this something that could be resolved before pushing out Django 1.4, or
> is it much lower on the list of priorities?
>
> Cheers,
> Victor

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Django 1.4 roadmap

[ptone]

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
transferred, due to understandable lack of personal bandwidth. Being
able to commit to Django-the-codebase does not confer the same
knowledge required to cut a release of Django-the-project.

Perhaps if James Bennet could do a brain dump, in outline form, of the
procedural steps of release on a wiki page to augment the more public
focused: https://docs.djangoproject.com/en/dev/internals/release-process/

Determine if there is someone newer to core (or unfamiliar with the
release process) who is interested in being mentored in the process.

Open a call for current core devs to comment on what in-progress
features they want to champion into 1.4 and get a rough self imposed
due date.  If those cluster nicely, use a soft average of those dates
as the target release date for the alpha.

Explicitly determine which core-dev will take ownership of which
remaining release blockers.

I have a few tickets I have in progress, and all I can do from my
position, is do my best to prioritize them, and get the top ones
wrapped up, rather than have all remain uncompleted.

-Preston

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: load template tag library

[ptone]

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 more general: the
> thing that loads/renders the template).

Such as a TemplateEngine...?

This seems a good candidate feature for: 
https://code.djangoproject.com/ticket/17093

>Why would I, as a back-end
> developer, make *all* of my template tags available to the front-end
> developer in *all* templates?
>
> A great benefit of moving the template tag library loading to code,
> would be that the template language could also be safely used in
> CharFields/TextFields, without the risk of users using unwanted
> template tags.
>
> Of course, for backward compatibility, this can't be changed. The
> thing I'm most interested in, though, is restricting the template tag
> libraries that can be used in a template from my view-code. This can
> be done in a backward compatible way.
>
> Opinions?
>
> Cheers, Roald

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Anonymous session carries over to authenticated session

[ptone]

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 - there are reasons to not flush it.

but this doesn't seem to merit a setting in the face of the ever
growing problem of settings bloat.

If https://code.djangoproject.com/ticket/17209 comes to pass, this
could be something on a login class, but otherwise I think you are
better off just doing a custom login view if you want to flush the
session.

-Preston

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

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

[ptone]

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,
>                     'label': capfirst(self.verbose_name),
>                     'help_text': self.help_text}
>         if self.has_default():
>             if callable(self.default):
>                 defaults['initial'] = self.default
>                 defaults['show_hidden_initial'] = True
>             else:
>                 defaults['initial'] = self.get_default()
>         if self.choices:
>             # Fields with choices get special treatment.
>             include_blank = (self.blank or
>                              not (self.has_default() or 'initial' in
> kwargs))
>             defaults['choices'] =
> self.get_choices(include_blank=include_blank)
>             defaults['coerce'] = self.to_python
>             if self.null:
>                 defaults['empty_value'] = None
>             form_class = forms.TypedChoiceField
>             # Many of the subclass-specific formfield arguments
> (min_value,
>             # max_value) don't apply for choice fields, so be sure to
> only pass
>             # the values that TypedChoiceField will understand.
>             for k in kwargs.keys():
>                 if k not in ('coerce', 'empty_value', 'choices',
> 'required',
>                              'widget', 'label', 'initial',
> 'help_text',
>                              'error_messages', 'show_hidden_initial'):
>                     del kwargs[k]
>         defaults.update(kwargs)
>         return form_class(**defaults)
>
> this code says
> if self.choices:
>     form_class = forms.TypedChoiceField
>
> this means that if you have a field that got choices, even if you pass
> during the super an argument different than forms.TypedChoiceField,
> you'll always get forms.TypedChoiceField
>
> must be defaults["form_class"] = forms.TypedChoiceField

do you mean something like:

if self.choices:
if 'form_class' in defaults:
form_class = defaults['form_class']
else:
form_class = forms.TypedChoiceField

-Preston
form_class =

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Wiki page on global state

[ptone]

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 be improved and serve two main
purposes:

1) A place to point people to when they are confused about how the
reliance on global state effects Django, or when someone bumps up to
some specific area where global state is effecting their use of
Django.

2) As a place to collect related tickets, and capture discussions or
conclusions from the community about how to proceed.

-Preston

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

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

[ptone]

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 currently in that it just lets the parent
Field class stick the string in the DB as a raw value.

what should it do? check if the value is a valid path to a file and
then use that?

https://code.djangoproject.com/ticket/17224

-Preston

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: TemplateResponse and loader should handle request

[ptone]

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 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

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

[ptone]

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 ambiguous and conflict prone would be better
IMO. Also an explicit link to the activate command from the section
where you introduce the current time zone concept. Perhaps with a
simple code example of how you would set current time per user in a
view.

https://bitbucket.org/aaugustin/django/compare/..django/django#chg_docs/topics/i18n/timezones.txt_newline109

Was a threading.local the only way to do this - I'm sure you've given
it some thought - there are relatively few uses of thread locals in
Django - translation being one. If the timezone were stored on the
current request, would that not be available to most places in django
code that need TZ within the current thread?

On Oct 30, 6:45 am, Aymeric Augustin
 wrote:
> Initially, I considered writing a script to automatically shift timestamps in 
> the database backends that need it, to ease the migration of existing 
> projects to USE_TZ=True. Upon further thought, I'm reluctant to mess with 
> people's databases, even with a big fat disclaimer. If I write such a script, 
> I'll upload it to djangosnippets.

I think a very brief outline of the steps required for migration may
be worthwhile in the release notes.

-Preston

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Cleaning up manage.py and import paths

[ptone]

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
> before 'mkdir foo' - you 'svnadmin create', then checkout the empty repo
> to start working. For either of these workflows, you probably wouldn't
> want startproject creating your main directory. I actually like the idea
> that Django is not supposed to be managing your entire project - rather,
> your project uses Django.
>
> Luke

For a possible solution to this situation, I've put together a patch
that allows startproject/startapp to write into an existing folder.
That way, if you want to turn an existing folder into a project you
can, otherwise the default outer directory will be created.

https://code.djangoproject.com/ticket/17042
https://github.com/django/django/pull/65

-Preston

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

login_required decorator and user.is_active (yes, again)

[ptone]

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
login_required needs to be documented, but before I open a doc ticket
for that, I wanted to give this another shot here.

On Apr 15 2010, 5:55 pm, Russell Keith-Magee 
wrote:
> On Thu, Apr 15, 2010 at 11:20 PM, subs...@gmail.com  wrote:
> > Thanks for breaking it down.
>
> > On Mar 17, 7:45 am, Russell Keith-Magee 
> > wrote:
>
> >>  1) Don't touch the code. It's an annoying edge case, but it can be
> >> caught by shortening session timeouts and making more use of
> >> permissions. However, we should document the edge case with
> >>login_required, as it is certainly contrary to obvious usage.

Note, this is not yet documented in trunk.

> As I indicated previously in this thread, there are two use cases that
> need to be handled:
>
>  1) Normal Django authentication, honoring the is_activeflag. For
> this use case, you are completely correct - the current behavior is
> wrong.
>
>  2) Custom authentication backends that *don't* honor the is_active
> flag. This is entirely legal, and documented as such.

However, as of 1.3, the expectation is that backends will "handle" an
inactive user.

It is unclear from the current docs, what exactly the expectation is,
but it implies that any custom auth backend  needs to support the
is_active attr on the user_obj.

"Django 1.5 will assume that every backend supports inactive users
being passed to the authorization methods."

Right now, it is confusing as to how the is_active flag is treated by
contrib.auth. While the auth system involves several layers, there is
basically two types of implementation: "the built in default" and
"custom" (anything other than the builtin).  It is inconssistant to
have one part of the built in defaults (the login form) check this
attribute, but have other parts not check it (the decorator).  I know
that the defaults aren't explicitly a "set" in this way, none the
less, I think generally that people consider the out of box experience
to be coherent.

I think that there would be pretty universal agreement about the
expectation of what should happen if you make a previously active user
inactive with regard to their access to @login_required protected
views.  Shortening session times, seems like a really unpalatable
workaround for sites that have chosen longer/default session
expiration times.

During the deprecation, the decorator could check
user.backend.supports_inactive_user, as unlike at the time of the
above thread, the user object is not annotated with the backend.

-Preston

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: deprecation vs removal

[ptone]

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 what the other sections generally tend to say.
> Some in section 1.6 say a feature "will be deprecated".
>
> Can we have a consistent policy on this terminology?


I've opened a ticket on this and submitted a patch with an attempt to
be more consistent in language - review would be welcome:

https://code.djangoproject.com/ticket/16988
https://github.com/django/django/pull/58

-Preston

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: deprecation vs removal

[ptone]

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 what the other sections generally tend to say.
> Some in section 1.6 say a feature "will be deprecated".

I'm +1 on this, it essentially inconsistently restates the deprecation
policy for each item.

Not all deprecations are removals, some are API changes.

I still think that the doc is basically forward looking, so future
tense should be preserved - I don't think any mention of when the item
was first deprecated is needed (as I said, that is in the policy and
does not need to be repeated).  I do think links to sections of
release notes are useful instead of restating the reasons in full.

On Oct 3, 6:35 am, Russell Keith-Magee 
wrote:
> +1. I agree with Paul that "PendingDeprecationWarning" is slightly
> problematic from a language perspective because we're saying that
> we're deprecating a feature now, and implementing that by raising a
> Pending warning. However, I think that's a mild inconsistency I can
> live with.

regarding PendingDeprecationWarning:

given that the policy is a relatively generous 2 version path, I like
that PendingDeprecationWarning allows a sort of "soft deprecation".
That is, if there was a large change in opinion (low probability), the
deprecation could be reverted.  Other's may object to this, but I
think adopting sort of a deprecation "beta" would allow for some
slightly more aggressive deprecation, with a period for community
feedback.  Many people will read release notes who don't pay attention
to deprecation discussions in dev.  The big downside to formalizing
this is that the decision could appear wishy-washy, or could be
subject to vocal minority crusades against a deprecation, so I'm +0
about it ;-)

-Preston

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: RFC: "universal" view decorators

[ptone]

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 working. I 
> have the places where the other 2 will go but from a combination of not being 
> very good at decorators, and not feeling well I haven't finished it yet.

I like the overall direction of this approach (mixin class as the root
container of functionality) - but a number of technical issues still
need to have a resolution demonstrated (ie the decorating function
behavior)

One, perhaps pony, of a universal approach, would be to convert the
decorator kwargs into class attributes, so that they could be
overriden in subclasses of a decorated parent, something easy to do
with mixins as the starting point.

Also on a somewhat related note, a better option for middleware
process_view to interact with class based views

-Preston

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: is it time to start deprecating parts of contrib

[ptone]

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 to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

is it time to start deprecating parts of contrib

[ptone]

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 PendingDeprecation warning could be reversed
if there was a large change of opinion.

There is perhaps no more humorous a line in all of the Django docs
than this:

"Databrowse is very new and is currently under active development. It
may change substantially before the next Django release."

My top nominations for contrib apps to go away are:

Databrowse
webdesign
formtools

What are yours?

Given the 3-version deprecation process, I figure it could be time to
start pulling some weeds.

-Preston

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: reset and sqlreset - PendingDeprecationWarning

[ptone]

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 are not exposed so I am
> > wondering.
>
> It depends a little on what they were doing in the first place. flush
> is the nuclear option, because it deletes *everything*; another would
> be learning how to use ALTER TABLE or DROP TABLE statements manually.

I'm sure the reasoning is sound in the decision to remove these, but
given that flush is db wide and not app targeted - this removes a
certain functionality without any documentation as to why it is being
removed.  The ticket only says "These commands break a lot" which
leaves a little room for clarification - either on the ticket or in
the docs.  I'm sure a number of people use reset when doing early
revisions on the models of an app, who don't need/want to flush the
whole db, and who don't need/want to drop into the db-shell to drop
tables.  Even with South, I use reset early on sometimes when I'm
roughly sketching out a model.  I know this is only a warning, but
seems might as well bring it up now while there is already a thread on
it.

-Preston

>
> Yours,
> Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Speed testing Django

[ptone]

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 earlier this year that started developing a
> benchmark set that could be used; results so far can be found here:
>
> http://github.com/jacobian/djangobench
>
> However, there's still a lot of work to do to build up the benchmark
> set and deploy it in a continuous integration environment. I'm not
> aware of anyone specifically coordinating this benchmark work at the
> moment, so if you want to step up and make this your contribution,
> feel free to do so!

the benchmarks project seems mostly like a high level comparison of x
is faster or slower than y

It is not so much about profiling.

The problem with some profiling approaches, is it involves going in
and adding profiling code to cover the whole project analogous to
testing.

enter Dtrace - which can expose profiling hooks at a very low level.
Since the test suite is a pretty good coverage python, I started
there.  But this could be used to watch a test server with a faux site
being hammered by test clients to give a real world performance view.

So I did a quick experiment using a Dtrace recipe from the Dtrace
toolkit [1] called py_cputime.d

I ran the current trunk test suite while probing.  I made no effort to
exclude setup and teardown.  There seems to be some limitations of the
Dtrace support in the Python I was using (OSX 10.6.3) in that I was
getting some reports of dynamic variable drops to stderr.  However I
think the results are still very interesting and as a technique, show
a lot of promise:

http://ptone.com/misc/django-dtrace.txt

The report shows for each function a count, an Exclusive function on-
CPU time, and Inclusive function on-CPU time

At a glance - this shows you where Django is spending most of its
time.  It doesn't say anything about whether that time is unavoidable
or required - just where to look for some possible lower hanging
performance fruit.

-Preston

[1] http://hub.opensolaris.org/bin/view/Community+Group+dtrace/dtracetoolkit

>
> Yours,
> Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Inclusion of easy-thumbnails into Django Contrib

[ptone]

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 and promote auth and sessions to core but 
> done in a way that is pluggable.  The reasoning behind this opinion is that 
> it leaves the surface area in the project smaller to maintain and it's really 
> not that hard to add a sorl-thumbnail external app to a Django project.  
> Furthermore, it provides more freedom for these apps to mature and develop at 
> their own pace.
>
> I realize I could very well be in a minority opinion here, but thought I'd 
> throw it into the mix nonetheless.

Another vote for evolving away from contrib.

My hope is that one day http://djangopackages.com/ will become
packages.djangoproject.com

(and along with that a management command startapp-dist which starts a
distributable skeleton)

-Preston

>
> On Sep 16, 2010, at 11:33 AM, Brian O'Connor wrote:
>
>
>
> > I have absolutely no pull in decision making, but maybe my message will 
> > count towards a "community voice".
>
> > I think that including an image thumbnail package that integrates into the 
> > database as easily as sorl.thumbnail and easy_thumbnail are is a great 
> > idea.  From what I can tell, sorl.thumbnail was the de facto standard for 
> > getting thumbnails in to Django, and I think it has just as much of a place 
> > in Django contrib as some of the other contrib apps do.  I don't think it 
> > belongs in the core, but contrib seems like an excellent place for it to go 
> > along with the other batteries in the pack.
>
> > On Thu, Sep 16, 2010 at 12:24 PM, Yo-Yo Ma  wrote:
> > I have no data to support the following assertion, but it's not too
> > unreasonable: More people probably need thumbnail images than they
> > need comments. Comments are most used on blogs, whereas thumbnails can
> > be used on blogs, e-commerce, photo hosting, social networking,
> > project management, et al. It's not to say that we don't need
> > "contrib.comments", just that I wouldn't want to lose easy_thumbnails.
>
> > On Sep 15, 11:32 pm, "David P. Novakovic" 
> > wrote:
> > > Actually, that really did sound negative. Sorry :)
>
> > > Is there a trac ticket open to address this issue? Generally it'd be
> > > better to get discussion happening over a ticket and if there are
> > > serious issues that need to be addressed then they can be discussed
> > > here.
>
> > > I know it'd be nice to get things like easy-thumbnails accepted into
> > > django.contrib , but the truth is that this probably falls outside of
> > > things that that should be in contrib. Contrib isn't really an easier
> > > way to get stuff into django, it still has to satisfy a bunch of
> > > conditions like the rest of the code in the core.
>
> > > The real question is not "can it be included?" but why is it a problem
> > > that this is a third party lib at the moment? Is there a strong case
> > > that it be better if it was part of django core or does it do its job
> > > just fine the way it is now?
>
> > > David
>
> > > On Thu, Sep 16, 2010 at 3:09 PM, David P. Novakovic
>
> > >  wrote:
> > > > I don't want to sound negative, but answering your own question before
> > > > anyone else can doesn't change the answer ;)
>
> > > > D
>
> > > > On Thu, Sep 16, 2010 at 3:00 PM, Yo-Yo Ma  
> > > > wrote:
> > > >> Is there any plans to 
> > > >> incorporatehttp://github.com/SmileyChris/easy-thumbnails/
> > > >> into django.contrib? I have seen so many apps/libraries come into and
> > > >> go out of existence (http://code.djangoproject.com/wiki/ThumbNailsfor
> > > >> instance mentions sorl-thumbnails which is no longer being developed).
> > > >> I just turned the key with easy-thumbnails and voila. It's like magic,
> > > >> but not. It's easy enough to see what's going on behind the scenes.
>
> > > >> This is something that, with the help of the core and other
> > > >> contributors, could be really great. It works for me as it it is, but
> > > >> it may not work for a more "enterprise" application that uses S3, etc.
> > > >> It might not be highly efficient (I wouldn't know). It might have bugs
> > > >> that I just haven't noticed yet. I'm mentioning all of this because I
> > > >> know somebody will say, "Why move it into Django if it's doing just
> > > >> fine as a separate project?". After experiencing the bliss I thought
> > > >> I'd drop a line here about it, and see what you guys thought.
>
> > > >> --
> > > >> You received this message because you are subscribed to the Google 
> > > >> Groups "Django developers" group.
> > > >> To post to this group, send email to 
> > > >> django-develop...@googlegroups.com.
> > > >> To unsubscribe from this group, send email to 
> > > >> django-developers+unsubscr...@googlegroups.com.
> > > >> For more options, visit this group 
> > > 

re: Allow context processors access to current version of context

[ptone]

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 be easily
> done with another argument, context, and also backwards compatible.
> Functions would only get additional argument if they are defined to
> get two arguments and whatever they would return would override that
> in the context.
>
> http://code.djangoproject.com/ticket/13841
>
> Mitar

I came upon your ticket whilst triaging and feel that the best way to
advance your issue is to present a clear and concise use case of where
modifying a context is useful.

The design of the context is such that it is a list of dictionaries,
while I'm new to the internals - someone else could speak as to why
the the original design is such that the last line of RequestContext
is:

self.update(processor(request))

instead of:

processor(request, self)

in otherwords why contexts are passed around for modification - and
instead are updated.

I think the patch for your ticket would be as simple as changing it
to:

self.update(processor(request,context=self))

Again - being new to internals I'm not sure what ramifications that
would have.  But in attempting to triage your ticket, maybe this post
will act as a foil for discussion.

-Preston

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

admin action breakage with changeset 12525

[ptone]

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 opened ticket #12973 and included a patch that that gets things
working again.  But in a way I think there is some more design
thinking needed here for 1.3 in terms of how an action follows
through.  The number of code paths going through the changelist view
seems a little convoluted.  It would make sense if there was some
design pattern that allowed an action to be more self contained and
able to perform its action independent from the changelist view.

-Preston

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Speeding up test running

[ptone]

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 pickled to be pushed to the worker
pool and not all test cases could be, almost 2 minutes of this is
spent having to run just several tests in the main thread.  If this
was resolved, I think the whole test suite could be run in about a
minute.

When it hits a stretch of tests that can be dispatched and lights up
all cores, it just screams.

With the increase of multicore machines, perhaps this is something of
interest.  Even with fast fail - waiting for tests to run takes away
from other development tasks, and being able to run the test suite
more frequently would probably help catch some bugs earlier before
they cascade or propagate by being extended or referred to.  I'll
grant this is a relatively low priority - but if anyone wants, I'd be
happy to clean up my hack and post it as a gist.

-Preston
-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.