Re: How many Django web pages does it take . . .

[Gabriel Hurley]

FWIF, the code that generates that message is here:

https://code.djangoproject.com/browser/django/trunk/docs/_ext/djangodocs.py#L84

Feel free to open a ticket if you like.

All the best,

- Gabriel

-- 
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/-/B_MkGZqmbDQJ.
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: Logout user when they change their password.

[Gabriel Hurley]

Options 2 and 4 from that list both involve database-level changes, and 
thus aren't feasible (our lack of schema migration tools being the biggest 
problem).

Of those, I'd go for option 3 as well. We definitely don't want to store 
the full hash in the session for obvious security reasons, but a small 
portion of the hash is probably enough to do the checking, be secure and 
provide a high degree of confidence that collisions would be unlikely.

I'll leave it to PaulM or someone else better versed in hashing to comment 
on what the appropriate subset might be, or if that's just totally off base.

Lastly, I'll add that it'd really be pushing it to get this into 1.4 at 
this point. I, personally, would be willing to allow it on the basis of it 
being a security concern, but we'd need to have a really solid patch for it 
in the next week or so to have time to review it, test it, etc. Once we 
release the beta it's definitely not making it into 1.4.

All the best,

- Gabriel

-- 
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/-/2FvSlmAuVOIJ.
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: Sprint in San Francisco

[Gabriel Hurley]

I'll be there as well! Either set of dates works for me.

- Gabriel

-- 
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/-/hCK2OwboH40J.
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: Deploying Feature in manage.py

[Gabriel Hurley]

Having done deployments of varying scales and having spent a lot of time 
with Fabric, as well as some with Chef, Puppet, etc. I don't think there's 
any way we can build a tool that will meet any but the absolute simplest of 
needs without unnecessarily re-inventing a lot of wheels.

However, if you're interested in pursuing this project then this is a great 
space for a 3rd-party app that ties in the features you'd like to see as 
management commands. There's absolutely no reason this needs to live in core 
and if it gains traction with the community then I could see it being a 
wonderfully useful asset.

All the best,

- Gabriel

-- 
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/-/uidNz6GYzn8J.
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: Sane defaults for Startapp and Startproject

[Gabriel Hurley]

I think there is sufficient interest in the idea of a "how to organize your 
Django project" page in the documentation that it would be worth beginning 
work on a patch for one, much in the way that the "How to contribute to 
Django"/"Spirit of contributing" page got started.

That means:

  1. Opening a ticket for it if one doesn't already exist.
  2. Creating a wiki page to start crafting the text where everyone can 
contribute.
  3. Writing an initial draft to get the ball rolling.
  4. Working with the mailing list to garner attention and consensus.
  5. Writing a patch in proper reST once general consensus has been reached.

I think there are going to be quite a few different opinions on this topic, 
so structuring it in such a way as to provide "Common patterns" with pros 
and cons of each would be a wise way to go about it.

All the best,

- Gabriel

-- 
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/-/JKsL_X5vzSkJ.
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: Sane defaults for Startapp and Startproject

[Gabriel Hurley]

Thanks for the suggestions, Rich... I'll try not to repeat what others have 
said, but have a couple notes to add:

should create ./static, ./uploads and ./newproj and ./newproj/ 
> templates 
>

I could get behind static, and *maybe* even templates, but absolutely not 
uploads. I would argue against Django automatically creating any directories 
inside your project that you wouldn't ever want to check into your VCS, and 
I definitely don't want my user uploads ever getting checked in to my repos. 
As others have noted, there are many other solutions for how those should be 
handled.
 

> and at the end, the commonly used from local settings import * block. 
>

Others have already spoken out against this, but as extra corroboration see 
our lovely BDFL Jacob's "Best and Worst of 
Django" 
presentation (particularly slides 46-51) where he argues against this 
explicitly (and rightly, IMHO).
 

As for the rest: I don't believe in adding magic in order to save a couple 
lines of typing (explicit > implicit), but I am in favor of things we can do 
to encourage best practices where the community agrees. So to that task I 
wish you excellent luck!

All the best,

- Gabriel

-- 
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/-/s10m_HFxT68J.
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: Custom transform in django docs

[Gabriel Hurley]

Definitely in favor of removing it. I've run into that before and been 
frustrated by hacking around the strange indentation.

- Gabriel

-- 
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/-/zdu_zw7iOVIJ.
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 messages framework

[Gabriel Hurley]

I'm a fan of the idea, with the caveat that it can't break any 
backwards-compatibility with the current syntax. As such, that could either 
entail reworking the current methods that add messages to accept a template 
string as a keyword argument (and making the positional "message" argument 
optional), or implementing it as a separate shortcut to allow further 
flexibility.

All the best,

- Gabriel

-- 
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/-/5awBysh9q9MJ.
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

[Gabriel Hurley]

+1 on deprecating databrowse. Dead code should be excised.

As for webdesign, why not roll the one piece in it (the marginally-useful 
lorem tag) into the main library and deprecate the hook in contrib?

-0 on deprecating formtools.

For the sake of argument I could see admindocs being deprecated and spun off 
into it's own app.

Otherwise I can't see any other contrib modules being deprecated in the near 
future.

All the best,

- Gabriel

-- 
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/-/x09VXWhBci8J.
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: Form Rendering API Proposal

[Gabriel Hurley]

I just want to quickly add a second mention for the importance of being able 
to control row-level groupings of fields, as well as row-level attributes 
such as classes. It's a problem I've run into many times and would love to 
have included in the new form-rendering solution.

All the best,

- Gabriel

-- 
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/-/w8E5-oX2gJQJ.
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: Adding UI and UX fields to Trac

[Gabriel Hurley]

A single flag for "UI/UX" would be my first choice, with just "UI" being 
second. Differentiating the two isn't going to produce a lot of useful 
information at this juncture. Certainly fine with me to go ahead and add 
something for it, though.

- Gabriel

-- 
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/-/cW5yQUdPdlFBaFFK.
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: pure sql fixtures for tests

[Gabriel Hurley]

This seems antithetical to the design goals of Django's ORM (e.g. *not* 
being an interface for SQL but an abstraction layer for managing objects). 
While it may not be as pretty to execute your raw SQL in your setUp method, 
that seems like the right way to handle cases of specialized SQL such as 
yours. There's no reason you can't store that SQL in a file with your 
fixtures and read it in to execute it.

Moreover, fixtures as a concept aren't representative of the state of a 
database, they are serialized objects which should be storage-system 
agnostic (hopefully).

All in all I think the necessary hooks already exist to accomplish what you 
need, so I'd be -1 on adding a feature like this and changing the purpose 
and meaning of fixture loading.

All the best,

- Gabriel

-- 
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: PatchHammer 40,000

[Gabriel Hurley]

That should be relatively trivial to hook up remotely via the XML-RPC API, 
similarly to the script Jacob posted here: https://gist.github.com/933116

- Gabriel

-- 
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: math tag

[Gabriel Hurley]

This is a case where there's nothing stopping anyone (as far as I can 
see) from creating such a tag as an external library. If it garners 
significant community support and has numerous compelling use cases, then it 
would be a candidate for inclusion in trunk. If, in developing it, there 
turn out to be issues within Django that need to be resolved to make it 
possible then those could be fixed.

But as an immediate feature proposal for trunk, this one's been pretty 
strongly shot down.

-- 
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: FloatField will not handle infinity values (Ticket #4287)

[Gabriel Hurley]

This seems to me like a problem best-solved by adding another attribute to 
BaseDatabaseFeatures so that DBs which don't support infinity can fail 
loudly, obviously, and preemptively. That make sense?

- Gabriel

-- 
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: [5-for-1] Review request

[Gabriel Hurley]

I noticed the "TODO" on the bottom of that page you linked... if you 
actually want to write something up for the docs about reviewing tickets 
(based on the discussion that's happened on the list the last few days) I'd 
suggest adding it to the /docs/howto/contribute section. Feel free to ping 
me if you get a patch written and I'll work with you on getting it in.

- Gabriel

-- 
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: Suggestion: a new "nature" field in Trac

[Gabriel Hurley]

+1 on blocker being a severity, -0 on "other" as an option here. +0 on the 
others. Happy to donate a couple hours reviewing a chunk of tickets in a 
coordinated way if we decide to do that.

- Gabriel

-- 
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: Trac components cleanup

[Gabriel Hurley]

The component re-organization is done now, as per Julien's (and Jannis') 
suggestions above. I even re-categorized the 84 tickets that were in 
"Contrib apps" into their new separate contrib.foo components (thank god for 
Trac bulk modify privileges!).

The organization definitely makes more sense now, though I fear the list has 
actually grown longer (due to all the contrib apps that were lumped together 
before). If anything, that should be a reminder that some of those apps are 
rather stale these days, but that's a conversation for another day. ;-)

If you find any problems feel free to let me know.

All the best,

- Gabriel

-- 
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: State of X-Sendfile support?

[Gabriel Hurley]

FWIW, I vaguely recall how the last thread on X-sendfile and the files API 
got conflated (derailed?) and as far as I understood it then and as far as I 
understand it now, they're related only because some backends (which we 
currently don't directly support) are difficult to work with without such 
conflation. That doesn't mean we can't solve one problem at a time, however. 
Especially when one problem *is* simple, and the other is not.

They're both good goals, and problems worth solving, but IMHO there's no 
reason that they couldn't be two separate features.

+1 on a simple solution for X-sendfile, +0 on making the file API more 
compatible with a broader range of backends, -1 for solving both issues 
together.

- Gabriel

-- 
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: Proposal: switch to HTML5 for bundled templates

[Gabriel Hurley]

Switching to the HTML5 doctype won't hurt IE6 rendering (having dealt with 
this myself several times). To the best of my knowledge--from my own tests 
and third-party sources--using the new input attributes also doesn't hurt 
IE6. However, if we start delving deeper into HTML5 and using the new HTML5 
elements, etc. we will definitely hit problems very quickly. Techniques for 
solving those problems are pretty readily available these days, but I don't 
think we have any reason to go there right now.

All the same, I'd still rather give people the choice and ability to change 
output rendering rather than simply making a unilateral change. I'd love for 
our default to be the modern choice as long as it's an easily changeable 
option!

But hey, aren't we starting to stray into... ::gasp:: front-end territory 
here?! Where's our Benevolent Designer For Life? ;-)

All the best,

- Gabriel

-- 
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: Trac components cleanup

[Gabriel Hurley]

I can work on it late tonight (about 6-8 hours from now) if no one else gets 
to it.

All the best,

- Gabriel

-- 
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: Proposal: remove compatibility for old signing functions

[Gabriel Hurley]

+1, this seemed kludgy to me and had potential insecurities as it was. 
You're only as strong as your weakest link, right?

All the best,

- Gabriel

-- 
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: Proposal: switch to HTML5 for bundled templates

[Gabriel Hurley]

While on a personal level I agree wholeheartedly about moving to HTML5, I do 
have reservations about it from the perspective of Django's "enterprise" 
customers (AKA the ones with legacy and bureaucratic issues).

Thankfully we don't have major backwards-compatibility issues to deal with 
from a functionality standpoint with the HTML5 doctype... but organizations 
with validation requirements certainly still have a stake in this decision.

Provided the template-based form widget rendering proposal gets implemented, 
perhaps the 1.4 documentation could give a full how-to on controlling the 
output rendering so that those folks who need valid output according to one 
spec or another have an obvious resource to turn to.

This is also probably an area where a third-party app could fill in the gap 
to offer various libraries of doctypes and widgets fairly easily.

On the whole I'm +0 in the name of progress.

All the best,

- Gabriel

-- 
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.3: running test suit

[Gabriel Hurley]

The extra object is in the initial_data.json fixture which is loaded 
automatically. If you're not seeing that object than something is wrong with 
your initial_data fixture loading.

- Gabriel

-- 
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: Enhanced auth.User

[Gabriel Hurley]

I would further add that the goal of any refactor in this area is not to add 
a wishlist of enhancements to the existing User model (though that may 
happen in tandem), but to truly make the framework extensible/agnostic in a 
way which it currently is not.

All the best,

- Gabriel

-- 
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: CSRF Header broken on uWSGI

[Gabriel Hurley]

>From the information you've given I can't say what's causing your process to 
hang, but as to your other point about jQuery... yes, jQuery 1.5.0 had a 
legitimate bug  that prevented headers 
from being properly set on AJAX requests. It was one of the reasons they 
pushed out the 1.5.1 release so quickly. In general we haven't documented 
cases where specific point releases of third party libraries had known bugs, 
but since I got bit by this as well I'm more inclined than usual to make an 
exception. Obviously, though, the impact of that problem will decrease over 
time as people catch up on newer jQuery releases.

All the best,

- Gabriel

-- 
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: Trac components cleanup

[Gabriel Hurley]

I'm not endorsing any specific set of changes here, but I can address the 
feasibility of making the changes in Trac:

>From empirical testing on my own Trac installation (running 0.11 currently, 
Django is on 0.12) updates to components, resolutions, etc. all propagate 
correctly when edited through the admin. Whether that's because Trac's 
backend is using foreignkeys (as one might hope), or whether it's simply 
wired up with the right hooks to update the database fields when the values 
are edited I don't know. But either way, it works as you'd expect.

So, whatever changes we decide to make, they shouldn't be hard to implement.

- Gabriel

-- 
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: "needsinfo": resolution vs. triage stage

[Gabriel Hurley]

Thanks for the input. The consensus is clear.

#14702 is now closed! (as fixed)

I wanted to close it as "needsinfo" just for the humor of it, but oh well. 
Enjoy the new resolution (and accompanying docs)!

- Gabriel

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

"needsinfo": resolution vs. triage stage

[Gabriel Hurley]

In regards to #14702 , which so 
far has been a universally favored idea, there's one lingering issue:

Do we want to implement it as a resolution (i.e. you close a ticket as 
"needsinfo" and the reporter reopens to provide the information) or as a 
triage stage (like DDN, RFC, etc.)?

Here's a quick overview arguments for each...

Resolution:


   - Keeps Trac free from the clutter of old tickets that the author never 
   returns to clarify.
   - Indicates clearly that the ticket in it's current state is unresolvable 
   and has no forward path.
   - Will show up more prominently in the timeline (tickets being 
   closed/reopened attract attention).

Triage stage:


   - May intimidate new contributors to see that their ticket was "closed".
   - Doesn't discount the fact that there may be a valid issue here which we 
   don't want to forget about.

I'll disclose my personal bias that I'm +1 for the resolution and -0 for the 
triage stage (I think another stage just adds clutter).

I'd like to put it to a vote, though, and see what the community (and the 
core team) decides.

*So which shall it be: resolution or triage stage?*
*
*
I'll take care of the docs patch and the Trac admin change once its decided.

All the best,

- Gabriel

-- 
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: psycopg2.OperationalError: could not connect to server

[Gabriel Hurley]

This list is for the development of Django itself. Please try asking your 
question on the Django Users list<https://groups.google.com/group/django-users>
.

All the best,

- Gabriel Hurley

-- 
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: Your thoughts on the Secure Web Application Framework Manifesto

[Gabriel Hurley]

I've got one bit of feedback to offer on the document (which I did
bookmark for future reference):

Monolithic documents present a huge problem for finding, using and
retaining information.

A very useful and interesting extension of this type of project would
be to work with people who have experience with information
architecture and data visualization to find new ways of presenting
this information. An interface that was simple, clear, interactive,
layered and multi-faceted would make your manifesto into a drastically
more valuable tool.

I would love to be able to sit down with an interface to all the
information you've gathered and "explore it". Ideally it would allow
me to visually follow threads of commonalities in vulnerabilities, see
clusters of the most common problem areas, and zoom in to the level of
detail you've gathered on any individual item if I so choose.

Either way, thank you for providing an interesting resource.

All the best,

    - Gabriel Hurley

