On Tue, Apr 6, 2010 at 12:52 PM, Alex Gaynor wrote:
> Google assigns us some number of slots. From my memory: 2 years ago
> is was 3/4 slots, last year we had 6. We don't know how many we'll
> get this year.
We actually request a certain number of slots, and Google uses our
suggestion along wit
On Thu, Apr 15, 2010 at 1:57 PM, Kevin Howerton
wrote:
> The level of resistance I see to change or outsider code contribution
> is an enormous de-motivator for people (like me) to want to make any
> contributions in the first place. Why should I contribute a patch to
> your flawed architecture i
On Fri, Apr 16, 2010 at 9:32 AM, Mike wrote:
> Correct me if I'm wrong but I read it as "If you do not like our
> policy then stability, maturity, and longevity aren't your priorities".
> With all due respect it is not fair.
But isn't that exactly what people in this thread are saying? The main
c
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,
On Mon, Apr 19, 2010 at 10:19 AM, orokusaki wrote:
> The release of Django 1.0 comes with a promise of API stability and
> forwards-compatibility. In a nutshell, this means that code you
> develop against Django 1.0 will continue to work against 1.1
> unchanged, and you should need to make only mi
On Mon, Apr 19, 2010 at 9:54 AM, Peter Landry wrote:
> One suggestion that jumped out at me (which I admittedly know very little
> history about with regards to Django or other projects) was the "trunk
> ready" branch(es) [1]. Perhaps an effort to outline what that process might
> entail in detail
On Mon, Apr 19, 2010 at 10:38 AM, David Zhou wrote:
> The specific number of point releases to remain compatible with can
> probably be quibbled over, but I think the point is that maintaining
> across the entirety of 1.x releases when point releases take this long
> can be untenable for good forw
On Mon, Apr 19, 2010 at 11:05 AM, Dennis Kaarsemaker
wrote:
> I've been thinking of starting a proper contribution in django in a
> similar way: a github repo with per-ticket branches that are trunk-ready
> and regularly updated (rebased) against trunk until they are applied.
>
> So far I've only
On Mon, Apr 19, 2010 at 9:55 AM, orokusaki wrote:
> With all respect, you still haven't addressed my main concern: You
> told me that it was because of backward compatibility that this simple
> change couldn't be put in the trunk. It is backward compatible. If I'm
> wrong, it would suffice to have
On Mon, Apr 19, 2010 at 12:09 PM, orokusaki wrote:
> Firstly, thanks to Jacob for the highly hostile nature of his bedside
> manor.
Please, just stop. This doesn't help.
> Secondly, I didn't assert anything. I merely referenced the docs (I
> suppose this will be another case where you simply adj
On Mon, Apr 19, 2010 at 12:03 PM, orokusaki wrote:
> Ok, problem solved:
When I apply this patch I get six test failures.
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...@google
On Mon, Apr 19, 2010 at 12:23 PM, orokusaki wrote:
> -- No matter what industry you're in, or what your title is, your
> real job is "Sales Person". Your second job is "Customer Service", and
> finally your third job is "[Insert Job Title Here]".
Dammit, this isn't my job -- it's my fucking hobb
On Mon, Apr 19, 2010 at 12:24 PM, orokusaki wrote:
> Jacob, I just refreshed. Please don't kick me. I'm trying to have a
> dialogue, and I'm not trolling. Django is my life, and I want to help.
Then prove it.
Ball's in your court.
Jacob
--
You received this message because you are subscribed
On Mon, Apr 19, 2010 at 2:32 PM, Giuseppe Ciotta wrote:
> Having an additional field{s} in the ticket, only accessible to core
> developers, where they would put the "official" (as in: approved by a
> core developer) triage status of the ticket, could improve the
> efficency of the tickets review.
On Mon, Apr 19, 2010 at 3:34 PM, Gabriel Hurley 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 th
On Tue, Apr 20, 2010 at 3:53 PM, Robert Coup
wrote:
> Idea #1:
> When a ticket is currently closed Trac sends you an email saying
> "status:closed resolution:wontfix" and whatever comment is made by the
> person who closed it.
> How about a plugin for Trac that expands these ... "concise" emails w
On Tue, Apr 20, 2010 at 4:49 PM, Robert Coup
wrote:
> Tada... http://code.djangoproject.com/wiki/TicketChangeHelp
>
> Most of it is empty - please help fill it in!
This is an awesome start - thanks! I'll try to help fill stuff in and
edit for tone/style as I can.
> I can write you a trac extensi
Hi Owen --
I'd agree that static asset handling in Django needs to be improved,
though like you I'm not sure of the correct direction for this to go
in.
If you'd like to look into it, a good place to start would be by
looking at the existing static asset management tools in the ecosystem
-- last
On Fri, Apr 23, 2010 at 11:32 AM, Russell Keith-Magee
wrote:
>> Can a DB dump be shared?
>
> I don't have any problem sharing the raw ticket data. However, I'm not
> sure if there's anything else in the database (like emails and
> passwords/hashes) that we would want to strip out before sharing.
>
On Tue, May 4, 2010 at 3:11 PM, George Sakkis wrote:
> Is this a bug or a feature ?
Take a look at the source (django/contrib/sessions/backends/db.py;
line 16 - the load() function). If the session key doesn't exist in
the database, a new session key will be generated. This prevents users
from be
On Wed, May 5, 2010 at 11:48 AM, Kevin Howerton
wrote:
> ps. I don't want to get into a flamewar
Then next time leave out the rambling, ad hominems, and sweeping
generalizations. Focus on technical suggestions -- working code is
even better. If you have problems, suggest fixes concretely.
Jacob
On Wed, May 5, 2010 at 1:53 PM, Kevin Howerton wrote:
> Where django pulls a 500 it should call these two lines, which will
> dump the exception raised to stderr.
>
> type, value, traceback = sys.exc_info()
> sys.excepthook(type, value, traceback)
No, really it shouldn't.
I made a quick sc
On Wed, May 5, 2010 at 3:31 PM, Kevin Howerton wrote:
> I don't think you understand what the code I just posted is doing or
> what the issue I described pertains to.
You want Django to globally catch all exceptions and call
sys.excepthook. I'm telling you that's a bad idea -- I've tried it,
and
On Tue, May 11, 2010 at 10:23 AM, Liviu Chiributa wrote:
> I encountered a problem while writing some django tests on the svn
> version. Whenever I call reverse(urlname), the db is emptied.
>
> Here is the code:
I just tried out this exact same code, and it works fine for me with
both the RC and
On Tue, May 25, 2010 at 10:28 AM, Vinay Sajip wrote:
>> Agreed; Are you at the conference? If so, corner me at some point
>> (either during the break or during the sprints); if you're not, I'll
>> try and review the code at some point and give you some feedback.
>
> Sadly, I couldn't come to Djang
On Tue, May 25, 2010 at 12:06 PM, naos wrote:
> I was migrating some django project recently from django 1.0.4 to 1.2.
> In Django 1.2/1.1 I found that if model have 'evaluate' attribute then
> one will get exception in admin edit page for that model if the page
> contains inline forms with relate
We're not changing the template syntax. Full stop.
If you don't like Django's syntax, I'm sorry. There are literally
dozens of other template languages; I'm sure one will fit anyone's
personal needs and style.
Jacob
--
You received this message because you are subscribed to the Google Groups
"
rOn Thu, May 27, 2010 at 10:48 PM, Marcob wrote:
> I've a table with only 160.000 records (but a record has many fields)
> and opening its admin page takes 55 seconds. A select count(*) takes
> 50 seconds, so I know it's all a db problem.
Yeah, this is a known problem -- there really needs to be
This is a bit of a tricky thing to discuss since we've been talking
about this IRL at the sprints, and also on the list. I'll try to sum
up where we are now, but if anything isn't clear, ask.
We're currently working towards URLpatterns of the form::
('...', SomeView)
i.e. passing a class dir
On Fri, May 28, 2010 at 5:48 PM, Russell Keith-Magee
wrote:
> So - comments? Suggestions?
Just FTR, Russ and I have been talking about this for a few days here
in Berlin, and I'm in agreement with this 100%.
Jacob
--
You received this message because you are subscribed to the Google Groups
"D
Hey Steph --
I've had a chance to play with your code, and I'm impressed and
generally +1 on replacing formwizard with yours.
I couldn't tell from my quick play, though, if there were any
backwards-incompatible changes. There's a fair bit of code churn (in a
good way :), so before we could merge
On Mon, May 31, 2010 at 4:07 AM, Kevin howerton
wrote:
> http://code.djangoproject.com/ticket/10758
>
> Can we fix this? It's a pretty easy fix.
I really don't want to be a jerk here, but this is precisely the
*wrong* way to go about getting work. Reminders are okay, but little
"pings" like this
Aat EuroDjangoCon Russ and I discussed a "startup" mechanism that'd
cover this use case, as well as a whole lot more. There's a few hints
in the logging discussion a few threads down.
So I'm -1 on this specific proposal, but only because I expect it to
be obsoleted by me and Russ' startup proposal
On Wed, Jun 2, 2010 at 9:28 PM, Gregor Müllegger wrote:
> I don't know much about the startup proposal, but I expect it to be a
> startup.py file in an application folder that gets loaded right after
> the django internals are ready and before the models have been loaded.
> The mechanism we ask fo
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"
Hey Sebastian --
Thanks for the reminder; I'll take a look when I get a moment.
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,
Hey Sebastian --
Okay, turned out I had a moment now. I've reviewed your tickets. See
each one for particular comments, but in general they look good.
However, they're all missing documentation and tests, which need to be
present before they can be checked in. If one of these tickets line up
with
On Wed, Jun 9, 2010 at 6:59 AM, Russell Keith-Magee
wrote:
> PostgreSQL 7.4 was released in November 2005, and will be end-of-lifed
> (along with PostgreSQL 8.0) in July this year. Our usual yardstick of
> slow updates, RHEL4, shipped with PostgreSQL 7.4. RHEL5 shipped with
> PostgreSQL 8.1.
And
Hey folks --
Mahalo will be hosting a Django sprint at their offices in Santa
Monica June 19th and 20th, and they've been awesome enough to help me
get out to Cali for it.
So I'd like to invite y'all to join me, either in person at Mahalo HQ or online.
I'm trying something a bit different this t
On Thu, Jun 17, 2010 at 3:32 PM, dffdgsdfgsdfhjhtre wrote:
> This is my proposal: We get rid of djangosnippets as it is now, and
> replace it with a Mediawiki. The benefits are as follows:
FYI, djangosnippets isn't run by the Django core team, or anyone
really associated directly with us. IOW, it
On Thu, Jun 17, 2010 at 3:41 PM, Alex Gaynor wrote:
> So here's an idea, of dubious quality ;)
Okay, folks: at this point the discussion has pretty much descended
into bikeshedding territory. I'm going to read through everything
posted so far and try to post a summary and round-up to help us get
On Tue, Jun 22, 2010 at 4:51 PM, Jacob Kaplan-Moss wrote:
> The other huge win -- besides your great versions -- is that without
... er, *reasons*.
Damned wires getting crossed in my brain.
Jacob
--
You received this message because you are subscribed to the Google Groups
"Django de
On Tue, Jun 22, 2010 at 4:47 PM, Robert Coup
wrote:
> While people are throwing around 1.3 ideas... I think we should start
> the process of deprecating and removing support for mod_python. Why?
The other huge win -- besides your great versions -- is that without
mod_python support Django just be
Hey Craig --
Thanks for the notes - this is good stuff!
On Tue, Jul 20, 2010 at 8:41 AM, Craig Younkins wrote:
> I'm very glad you don't have MD5 as the default. SHA-1 (currently employed)
> is acceptable for now, but at this point there are theoretical attacks that
> can find collisions in time
On Tue, Jul 20, 2010 at 10:50 AM, Kiko Griffin wrote:
> Please take a moment to review the job description below and share
> with your network.
Please don't post job ads to this list.
This is your second warning -- you've posted job ads here before, and
before been told to direct them to django-
On Fri, Jul 23, 2010 at 8:17 AM, Tobias McNulty wrote:
> The only concern in that ticket seems to be that 0 means different things
> for different cache backends.
> There may have been some effort towards making them all behave the same when
> 0 is passed.
> Personally I prefer the approach of not
On Fri, Jul 23, 2010 at 9:37 AM, Jeremy Dunck wrote:
> I think maybe the rendering can just be altered to ignore tags with
> the old values?
Actually, I think I'd rather just remove them -- plenty of people
(including me) read the docs in plain text, and the "versionadded" is
just cruft.
I'd sug
On Mon, Jul 26, 2010 at 9:44 AM, Ramiro Morales wrote:
> Richard has opened ticket [1]14000 for tracking work on this.
14,000!
> One additional question: Should the 'versionchanged' notes
> get the same treatment?
Yeah, I think so. Remember: we might need to edit/rewrite certain
sections to cle
Hi Craig --
Once again, thanks for this work; I can see it paying off big. And I
know you know this, but for the benefit of anyone else reading this
thread:
**PLEASE report any security issues — potential or otherwise — to
secur...@djangoproject.com.**
(More on our security policy:
http://docs.d
On Mon, Jul 26, 2010 at 1:38 PM, Alex Gaynor wrote:
> Bzzz :), we do flush the entire session here:
> http://code.djangoproject.com/browser/django/trunk/django/contrib/auth/__init__.py#L84
Ah, you're right - thanks. Looks like it's been that way for a while:
http://code.djangoproject.com/changese
Hi Dennis --
I'm not totally thrilled with this proposal, though perhaps there's
some points I just don't get. As it is, though, I'm -0 on the idea.
update() is supposed to be an optimization that's "close to the metal"
of the database; adding potentially-hidden slow code to the mix rubs
me the wr
On Tue, Jul 27, 2010 at 2:39 AM, Mark Sandstrom
wrote:
> I've added a ticket with a patch for automatically discovering models within
> a package without using the app_label Meta attribute.
I can't quite follow what the motivation is here -- could you perhaps
explain *why* you created this patch?
On Wed, Jul 28, 2010 at 12:09 PM, Rajeev J Sebastian
wrote:
> I think it might be useful for people refactoring their ever-growing models.py
That's maybe part of what I don't understand: I can't ever say I've
seen a models.py so big that I felt the need to split it up. Or
rather, I have, but in e
On Wed, Jul 28, 2010 at 12:53 PM, Dennis Kaarsemaker
wrote:
> This would add boilerplate to each class and makes it nontrivial to do
> update() tracking for third party applications. I don't see why pre/post
> update signals are worse than pre/post save and delete.
Because the save/delete signals
On Wed, Jul 28, 2010 at 2:08 PM, Dennis Kaarsemaker
wrote:
> As implemented in my github branch it is called once (well, twice, pre
> and post) per update() statement, not once per object.
Okay, I missed that -- sorry.
Doesn't really change how I feel about the feature, though: I don't
see the p
Hi Vito --
On Thu, Jul 29, 2010 at 3:41 PM, Vito wrote:
> Are you working on it?, If so, please refer me to help in any way
> possible, if not, say why are we so far behind that?
If you read over the archives on this list for the last couple-three
months you'll see that there's a *lot* of activi
Hi Vito --
First, can you please do us all a favor and stop starting new threads?
If you'll just reply to the existing threads it's much easier for
everyone to track what's going on.
On Fri, Jul 30, 2010 at 12:01 PM, Vito wrote:
> Google since the beginning of the app engine gave support to Djan
On Fri, Jul 30, 2010 at 12:36 PM, Jacob Kaplan-Moss wrote:
> Django has a bunch of part time engineers and no budget.
That should have read *volunteers* -- the point is that not a single
person gets paid to work on Django.
Jacob
--
You received this message because you are subscribed to
On Fri, Jul 30, 2010 at 3:39 PM, Mark Bucciarelli wrote:
> The devs here _extremely_ patient with whiners [1].
>
> m
>
> [1] People with lots of ideas about how you should
> spend your free time, and spend hours writing emails
> trying to convince you how smart they are, but can't
> be bothered to
On Fri, Jul 30, 2010 at 3:57 PM, Jerome Leclanche wrote:
> Nice job scaring that poor guy who was just trying to be helpful. His
> first post is met with so much hostility and elitism, I can't imagine
> being him right now.
Could you please quote where you felt I was "hostile" or "elitist"?
Priva
On Fri, Jul 30, 2010 at 5:59 PM, OverKrik wrote:
> Hi, I've been profiling Django to see how much overhead is being added
> by ORM, and found a very strange case of memory usage(which is either
> some kind of bug or me misunderstanding low level stuff) - as long as
> I have 0 to 3 fields of any ty
On Sat, Jul 31, 2010 at 9:04 AM, tiemonster wrote:
> I've been doing lots of research with Django on GAE, and am actually
> using it in production. If you're interesting in this particular
> stack, please contact me off-list and I can attempt to answer any
> questions that you have.
I'd love to s
On Sat, Jul 31, 2010 at 7:20 AM, OverKrik wrote:
> Hi, I am not having any memory leaks, just checking how much memory
> every part of django use out of interest.(And because I am writing an
> article about how Django ORM rocks :) ).
You've constructed a somewhat artificial situation -- in the re
Hi Andre --
I'm sorry, but we can't help you here. This list is for discussion of
developing Django itself, not user questions.
Since you're very new to Python, I'd suggest trying comp.lang.python
(http://groups.google.com/group/comp.lang.python) or the #python IRC
channel on Freenode.
Once you'
On Tue, Aug 3, 2010 at 9:22 AM, Stephen Kelly wrote:
> I'd like to contribute more small patches to Django, but I must say it's
> demotivating that those haven't seen any action since being accepted, and I
> couldn't see what I need to do to get those committed. If someone can tell
> me what's mis
On Tue, Aug 3, 2010 at 9:55 AM, André A. Santos
wrote:
> about Django how does it work in terms of architecture?
Again, this isn't the right forum for these questions: we use this
list to coordinate the development of Django itself, not answer
questions. Please direct these kinds of questions to
On Wed, Aug 4, 2010 at 8:06 AM, Byron wrote:
> Updated the patch http://code.djangoproject.com/ticket/13795
Looks good. A couple of questions/comments:
* Is there a reason to keep CACHE_MIDDLEWARE_KEY_PREFIX around? I don't
quite see the point of a separate setting, so unless you can think of
Hi Hejsan --
Thanks for the reminder, and for your round-up of the solutions in the
previous thread.
Having used all three of the projects you looked at, and having spent
a bunch of time thinking about the problem, I've come to the
conclusion that nothing's really fully baked enough to consider a
On Thu, Aug 5, 2010 at 3:44 PM, OverKrik wrote:
> Hi, I am testing performance of three querysets
Good! We need as many benchmarks as we can get our hands on.
> I was expecting first two querysets to be faster, but for some reason
> it takes about ~105sec to finish (3) and ~130sec for (1) and (2
On Thu, Aug 5, 2010 at 6:14 PM, OverKrik wrote:
> Hi Jeremy, I will release all my code after finishing the test suite -
> I think, in about 2 weeks.
I'm looking forward to seeing it. I agree that the results are
counter-intuitive; seems there's *something* going on here that
shouldn't be happeni
On Sat, Aug 21, 2010 at 2:01 AM, Alex Gaynor wrote:
> My
> recommendation would be for any changes in Django itself to be merged,
> including the new form fields, but for the MongoDB backend (and,
> indeed, any future backends) to live external to Django,
I agree. I'd like to see the first step t
On May 8, 2006, at 11:44 AM, Joseph Kocherhans wrote:
> I'd like to get a branch started for the new authentication stuff I've
> been working on. A current patch is attatched to ticket #1428. This
> will make a easier for people to test this out, and give more feedback
> so I can get the docs up t
On May 8, 2006, at 3:12 PM, Luke Plant wrote:
> How do I test that the changes I've made to documentation (in the /
> docs/
> folder) are correct ReST, and will produce the HTML docs correctly,
> before committing something or submitting a patch?
The rst2html tool in the docutils distribution sh
On May 13, 2006, at 12:23 PM, bradford wrote:
> Will something like this ever be available for use with lighttpd and
> fastcgi?
>
> http://www.djangoproject.com/documentation/apache_auth/
Might be possible, but you'd probably need to ask the lighty folks.
Given that lightty doesn't have any eq
On May 16, 2006, at 3:37 PM, [EMAIL PROTECTED] wrote:
> Bizzaro-tastic! Spent half of the morning trying to figure this out. I
> finally just blew away the branch, got a fresh checkout, and Ta Da!
>
> /ME grumbles something about svn, makes a note, and goes back to work
Oh man have I ever been th
On May 16, 2006, at 3:11 PM, Joseph Kocherhans wrote:
> Anyone interested in mutiple authentication backends should check out
> http://code.djangoproject.com/wiki/MultipleAuthBackends
w00t!
> At this point only 2 backends are included, one that checks
> django.contrib.auth.models.User, and one t
Howdy folks --
I'm just finishing up the generic relationship stuff that Ian Holsman
posted about a while ago [1], and I need to add
django.contrib.contenttypes to INSTALLED_APPS for testing.
As I think about it, it seems that all the django.contrib models
should be installed in the test h
On May 25, 2006, at 11:27 AM, lazaridis_com wrote:
> At this point, Django's persistency layer seems intresting, but the
> evaluation uncovered a few weaknesses, most importantly the lack of
> schema evolution support:
This is actually one of the accepted Summer of Code projects for
Django, so
Hi folks --
So the benefits of automatic escaping are pretty obvious --
protection from XSS attacks -- but I'm wary of a few details in the
existing proposals.
First, escaping everything by default complete breaks every existing
template. That's not necessarily a complete deal-breaker, but
On Jun 20, 2006, at 6:26 AM, Luke Plant wrote:
> In fact there seems to be a problem with the whole website now -- it's
> very slow, and media.djangoproject.com doesn't seem to be working at
> all.
Yeah, the media server failed early this morning.
It should be fixed now, but I think the updates
On Jun 21, 2006, at 1:26 PM, Deryck Hodge wrote:
> I just wondered if Django had any copyright
> contingencies when submitting large chunks of code (obviously, small
> patches aren't as much a concern.) No biggie, if not.
We don't; my conversations with the company lawyers seemed to
indicate t
On Jun 21, 2006, at 12:13 PM, Simon Willison wrote:
> Rather than directly accessing GET and POST data
> you do it through some mechanism that /guarantees/ the format of the
> data returned - and raises an exception if it can't make that
> guarantee. There is no possible way of invalid data ending
On Jun 21, 2006, at 5:16 PM, SmileyChris wrote:
> Having used TAL a lot (like KID, automatically escapes), I did not
> actually find this annoying.
I really wish there was a way of saying this that didn't make me
sound like a jerk... but:
If you like TAL better, use it.
Again, I'm not
On Jun 21, 2006, at 8:25 AM, Malcolm Tredinnick wrote:
> I noticed earlier this evening that automatic documentation rebuilds
> aren't happening, either (models-api.txt and templates.txt have both
> been updated today).
OK, got this fixed (thanks!)
Jacob
--~--~-~--~~~---
On Jun 21, 2006, at 7:28 PM, Jeremy Dunck wrote:
> Was it Unicode? How did you find the offending bits? Is it something
> we could have helped with? (Can we help next time?)
Nah, just a small change in the layout of the test directory that
broke the update script (see http://code.djangoproje
On Jun 21, 2006, at 7:47 PM, Malcolm Tredinnick wrote:
> Sorry about that. I had not properly remembered that portions of
> runtests.py were used to generate the docs. :-(
Oh, no problem -- the doc generation code is a total one-off anyway,
so I kinda expect having to maintain it from time to t
On Jun 21, 2006, at 8:35 PM, Todd O'Bryan wrote:
> Does there seem to be consensus out there among web frameworks about
> whether escape=default, raw=exception or raw=default,
> escape=exception?
Not really sure, myself -- my impression is that most web frameworks
don't think about XSS all th
On Jun 21, 2006, at 9:29 PM, SmileyChris wrote:
> Out of interest, have you (both Jacob and anyone else involved in this
> discussion) seriously tried an auto-escaping templating system and had
> a problem with it opposing your needs?
At the risk of turning this into a war stories thread, I've ha
On Jun 23, 2006, at 9:16 AM, [EMAIL PROTECTED] wrote:
> So, would it be possible to create a branch for work on multiple db
> support? If so, and if you can restrict commits to branches only, then
> it would be great for Jon and myself to have commit access there.
Created at http://code.djangopro
On Jun 19, 2006, at 10:42 AM, Joseph Kocherhans wrote:
> I'd like to get a branch started for my summer of code project. It's
> not urgent, but something in the next couple of days would be great.
Created at http://code.djangoproject.com/svn/django/branches/generic-
auth/; enjoy!
Jacob
--~--~-
Howdy folks --
Time for yays or nays to merging the mutli-auth branch into trunk...
I've been running it for a few weeks without any problems, so I'd say
it's pretty much stable.
With Joseph moving onto his second branch () I'd like to get
that one closed off. So speak now or forever hold
Hi folks --
Quick proposal: what do y'all think about having ``object.save()``
return ``object``? It's slightly Java-ish, but it would allow::
p = Person(first_name="Jacob", last_name="Kaplan-Moss").save()
instead of the current two-line idiom of::
p = Person(first_name="Jac
On Jun 26, 2006, at 9:04 PM, Russell Keith-Magee wrote:
>
> On 6/27/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
>
>> The other way to spell this might be::
>>
>> p = Person.objects.create(...)
>>
>> Which is kinda orthogonal to ``get_or_cr
On Jun 27, 2006, at 9:58 AM, toth anna wrote:
> I'm working on my thesis in our academy (i have to
> implement, too).
> Searching for an enviroment, i found django, and it looks
> very nice.
> After reading tutorial, i have some questions (and more to
> come...:) before i fall in love with it.
>
>
On Jun 28, 2006, at 6:07 AM, Gábor Farkas wrote:
> what i think we are missing the most is to hear about the "main"
> developers (project owners?) (adrian, malcolm, jacob etc.) opinion
> about
> unicode-ification. if they think we should switch django completely to
> unicode, then fine. but if t
On Jun 28, 2006, at 8:08 AM, Gábor Farkas wrote:
> let's imagine for a second that the unicode-django patch is done and
> available (it's not, but let's imagine it is)
>
> would there be a chance to get it applied?
Obviously that would depend on the quality of the patch and the
ramifications of
On Jun 28, 2006, at 9:03 AM, Simon Willison wrote:
> As far as engineering goes, developing a water-tight test suite seems
> like a critical component for confidently adding unicode support.
I couldn't agree more strongly.
Sucks that writing good tests is so damn hard :)
Jacob
--~--~-~
Howdy folks --
Just a quick note that I've merged Joseph's multi-auth branch to
trunk. As far as I've seen over the past few weeks this doesn't
break anything, but if it does let me/him know.
Thanks, Joseph.
Jacob
--~--~-~--~~~---~--~~
You received this mes
On Jun 28, 2006, at 11:45 AM, Malcolm Tredinnick wrote:
> For things like applications/atomserv+xml and related ones (basically,
> everything else), data should be left unprocessed by the Django
> layers,
> I would have thought. For example, an Atom publishing request contains
> XML data that ca
On Jun 30, 2006, at 7:04 AM, Russell Keith-Magee wrote:
> However, since this change could effect people in the field, I
> thought I'd check for objections before I commit.
I'm +1 as long as looking up by ID still works as well. In my mind,
both of these should do exactly the same thing::
101 - 200 of 1372 matches
Mail list logo
