On Mon, Nov 29, 2010 at 9:27 PM, Bita Bita wrote:
> My client is in a immediate need for a front end engineer whi knows
> Django, Python, AJAX, and/or html5 . This is a full time position with
> a really good pay in Palo Alto, CA. Sent me your updated resume if
> interested.
You're on the wrong
On Fri, Nov 26, 2010 at 8:38 PM, Russell Keith-Magee
wrote:
> Ok - looks like I had a couple of seriously loose screws last night.
> I'll take another look today. Apologies for the confusion.
I noticed that you merged the change in — thanks!
I saw that you explicitly imported the names that used
On Sun, Nov 28, 2010 at 12:11 PM, Christophe Pettus wrote:
>> I'm not arguing that a salt helps against brute-forcing a *single*
>> password (it doesn't), but it does in fact help against someone trying
>> to brute-force your entire password database (or any subset of more
>> than one password), s
On Sun, Nov 28, 2010 at 12:19 AM, Christophe Pettus wrote:
> Let's do the math. The space of eight alphanumeric character passwords is
> 2.8e12. Even assuming you can cut two orders of magnitude off of that with
> good assumptions about the kind of passwords that people are picking, this
> me
On Sat, Nov 27, 2010 at 11:47 PM, Christophe Pettus wrote:
> Actually, no, the situations are really quite asymmetrical. In order to
> brute-force a password, an attacker has to be able to try many, many
> thousands of combinations per second. To log in a user, an application has
> to do it e
On Sat, Nov 27, 2010 at 10:14 PM, Christophe Pettus wrote:
> Right now, Django's auth system pretty much uses sha1 hardwired in
> (literally, in the case of User.set_password) for the hash. For a discussion
> of why a general-purpose hash function is not the best idea in the world for
> passwo
On Fri, Nov 26, 2010 at 9:44 AM, Russell Keith-Magee
wrote:
> I just took a look at your patch. For the most part, it seems fairly
> straightforward -- but I was stumped by the extremely small subset of
> symbols you've put in __all__.
>
> It makes perfect sense to me that we should adopt an __all
Do the Git-using core developers have a preference for merge vs.
rebase for updating an upstream-tracking branch? I prefer to rebase
to keep the changes in question at the branch HEAD, especially if the
branch hasn't been pushed publicly yet, but a rebase for something
that *has* been pushed means
I've updated the changes for ticket #12248 and placed them on GitHub:
http://code.djangoproject.com/ticket/12248
http://github.com/tomxtobin/django/tree/template-import-refactor-t12248
Is there any chance this might make it into the next release? The
ticket has been Accepted for several months,
On Thu, May 27, 2010 at 7:36 AM, Tom Evans wrote:
> Most PHP templating languages allow you to do things that are by
> design not in django's templating, for example in Smarty, one can
> assign new variables on the fly in the template, and even do crazy
> stuff like call functions that take argume
On Wed, Apr 21, 2010 at 1:33 PM, Jeremy Dunck wrote:
> On Wed, Apr 21, 2010 at 1:14 PM, Tom X. Tobin wrote:
> ...
>> There are no formal plans (on experimental's side) to merge anything
>> from experimental to trunk. Anyone is welcome to package up code from
>>
On Wed, Apr 21, 2010 at 1:08 PM, Tom Evans wrote:
> On Wed, Apr 21, 2010 at 6:14 PM, Tom X. Tobin wrote:
>> That said, we don't want to degrade the signal-to-noise ratio here, so
>> we'll be working off of the mailing list Kevin mentioned.
>>
>
> Presumably
On Wed, Apr 21, 2010 at 11:46 AM, Kevin Howerton
wrote:
> Thanks for the support Russ...
>
> I think Cujo (the name at least) has been abandoned and I have joined my
> efforts with some other developers also interested in contributing to an
> experimental branch.
>
> http://github.com/tomxtobin/dj
On Wed, Apr 21, 2010 at 11:53 AM, Jeremy Dunck wrote:
> Tom, it may be inconvenient at this point, but please consider forking
> the github django repo so that upstream pulls can be handled more
> easily.
I've been running a private Git mirror of Django for a long time now,
which we source for th
On Fri, Apr 16, 2010 at 11:13 PM, Jerome Leclanche wrote:
> For one, there is no split between a -users mailing list and a
> -developers mailing list. Understand that the Bazaar mailing list is
> just as active as django-developers (so less active than -users +
> -developers). But it does have on
On Fri, Apr 16, 2010 at 10:10 PM, Russell Keith-Magee
wrote:
> However, at this point, I would like to tell you a story about four
> people named Everybody, Somebody, Anybody, Nobody.
This is exactly why I try not to bitch too much about Django's
development process. It's very easy to complain,
I recently noticed that the Django test suite seemed to be ballooning
in run time, so I wrote a new test runner that tracked run times. I
set it to emit run times longer than two seconds, and had the
following results (under PostgresSQL, since that's what we use in
production):
**
Long ru
On Fri, Apr 16, 2010 at 9:36 PM, Russell Keith-Magee
wrote:
> On Sat, Apr 17, 2010 at 12:33 AM, sago wrote:
>>
>> On a completely unrelated note, any plans to move Django to git?
>
> I answered this exact question earlier in this thread. The answer is
> no, because it would make exactly no differ
On Fri, Apr 16, 2010 at 4:34 PM, Taylor Marshall
wrote:
> On Fri, Apr 16, 2010 at 12:23 PM, Tom X. Tobin
> wrote:
>> None of this means that I think the core development process should
>> change. (Well, besides my fervent desire that they officially adopted
>> git —
On Fri, Apr 16, 2010 at 11:23 AM, Tom X. Tobin wrote:
> But here's the great part: nothing is stoping anyone from hacking new
Argh, the snoot in me just winced at re-reading my post and noticing
that I misspelled "stopping". ::hangs head::
--
You received this messa
On Fri, Apr 16, 2010 at 10:32 AM, Jacob Kaplan-Moss wrote:
> I'm not arguing that "stability, maturity, and longevity" are
> "correct" priorities, only that, well, those are the ones we've
> chosen. I'm not saying it's "wrong" to want more rapid improvement,
> only that it's lower on *my* list.
M
On Fri, Apr 16, 2010 at 9:32 AM, Mike wrote:
> On Apr 15, 3:32 pm, Jacob Kaplan-Moss wrote:
>> For better or worse, we've chosen a development policy that
>> prioritizes stability, maturity, and longevity. If those aren't your
>> priorities, then perhaps a fork is the right answer.
>>
> Correct m
On Thu, Apr 15, 2010 at 1:57 PM, Kevin Howerton
wrote:
> "You seem to be suggesting that a fork will somehow magically fix the
> speed of Django development. I ask you: who is going to work on this
> fork?"
>
> I think a hostile fork is almost a certain outcome if development
> continues as it has
23 matches
Mail list logo