On Feb 21, 5:09 pm, Rohit Sethi <rkli...@gmail.com> wrote:
> Russell, awesome feedback. Thanks for being candid. We are on the same
> page that the manifesto is really not all that important in and of
> itself: The document piece is really only designed to give frameworks
> a platform to say "hey, these are what we support" so that web app
> developers building security-sensitive apps get an idea of how much
> help they'll get from various framework.
>
> I didn't want to bring this up until I got at least one response, but
> my team is busy seeing which manifesto requirements are:
>
> a) Already being fulfilled by Django (great- no more work to be done!)
> b) Have been fulfilled elsewhere (e.g. OWASP ESAPI for Python) and
> could be built into Django
> c) Have not yet been done
>
> We'll be looking to address b) and c) by either porting or building
> ourselves. We hope we can get your feedback on why some things aren't
> being implemented (if we can't find a pre-existing discussion in
> existing tickets and/or this group).
>
> The manifesto is designed to only a starting point: it's taking
> several vulnerabilities, beyond the OWASP top 10, into something
> targeted specifically for frameworks. It's definitely not intended to
> be implemented by every framework in the world - nor should it be.
>
> So, we (myself and at least four of our developers) will be working
> closely with the Django community. I will be watching the list closely
> and providing feedback when I can.
>
> Looking forward to working with you
>
> Cheers,
>
> Rohit
>
> On Feb 21, 7:42 pm, Russell Keith-Magee <russ...@keith-magee.com>
> wrote:
>
>
>
>
>
>
>
> > On Mon, Feb 21, 2011 at 11:21 PM, Rohit Sethi <rkli...@gmail.com> wrote:
> > > Django devs, I wanted to thank you for a truly awesome framework.
> > > Programming with Python, and web app dev in Django, is truly a
> > > pleasure. Our company, Security Compass, uses Django quite
> > > substantially internally.
>
> > > We put together a document called the Secure Web Application Framework
> > > Manifesto for the Open Web Application Security Project (OWASP) - see:
> > >http://www.owasp.org/index.php/Projects/OWASP_Secure_Web_Application_...
>
> > > I would love to get your feedback about this project. How much of this
> > > is realistic and how much of it is pie in the sky? Is it relevant for
> > > you? If not, how does this document need to change to become relevant?
> > > Clearly, Django takes security seriously which is a major reason we
> > > use it. Please feel free to be candid - if you think the document
> > > sucks and could never be used, it's important you let us know that
> > > too.
>
> > Hi Rohit,
>
> > A lot of effort has clearly gone into this document. I haven't gone
> > through it with a fine-toothed comb, but it seems like a reasonably
> > thorough discussion of security issues affecting web frameworks.
>
> > However, if you're looking for frank feedback, here goes:
>
> > Who exactly is the intended audience for this document? What is/are
> > the action item(s) stemming from it?
>
> > More broadly, what it is you are hoping to achieve by writing this document?
>
> > Reading between the lines, I'm guessing you would like to see every
> > web framework in the world adhering to best practices, with no obvious
> > and know security vulnerabilities. This is a laudable goal, and I
> > certainly share this aspiration.
>
> > But there are two ways to achieve this goal. The first is to sit in a
> > tower, passing down Solomonic judgements on "the way it should be".
> > The second is to a

Re: Suggestion: a new "nature" field in Trac

[Gabriel Hurley]

I'm still in favor of adding the "needsinfo" resolution and would love to 
see that happen... I guess technically I could even do that one myself via 
Trac's web admin if we're all agreed on it.

I'm ambivalent about adding the "ticket type" field back in, though. It can 
be useful, but it *is* an extra item to keep managed and argue about... My 
bigger concern, though, is the 1700+ existing tickets which will be 
uncategorized. It would end up meaning that using that flag for queries in 
Trac wouldn't give you a complete picture (at least not for a very long time 
while things catch up).

All the best,

- Gabriel

-- 
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: Contributing Guide Request For Input

[Gabriel Hurley]

I've added a patch to ticket #14401<http://code.djangoproject.com/ticket/14401> 
based 
on the contributions people made to the wiki. This is the final call for 
comments and review before it gets officially added.

Thanks!

- Gabriel Hurley

-- 
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 Design] Inline debugging

[Gabriel Hurley]

I'm not a fan of one-size-fits-all debugging tools. The last several replies 
clearly show the variety of preferences people have for the already-existing 
options. Adding a setting that allows you to replace the debugging module 
also implies the replacement modules support a common API, which may not be 
true in plenty of cases.

If we can make changes that make integration easier for the great 3rd-party 
tools that are out there, that'd be excellent. I'm not sure what the current 
pain-points are for the developers of those tools off the top of my head, 
however.

The concept of the feature is great, and I do like the idea of having a 
command line flag to enable it, but the solution on that ticket doesn't 
really do it for me overall. Getting more consensus on what would make 
integrating these tools easier would be a good place to start, IMHO.

All the best,

- Gabriel

-- 
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: contributing to django as a part of master thersis

[Gabriel Hurley]

Russ' points on number 3 are very interesting. Regarding multi-read/write 
There are a number of places throughout the code where DB operations scale 
linearly when they could be constant (in terms of queries). As for 
multi-reads, at some point there's going to be a limit to what you can 
combine to produce a performance boost vs. just generating more complexity 
and overhead. The way writes work on M2M relations do bug me personally, but 
it's never been a high-priority issue on my list.

That said, in the context of "extremely high traffic sites" the types of 
issues you've described are already mitigated by good use of caching, 
database architecture, etc. using existing facilities and tools. You said 
you interned at Facebook so obviously you've seen some of this in action. As 
an aside, I'd bet good money their site would be faster and scale far better 
if it were using Django rather than their hacked up "PHP custom-compiled 
into C" mess that they've chosen to stick with. All the same Django doesn't 
necessarily need to take the place of proper external tools, planning and 
expertise as long as it provides good hooks to put them all to use.

Asynchronous DB access would be very cool. Obviously it isn't going to be 
supported by many of the backends Django ships with, but it would be an 
extremely interesting feature. From a philosophical standpoint I like it 
because it fits the concept of Django's ORM not being an abstraction of SQL 
but rather a means of dealing with *objects*. Also, I believe several of the 
non-rel database engines support asynchronous operations as well, so it 
would be a boon to those projects as well. My big concern there would be in 
answering the question "how do you know when is the *right* time to fetch 
the data asynchronously?" I could envision this bogging down a DB if 
configured poorly in the same way that badly-done AJAX can be a mess on a 
web server.

Either way, there's certainly some meat on the bones of that last idea. I'd 
be very curious to see a more thorough proposal/set of ideas (feature for 
the 1.4 or 1.5 timeframe?).

All the best,

- Gabriel Hurley

-- 
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: Interested in contributing to Django

[Gabriel Hurley]

Hi Vivek,

It's great to hear you're interested in contributing! This year's GSOC is 
just getting underway and while Django will likely participate as it has in 
years past, we're not quite at that stage yet.

However, if you're serious about GSOC you'll have a much better chance of 
being selected if you've gotten your feet wet with contributing to Django 
already. So definitely take on some issues you're interested in.

If you'd like some ideas on how to get started, we are actually working on a 
new "how to" guide for new contributors right now! It currently lives in the 
wiki so the community can add to it, but it'd be great if you want to give 
it a read and give some feedback on how it could be made more useful to you 
as a new contributor! Check it out here:

http://code.djangoproject.com/wiki/ContributingHowTo

If you have further questions you can always ask here on the mailing list or 
in the #django-dev IRC channel.

All the best,

- Gabriel

-- 
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: contrib.sites and multitenancy

[Gabriel Hurley]

On Wednesday, January 19, 2011 12:01:57 PM UTC-8, Carl Meyer wrote:
>
> Contrib.flatpages is an example 
> of this -- the flatpage model has an FK to Site, so it doesn't make 
> sense for flatpages to call a method which might return a Site object 
> or might return something else. It needs a real Site object. In my 
> mind, this use case is why deprecating Site.objects.get_current() is 
> not a good option.The current patch on #15089 deprecates 


I'm very much in agreement here. This is what I ran into when I first tried 
to replace all the calls to Site.objects.get_current_site() with 
get_current_site()... there simply *are* cases where a Site object is 
required, and using the object manager is the right way to do it, as you 
pointed out.
 

> In my mind, the introduction of a multitenancy hook (in the 1.4 
> timeframe) could then look something like this:
>

Also agreed on the 1.4 timeframe. While there is a valid concern for making 
sure that get_current_site() (introduced in 1.3) doesn't end up getting 
changed in 1.4, this whole task seems like it's snowballing a small feature 
whose main purpose was to be more DRY into a large feature with a totally 
different goal, and doing so very late in the game for the 1.3 release 
cycle.
 

> * Add an optional "request" argument to Site.objects.get_current_site(). If 
>
> SITES_BACKEND is set and Site.objects.get_current() is not passed the 
> request, it's an error. But existing code, with no SITE_BACKEND, 
> continues to work fine calling Site.objects.get_current() with no 
> request.
>

I'm a little uneasy about this... I think it would be an error for 
Site.objects.get_current() to ever return an object which is not a Site 
instance, and if we're dealing with arbitrary callables from a SITES_BACKEND 
setting being responsible for returning a Site-like object it seems like 
this could break in non-obvious ways.

What that means to me is that while you might want 
Site.objects.get_current_site() to have multiple ways of retrieving the 
current Site object based on data in the request, I don't think those should 
be conflated with the arbitrary SITES_BACKEND callables. I'd rather see 
Site.objects.get_current_site() try more ways of getting the current site if 
a request is passed in, and/or have a separate method on the Site manager 
that can take a request and do request-based lookups. Expand the options on 
the built-in manager but keep them finite.

I'd say all the SITES_BACKEND functionality should remain tied to 
get_current_site() and out of the Site manager.
 

> * Both Site.objects.get_current() and get_current_site() call 
> SITE_BACKEND, if its set, and return whatever it returns. 
> Site.objects.get_current() should check this return value and error if 
> its not an instance of the Site model. get_current_site() doesn't care 
> what it returns. 
>

See my previous comment. Raising an exception if the SITES_BACKEND callable 
returns an object of the wrong type is one way to handle it, I'm just not 
sure it's my favorite solution. Seems brittle given that a developer using a 
custom callable might not think about how other apps (especially in contrib) 
are going to interact with the return value of their callable.
 

That's what I've got for now. Thanks to legutierr for the work on the patch 
so far.

All the best,

- Gabriel

-- 
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: Status of InstalledAppsRevision, soc2010/app-loading branch?

[Gabriel Hurley]

I haven't been tracking it closely, but last I heard on the subject is that 
it's on target for the 1.4 release cycle. So basically once we get 1.3 
pushed out (and have a little rest) that'll be towards the top of the heap 
to be wrapped up and worked into trunk. There's almost certainly still some 
polishing that needs to happen on it, but like Russ said, it's looking 
reasonably good.

All the best,

- Gabriel

-- 
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: contrib.sites and multitenancy

[Gabriel Hurley]

I would be more in favor of seeing a new setting to configure 
`get_current_site()` than seeing the existing `SITE_ID` setting shoehorned 
into a new purpose (and being permanently misnamed for legacy reasons). For 
the sake of allowing complete customization of the site lookup process I 
suppose a new settings makes sense here.

As I noted on the ticket, I'm not entirely sure that deprecating 
Site.objects.get_current_site() is necessary, and there are arguments to be 
made for both sides. Avoiding user confusion is a good thing, but there are 
cases where authors may want to make use of the Site model exclusively, in 
which case the shortcut and its associated caching is still useful.

In response to Yuri:

 1. You would not need the Sites Framework installed. The get_current_site 
function works by checking to see if contrib.sites is installed, and 
returning a RequestSite if not. RequestSite is just a generic object which 
implements a common interface with the Site model. Using a custom callable 
could similarly bypass any need for the Site model if so desired, or it 
could simply be a different way to retrieve a Site object.

 2. Allowing a custom callable solves the problem of being tied to a 
particular model, because your custom callable can return an object of any 
type you like so long as it implements the appropriate hooks (as RequestSite 
does). This practice is generally referred to as "duck typing".

The "correct interface"--as I understand it--is that all authors should be 
moving towards get_current_site() as the single point of entry for gaining 
access to a Site-like object, and that you should not expect the returned 
object to be a Site instance, but simply that it will behave like one and 
have an equivalent base set of attributes and methods.

All the best,

- Gabriel

-- 
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: Customizable Separator for slugify

[Gabriel Hurley]

I did actually just come up with two problems involved in having a 
customizable separator for slugify:

1) SlugField would also have to take a parameter to define the separator so 
that there wouldn't be inconsistencies in the output of SlugField and 
slugify. This seems like it would be a big pitfall for potential user error.

2) For users who have been using slugify as-is, but then change to a new 
separator: if you stored a URL path component in your DB with a SlugField 
then changed the slugify separator from a dash to a something else, not only 
would you end up with an inconsistent mix of things in your DB, if you ever 
tried to reconstruct that same URL using slugify you wouldn't come up with 
the same result.

- Gabriel

-- 
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: Customizable Separator for slugify

[Gabriel Hurley]

Adding Yet Another Setting doesn't seem like much of a solution here.

To the original poster's question I'd say that using anything but dashes for 
slugify would be very uncommon, but I don't see any reason why the slugify 
filter *couldn't* take an optional parameter to define what token should be 
used if some people would find that useful. Providing a patch against trunk 
with tests and docs are a good way to see it happen.

The issue of Russian (or any other unicode) characters with slugify is an 
unrelated issue. I wasn't around for the initial creation of the slugify 
filter, but I'm sure the conversion to ascii in it is because Internet 
Explorer didn't support IDNs until version 7. While a majority of browsers 
support IDNs now, it's still not 100%. Off the top of my head I'm not 
entirely sure what the right solution for Django is for that issue, but 
there are quite a lot of possible solutions that don't introduce new 
settings.

All the best,

- Gabriel

-- 
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: Regressions in 1.2.4

[Gabriel Hurley]

On Thursday, January 6, 2011 6:29:32 AM UTC-8, James Bennett wrote:
>
> It'd also be a major
> maintenance/bookkeeping headache and, I think, *more* likely to result
> in us accidentally crossing the streams while trying to keep track of
> what goes on in which branch.
>
I have the same concern here. With an A.B.C.D system my concern is that a 
lot of people would simply be confused. It'd be confusing enough for the 
core team to manage, let alone trying to explain it to users.

> Personally, I'd be in favor of keeping the overall release process
> as-is -- one release branch, which gets all bugfixes while applicable,
> plus highlighting the individual security patches as released -- and
> providing better documentation of what the release branch really is
> (i.e., not a security-only branch) and how to pull just a security
> update if that's what you want.
>
 +1 on that. As long as it's easy for people who *only* want the security 
patches to get them without any other updates I think that's fine.

>From a slightly more philosophical point of view, I'll add two other points 
of consideration:

1) Even security patches can introduce regressions, so creating a 
security-fix only branch doesn't inherently provide a regression-free 
branch; it only make it less likely by decreasing the number of changes 
which could potentially contain a bug.

2) Any bug is a potential liability for a user. While the bugs that are 
serious enough to trigger security releases are more urgent, there is a 
statistical net gain to having all the fixes included in the branch. While 
it's psychologically frustrating to a user to upgrade and be faced with a 
new regression that was previously unknown, from a purely mathematical 
standpoint you're actually better off in the aggregate.

All that is to say that a 1.2.5 release is completely appropriate and I'm +1 
for it, and I think it's better to continue as we have and be as responsive 
and responsible as possible when new regressions are found.

That's my two cents,

- Gabriel

-- 
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: Style guide for section headers in docs?

[Gabriel Hurley]

And that's what I get for having an MLA reference sitting on my desk...

- Gabriel

-- 
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: ForeignKey with null=True

[Gabriel Hurley]

I'm in favor of the patch you've provided, Luke. Raising an exception seems 
like the best option here to me.

While it *is* a logical error to get the related objects of an unsaved 
instance, the current behavior seems buggy and (as Ian Clelland points out) 
it can be potentially harmful.

FWIW, I'm almost certain Russ's original wontfix was based on the same 
understanding we all had upon first reading the ticket. It was only when I 
tested it myself that I saw the behavior the OP was really trying to 
describe.

All the best,

- Gabriel

-- 
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: Purpose of constant_time_compare?

[Gabriel Hurley]

You wanna hand over your paycheck now, or later? :-)


I know someone with a functional white-hat timing attack script sitting
on their laptop. They've been honing the statistical analysis to get
the number of data points needed down to a less noticeable size, but
the technique can already be successfully applied.


To your latter point, you can run a timing attack as slowly as you
like, and a lot of sites have very poor monitoring for things like
404s. A month or more of patient low-level attacking to gain access to
a prime target is well worth it.


The point being that we all ought to take timing attacks seriously.
They're not nearly as unrealistic as people think.


All the best,


- Gabriel

-- 
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: Documentation style guide hint for section headers?

[Gabriel Hurley]

Agreed with Alex. I brought this up on IRC a month or so ago, and the
(small) consensus was that it'd be great to have the ":real markup:"
generate TOC entries the way we want it to, but that doing so involves
hacking Sphinx (or at best writing a plugin for it) and nobody was
ready to jump into that project at the time. The issue had been raised
before on the Sphinx mailing list, but didn't get a lot of response.

However, to answer your question for the time being:

In the reference documentation I don't mind the use of the backticks
in the headings for methods/attributes. Since the backticks cause the
entry in the TOC to show up in white instead of yellow it offers a
visual distinction which I think is helpful. I'd carry that
distinction through to any future Sphinx improvements that would allow
us to get rid of those headings altogether.

All the best,

- Gabriel



On Nov 25, 12:27 pm, Alex Gaynor  wrote:
> On Thu, Nov 25, 2010 at 2:25 PM, Adam V.  wrote:
> > The docs seem a bit inconsistent on the use of raw lines for headings
> > that describe classes/methods/attributes.
>
> > The stated preference is to use a directive before the heading to make
> > it easier to link. Is there also a preference on whether these
> > headings should be raw quoted or normal text?
>
> > FWIW, my personal preference would be to remove quoting from API docs,
> > so for instance, remove it from the headings on this page
> >http://docs.djangoproject.com/en/dev/ref/forms/fields/for the field
> > and class names.
>
> > But mostly I just want to know what the official stance is, if any.
>
> > Thanks.
>
> > --
> > 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 
> > athttp://groups.google.com/group/django-developers?hl=en.
>
> Personally I'd prefer that we only have the :real-markup:, however as
> it doesn't generate actual TOC entries it makes them near useless.  If
> someone, , were to figure out how to have those it would be
> awesome ;)
>
> Alex
>
> --
> "I disapprove of what you say, but I will defend to the death your
> right to say it." -- Voltaire
> "The people's good is the highest law." -- Cicero
> "Code can always be simpler than you think, but never as simple as you
> want" -- Me

-- 
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: Relation between models of different applications

[Gabriel Hurley]

Hi Alex,

Neither of the ideas you mentioned (making auth.user more extensible/
replaceable and improvements to app loading) are new to the Django
community. In fact, both were candidates for last year's Google Summer
of Code. The app loading project even got accepted and had a good deal
of work done on it and will likely be merged into a not-too-distant
Django release (not 1.3).

Both issues are very complex, and there have been extensive
discussions in Trac, on this list, in the IRC logs and everywhere else
you can imagine. Everyone agrees on the problems and the potential
benefits, but finding the right solutions is very difficult.

For some basic reading, I'd suggest taking a look at the GSOC 2010
wiki page. It's at least got a high-level overview of the issues
associated with both of those ideas:

http://code.djangoproject.com/wiki/SummerOfCode2010

A search on this mailing list will turn up plenty more info.

If you have new ideas on how to solve these problems your input is
always welcome; just be sure and familiarize yourself with the
existing (substantial) body of work on the subject as well.

All the best,

   - Gabriel

On Nov 18, 8:20 pm, Alex Kamedov  wrote:
> Hi all!
>
> It is really hard to replace some django.contrib modules on your own now.
> I'm have many reason to replace django.contrib.auth on my own module now
> in my current project, but in this way I've need to rewrite many others
> applications related with django.contrib.auth, if I want to use it. The my
> project has no long time and ends before any implementation of ideas from
> this message, but I think about future.
>
> Application abstraction is simply collection of models, views and others in
> Django Framework now. I propose extend application abstraction with adding
> something like application type and adding model relation by application
> type.
>
> Example of really reusable application:
>
> auth = get_app('auth')
>
> class MyModel(models.Model):
>     user = models.ForeignKey(auth.User)
>     ...
>
> get_app can raise AppIsNotInstalled exception, if required application type
> is not specified in project settings.
>
> Proposed changes in project settings to register installed applications:
>
> install_applications(
>     'django.contrib.contenttypes',
>     'django.contrib.sessions',
>     ...
>     auth = 'django.contrib.auth',
>     ...
> )
>
> install_applications adds applications to INSTALLED_APPS.
>
> Cheers!
>
> Alex Kamedov

-- 
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: RFC: Add a "needinfo" state to triaging

[Gabriel Hurley]

> >> Example workflow:
>
> >>  * Alice creates a ticket, with an incomplete patch (no tests,
> >> incorrect implementation)
> >>  * Bob reviews the patch, marks it "Accepted, needs tests, patch needs
> >> improvement"
> >>  * Alice updates the patch, adding tests (but not changing the
> >> implemenation). She removes the two flags.
> >>  * Charlie reviews the patch, resets the 'patch needs improvement flag'
> >>  * Alice updates the patch, fixing the implementation. She removes the
> >> needs improvement flag.
> >>  * Daisy reviews the patch, marks it RFC.
>
> >> At any point in this process, a search for tickets "Accepted & has
> >> patch & !needs improvement & !needs docs  & !needs tests" will reveal
> >> tickets that need review of some kind. These tickets either need to be
> >> moved to RFC, or need to have their flags set to indicate the
> >> deficiency in the patch.
>
> > I admit I am guilty of breaking the (unknown to me) rule/etiquette of
> > marking my own tickets RFC as a last resort to move them forward.
>
> To date, this hasn't been formally documented. This is something that
> #14401 will hopefully address.

Thanks for the example workflow. I'll definitely incorporate that into
#14401. I'm gonna give that ticket one last call for "words of wisdom"
from anyone who'd like to contribute to the wiki, then write it up as
a patch.

-- 
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: RFC: Add a "needinfo" state to triaging

[Gabriel Hurley]

Bear in mind that this is a *very* old Trac installation... ;-)

I don't have access to that server to see if the TracAdmin module is
current enough to support the "resolution add " command. If so,
that'd be the easy way. If not, like Daniel said, it's straight to the
DB!

- Gabriel

On Nov 16, 5:37 pm, Daniel Moisset  wrote:
> On Tue, Nov 16, 2010 at 12:02 PM, Luke Plant  wrote:
>
> > This will also require a change to Trac, which I for one don't know how
> > to do (I don't see the configuration pages I would need in the Trac
> > admin interface).
>
> If you have the admin module ui enabled and TRAC_ADMIN permissions,
> you should see an admin link to the right displaying a dashboard with
> a "resolutions" link at the left where you can add ticket resolutions.
> If you don't... you should, it helps a lot :)
>
> Otherwise you'll need to add a row to a table in the trac db.
>
> Regards,
>
>    D.

-- 
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: RFC: Add a "needinfo" state to triaging

[Gabriel Hurley]

> Maybe trac can be improved in this respect by notifying
> reviewers when tickets that they have closed, or accepted, or provided
> feedback on, are updated.

In my experience Trac already does that... when a ticket is changed
(by anyone), the reporter, the owner, anyone on the cc list, and
anyone who has changed the ticket (by adding a comment, triaging,
etc.) gets an email. I get quite a few notifications every day from
Django's Trac install. I can only imagine what it's like for the most
active devs.

The issue which has already been alluded to is that these are
unfiltered streams of information. Getting 30 emails that say someone
added themselves as a CC on this ticket or that ticket makes it less
likely that you'll see the one email where someone reviewed a patch
and marked it as RFC. This is where good Trac queries come in.

As always, the rest comes down to the real hours we're all willing and
able to put in :-)

All the best,

- Gabriel

-- 
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: RFC: Add a "needinfo" state to triaging

[Gabriel Hurley]

Having recently set up a Trac installation for another project, I can
tell you that making the actual change will require some hacking in
the trac.ini file. There's no way to do it through the admin.

All the best,

- Gabriel

On Nov 16, 7:02 am, Luke Plant  wrote:
> On Tue, 2010-11-16 at 11:34 -0300, Daniel Moisset wrote:
> > OK... after seeing a generally positive response (even if there's some
> > bikeshedding about the actual implementation which I don't care much
> > about, any of the proposals solve *my* problem ;-) ), how can this be
> > moved forward? I know the process that django changes follow, but I
> > don't know what's the process to change process :) (or who takes the
> > decision)
>
> > Should I open a ticket about this proposal?
>
> Do open a ticket, because we need documentation patches for this, in the
> 'contributing' page. The current page says this:
>
>   “worksforme”
>   Used when the ticket doesn’t contain enough detail to replicate the
>   original bug.
>
> That happens to be very similar to what we are proposing for
> 'needsinfo', so we at least need to think about how 'worksforme' is
> different.
>
> This will also require a change to Trac, which I for one don't know how
> to do (I don't see the configuration pages I would need in the Trac
> admin interface).
>
> My 2 cents on state vs resolution:
>
> If we go for a 'needsinfo' triage state, then at some point we will need
> to go and close ancient tickets which have 'needsinfo' and the original
> reporter has not provided it - presumably closing as INVALID. This will
> require some work to do (manual or scripted), and it may well be
> incorrect - we don't *know* that the report is invalid (according to our
> current definition), we just don't know enough to say it *is* valid.
> That pushes me in the direction of a 'needsinfo' resolution. We just
> have to remember to say 'Please re-open the ticket when the information
> has been provided' - and the 're-open' action is very obvious in Trac -
> more obvious than the 'Triage stage' box.
>
> Regards,
>
> Luke
>
> --
> "I spilled spot remover on my dog. Now he's gone." (Steven Wright)
>
> Luke Plant ||http://lukeplant.me.uk/

-- 
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: RFC: Add a "needinfo" state to triaging

[Gabriel Hurley]

I like this idea for an additional reason:

I look at the Django timeline regularly, but I have ticket detail
changes filtered out. Therefore I *don't* see changes like
"unreviewed" -> "accepted", etc. I do, however, see ticket status
changes (closing, reopening, etc.). Thereby these kinds of changes
will be more visible, especially when a ticket is re-opened,
presumably with more information.

I do have one concern, though... I worry that it might be off-putting
to new contributors who may not provide enough information if their
ticket is *closed* with needsmoreinfo rather than commented on with
"needs more info".

All in all, I like it.

- Gabriel

On Nov 13, 11:58 am, SmileyChris  wrote:
> On Nov 14, 5:52 am, Daniel Moisset  wrote:
>
> > In most cases we sent a reply back
> > to the submitter asking for more details about their problem, but the
> > ticket remains in the "Unreviewed" state, still taking the time of
> > other triagers looking for tickets to review.
>
> > Many projects have a "need information" state to report this
> > situation. I think adding this to the ticket state diagram [1] would
> > be helpful for triagers, and to developers reviewing the ticket list
> > and wanting to know how many tickets actually need to be looked at
> > before a release.
>
> > What are the thoughts of the core team on this?
>
> Here's another more forward solution, requiring less follow-up
> triaging:
> Have a "needsmoreinfo" resolution. Tickets can be closed with that
> with a note to reopen it when more info is provided.

-- 
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: IP addresses in docs.

[Gabriel Hurley]

> Hmm, I don't agree. They are not 'values' in the Python sense - if I
> type 127.0.0.1 at a Python prompt I get a syntax error. They are no more
> values than integers and floats (less so, by the above definition), and
> we don't put any special markup around numbers. They would become values
> if wrapped in quotes to make them Python strings.

I suppose that was my latter point as I reasoned through it: they're
only Python values when wrapped in the quotes to make them a string.

> So I would go for plain text with no quotes - it seems easier to read
> that way and much more in keeping with how I've seen them written
> elsewhere. If they appear in the sentence as text that must be typed,
> then use the double ticks.  So I would have sentences like this:
>
>    Note that the default IP address, 127.0.0.1, is not accessible from
>    other machines on your network
>
>    In the IP address field, enter ``127.0.0.1``.

I can get behind this. It's appropriate to the context, and I never
did like quotes inside backticks.

- Gabriel

-- 
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: making URL resolving/reversing gradually more flexible

[Gabriel Hurley]

> I'm not sure how open the core devs
> are to non-core devs poking around in core parts of the framework
> though.

Anyone and everyone is welcome to write patches for any part of the
framework! There's no sacred portion that only a core dev can touch.
It sounds like you've given thought to the impacts on backwards
compatibility, which is always the biggest concern when dealing with
something as central as URL resolution.

You've done the right thing by opening the thread here, and I'm sure
some of the core folks who are more familiar with this area of the
codebase will weigh in. Having a patch to look at is even better.

Thanks for the contribution and for following through on the right
process!

- Gabriel

-- 
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: IP addresses in docs.

[Gabriel Hurley]

IP addresses definitely don't belong in plain text since they're a
value... so that option can be ruled out.

Between the other two options, I'm torn: I think that using the
``"some_value"`` notation (quotes inside an inline code block) breaks
the visual flow for what's usually an obvious distinction, but it
could also be argued that it's technically correct when you're
representing a string value. The quotes also serve to differentiate
string values from attributes, methods, and other cross-ref targets
which are automatically formatted similarly but without the quotes.

If you hadn't raised the question, I would have used the double
backtick without the quotes. However, thinking about it now I'm
undecided...

Who else would like to weigh in? ;-)

- Gabriel

On Nov 12, 4:55 pm, Łukasz Rekucki  wrote:
> Hi,
>
> While updating a patch for ticket #7735 I noticed that docs are
> inconsistent about how IP addresses should be written. Some are
> surrounded with double back quotes (``) and some are plain text[1].
> After a quick search I also found a quoted one[2].
>
> Is there a preferred way of writing IP addresses in the docs ? Maybe
> we could add a one to contributor docs.
>
> [1]:http://docs.djangoproject.com/en/dev/ref/django-admin/?from=olddocs#r...
> [2]:http://docs.djangoproject.com/en/dev/ref/models/fields/#ipaddressfield
>
> --
> Łukasz Rekucki

-- 
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: Ticket #7817: Extending "with" and "include" tags.

[Gabriel Hurley]

I apologize for the unintentional insult. In retrospect "silly" was a
poor choice of words, and certainly not directed at you specifically,
Jannis. Your opinion is plenty valid, even if we disagree.

The real crux of my argument is this: Django's philosophy of keeping
programming concerns out of templates is a great principle; however,
it creeps into a tacit implication that template authors (in other
words, designers) need to be treated with kid gloves. As someone who
actually came up *as a designer* before I ever learned to code, and
who has been very involved in design communities in the past, I find
the implied necessity of readability specifically for "the target
audience" (designers) mildly pejorative. I'm sure it's not always
meant that way, but that's how it feels when I read these types of
rationales. I'm +1 on readability for readability's sake. -1 on
readability for the sake of "the target audience".

Getting back to the real subject at hand, I like the general human
readability of your syntax (and the current syntax in general), I just
like the "=" a little more. I'm +1 on "=", and +0 on "... as ...".
Either one gets the job done and I'd gladly accept either as they both
solve the same problems.

Thanks!

- Gabriel


On Nov 10, 1:36 am, Jannis Leidel <jan...@leidel.info> wrote:
> On 10.11.2010, at 09:20, Gabriel Hurley wrote:
>
>
>
>
>
>
>
>
>
> > In a fit of coincidental timing, I was just being frustrated by this
> > very issue with inclusion tags today. I'm +1 on supporting kwargs with
> > "=". It is in fact *more* familiar to someone who works with HTML to
> > be able to assign attributes in arbitrary order, for example:
>
> > http://example.com; class="green" id="my_id">
>
> > works the same as:
>
> > http://example.com;>
>
> > whereas this is just nonsense:
>
> > http://example.com; "my_id" "green">
>
> > and this is even more broken:
>
> > <ahttp://example.comas src and my_id as id and green as class>
>
> While I appreciate that you think that's a fact, comparing HTML semantics 
> with those of the template language doesn't proof anything, at the most shows 
> that they both have the concept of parameters. If that's all you are implying 
> we should probably move to using arrow brackets?
>
> > So any argument about not using kwargs being "for template authors"
> > seems a bit silly to me. Designers may not be programmers (though many
> > of them are these days), but the reality of the tools they already use
> > is that this is a familiar syntax.
>
> Please stop trying to make a point by calling my argument silly. I've voiced 
> my strong concerns about the proposed change but agreed with a different 
> proposal.
>
> Jannis
>
>
>
>
>
>
>
> > On Nov 8, 7:16 pm, Peter Baumgartner <sgt.hu...@gmail.com> wrote:
> >> On Thu, Nov 4, 2010 at 5:37 AM, silent1mezzo <adammcker...@gmail.com> 
> >> wrote:
> >>> +1 for {% include "foo.html" x=1 y=2 %}
>
> >>> This just seems more natural.  My designer agreed based on the {% url
> >>> %} tags.
>
> >> +1 for using the = syntax here. My reasons have been mentioned above,
> >> but to recap:
>
> >> * and/as gets too verbose and difficult to read if you add more than a
> >> couple variables
> >> * HTML uses "=" to set attributes, so this shouldn't be a new paradigm
> >> for template authors
>
> >> -- Pete

-- 
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: Ticket #7817: Extending "with" and "include" tags.

[Gabriel Hurley]

In a fit of coincidental timing, I was just being frustrated by this
very issue with inclusion tags today. I'm +1 on supporting kwargs with
"=". It is in fact *more* familiar to someone who works with HTML to
be able to assign attributes in arbitrary order, for example:

http://example.com; class="green" id="my_id">

works the same as:

http://example.com;>

whereas this is just nonsense:

http://example.com; "my_id" "green">

and this is even more broken:

http://example.com as src and my_id as id and green as class>

So any argument about not using kwargs being "for template authors"
seems a bit silly to me. Designers may not be programmers (though many
of them are these days), but the reality of the tools they already use
is that this is a familiar syntax.

All the best,

- Gabriel

On Nov 8, 7:16 pm, Peter Baumgartner  wrote:
> On Thu, Nov 4, 2010 at 5:37 AM, silent1mezzo  wrote:
> > +1 for {% include "foo.html" x=1 y=2 %}
>
> > This just seems more natural.  My designer agreed based on the {% url
> > %} tags.
>
> +1 for using the = syntax here. My reasons have been mentioned above,
> but to recap:
>
> * and/as gets too verbose and difficult to read if you add more than a
> couple variables
> * HTML uses "=" to set attributes, so this shouldn't be a new paradigm
> for template authors
>
> -- Pete

-- 
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: Call for review and comment: #7539 (ForeignKey on_delete)

[Gabriel Hurley]

> Another documentation-related question I have; is it necessary to mark
> each passing referencing (and link) to on_delete with the version-
> added marker? I went back and forth, and eventually decided against
> it, for these reasons: (1) The passing references don't provide enough
> info to use the feature; anyone following the link to the actual
> feature documentation will see the version marker, and (2) inserting
> the version-added markers in places like the QuerySet.delete
> documentation made it appear ambiguous to me exactly which paragraphs
> the marker referred to; it would be a reasonable interpretation to
> think it covered everything through the end of the section, which
> would not be accurate. Open to feedback from the documentation experts
> here.

As much as I'd like to agree that the "versionadded" directives aren't
needed for the sake of not adding clutter, I have no doubt that within
weeks we'd have someone opening a ticket because they tried to use the
on_delete argument with a previous release, not realizing they were
looking at the dev/1.3 docs. So here's my recommendation:

1. Add the versionadded directive to "docs/topics/db/queries.txt", and
"docs/ref/contrib/contenttypes.txt". For reference, you can make it
very clear what was changed/added by using the following syntax (note
the *single* line break between the versionadded and the following
*indented* text):

.. versionadded:: 1.3
The on_delete attribute was [blah blah blah...]

Thus the ambiguity about whether this paragraph or that paragraph was
changed can be avoided.

2. The documentation for "docs/ref/models/querysets.txt" needs to have
a versionadded directive as well, however the bulk of that text needs
to be backported to the 1.2.X docs, as per #14599 [1], and the
backported text shouldn't have any reference to on_delete at all.

It looks like an excellent patch overall. Thanks to everyone involved!

- Gabriel

[1] http://code.djangoproject.com/ticket/14599

-- 
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 sends out potentially harmful m2m_changed signals

[Gabriel Hurley]

I'd like to call attention to ticket #6707 [1], which deals with the
implementation of ReverseManyRelatedObjectsDescriptor.__set__.
Specifically, the problem is that the current implentation takes a
very efficient "clear everything and add all the keys back in"
approach to managing these relationships.

However, since 1.2 gained signals for ManyToMany relationships, this
is now a real problem. As reported in #13962 [2] and #14482 [3],
rather than sending the correct pre_add/post_add/pre_remove/
post_remove signals based on changes to a ManyToManyField in the admin
you instead get a set of pre_clear, post_clear, pre_add, post_add
signals containing *all* the keys.

This strikes me as having the potential for significant data loss,
corruption or duplication if the wrong kind of signals are hooked up.
Particularly to the pre/post-clear signals. It would be very easy to
see a user accidentally clearing a related table of data with a signal
not realizing that the admin application would be sending that clear
signal only to add everything back a moment later.

So, I want to get some discussion going on the right way to fix the
problem. The patch on the ticket uses an extra query and sets to
compute the added and removed keys; Malcolm suggested that the admin
might independently track the old values to compute what's changed as
per #4102. [4] The existing patch has the advantage of being much
simpler to implement even if less efficient.

What are other people's thoughts?

Thanks!

- Gabriel

[1] http://code.djangoproject.com/ticket/6707
[2] http://code.djangoproject.com/ticket/13962
[3] http://code.djangoproject.com/ticket/14482
[4] http://code.djangoproject.com/ticket/4102

-- 
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: Model proxy instance does not equal the respective model instance

[Gabriel Hurley]

Speaking on a semantic level, a "proxy" is a stand-in acting on behalf
of (or in place of) another entity. There is an implied near-
equivalence, but inherent in the idea of a proxy is that it is *not*
the same as the original. As in the case of assigning a proxy to vote
for you in corporate elections: the proxy you delegate your right to
vote to is the functional equivalent of you, but they are recognized
as not *actually* being you.

In my mind the same reasoning applies to Proxy Models. While they are
a stand-in for accessing the same underlying data, they may have very
different properties (ordering, methods, etc.). So while they may pass
a rough equivalence test, they are in specific ways dissimilar. The
underlying table/data stored by the model is only one piece of what
makes up the sum total of a model.

That said, I can certainly see the use case for comparing proxy models
as equal to the original model...

All the best,

- Gabriel

On Oct 20, 6:24 am, Byron  wrote:
> Continuing from...http://code.djangoproject.com/ticket/14492
>
> > the real issue here is "What is a Proxy", and "what is equality"
>
> I agree, that is the real issue. I based most of my reasoning off of
> what the docs already state in that a proxy model can be written to
> extend the behavior of the model being proxied, i.e. the data model
> cannot be changed. That being said, I feel the default behavior when
> dealing with equality, other data related things... should inherit
> from there parent. If there is a need to override this behavior, I am
> sure other hooks can be implemented to customize proxy models
> differently then there parent. With regards to my primary issue of
> equality, in this context two objects are being compared to determine
> whether they represent the same row of data. It seems less likely to
> compare two model objects to only be interested in whether they are
> equal data structures.
>
> Regarding permissions, the arguments presented 
> inhttp://code.djangoproject.com/ticket/11154
> all can be accomplished with writing a custom manager for the proxy
> model or writing a custom ModelAdmin class for the admin. I agree with
> Malcolm that a proxy model's permission should shadow its parent.
>
> On Oct 19, 9:08 am, Byron  wrote:
>
>
>
> > Added ticket and patch:http://code.djangoproject.com/ticket/14492
>
> > On Oct 17, 12:00 pm, Byron  wrote:
>
> > > I came across an issue when comparing a model proxy instance and a
> > > model instance, that is:
>
> > >     obj1 = Entry.objects.get(id=1)
> > >     obj2 = EntryProxy.objects.get(id=1)
>
> > >     obj1 == obj2 # False
>
> > > This I feel is a bug and the culprit is in ``Model.__eq__`` where it
> > > tests to see if the object being compared against is an instance of
> > > the same class of the Model itself.. which will always be false for
> > > proxy models being compared to there non-proxied instance
> > > counterparts. It should test if it is a proxy and whether the object
> > > is an instance of the parent class as well.
>
> > > Was this a design decision or overlooked?

-- 
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: #6375 -- Class Based Views: Opinions on commit plan

[Gabriel Hurley]

I got my first real taste of the new API today by thoroughly proofing
the docs for class-based views. I just wanted to say that there's some
great stuff in there, and I give a big thanks to everyone who
contributed! I'm really looking forward to using the new class-based
views ASAP.

Thanks!

- Gabriel

On Oct 14, 9:19 am, Russell Keith-Magee 
wrote:
> Hi all,
>
> With the deadline for 1.3 alpha rapidly approaching, it's getting to
> crunch time for class-based views.
>
> The wiki page [1] now contains a good summary of the debate so far,
> showing why we have ended up at the "ClassBasedView.as_view()"
> deployment solution. I've also got a implementation up on my bitbucket
> repo [2] (in the class-based-views branch) that is integrated into the
> Django source tree.
>
> I've done an audit of the simple (template and redirect), detail and
> list views, and I'm reasonably happy with the feature set, feature
> parity with old-style function views, and test coverage. I've also
> checked that the outstanding generic-view tickets (#1282, #2367,
> #8378, #9150, #12669, #13753, and #13953) are solved or are solvable
> using the new class-based framework.
>
> The following things are still needed:
>
>  * An audit of create/update views.
>  * An audit of date views.
>  * Documentation, including
>     - changes to the tutorial
>     - topic documentation
>     - reference documentation
>     - a migration guide for function generic views to class-based generic 
> views
>  * Feedback from the community on the API that has been exposed.
>  * Fixing Django's handling of PUT requests (this currently raises an
> expected failure in the test suite)
>
> Unfortunately, the 1.3 alpha deadline is Monday. Over the next couple
> of days, I intend to finish my audit of edit and date views, and make
> a start on at least reference documentation, but it's highly unlikely
> I'm going to get all the items on this list done by Monday.
>
> So - I'd like to field opinions on committing class-based views in an
> 'almost finished' state.
>
> I won't commit anything until at least my review of create/update and
> date views is complete. In particular, I'm not especially happy with
> the current state of the create/update views. I'd also like to see a
> couple of independent reviews of the API as a sanity check.
>
> Then, during the beta period, we will need to expand on the
> documentation and finish the other outstanding items. I would also
> expect to see some minor tweaks to the API as different use cases
> emerge. Some of these changes may be backwards incompatible, but I
> don't anticipate any widespread changes being necessary. Once we hit
> beta, I would anticipate that any backwards incompatible changes we
> need to make will have shaken out.
>
> One piece of evidence supporting this plan: history has shown us that
> we don't really get much serious testing of new features until they
> hit trunk, and we don't get the *really* serious testing until a final
> release is made. Getting an 'almost finished' version into trunk may
> actually help the feature develop faster than it would if we postponed
> to 1.4, hoping that it will mature in a separate branch.
>
> Any opinions or objections to this plan?
>
> [1]http://code.djangoproject.com/wiki/ClassBasedViews
> [2]http://bitbucket.org/freakboy3742/django- (class-based-views branch)
>
> 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: #6375 -- Class Based Views: Opinions on commit plan

[Gabriel Hurley]

> What do you call this. I don't see how any software developer could
> consider constructive criticism as anything other than helping out.

You've posted three messages in this thread, but none of them seem
"constructive" to me. You've pointed out areas of disagreement and
used inflammatory hyperbole, but not offered your alternatives or
improvements.

While I firmly stand by your right to disagree with this API and
anything else you see fit (including this response), this API
represents consensus. It is the result of months (maybe years) of
work, hundreds of messages between tens of developers, dozens of
discussions, numerous attempts at different implementations, and who
knows how many man-hours spent on it... In fact, it may be the most
thoroughly discussed feature I've seen in my time with Django.

So the question stands, what would your implementation look like? How
would it improve things and still avoid all the pitfalls that have
been mentioned over the course of development?

Respectfully,

- Gabriel

-- 
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: It is real to add ticket #8054 to 1.3 milestone?

[Gabriel Hurley]

Hi alekam,

This is certainly the kind of ticket that we want to deal with in 1.3
since it's been around so long and deferred a couple times. Starting
the discussion here is definitely the right way to make it happen.

That said, at the very least it needs a thorough code review, a full
set of tests, and good documentation before it can be included.

I'm not personally sold on the way the functionality is implemented,
but I'd have to think on what would be preferable. I'm sure others
will have stronger opinions on it one way or the other.

All the best,

- Gabriel

On Oct 12, 9:47 am, alekam  wrote:
> Hi All,
>
> I found very useful ticket #8054. This ticket has accepted status and
> assigned to brosher about 2 years. The problem describes on ticket
> detail page and in the wikihttp://code.djangoproject.com/wiki/ListColumns
> The ticket has patch witch passes all existing regression tests and I
> plan to write unit tests for it.
> It is real to add ticket #8054 to 1.3 milestone?
>
> Cheers,
>
> Alex Kamedov

-- 
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: Congratulations!

[Gabriel Hurley]

If you glance at the revision log for the committers page in the docs,
there are actually a couple more ;-)

http://code.djangoproject.com/log/django/trunk/docs/internals/committers.txt

On Oct 8, 6:15 pm, Łukasz Rekucki  wrote:
> I just noticed we have 2 new Core Developers: Alex Gaynor and Andrew
> Godwin and a new Admin Specialist Simon Meers.
>
> Just wanted to say: Congratulations guys and keep up the good work! :)
>
> --
> Łukasz Rekucki

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

Contributing "How To"

[Gabriel Hurley]

There has been repeated talk of putting together resources for new
contributors in a way that's more accessible and to-the-point than the
current contributing docs. Most recently Russell mentioned it in this
thread:

http://groups.google.com/group/django-developers/browse_frm/thread/9ebc3e57d539d1ff

I would like to put such a page in the official docs together, and to
that end I have created a wiki page to serve as the basis for the
eventual patch:

http://code.djangoproject.com/wiki/ContributingHowTo

I've also opened a ticket to hold the eventual patch and track the
issue:

http://code.djangoproject.com/ticket/14401

Contributions to the wiki page are more than welcome!

Thanks,

- Gabriel

-- 
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: Site app should be able to make absolute URLs #10944

[Gabriel Hurley]

I added some feedback on the ticket. Looks like a good start!

- Gabriel

On Oct 4, 2:12 pm, Laurent Luce  wrote:
> Hello,
>
> I added a patch to this ticket http://code.djangoproject.com/
> ticket/10944">#10944
>
> - add method get_url to Site model to return an absolute url based on
> a relative path passed as an argument.
> - add site_url template tag doing the same
>
> I am not sure about the method and template tag names. Better naming
> is welcome.
>
> Can someone review the patch?
>
> I will work on the documentation changes when I get more feedback.
>
> Laurent Luce

-- 
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: Sites Framework: RequestSite and get_current

[Gabriel Hurley]

There is now a ticket and a patch for this, which includes the utility
method and a rollup of fixes for the aforementioned tickets as
appropriate. Tests and docs included. Details are in the ticket
description:

http://code.djangoproject.com/ticket/14386

I'd love to get some feedback on it when possible.

Thanks!

- Gabriel

On Oct 1, 4:12 am, Luke Plant <l.plant...@cantab.net> wrote:
> On Thu, 2010-09-30 at 23:48 -0700, Gabriel Hurley wrote:
> > I went to triage a few tickets tonight, and noticed that #8960,
> > #10235, #10608 and #13814 have all arrived at essentially the same
> > conclusion: there needs to be a single idiomatic way to get either the
> > current Site object if contrib.sites is installed, or a RequestSite
> > object if not. All four tickets use the same bit of code, the argument
> > really only lies in where to put it.
>
> > #10235 adds it as a utility function in contrib.sites.models, #13814
> > as a separate method on SiteManager, and #8960 and #10608 basically
> > just copy and paste where needed. I'm of the opinion it should have
> > its own home in contrib.sites, but where, and under what name?
>
> I think a stand-alone function in contrib.sites.models is fine, called
> `get_current_site` (or some other sensible colour of your choosing).
> Since both Site and RequestSite already live there, it seems a good
> place.
>
> Thanks for your work on this,
>
> Luke
>
> --
> "Despair: It's always darkest just before it goes pitch black."
> (despair.com)
>
> Luke Plant ||http://lukeplant.me.uk/

-- 
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: Sites Framework: RequestSite and get_current

[Gabriel Hurley]

I can see why you might want control at the middleware level, but I'm
not sure that's the only/best way to accomplish that goal, and it
seems like the subject of a totally separate ticket to me. I'd rather
see this set of redundant problems solved in a simple fashion rather
than get into a debate over implementing a different feature...

just my two cents,

- Gabriel



On Oct 1, 1:13 am, "burc...@gmail.com" <burc...@gmail.com> wrote:
> Hi Gabriel, everyone,
>
> I'd also like if such function can support option "developer provides
> function that knows the current site based on the request".
> That means, "get my site" function ultimately needs a backend connector!
>
> I think this might be fixed in the way we did with 
> urlconf:http://docs.djangoproject.com/en/dev/topics/http/urls/
>
> So it will be taken from request:
> request.site with default implementation to LazySite, with default
> implementation of Site.objects.get_current() if sites_installed() or
> RequestSite(request).
>
> That implementation would be overriden with middleware
>
> What do you think?
>
>
>
>
>
> On Fri, Oct 1, 2010 at 1:48 PM, Gabriel Hurley <gab...@gmail.com> wrote:
> > I went to triage a few tickets tonight, and noticed that #8960,
> > #10235, #10608 and #13814 have all arrived at essentially the same
> > conclusion: there needs to be a single idiomatic way to get either the
> > current Site object if contrib.sites is installed, or a RequestSite
> > object if not. All four tickets use the same bit of code, the argument
> > really only lies in where to put it.
>
> > #10235 adds it as a utility function in contrib.sites.models, #13814
> > as a separate method on SiteManager, and #8960 and #10608 basically
> > just copy and paste where needed. I'm of the opinion it should have
> > its own home in contrib.sites, but where, and under what name?
>
> > If we can agree on where this bit of code should live, I'd be happy to
> > get all of these tickets fixed in one fell swoop. For reference, #8960
> > which has been bumped out of several releases now and is prime 1.3
> > material.
>
> > Suggestions?
>
> > All the best,
>
> >    - Gabriel
>
> > --
> > 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 
> > athttp://groups.google.com/group/django-developers?hl=en.
>
> --
> Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
> MSN: bu...@live.com

-- 
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: How to "lobby" for a ticket to be in 1.3?

[Gabriel Hurley]

Sorry, that was phrased badly on my part. I meant to imply that if
someone else wrote a patch, he could help by reviewing it...

- Gabriel

On Oct 1, 11:47 am, Jeremy Dunck <jdu...@gmail.com> wrote:
> On Fri, Oct 1, 2010 at 1:41 PM, Gabriel Hurley <gab...@gmail.com> wrote:
>
> ...
>
> > In both cases, once that's done you can either write/help write a
> > patch that has the desired effect, make sure it has docs and tests,
> > test it on your own systems/projects, give feedback on the ticket...
> > if you're certain it meets all the criteria at that point you could
> > even mark it as RFC.
>
> All correct, except that it's bad form for a person that writes a
> patch to mark that patch RFC.  Get someone else to review it and mark
> RFC.  Even frequent committers generally have others review their work
> and mark RFC.

-- 
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: How to "lobby" for a ticket to be in 1.3?

[Gabriel Hurley]

Well, looking at those two tickets, #7028 is currently related to the
debate happening on this list ("rethinking raw_id_fields"), so the
best thing to do for that ticket is to actively participate in that
discussion.

For #6903 the ticket is in DDN, which means this is a perfect
opportunity for the core devs to use their new procedural rules.
Basically, you'd be best served by starting a thread particularly for
that ticket here, or hopping on IRC, and politely gathering a
consensus for a particular solution.

In both cases, once that's done you can either write/help write a
patch that has the desired effect, make sure it has docs and tests,
test it on your own systems/projects, give feedback on the ticket...
if you're certain it meets all the criteria at that point you could
even mark it as RFC.

Once a ticket is RFC, a core committer will eventually look at it.
Especially since both of those are old tickets I'd imagine they'll get
attention for 1.3 and won't get bumped again as long as there are good
patches.

Hope that helps,

- Gabriel

On Oct 1, 10:28 am, Marcob  wrote:
> I see a huge list of tickets that shoud be in 1.3 
> release:http://code.djangoproject.com/query?status=new=assigned...
>
> Within them I didn't found some that are, imho, a must for every
> Django installation I did in the last two years:
>
> Better raw_id_fields feedback in newform-admins 
> branchttp://code.djangoproject.com/ticket/7028
>
> Go back to old change_list view after hitting 
> savehttp://code.djangoproject.com/ticket/6903
>
> At each new django release it's a pita to adapt these patches.
>
> How can I help to make these two tickets in the 1.3 milestone?
>
> Ciao.
> Marco.

-- 
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: Sites Framework: RequestSite and get_current

[Gabriel Hurley]

I should add that #10909 is another ticket that ultimately revolves
around getting a Site/RequestSite object to have access to the current
domain. Easily fixed once this function/method exists.

While I'm at it, #10944 would be moved one step closer by having a
consistent way to get the current Site/RequestSite as well.

- Gabriel

On Sep 30, 11:48 pm, Gabriel Hurley <gab...@gmail.com> wrote:
> I went to triage a few tickets tonight, and noticed that #8960,
> #10235, #10608 and #13814 have all arrived at essentially the same
> conclusion: there needs to be a single idiomatic way to get either the
> current Site object if contrib.sites is installed, or a RequestSite
> object if not. All four tickets use the same bit of code, the argument
> really only lies in where to put it.
>
> #10235 adds it as a utility function in contrib.sites.models, #13814
> as a separate method on SiteManager, and #8960 and #10608 basically
> just copy and paste where needed. I'm of the opinion it should have
> its own home in contrib.sites, but where, and under what name?
>
> If we can agree on where this bit of code should live, I'd be happy to
> get all of these tickets fixed in one fell swoop. For reference, #8960
> which has been bumped out of several releases now and is prime 1.3
> material.
>
> Suggestions?
>
> All the best,
>
>     - Gabriel

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

Sites Framework: RequestSite and get_current

[Gabriel Hurley]

I went to triage a few tickets tonight, and noticed that #8960,
#10235, #10608 and #13814 have all arrived at essentially the same
conclusion: there needs to be a single idiomatic way to get either the
current Site object if contrib.sites is installed, or a RequestSite
object if not. All four tickets use the same bit of code, the argument
really only lies in where to put it.

#10235 adds it as a utility function in contrib.sites.models, #13814
as a separate method on SiteManager, and #8960 and #10608 basically
just copy and paste where needed. I'm of the opinion it should have
its own home in contrib.sites, but where, and under what name?

If we can agree on where this bit of code should live, I'd be happy to
get all of these tickets fixed in one fell swoop. For reference, #8960
which has been bumped out of several releases now and is prime 1.3
material.

Suggestions?

All the best,

- Gabriel

-- 
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: #13870: Correctly handling database isolation (in PostgreSQL)

[Gabriel Hurley]

I ran into this issue with daemons/scheduled jobs and "idle in
transaction" in Django quite a while ago. I have a nice writeup of the
problem and solution on this StackOverflow question if anybody's
interested:

http://stackoverflow.com/questions/1303654/threaded-django-task-doesnt-automatically-handle-transactions-or-db-connections

Ultimately it's a matter of being aware of what Django will, and will
not, do for you. The lack of a request/response cycle from the daemon
means that the usual connection-closing mechanism
[signals.request_finished.connect(close_connection)] never gets
triggered. Being a *web framework* it seems reasonable to me that it's
built around requests/responses...

- Gabriel

On Sep 6, 10:09 am, Jordan  wrote:
> On Mon, 2010-09-06 at 16:47 +0200, Robert Gravsjö wrote:
> > Can you please show me the code you're running to reproduce this?
>
> > Regards,
> > roppert
>
> I've experienced what Patryk is describing here. It seems that the
> Django ORM, when not explicitly in a transaction, doesn't commit or
> rollback after each query.
>
> You can reproduce this simply in the dbshell. Go into your favorite
> project and try this (replacing `myproject`, `myapp`, and `MyModel`
> appropriately):
>
> from myproject.myapp import models
> models.MyModel.objects.all()[:1]
>
> Now, in a superuser database connection, check the results of "select *
> from pg_stat_activity." You should see the database connection from the
> dbshell stuck in the " in transaction" state.
>
> Regards,
> Jordan
>
>  signature.asc
> < 1KViewDownload

-- 
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: python 3.x

[Gabriel Hurley]

The RHEL/Python 2.4 question was addressed at length not more than a
month ago:

http://groups.google.com/group/django-developers/browse_frm/thread/b7390024b28a694d/f72c272152e968d7

Russell's reply there spells it out as clearly as anyone will be able
to right now...

All the best,

- Gabriel

On Sep 3, 1:27 am, Markus Gattol  wrote:
> It is actually so that with using __future__ and >=2.6 you already have
> most of the things available from Python 3 e.g. print() rather than
> print. See table at the bottom of
>
> http://docs.python.org/dev/library/__future__.html#module-__future__
>
> Sure, everybody is raving about Python 3 but 2.6 being the smallest
> supported version with Django would already be a huge leap towards 3 I
> think.
>
> As Russell said, looks like RHEL is going to be the indicator as to when
> things will move forward.
>
> If I look athttp://distrowatch.com/table.php?distribution=redhat
> however and assume that RHEL 5.5 is going to be supported for quite some
> time then I think it might be a long time until Django arrives at 2.6
> being the smallest supported Python version.
>
> How long are we going to plan supporting RHEL 5.5 and thus Python 2.4
> after RHEL is out?

-- 
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: Proposal: Revised form rendering

[Gabriel Hurley]

Thanks for the thoughtful reply, Russ! Just a couple quick points:

> As noted in my reply to Preston, this should easily possibly using
> chrome; I'm not sure I see why you disagree. The new options may be
> funcitonal, but from my reading of the HTML5 spec, they're functional
> in terms of UX, not in terms of data modification. The widget and
> field are used to process and parse the content of any value that is
> POSTed by a form; anything that the user sees about a form is a
> presentational issue, AFAICT.

Having now read that reply, I see what you mean about the chrome. I
hadn't understood chrome as being something that could be "layered".
It sounded more like your idea was "here is a complete calendar UI
solution" and that to add new attributes you'd essentially have to
subclass/rewrite the whole piece of chrome. If they're "stackable",
I'm all for it.

> > So, whether these become filters, or arguments to the {%
> > form %} tag, I really can't support them being implicit in the form
> > tag that gets loaded. No magic here, please!
>
> I think I understand the nature of your concern, but I'm not sure if I
> agree with calling this magic. You import a library that exercises the
> defaults you want to use. Library loads only survive for the duration
> of a single template, so there isn't any risk of a load in one
> template file accidentally changing behavior elsewhere.

The case where it becomes "magic" is if tag library authors start
including these renderers with bundles of other tags... so you go to
load up your favorite handy tag library, and you forget that it also
comes with a custom renderer, and suddenly you've got a mess on your
hands because it replaced your explicitly-loaded renderer. Admittedly
it's not the most common case, but it still concerns me.

> That said, the block-based {% form %} rendering proposal potentially
> gets around this by opening the possibility of making the layout
> selection a subtag that is explicitly specified in the context of a
> specific {% form %} instance.

That certainly seems reasonable to me.

> Thanks for the feedback, Gabriel.

Thank you!

- Gabriel

-- 
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: Proposal: Revised form rendering

[Gabriel Hurley]

Hi all,

I'm certainly excited to see improvements in the form rendering arena,
so thanks Russ for putting in the work here!

I work with Django plenty as a programmer, but in truth I work more as
a designer. And as a designer, I've spent more than my share of time
wrangling Django's existing templating mechanisms into forms which
accomplish the requisite goals. As such, I'd like to chime in on a few
cases that certainly matter to me:

 1. Ability to add attributes to individual fields.

Preston raised this concern and I strongly second it. It will only
become more important as HTML5 inputs expand the number of valid
attributes (I believe there are 10 or so, at least). If the new form
rendering can't accommodate this it ends up being a -0 for me since
I'll still be writing tags by hand. And I don't think writing custom
chrome is the place to add these types of attributes. They're
functional, not presentational.

 2. Ability to alter individual fields without writing out the entire
form.

Tim has been the main proponent of this one so far, and I'm with him.
In the scope of "perfectionists with deadlines" I don't have time to
write out the entire form just to replace the chrome on a single
field! ;-) Not that this is the right syntax or method, but the idea
of being able to do something like {{ myform|
chrome:"birthdate=calendar" }} is VERY appealing. That said, I do like
the "using" syntax you've proposed.

3. Syntax and Readability.

There's been a lot of discussion on template tag(s) vs. filters, and
while wearing my designer hat I'd say that calling a "form" tag to
render individual fields doesn't make sense. Adding a {% field %} tag
or something of the sort sits better with me.

As for filters, I support them in elegance but not at the expense of
functionality. That said, I don't see any conceptual problem with "|
as_ul" since in my mind filters are simply transformations. Anybody
who's used Photoshop has seen the term "filter" applied in a similar
fashion. This leads me to my last concern, though...

4. Layout renderers being loaded implicitly by form libraries.

I'm a HUGE -1 on this. The choice of "as_ul", "as_p", etc. needs to be
as explicit as possible, and the idea that you could load multiple tag
libraries and accidentally override your form rendering sounds like a
nightmare. So, whether these become filters, or arguments to the {%
form %} tag, I really can't support them being implicit in the form
tag that gets loaded. No magic here, please!


Those concerns aside, I really like the rest of the proposal. This
seems like a great step forward, and the ideas about chrome and
doctype sound excellent to me.

All the best,

- Gabriel Hurley

On Jul 11, 8:36 am, Russell Keith-Magee <freakboy3...@gmail.com>
wrote:
> Hi all,
>
> I'd like to propose a few extensions to Django's form library for 1.3.
> I'm still working on some fine details, but before I get too far, I'd
> like to field opinions so that I can:
>
>  * Discover any edge cases I've missed in my analysis
>  * Field any criticisms from people with more design/frontend
> experience than myself
>  * Determine any related problems that we have the opportunity to
> solve at the same time
>  * Find out if there is anyone in the community who is interested in
> helping out.
>
> Apologies in advance for the length, but there's a lot of detail to cover.
>
> With this proposal, I'd like to address three problems:
>
>  1. The layout problem. Django's forms can be rendered "as_ul",
> "as_table" or "as_p", and that's it. These layout schemes can be
> overridden and customized if you know what you're doing, but it's not
> easy to do so. Furthermore, visual layout concerns aren't separated
> from data processing concerns. You need to write (and install) a form
> subclass to implement your own form layout. Although it's good
> app-writing practice to ensure that forms can be easily substituted,
> it's not an enforced or universal practice.
>
>  2. The widget problem. This is a variant on the previous point. A
> designer that wants to use a specialized calendar widget for a date
> field needs to modify form code. This is a complexity that shouldn't
> exist; a designer should be able to specify the widget library that
> needs to be used (with all it's required rendering requirements,
> javascript triggers etc) without modifying views and form processing
> code.
>
>  3. The DOCTYPE problem. Most importantly, there is the closing slash
> problem, but the introduction of HTML5 also means that there are
> richer input types like  that aren't available in
> HTML4 or XHTML1. Django currently outputs XHTML1 unconditionally, and
> has no support for the new HTML5 input types.
>
> To solve these three probl

Re: Suggestion of exception Http301 add as new feature

[Gabriel Hurley]

Http301 doesn't seem entirely correct to me, however I have found use
for an Http302/HttpLoginRedirect exception that can be raised from
anywhere to handle unauthorized users.

If your authorization process is handled somewhere other than directly
in a view or decorator (like in a manager that checks custom
permissions) it can be a nuisance to constantly be checking the
returned value to make sure it's not a redirect. Raising an exception
there and catching it with a middleware works nicely.

I'm not saying that it needs to be in core, but it's been extremely
helpful for me and might be useful for others.

All the best,

- Gabriel

On Jun 28, 8:14 am, Patryk Zawadzki  wrote:
> On Mon, Jun 28, 2010 at 12:07 PM, kernel1983  wrote:
> > There is exception Http404 in the system.
>
> > During django programming, we often need to do some data valid:
>
> > def A(request):
> >    valid()
> >    return render_to_response(...)
>
> > def B(request):
> >    valid()
> >    return render_to_response(...)
> > ...
>
> > def valid():
> >    throw Http301(url)
>
> from django.shortcuts import redirect
>
> def valid(method):
>     def decorated(request, *args, **kwargs):
>         if not 'Tim' in request.user.called_by_some_people():
>             return redirect('some-view', ...)
>         return method(request, *args, **kwargs)
>     return decorated
>
> @valid
> def A(request):
>     return render_to_response(...)
>
> @valid
> def B(request):
>     return render_to_response(...)
>
> print 'There you go.'
>
> --
> Patryk Zawadzki

-- 
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: django.contrib.admin.ModelAdmin.formfield_for_manytomanyfield

[Gabriel Hurley]

You're right that formfield_for_manytomany probably ought to be better
documented.

If you aren't sure how to write a patch for the docs, the best thing
to do is to open a ticket for the issue in Trac. That way it will be
logged and someone else can look at it, write a patch, and eventually
get it committed.

File a new ticket here:
http://code.djangoproject.com/simpleticket

If you need to create an account in Trac:
http://www.djangoproject.com/accounts/register/

All the best,
- Gabriel

On Jun 28, 6:55 am, Massimiliano della Rovere
 wrote:
> Trying to solve (and it is solved now) my problem I found the
> undocumented formfield_for_manytomany in contrib/admin/options.py
> I think it is noteworth and I think it should be mentioned along 
> withhttp://docs.djangoproject.com/en/dev/ref/contrib/admin/#django.contri...
>
> I'd modifyhttp://docs.djangoproject.com/en/dev/ref/contrib/admin/
> page by myself but I do not know how to.

-- 
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: Proposal: {% include_partial %} template tag

[Gabriel Hurley]

Extending the include tag seems like a fantastic idea! I end up
writing the {% with %}{% include %} combo all the time for my reusable
template snippets.

However, I feel like selectively clearing the context inside a
template tag is asking for trouble and/or confusion. It also sounds
like it goes against Django's "templates require no knowledge of
programming" principle. While I can see how you might run into context
name collisions in a *very* large or complicated project, the right
solution there seems like it ought to be to clean up your context and/
or templates outside of the template itself... Even in projects with
dozens of installed apps (both my own and third-party ones mixed
together) I've never had that problem where two minutes of tweaking
couldn't fix it for good.

I'm certainly not saying you don't have a use case for it, or that it
wouldn't be extremely helpful to you. Just that having a tag that
clears the context sounds fishy to me...

All the best,

- Gabriel

On Jun 7, 10:52 am, Marco Louro  wrote:
> I'd prefer extending the {% include %} tag actually, but didn't of
> that in the first place.
>
> The clean context implementation was to make sure we don't pass
> variables we don't want to. One of the use-cases is including form
> field "templates", so I have code like:
>
> 
> 
>     
>         {% if label %}
>         {{ label }}
>         {% else %}
>         {{ field.label_tag }}
>         {% endif %}
> 
>
> if there was a "label" variable in the context but not in the
> parameters, the code above would output the wrong values. There is one
> problem with not inheriting the context: {% csrf_token %} will fail.
>
> On Jun 7, 5:35 pm, Łukasz Rekucki  wrote:
>
>
>
> > On 7 June 2010 18:13, Jacob Kaplan-Moss  wrote:> On 
> > Mon, Jun 7, 2010 at 5:03 AM, Marco Louro  wrote:
>
> > >> I'd like to propose adding a tag that includes a template with clean
> > >> context, but can accept parameters that will be added to that
> > >> context.
>
> > > Is there a reason to do this as a separate tag? Why not just::
>
> > >    {% include "some/template.html" with foo=bar baz=spam %}
>
> > Personally, I would expect this to extend the current context with
> > "foo" and "bar", render the include and restore foo, bar to old values
> > (if any). Using a clean context instead is a bit non-obvious to me.
>
> > --
> > Łukasz Rekucki

-- 
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: Proposal: modular django configuration

[Gabriel Hurley]

For the record, the "from settings_default..." method is exactly how
my team's largest projects are deployed. It works just fine for us!

Even more fun (though bordering on too tricky) is converting
INSTALLED_APPS to a set instead of a list so you can add *or* subtract
items.

This whole argument has gotten silly, though, since Russ (rightly)
rejected it about 20 posts back ;-)

All the best,

   - Gabriel

On Jun 7, 9:47 am, Tom Evans  wrote:
> On Mon, Jun 7, 2010 at 5:38 PM, Chris  wrote:
> > On Jun 7, 10:45 am, Alex Gaynor  wrote:
> >> On Mon, Jun 7, 2010 at 1:15 AM, Chris  wrote:
> >> >> try:
> >> >>   from settings_local import *
> >> >> except:
> >> >>   # It's ok to not have any local settings.
> >> >>   pass
>
> >> > This pattern is used by almost everybody it seems. Is there any reason
> >> > why this pattern hasn't been adopted by "django-admin.py startproject"
> >> > yet?
>
> >> For one thing I'd say because most *really* large projects realize
> >> this is a really bad way of handling settings.
>
> > Worse than one giant settings.py file?
>
> >> From my experiences
> >> I'd say it makes a lot of sense to invert the dependencies, localized
> >> settings require the global defaults, not the reverse.
>
> > The way I do it (and I'm assuming a lot of people do it this way too)
> > is to have global settings tracked in their source control, while
> > local_settings is something they have to write manually because it is
> > untracked (due to having passwords and all). So it's way lore likely
> > that the local settings file is missing instead of the global
> > settings. Also, it really doesn't matter if one is more likely to be
> > missing because both have to be present in order for the project to
> > run. Does it really matter if the global or the local settings file
> > raises the import error?
>
> Having posted the first way, I can appreciate that Alex's technique
> gives slightly more control to the person writing the per-instance
> config, without some of the cruft. For instance, my 'settings imports
> settings_local' technique looks like this:
>
> try:
>   from settings_local import *
> except:
>   # It's ok to not have any local settings.
>   pass
>
> # Convert INSTALLED_APPS and MIDDLEWARE_CLASSES into lists,
> # so we can append any extra ones supplied in settings_local.py
> if EXTRA_APPS:
>   INSTALLED_APPS = list(INSTALLED_APPS) + EXTRA_APPS
>
> where as if settings.py is the 'local' file, with it loading default
> settings from settings_default.py, it could look like this:
>
> from settings_default import *
> INSTALLED_APPS = list(INSTALLED_APPS) + [
>     'some_app',
>   ]
>
> The project will always have default settings, so no need for a
> try/except block, and we can directly manipulate settings without
> having to pass around extra arguments, it's much neater.
>
> OTOH, it works exactly the same once deployed :)
>
> Cheers
>
> Tom

-- 
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: Ticket #10284

[Gabriel Hurley]

Hi, J. Alheid,

Don't be too afraid to get started. From looking at the history on
that ticket (as well as the current codebase), my guess is that
Jacob's concern is that there's no mechanism in place for handling
what happens to those objects if commit=False. The current patch tells
us what *not* to do with those objects, but doesn't do something else
with them instead. Obviously it's not good to go ahead and delete
anyway if commit is not True, but just bypassing that obj.delete()
call would raise a completely different problem.

The best way to see if that concern is valid is to write the necessary
regression test for the patch. It should verify that under the current
trunk the objects are deleted when they should *not* be, and that with
the patch applied, the objects are not only not deleted on the first
pass when commit=False, but that they are subsequently deleted when
they should be later on.

Offhand, I think I agree with Jacob that the existing patch will cause
problems on the latter part of that test case. I'm sure he knows
better than I, though.

Anyhow, that's what it needs. Oh, and btw, the chunk of code has moved
in the current trunk. The delete call is now at:

http://code.djangoproject.com/browser/django/trunk/django/forms/models.py#L604

So the patch itself needs updating regardless.

All the best,

- Gabriel

On Jun 2, 12:49 pm, Shakefu  wrote:
> Hi, I'd really like to get this ticket resolved, and I'm willing to do
> the work personally, but I've never contributed before, so I was
> hoping to solicit some guidance.
>
> It seems to me that we'd need a similar patch to the one already
> existing but updated against trunk and a patch for the documentation
> to note the change in behavior. I commented last night (Wedg) and
> someone set the needs tests flag, but I'm not entirely sure what tests
> would be needed, except maybe to validate that commit=False doesn't
> delete instances, and commit=True does.
>
> I dunno if I'm a bit too green with the contributing to take ownership
> of this ticket, but I'd like to do anything I can to help get this
> ticket's suggested behavior into trunk, for my own selfish reasons. :D
>
> Please advise,
> J. Alheid

-- 
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: Project-wide cache prefix (low-level API)

[Gabriel Hurley]

Personally, I solved this by writing a wrapper around
django.utils.cache that can be dropped in transparently. It was a
really simple matter to have it take a cache prefix (in my case from
settings.py) and pass that into the original functions.

It's a pretty easy fix if the core team agrees that it's useful. Seems
like the debate might be more around adding another setting for it/
where/how to manage that prefix.

All the best,

- Gabriel


On Jun 1, 8:12 am, Byron  wrote:
> I ran into a seemingly common problem with cache key conflicts between
> two projects that both share an app and the same memcache instance. I
> would imagine that being able to optionally set a PROJECT_CACHE_PREFIX
> that is prepended to every key when setting/getting would be a nice
> transparent way of ensuring there are no conflicts. Obviously if the
> behavior is to share cache between projects, then no prefix can be
> specified.
>
> I want to get initial feedback, implications, etc. on this before I
> start writing a patch.
>
> Thanks,
> -Byron

-- 
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: Feature idea

[Gabriel Hurley]

I like the idea of boxing up the autodiscover code into a publicly
accessible utility class... it's a problem many people solve for
themselves (myself included) but even moreso it would go well with the
new startup.py proposal that's in the works.

Once it's easy to have things run once at startup, the desire to run
some sort of autodiscovery mechanism from those startup files is
likely to take off. And it's not that it's a hard problem for someone
to solve themselves, but it might be one worth solving once and being
done with it.

The downside, of course, is the cost of maintaining it and ensuring
backwards compatibility going forward.

All the best,

- Gabriel

On Jun 1, 12:02 pm, Gregor Müllegger  wrote:
> I also needed this functionality in one of my apps and just went the
> way of copy and pasting the existing solution that is already
> implemented in django.contrib.admin. But making this code reuseable
> would IMO be a benefit for some app developers.
>
> But I think the approach of using an setting for this purpose is not
> the ideal way. Admin does a great job in that way, because it only
> uses the autodiscover functionality on demand. My need for an
> autodiscover functionality was directly tight to a management command.
> I don't want to load these modules unless I invoke the management
> command, which is possible with the admin like autodiscover() function
> instead of using a setting.
>
> My proposal would go into the direction of pulling the autodiscover
> function out of the django.contrib.admin module and putting it
> somewhere in the core. Since the admin needs some special
> functionality on errors while loading an admin.py module from an app,
> I would suggest a Autodiscover class that provides some hooks to be
> better customizable.
>
> Something like:
>
>     class Autodiscover(object):
>         def __init__(self, module_name):
>             self.module_name = module_name
>
>         def __call__(self):
>             # existing autodiscover code from django.contrib.admin
>
>         def pre_load(self, app_label):
>             # gets called directly before trying to load an app's module
>
>         def post_load(self, app_label):
>             # gets called after trying to load an app's module even if the
>             # import failed
>
>         def on_success(self, app_label, module):
>             # gets called if the module was imported successfully
>
>         def on_error(self, app_label):
>             # gets called if the module didn't exist or import failed
>
> In django.contrib.admin or in any other app we can use:
>
>     from django.core.autodiscover import Autodiscover
>
>     autodiscover = Autodiscover('admin')
>
> This also provides backwards compatibility since the following snippet still
> works:
>
>     from django.contrib import admin
>
>     admin.autodiscover()
>
> Yours,
> Gregor Müllegger

-- 
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: Upgrading Trac

[Gabriel Hurley]

Is it worth upgrading to the 0.11.X branch with Trac 0.12 scheduled to
be out the door within a couple weeks?

On the one hand, a brand new Trac release would be more likely to
contain bugs than a bugfix branch that's now on it's 7th revision. The
configurable workflows and per-user permissions were the big features
for 0.11, and both of those require an inordinate amount of setup to
be made useful (inordinate being relative to how those tasks are
managed in other trackers).

On the 0.12 side, the improved query system sounds like it would be a
big boost for some of the issues that have been discussed, and live
previews, ticket interface improvements, and translations all sound
like really good features to have.

Just throwing it out there.

All the best,
- Gabriel

On Apr 30, 8:06 am, Jeremy Dunck  wrote:
> Does anyone have crib notes on what upgrading from (presumed) 0.10.4
> to 0.11.7 would buy us?  If not, I can go read changelogs.
>
> Separate from that, I'd like to open discussion on what it would take
> to do the upgrade.
>
> Who has access to the server?  What do I need to do to convince to let
> me upgrade?
>
> This is purely exploratory-- I imagine the workflow stuff I'm trying
> to do doesn't really need the upgrade, but Russ complained a bit about
> nits, so I thought I'd at least see what's what.
>
> --
> 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 
> athttp://groups.google.com/group/django-developers?hl=en.

-- 
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: Trac workflow assistance (commiter feedback needed)

[Gabriel Hurley]

I'd also be interested in working on this, as long as I'm not alone on
it. Have you and/or Alex set up any kind of mailing list for it? Do
you plan to use git's issue tracker or something else? What's the
process plan for getting development kick-started on it?

- Gabriel

On Apr 30, 11:22 am, Idan Gazit  wrote:
> FWIW, I spoke with Alex the other week about turning piano-man into a
> more finished product.
>
> So long as core guarantees that they'll at least take a look at
> whatever is made, I'm +1 on rolling our own, and am willing to
> champion this project.
>
> I think having something we can easily shape to meet our process needs
> will be a Good Thing. A good ticket tracker helps devs paw through the
> pile of tickets and keep kicking the ball forward with a minimum of
> effort. Reducing the overhead on core will make those people's lives
> more pleasant (and free up their time for dealing with, you know,
> code.)
>
> Another benefit: one of the complaints I (anecdotally) hear all the
> time is that it is hard to contribute to django. Part of that is the
> high bar we set for contribution, and the (necessary) process we
> impose in order to prevent oopses, but I posit that a significant part
> of the feeling stems from people confusing a lack of activity on their
> ticket with a lack of activity. Making it easier for devs to update
> tickets will help, and providing some kind of dashboard on project
> stats will give us something to point to next time somebody throws
> their toys out of the pram because their pony isn't being seen to.
>
> I'll be in Berlin, and plan to sprint on piano-man there. Plan:
>
> 1. Figure out a handful of "most useful" tricks that trac doesn't
> accomplish, and adding those to piano-man. I particularly like the
> idea of baking in some behaviors like timed ticket death and other
> things that prevent a buildup of detritus and cut down on ticket
> gardening chores.
> 2. Put up a test instance with a dump of data from trac.
> 3. Kick the tires and see if it engenders interest.
>
> If people think it's awesome, we'll keep going. :)
>
> -I
>
> --
> 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 
> athttp://groups.google.com/group/django-developers?hl=en.

-- 
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: Trac workflow assistance (commiter feedback needed)

[Gabriel Hurley]

On Apr 30, 8:02 am, Jeremy Dunck  wrote:
> I haven't heard one proposed.  I'll take a look at RedMine and/or
> steal ideas from launchpad -- but writing a new tracker isn't the
> problem I'm trying to solve.

FWIW, I currently use (and administer) Redmine for my company. I'd say
it's only a marginal improvement over Trac overall. We like it better
because it's more friendly towards non-software project management,
and has easy workflow setup. But the big downside: it's Ruby/Rails.
The thing is a resource hog, and tends to be slower than I'd like
overall. There's a fair plugin community to add cool features, but
having tried a bunch of them I'd say they fall in the "unstable"
category more often than not.

Those are my two cents on Redmine.

- Gabriel

-- 
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: Django unit test coverage

[Gabriel Hurley]

One of the GSOC projects that was accepted is about updating and
improving Django's test suite. The guy doing it has expressed interest
in using coverage.py to help with the project (whether as a long-term
part of django or just for the GSOC project), so there'll probably be
more concrete information available in a few months...

All the best,
- Gabriel

On Apr 28, 8:36 am, Vinay Sajip  wrote:
> Can someone please point me to any information about stats on coverage
> of Django's own code by its unit tests? I searched for "Django test
> coverage" and "test coverage site:djangoproject.com" but I'm getting
> pages about testing code which uses Django using Django's test
> infrastructure, and I couldn't spot anything which refers to coverage
> of Django's own code. If I've missed something blindingly obvious,
> sorry for the bother, but a pointer would be appreciated!
>
> Regards,
>
> Vinay Sajip
>
> --
> 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 
> athttp://groups.google.com/group/django-developers?hl=en.

-- 
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: Trac workflow assistance (commiter feedback needed)

[Gabriel Hurley]

I'm in a similar boat to Russell... LaunchPad's UI always seemed like
a complete disaster to me...

However, in reading through LaunchPad's FAQ to give it a fair chance,
I saw a couple of other features that Trac doesn't have to add to the
list:

 * Out-of-the-box OpenID support
 * "Bug Expiry" to handle tickets that are both outdated and inactive
 * Multi-project bugs (so that different projects can track, say, the
same bug in Python in a concerted manner)
 * Sprint management
 * Tracker interaction via email reply
 * Concrete "triaged" statuses and indicators for "project
supervisors" beyond those available to the community.
 * The ability for Launchpad to watch and integrate bugs from other
trackers (such as Trac) in an ongoing fashion.

Not necessarily advocating for Launchpad, just thought it was
interesting.

- Gabriel



On Apr 25, 11:34 am, yml  wrote:
> As you have noted I have avoided to the DVCS matter because I knew it
> is a slippery slope and because it don't really matter. Launchpad
> allows you to import branch from many of the popular VCS [1] cvs, svn,
> git, hg.  The documentation mention that drupal is using this feature
> to import on a regular basis their "trunk" which is control in a CVS
> repository. This import capability is the reason I kept the DVCS
> aspect out of my initial post my understanding was that nothing
> describes before would require a move from svn to bzr for django's
> "canonical trunk".
>
> I am adding a link to the "Karma calculation" [2].
> Regards,
> --yml
>
> [1]https://help.launchpad.net/Code/Imports
> [2]https://help.launchpad.net/YourAccount/Karma?action=show=Kar...
>
> On Apr 25, 11:15 am, Russell Keith-Magee 
> wrote:
>
>
>
>
>
> > On Sun, Apr 25, 2010 at 10:54 PM, yml  wrote:
> > > Hello,
>
> > > On Apr 23, 12:32 pm, Russell Keith-Magee 
> > > wrote:
> > >> On Fri, Apr 23, 2010 at 3:04 PM, Jeremy Dunck  wrote:
> > >> > Commiters and triagers,
> > >> >  I've gone through the contributing doc and tried to identify places
> > >> > that tickets might get stuck (or other places that automation might
> > >> > smooth the process).
> > >> >  If you could take a few minutes to give feedback on the list,
> > >> > hopefully prioritizing in your named column with +/- 0/1, it'd help me
> > >> > focus effort.
>
> > >> Comments by row number from the spreadsheet:
>
> > >> 2: Would be useful as a work list for people looking for. It would
> > >> also be useful if tickets could be auto-disowned; i.e., if there's no
> > >> activity from the owner after a month, post a comment asking for a
> > >> status update; if no activity after another month, remove the
> > >> ownership. This might get annoying for long-lived tickets with an
> > >> owner that has a vested interest, though.
>
> > >> 3: That's essentially just a list of people who can't (or won't) read
> > >> the contribution guide. I'm not sure tracking that stat would help.
>
> > >> 4: Is essentially a list of 'active tickets'. I keep track of that by
> > >> manually eyeballing Trac updates; it might be a useful stat to have
> > >> exposed for people who don't watch Trac as much as I do.
>
> > >> 5-10: The most useful of the lot for me personally. An automated
> > >> process that applies patches and runs tests would be nice; if it can
> > >> autocheck the appropriate flags ("patch needs improvement", "needs
> > >> tests" etc) that would be even better.
>
> > >> There are edge cases that will make this difficult; e.g., patches that
> > >> span multiple diffs, or tickets where the submitter provides multiple
> > >> alternative patches.
>
> > >> I would also add to this list checks that the test is actually a
> > >> regression test - that is, that the contributed test fails unless the
> > >> rest of the patch is applied.
>
> > >> I'm also not sure if a direct email or adding a comment to the ticket
> > >> in trac would be the best approach. I suspect a comment would be
> > >> better, since it provides a public record of the automated reporting
> > >> activity.
>
> > >> 11: Useful as a working list for someone looking for something to do.
>
> > >> 12-14: Nifty stats, but I'm not sure they would help much
>
> > >> 15-17 would be useful if we wanted to audit the work of volunteers,
> > >> but that's not really something we do. I keep a rough eye on every
> > >> ticket change as they come in; if something looks way off, I'll jump
> > >> on it, but otherwise I just live and let live and let the crowd sort
> > >> it out.
>
> > >> 18: I'd be interested to see what this produces. My gut tells me that
> > >> tags aren't used often enough (or consistently enough) for this to
> > >> provide any real patterns. However I might be wrong. If it works, it
> > >> might be a handy way to work out common themes that need a broader
> > >> approach.
>
> > >> 19: Again, like 3; this is just a list of people who don't follow 
> > >> 

Re: Trac workflow assistance (commiter feedback needed)

[Gabriel Hurley]

I've been dancing around this idea for a while. I know it's not a new
thought, and Alex Gaynor and Justin Lilly even started work on "piano
man" [1]... I'd be curious to know what the state of that project is
and if a few more devs working on it might be able to bring it to a
place where it'd be ready for prime time.

Re-inventing the wheel is usually a bad idea, but at the same time a
Django-based tracker just seems like such a natural choice.

- Gabriel

[1] http://github.com/alex/piano-man

On Apr 25, 11:10 am, "burc...@gmail.com"  wrote:
> Hi Russell, Jacob,
>
> What do you think, is it good idea to write django-based bug tracker
> as a trac replacement?
> As we all know, Django would be a perfect fit for such project!
>
> Current Trac templates & layouts can be used for prototyping the project.
>
> On Sun, Apr 25, 2010 at 6:15 PM, Russell Keith-Magee
>
>
>
>
>
>  wrote:
> > On Sun, Apr 25, 2010 at 10:54 PM, yml  wrote:
> >> Hello,
>
> >> On Apr 23, 12:32 pm, Russell Keith-Magee 
> >> wrote:
> >>> On Fri, Apr 23, 2010 at 3:04 PM, Jeremy Dunck  wrote:
> >>> > Commiters and triagers,
> >>> >  I've gone through the contributing doc and tried to identify places
> >>> > that tickets might get stuck (or other places that automation might
> >>> > smooth the process).
> >>> >  If you could take a few minutes to give feedback on the list,
> >>> > hopefully prioritizing in your named column with +/- 0/1, it'd help me
> >>> > focus effort.
>
> >>> Comments by row number from the spreadsheet:
>
> >>> 2: Would be useful as a work list for people looking for. It would
> >>> also be useful if tickets could be auto-disowned; i.e., if there's no
> >>> activity from the owner after a month, post a comment asking for a
> >>> status update; if no activity after another month, remove the
> >>> ownership. This might get annoying for long-lived tickets with an
> >>> owner that has a vested interest, though.
>
> >>> 3: That's essentially just a list of people who can't (or won't) read
> >>> the contribution guide. I'm not sure tracking that stat would help.
>
> >>> 4: Is essentially a list of 'active tickets'. I keep track of that by
> >>> manually eyeballing Trac updates; it might be a useful stat to have
> >>> exposed for people who don't watch Trac as much as I do.
>
> >>> 5-10: The most useful of the lot for me personally. An automated
> >>> process that applies patches and runs tests would be nice; if it can
> >>> autocheck the appropriate flags ("patch needs improvement", "needs
> >>> tests" etc) that would be even better.
>
> >>> There are edge cases that will make this difficult; e.g., patches that
> >>> span multiple diffs, or tickets where the submitter provides multiple
> >>> alternative patches.
>
> >>> I would also add to this list checks that the test is actually a
> >>> regression test - that is, that the contributed test fails unless the
> >>> rest of the patch is applied.
>
> >>> I'm also not sure if a direct email or adding a comment to the ticket
> >>> in trac would be the best approach. I suspect a comment would be
> >>> better, since it provides a public record of the automated reporting
> >>> activity.
>
> >>> 11: Useful as a working list for someone looking for something to do.
>
> >>> 12-14: Nifty stats, but I'm not sure they would help much
>
> >>> 15-17 would be useful if we wanted to audit the work of volunteers,
> >>> but that's not really something we do. I keep a rough eye on every
> >>> ticket change as they come in; if something looks way off, I'll jump
> >>> on it, but otherwise I just live and let live and let the crowd sort
> >>> it out.
>
> >>> 18: I'd be interested to see what this produces. My gut tells me that
> >>> tags aren't used often enough (or consistently enough) for this to
> >>> provide any real patterns. However I might be wrong. If it works, it
> >>> might be a handy way to work out common themes that need a broader
> >>> approach.
>
> >>> 19: Again, like 3; this is just a list of people who don't follow process.
>
> >>> > Also, I'm planning on building the tool using the XMLRPC trac plugin
> >>> > (I'm assuming the live app can't easily have access to the DB, or that
> >>> > the RPC API's abstractions are useful at the app level).  Correct me
> >>> > if I'm wrong.
>
> >>> If you're looking to implement this as a standalone thing, it probably
> >>> *could* access the Trac DB directly, but in the interests of
> >>> everyone's sanity (including Trac's) it's probably best to keep to
> >>> public interfaces like XMLRPC.
>
> >>> However, it's also possible that some of these features would best be
> >>> implemented as a Trac plugin.
>
> >>> I'd also suggest that before you embark on a big Trac-specific
> >>> tool-building exercise that we investigate what we could gain by
> >>> moving to another bug tracking tool. I'm not a huge fan of Trac - it's
> >>> got lots of quirks 

Re: Process discussion: reboot

[Gabriel Hurley]

On Apr 22, 1:21 pm, Adam Nelson  wrote:

> 2. Assign all of these tickets to 1.3 and nothing else:
>
> http://code.djangoproject.com/query?status=new=assigned...

A, only 900 tickets to work through for 1.3? Don't go too easy on
the core team! ;-)

All the best,
- Gabriel

-- 
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: managing javascript and css resources

[Gabriel Hurley]

I like the idea of having these "bundles" or "stacks" for media. Just
thinking out loud here, if there were a compression engine in play
that could do concatenation as well as minification you could have a
useful syntax for ordered combinations of scripts similar to how
ModelAdmin's fieldsets work (using a dictionary of nested tuples).

A quick example:

scripts = {
"head": (
"media/js/script_to_be_loaded_first.js",
),
"tail": (
"media/js/script_that_shouldn't_be_concatenated.js", ("media/
js/concatenate_me_1.js", "media/js/concatenate_me_2.js"),
)
}

That would give you the benefit of automated concatenation while
somewhat alleviating the problem Kevin Howerton pointed out about it
best being done by hand.

That's my thought for the moment.

- Gabriel

On Apr 21, 9:18 am, Owen Nelson  wrote:
> I've been thinking about this ever since I learned that django's admin
> was going to be using jQuery, but I admit I didn't really consider it
> that important until recently (building sites against 1.2-beta).
>
> I know now is not a fantastic time to be talking about features, but
> this is something I'd enjoy working on (personally), and I am just
> hoping to get a little feedback regarding the design, and how it might
> fit in with everything else going on in django's guts
> (philosophically).  I also understand that this isn't something for near
> versions of django, but rather the distant future.
>
> Here's where the pin dropped:
> * The jQuery used by the admin site is conjured using the no conflict
> option and is relegated/isolated to it's own namespace (excellent).
> * There are many projects/apps out there that also rely on jQuery - they
> also "bundle" the framework, but may not be quite so quick to play nice.
>
> In my case, I noticed that when I added a few jQuery-enhanced form
> widgets to a form in my admin site, it resulted in 3 instances of the
> framework being sourced in the document head.  Although, this is
> actually ok for the most part in terms of operation (so long as the
> scripted events that come with each widget are bound to the dom before
> the plugin of origin gets wiped by the next sourcing of jQuery), it's
> far from ideal.
>
> There are a myriad of ways to skin this cat, be it a simple
> recommendation to adopt  the use of  django's jQuery and a template tag
> to provide access to the appropriate script tag, or something more
> structured/engineered/formal 
>
> My goal would be to provide app developers with scaffolding to add
> javascript/css resources to the rendered view in a non-competitive way.
> I'm thinking in terms of a template tag that works along the lines of {%
> include %}, but for script and link tags, allowing folks to add scripts
> with an optional way to influence the position in the "stack".  A
> similar interface would also be provided for form media, and perhaps
> some kind of helper or shortcut for ease the addition of these scripts
> from our view functions.
>
> I understand that Django has historically been
> anti-javascript-framework-blessing, and I'm wondering if opening this
> can of worms would mean having to incorporate some kind of a pluggable
> backend system (for working with different frameworks, or multiple
> frameworks at a time) - something I've briefly considered, but started
> foaming at the mouth as a result.
> I've also considered the fact that the reaction here might be, "just
> don't - leave it all in the individual's hands".
>
> In closing... don't hit me!
>
> Regards,
> Owen Nelson
>
> --
> 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 
> athttp://groups.google.com/group/django-developers?hl=en.

-- 
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: Process discussion: reboot

[Gabriel Hurley]

I just built something in a similar vein as this for my team's
internal use. Amusingly, I used Django's inspectdb feature to directly
interface with Redmine's database and provide a separate front-end.
The data feeds into a javascript graphing library.

The ability to visualize languishing issues, activity over time, etc.
is really pretty awesome. I've got no experience hacking at Trac
particularly, but I can at least speak to how useful having that kind
of resource can be.

- Gabriel

On Apr 20, 2:46 pm, Jeremy Dunck  wrote:
> On Mon, Apr 19, 2010 at 9:19 AM, Jacob Kaplan-Moss  wrote:
>
> ...
>
> > So: here's your chance. You have suggestions about Django's
> > development process? Make them. I'm listening.
>
> I have a perception that there are some phases of the ticket lifecycle
> where things get stuck -- I think that if you look at this 
> diagram:http://docs.djangoproject.com/en/dev/_images/djangotickets.png
> there is a pretty clear flow, and people are encouraged to pitch in
> where ever they feel it might help.
>
> But in practice, it seems that some of the edges become queues, and
> some tickets sit in that queue for a long time -- either because the
> next step for that ticket isn't obvious, or because there's a shortage
> of triage attention on that particular ticket.
>
> Earlier in the other thread, someone claimed there were hundreds of
> patches ready (but ignored), while the response was "no, those tickets
> aren't actually ready" -- the issue was a recognition of procedure, in
> that case.  Even so, the perception of ignored tickets is part of the
> problem-- whether tickets are actually ignored or not, the perception
> still would discourage contribution.
>
> I'd like to highlight tickets that have sat in each queue for a period
> of time -- a summary of min, max, mean time in queue (over time), and
> a detail view to sort tickets by age in queue, etc.
>
> I know this isn't well-supported by Trac, but Joseph pointed me at the
> XML RPC API--- the pieces are there.  I never worked on it; generally,
> I felt that the triagers are doing what they can and if anything, my
> time would be better spent fixing bugs or triaging.
>
> But this debate has been at least partially about responsiveness and
> the perception of inclusion.
>
> Triagers, commiters, off-put contributors, do you think this sort of
> view would help the workflow and understanding of the ticket status?
>
> --
> 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 
> athttp://groups.google.com/group/django-developers?hl=en.

-- 
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: Process discussion: reboot

[Gabriel Hurley]

That sounds like a great idea! Even having been at this for a few
months I'd watch it just to see how somebody else handles things.

On Apr 20, 10:55 am, Alex Gaynor <alex.gay...@gmail.com> wrote:
> On Tue, Apr 20, 2010 at 1:36 PM, Bmheight <bmhei...@gmail.com> wrote:
> > +1 to Stephen Crosbys' proposal, although I think this would be a bit
> > difficult to perform as the Framework evolves and the documentation on this
> > would be a bit outdated as time goes on (And have to yet again maintain
> > another Document to keep up to date).
> > It it still none the less a good idea in my opinion.
>
> > On Tue, Apr 20, 2010 at 9:43 AM, Stephen Crosby <stevecr...@gmail.com>
> > wrote:
>
> >> What could be very helpful here is some education for would-be Django
> >> developers. The tutorial format has worked so well for educating new Django
> >> users, why not apply it also to Django developers also? After the 1.2
> >> release, why don't we come up with a Django developers tutorial that walks
> >> us through the process of solving issues and working on Django. The goal of
> >> this would be to help would-be developers understand the Django development
> >> process by getting their hands dirty with a real issue.
> >> It could begin with a short explanation of the process, go through finding
> >> a real (old) example issue in Trac (already solved), it could run down what
> >> type of Trac activity is helpful and what is not. Then the tutorial could
> >> instruct the reader to checkout an old revision of Django (with the 
> >> unsolved
> >> issue) and how to reproduce the issue.
> >> We could show the reader how to apply a bad patch (attached by some
> >> less-informed Trac user), then how to run the test suite and notice that
> >> some tests fail. Some instruction on how to politely note that fact on Trac
> >> might be in order as well as how the patch was rewritten in order to pass
> >> the tests.
> >> Another bit on proper documentation, some notes on quality, where to get
> >> help, what types of issues need discussion on this list would be great and
> >> I'm sure there's more that could be included with this type of tutorial.
>
> >> On Tue, Apr 20, 2010 at 9:09 AM, Jacob Kaplan-Moss <ja...@jacobian.org>
> >> wrote:
>
> >>> On Mon, Apr 19, 2010 at 3:34 PM, Gabriel Hurley <gab...@gmail.com> wrote:
> >>> > When I finally did submit my first patch, I was terrified of getting
> >>> > it wrong and having it rejected. I'd seen it happen on other tickets.
> >>> > It wasn't until I got *more involved* and started keeping up with the
> >>> > trac timeline--watching the ebb and flow of tickets--that I started to
> >>> > understand how the tone on trac had a reason. Until you get that
> >>> > perspective, it's hard to know what's right or wrong, and easy to take
> >>> > things personally. The core devs can seem imposing or scary simply
> >>> > because you don't know them.
>
> >>> This is *really* good feedback, and thank you very much for it.
>
> >>> Clearly scaring people isn't our intent, but if that's the result...
> >>> well, we're doing something wrong. I really don't want people to be
> >>> scared off, and I'm hearing from you and a few others that that's
> >>> already happening.
>
> >>> I don't think I need to enumerate why the tone on a ticket tracker
> >>> tends towards the terse -- lack of time, repetition, yadayada -- but
> >>> regardless I don't like our process being scary.
>
> >>> > If anything, my point is that getting started as a Django contributor
> >>> > *can* be difficult, and the core team just being aware of that fact is
> >>> > a good thing.
>
> >>> I hear you loud and clear, and I'd love any suggestions you might have
> >>> about how we might improve in this area.
>
> >>> 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-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.
>
> >> --
> >> Stephen Crosby
> >> Web Developer
> >>

Re: Process discussion: reboot

[Gabriel Hurley]

That's awesome. I'll definitely add to that when I have some time
tonight.

On Apr 20, 2:49 pm, Robert Coup 
wrote:
> On Wed, Apr 21, 2010 at 9:12 AM, Jacob Kaplan-Moss  wrote:
> > I like this a lot. Especially the "your next steps" part - it makes it
> > very obvious what the next thing interested parties should do is.
>
> > Could you start a wiki page with this stuff? Until we figure out how
> > to get it more visible, it could at least serve as a sort of FAQ about
> > what different ticket actions mean. Starting it on the wiki means
> > folks can pitch in and help get the wording good.
>
> Tada...http://code.djangoproject.com/wiki/TicketChangeHelp
>
> Most of it is empty - please help fill it in!
>
>
>
> > In the meantime, I'll look into how to get it into Trac somehow.
>
> I can write you a trac extension/patch - just didn't want to spend the
> time on it if nobody was keen. May be as simple as customising the
> email template, but we don't want it to send out stuff whenever
> someone is added to the CC list, etc.
>
> Rob :)
>
> --
> 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 
> athttp://groups.google.com/group/django-developers?hl=en.

-- 
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: Wherein Benjamin Franklin answers questions pertaining to the Django development process

[Gabriel Hurley]

Brilliant! Absolutely brilliant!

- Gabriel

On Apr 19, 4:23 pm, Bitrot McGee  wrote:
> Q: When will Django finally have every feature I want?
> A: "Ambition has its disappointments to sour us, but never the good
> fortune to satisfy us."
>
> Q: What the fuck is taking so long?
> A: "As we enjoy great advantages from the inventions of others, we
> should be glad of an opportunity to serve others by any invention of
> ours; and this we should do freely and generously."
>
> Q: Should certain Trac fields only be editable by commiters?
> A: "Those who would give up Essential Liberty to purchase a little
> Temporary Safety, deserve neither Liberty  nor Safety."
>
> --
>
> I hope this attempt to lighten the mood isn't too distracting.
>
> To the core team: your efforts are so, so appreciated. Benjamin
> Franklin (et al.) know that you have a lot of other things you could
> be doing, and that working on Django is too often thankless. Thank
> you! You all deserve many, many IRL ponies. A herd of ponies.
>
> To everyone: I'd like to close with a quote by Richard Penn: "We must,
> indeed, all hang together, or assuredly we shall all be forced to use
> Rails separately." Please keep that in mind. It seems relevant for
> some reason.
>
> ~Bitrot
>
> --
> 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 
> athttp://groups.google.com/group/django-developers?hl=en.

-- 
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: Low-Hanging Fruit

[Gabriel Hurley]

I just want to second this suggestion from Russell:

On Apr 19, 8:11 am, Russell Keith-Magee 
wrote:

> Lastly, pick anything to do with documentation. This isn't a coding
> problem, obviously, but writing up a documentation patch to clarify
> some issue will help you get to know Django's Sphinx markup
> extensions, and it's good practice for when you submit a bigger ticket
> that does requires documentation

Even beyond that, taking on documentation tickets will take you into a
broad range of areas and have you digging into the codebase to figure
out what the correct documentation ought to be. It's a great way to
find out what you weren't aware that you didn't know. (that's kind of
like preparing for the unexpected...)

   - Gabriel

-- 
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: Process discussion: reboot

[Gabriel Hurley]

Before I even say anything: I think the core team does a great job,
they're as fair as humanly possible in their decisions, and Django's
stability is amazing.

My disclaimer out of the way, I'd like to share my own experience of
being a new contributor just to add another perspective.

I only started submitting patches during the 1.2 release cycle, so I'm
still a relative newbie. In 4 months I've learned *a lot* about
Django's process and the history of thought behind many of the issues
in both the codebase and the development process. But that knowledge
wasn't easy to come by.

I read the contributing docs twice before I even opened my first
ticket. Twice more before I submitted a single patch.

When I finally did submit my first patch, I was terrified of getting
it wrong and having it rejected. I'd seen it happen on other tickets.
It wasn't until I got *more involved* and started keeping up with the
trac timeline--watching the ebb and flow of tickets--that I started to
understand how the tone on trac had a reason. Until you get that
perspective, it's hard to know what's right or wrong, and easy to take
things personally. The core devs can seem imposing or scary simply
because you don't know them.

Even after reading the contributing docs and all the internals several
times, there was still a large portion of knowledge that I found only
existed outside those docs. Spending hours reading through this list's
history and through the #django-dev IRC logs have answered a lot more
of my questions. While it might seem obvious to say "go add that
information to the docs" the truth is that a lot of what new
contributors need to learn is subjective, and may not belong in
official documentation.

I did find that the ambiguity of ticket statuses in trac made it hard
to dive right in and understand what was going on. But that's been
discussed at length. When someone has an idea for a solution there,
I'll be the first to jump in and work on it.

If anything, my point is that getting started as a Django contributor
*can* be difficult, and the core team just being aware of that fact is
a good thing.

That said, I have no sympathy for the malcontents. I would really
rather have seen 1.2 get released than 80+ messages on these two
threads. If complaints were patches, we'd be halfway to 1.3 by now.

Divisiveness and ill-willed argument is stifling to creativity and
progress. I hope this post doesn't contribute to it.

I'll close with Benjamin Franklin: "We must hang together or assuredly
we shall hang separately."

   - Gabriel



On Apr 19, 7:19 am, Jacob Kaplan-Moss  wrote:
> Hi folks --
>
> I'd like to try to reboot the discussion that's been going on about
> Django's development process.
>
> I'm finding the current thread incredibly demoralizing: there's a
> bunch of frustration being expressed, and I hear that, but I'm having
> trouble finding any concrete suggestions. Instead, the thread has
> devolved into just going around in circles on the same small handful
> of issues.
>
> So: here's your chance. You have suggestions about Django's
> development process? Make them. I'm listening.
>
> 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-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group 
> athttp://groups.google.com/group/django-developers?hl=en.

-- 
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: GSoC Proposal: Web Unifying Markup (templating) Language, or WUML

[Gabriel Hurley]

To be honest, my biggest question is "is this really about Django?"

It seems like this proposal could have gone to anybody, or it could be
a standalone app.

I also would like to know if you have examples of other successful
implementations of such a system that incorporate HTML, CSS, *and* JS
into one. Striking out into this territory and finding it's a much
larger job than expected just means the code branch is more likely to
die.

I'm particularly concerned about your discussion of javascript being
included. Though Django has chosen jQuery for its admin there is no
such requirement for the rest of any Django site's codebase. Writing a
meta-language for javascript that is framework-agnostic (or framework-
independent) is going to be extremely hard.

You talk about extensibility, but don't give any examples of how this
system would *actually* be extended.

How do you propose for your parser to determine the difference between
this new WUML markup and non-escaped similar-looking markup in legacy
templates? Backwards compatibility is not a simple issue here.

Adding dependencies on more external Python libraries also doesn't sit
well with me. I don't want to have to install SASS and SHPAML
libraries, nor do I want to be reliant upon the development directions
of those projects.

This proposal is certainly ambitious. I'll give you that.

All the best,

 - Gabriel

On Apr 9, 11:14 am, nubela  wrote:
> Proposal Title
> --
>
> Web Unifying Markup (templating) Language, or WUML
>
> Background
> --
>
> As a freelance developer having built entire platforms of Django, I
> find the most time consuming part of web development to be the front
> end development. Essentially, Javascript, HTML, and CSS. Of course
> there are tools that might help. For example, SASS for CSS, JQuery for
> Javascript, and recently, an exciting new library known as the SHPAML
> surfaced that is pretty similar to HAML, but more pythonic, and
> definitely more transparent. (http://shpaml.webfactional.com/)
>
> However, what does not change is that these components are still
> distinct. Everytime I have to modify a property of an element, I'd
> still have to go to my CSS file, or SASS file. Same goes to JS, or
> HTML.
>
> But thats not all, if we were to use SHPAML and SASS, every time we
> have to test the interface, we have to manually compile, or have a 3rd
> party script to compile all the relevant files back into its HTML/CSS/
> JS components. And that means before every F5, we have to run a mini
> script. It gets annoying after a while.
>
> This is when I hope WUML can come in.
>
> Essentially, I hope to have a unified templating language that will
> coexists with template tags of Django, whereby I can streamline my
> development into a pythonic element-centric experience. But its better
> to demonstrate with examples.
>
> Examples
> 
>
> html
>   body
>     div#header
>       | this is some verbose text inside this div
>       + background-color: {{ backgroundcolor }}
>       + pointer: cursor
>       ^ alert("true");
>       ^ this.hide();
>
> will be compiled into
>
> > A HTML FILE
>
> 
>   
>     this is some verbose text inside this div
>   
> 
>
> > A CSS FILE
>
> html body div#header {
>   background-color: #FFF;
>   pointer: cursor;
>
> }
> > A JS FILE (using JQuery)
>
> $(document).ready({function(){
>   $("div#header").live("click",function() {
>     alert("true");
>     this.hide(); //hide here has to be defined in another js file.
>   });
>
> });
>
> Arguments against WUML (or why it is helpful)
> -
>
> Some people might argue that this defeats the purpose of abstraction
> of different components into its respective components. JS/HTML/CSS
> existed distinctly for a reason. While I agree strongly with this
> point, but I hope to point out that WUML is not replacing any of those
> components.
>
> Here are some reasons why WUML might be interesting:
>
> 1) A javascript coder, a HTML writer, and a CSS scriptor, can still
> work on their individual files, no one is stopping them. What WUML
> does is, it provides a shorthand in an element-centric manner to
> various of these components in a pythonic sense. The 3 different
> people can now instead of working on 3 different files, they can work
> on the same code, and view distinctly what are the relevant details to
> each element they should take note of. Besides, with the state of the
> art revision control any decent programmer should use these days,
> merging will make this much easier.
>
> 2) WUML is s much shorter.
>
> 3) WUML is pythonic, at least syntatically-wise.
>
> 4) WUML will greatly boost any frontend developer's lead time.
>
> Implementation Details
> --
>
> In a gist, I will basically be merging the best components of JS/CSS/
> HTML, and providing a markup syntax for them in a pythonic fashion.
>
> Details:
>
> - Architecture: The WUML layer will live 

Re: Application to update the Test Suite

[Gabriel Hurley]

Maybe it's an overly simplistic question, but: what makes the tests
slow currently? It's not simply the volume of them. It's more than
possible for Python to race through hundreds of tests per second under
the right conditions.

Some of Django's test modules obviously zip along, but others seem to
take a rather long time to complete individual tests. Has anyone
identified which tests are the slowest and what is making them so
slow? Is it the length of the tests? The parsing? The fixtures that
are loaded? The data generated in the test itself?

Without knowing what gives the current test suite its performance
characteristics aren't we all just guessing at how a rewrite of it
will compare?

Perhaps a good test would be to take one test module and convert it
from doc tests to unit tests and profile the before and after versions
to see how they compare. While the micro-scale may not ultimately
compare to the macro, it would at least be a starting benchmark.

I don't have any answers here, but that's what occurs to me about
performance...

All the best,

- Gabriel

On Apr 9, 12:51 pm, Paul McMillan  wrote:
> I've revised the proposal, but am inlining more complete answers.
>
> > If someone needs to fix a bug, they will essentially need to
> > write the test twice; once for the old framework, and once for the
> > new. Do you have any suggestions on what we should be doing to
> > mitigate this complexity?
>
> Unfortunately some mismatch seems inevitable for major changes like
> the proposed one. I will include comments indicating where
> corresponding test code in the previous branches can be found to help
> with this problem. If the test code is a completely new chunk of code,
> it will be written in the unittest style which should not be too hard
> to add to the old test suite. Many of the bits of code that are
> currently doctests are fairly well vetted by now, and so should
> hopefully have few changes necessary for backports. If it's just a
> minor couple line testing change, that shouldn't be too hard to make
> into a doctest if that's more appropriate. Better ideas are, of course
> welcome.
>
> > We have a buildbot currently in development; if you're have the
> > resources to contribute, it would be good if these could be integrated
> > permanently into the build farm.
>
> That might be possible. I was intending to pull up vmware instances on
> my development machine, but we should discuss how best I could
> contribute to that.
>
> > The #python IRC channel needs to think about the problem a little more.
>
> I figured that was probably the case, given that you included that
> aspect in the project suggestion...
>
> > While this project is *very* appealing from a project point of view --
> > we get the benefit of individually failing and isolated tests -- but
> > the risk of test runtime blowouts is huge. Any suggestions on how to
> > tackle this problem (and speed up test runs in general) would be
> > almost as valuable as the doctest->unittest conversion itself.
>
> This is a bit of a sticky problem. I'll be thinking about it between
> now and when the project (potentially) starts, but my first thoughts
> are as follows:
>
> We know that the existing doctests work when run sequentially. There
> may be bugs that are revealed as they're run individually, but to a
> first order, we know that some tests can safely be run sequentially
> without the setup/teardown each time. Since we're worried that this
> process is going to greatly inflate runtime, why not investigate
> options that let us avoid it where appropriate? Specifically, why not
> structure things such that we can lump tests together into groups that
> can safely be run sequentially, but also allow a "full" test run that
> runs each tested item individually as is currently the case for
> unittests?
>
> There are a couple problems with this approach. The first is that
> there are now 2 different ways to "pass the tests" - the quick run and
> the full run. Developers will still have to run the "full" run
> sometimes, negating at least some time saved. On the other hand, the
> proposed "quick" run doesn't provide LESS coverage than the existing
> doctests, so it might be good enough, particularly for tests which are
> currently in the regression test category. Unfortunately, it's
> probably not broadly appropriate for a majority of existing unit
> tests. We could make the "quick" option the standard for unit tests,
> with the "full" option reserved for assistance in bug hunting when
> there's an identified error.
>
> It needs more concerted thought, but I'd be interested in feedback.
> Maybe it's a terrible idea. This subject should probably have a
> dedicated thread here for better exposure and more specific
> discussion. Hopefully others have good ideas.
>
> In any case, I should do some profiling work as I'm doing the
> conversion to identify particularly inefficient areas and clean them
> up. This is part of the advantage of 

Re: High Level Discussion about the Future of Django

[Gabriel Hurley]

If you haven't already, take a read through the "internals" section of
the docs. It covers a number of the questions you've asked about
deprecation, what can be changed in minor (1.x) releases, etc.

http://docs.djangoproject.com/en/dev/internals/

They were definitely interesting for me.

Being a long-time django user but only recently a contributor, I'd
imagine any truly breaking changes would have to be targeted for 2.0,
which really is just a "someday" right now from all I've gathered.

Also, scattered throughout the wiki section of the docs are numerous
high-level ideas for future releases. They're hard to find, but
they're in there.

Most of the high-level stuff I'd personally like to see has already
been brought up in GSOC proposals and wiki pages, so I can't add much
to that discussion right now. But hey, that's a good thing, right? It
means I like where Django's (probably) headed!

Once 1.2 gets released, I think we'll all be a lot happier, right? (by
the way, congrats to the core devs on knocking out the last ORM ticket
that was open against 1.2 today! That's awesome!)

All the best,

 - Gabriel

On Apr 4, 8:02 pm, orokusaki  wrote:
> This is a bit abstract, but I'd like to bring up this idea, and
> firstly let me say that I don't intend to waste the time of the major
> contributors (unless you want to join in of course). I mostly want to
> get an idea of what some of the contributors/feature proposers out
> there are thinking of, in a sort of fly by the seat of your pants way.
>
> Through reading some of the ideas/problems on this group (including my
> own) I've noticed that some tend to be A) too far in the future, B)
> too abstract, C) (very important) Backwards incompatible, D) (very
> important) Too much architecture changes. The discussions tend to turn
> from macro to micro very quickly because of some of the existing
> constraints.
>
> 2 thoughts came to mind:
>
> 1) What if every major element could be re-factored for better
> extensibility (and perhaps speed as well) without regard for the
> backwards compatibility.
> 2) Imagine the progress that could be made if the existing code base
> was able to be re-factored in one week (impossible of course, but
> hypothetically speaking), knowing everything that the developers know
> now.
>
> I know neither of those is possible at the moment, but take those two
> ideas (rules) in mind, and talk about what you'd add / change / make
> better / etc.
>
> Perhaps this is way more 2.0 than even 1.3, but I wanted to get a very
> early look through foggy goggles into the future so that I can come up
> with ideas. I've been bombarding Russell K M with questions, thoughts,
> etc that are just very poorly timed with 1.2 Beta and all, and I want
> to step back and really prepare for next time.
>
> 2 related questions for anyone who cares to answer:
>
> 1) Is anything allowed to become non-backwards compatible during a .x
> release? (ie, from 1.2 to 1.3 or 1.4)
> 2) When will 2.0 development begin?

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