Re: Reduce bug triage overhead: DjangoAwesomeBot

On May 12, 2009, at 13:24, J. Clifford Dyer wrote: > I don't see this as a necessary requirement for all patches. What if > the patch has nothing but tests in it, and is improving something that > was sub-optimal or missing altogether in the test code. I'm sure you can find 99

Re: Making Django a bit more AJAX friendly

On May 8, 2009, at 11:25, OverKrik wrote: > Hello, I am working on heavy-AJAX-based website and use firebug alot > to check responces from server, in case of 500 error Django sends full > 500 page which is not very easy to use. I've made a simple patch to > provide light version of 500 page in

Re: A Letter to the Authors of Web Authentication Libraries

On May 3, 2009, at 15:34, Paul Johnston wrote: > the security benefits of per-user salts are minor. No. - Ludvig --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group,

Re: IPy for settings.INTERNAL_IPS

On Mar 15, 2009, at 05:02, Jeremy Dunck wrote: > class CIDR_LIST(list): >def __init__(self, cidrs): >from IPy import IP >self.cidrs = [] >try: >for cidr in cidrs: >self.cidrs.append(IP(cidr)) >except ImportError: >pass >

Re: Declarative fixtures for django

On Mar 8, 2009, at 19:01, Ben Ford wrote: > class app__Model(DataSet): > class generic_instance: > field_one = ... > lots of other generic fields here > > class another_instance(generic_instance): > different_field = ... > other_overridden_field = ...

Re: testclass

On Mar 8, 2009, at 12:06, nenduvel wrote: > so i have two questions: > > - how can i let my test work > - perhaps somebody knows a better way to test my application This is a "how do I?" sort of question. The best place to ask those is the django-users mailing list. This list is for the

Fwd: FileField.delete_file opening a file when deleting

Begin forwarded message: > From: Ludvig Ericson <lud...@lericson.se> > Date: February 22, 2009 22:37:16 GMT+01:00 > To: django-developers@googlegroups.com > Subject: FileField.delete_file opening a file when deleting > > django.db.models.fields.files.FileField.de

Re: Silently capturing all UnicodeDecodeError exceptions in widget rendering

> On Feb 20, 2009, at 22:22, Ludvig Ericson wrote: >> logger = logging.getLogger("django.template") >> # ... >> try: >> do_whatever() >> except MyError: >> logger. > > How very clever of me to just leave a half-written exam

Re: Silently capturing all UnicodeDecodeError exceptions in widget rendering

On Feb 20, 2009, at 20:38, Ben Gerdemann wrote: > > I just spent a good part of my afternoon tracking down a bug in my > code, that eventually turned out to be a Unicode encoding problem. The > reason it took me so long to track down the problem is this code here > in 'template/__init__.py': > >

Re: Is this true. that django really takes a lot of memory?

On Feb 18, 2009, at 02:13, Malcolm Tredinnick wrote: > > On Tue, 2009-02-17 at 18:57 -0600, Jeremy Dunck wrote: >> On Tue, Feb 17, 2009 at 6:49 PM, Malcolm Tredinnick >> wrote: >> ... >>> I'd be somewhat against this, I think. It's *very* easy to reuse >>> querysets

Re: Django, initial data and custom SQL

On Feb 12, 2009, at 11:53, Russell Keith-Magee wrote: > On Thu, Feb 12, 2009 at 4:49 PM, Ludvig Ericson >> One solution, which is entirely backwards-compatible, would be to say >> that "if you want your custom SQL to run after indices creation, name >> files '*.pos

Re: Django, initial data and custom SQL

On Feb 12, 2009, at 07:48, Russell Keith-Magee wrote: > On Thu, Feb 12, 2009 at 2:54 PM, Ludvig Ericson > <ludvig.eric...@gmail.com> wrote: >> >> I fail to see how "it has consequences for existing code", as Russell >> put it. > > It has consequences

Re: Django, initial data and custom SQL

Feb 11, Johan Bergström: > I took the liberty of creating a ticket with attached patch at: > http://code.djangoproject.com/ticket/10236 I fail to see how "it has consequences for existing code", as Russell put it. I did discuss this with Bergström, and we came to the conclusion that it

Re: Testing framework inflexibilities

Feb 8, Russell Keith-Magee: > First off - it isn't impossible to do what you are describing with the > existing setup. There is no reason you couldn't override _pre_setup() > in your subclass and either re-instantiate self.client, or modify the > self.client instance that has already been

Testing framework inflexibilities

Hi, I realize this topic is in a gray zone between django-users and django-developers, but I thought it'd be more fitting to post it here. I needed to inject things into the session, and I'm not using regular sessions. I have my own session framework*, but the testing framework is rather

Re: reason for missing readline() in uploaded files?

On Jan 30, 2009, at 22:19, Todd O'Bryan wrote: > On Fri, Jan 30, 2009 at 3:10 PM, Ludvig Ericson > <ludvig.eric...@gmail.com> wrote: >> >> On Jan 30, 2009, at 17:28, Todd O'Bryan wrote: >>> OK, after I did this, I was lying in bed and had the following >&g

Re: reason for missing readline() in uploaded files?

On Jan 30, 2009, at 17:28, Todd O'Bryan wrote: > OK, after I did this, I was lying in bed and had the following > revelation. Would there be anything terribly wrong with just using > __getattr__ in UploadedFile to forward all attribute requests that the > UploadedFile can't process to self._file,

Re: proposal: forloop previous and next

On Mon, 2009-01-26 at 16:16 -0200, Santiago Perez wrote: > Hi, I found myself needing to reference the previous or next element > of a list within a for loop of a template. > I think it would be pretty easy to implement the following extra > members to the forloop context variable: [snip] Though

Re: Joins and aggregates

On Jan 21, 2009, at 14:10, Russell Keith-Magee wrote: > Any opinions? Any other options that I may have missed? Sorry if I'm stating the obvious, but would it be impossible to error out if two aggregates cause this unexpected behavior? I mean then I'd say raising an exception for such queries

Re: get_url() and get_url_path() for 1.1?

[1] http://code.djangoproject.com/wiki/Version1.1Features At best I would think there'd be a deprecation plan until 2.0, as this kind of BC is what I expect of Django for 1.x. Also, is this really worth it as this point? My initial reaction to that thread was, honestly, "Let's have it

Re: Multi Database use with statement

On Dec 27, 2008, at 12:23, wei guangjing wrote: > from __future__ import with_statement > from django.contrib.auth.models import User > from django.db import using > > with using('db1'): >print User.objects.count() # db1 user count >with using('db2'): >print User.objects.count() #

Re: Setting Session time out value to settings.py

On Dec 25, 2008, at 10:33, burcu wrote. Please ask the Django users mailing list for usage-related questions: http://groups-beta.google.com/group/django-users --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django

Re: no module named _sqlite3 on Mac OS X

On Dec 25, 2008, at 13:08, Rick Dooling wrote. Please ask the Django users mailing list for usage-related questions: http://groups-beta.google.com/group/django-users --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups

Re: view permission for contrib.admin

On Dec 18, 2008, at 09:12, gert wrote: > Your thoughts on this? The Django book, for example, clearly states that the admin is for administrators. Nothing less. - Ludvig --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google

Re: The Django Book, and outdated information

On Dec 6, 2008, at 09:07, David Zhou wrote: > Is it possible to reword the introduction on the Django Book website > (http://www.djangobook.com/) or perhaps somehow update it? I fail to see what this has to do with the development of Django. Ludvig Ericson [EMAIL PRO

Re: Django, Simplejson and speedups

On Nov 28, 2008, at 10:56, Johan Bergström wrote: > I still wonder if there's a better solution for somehow allowing users > to drop in their own simplejson without resorting to edit > django.utils.simplejson or overriding sys.modules. This would reduce > the need for upgrading the bundled

Re: Dropping Python 2.3 compatibility for Django 1.1

On Nov 25, 2008, at 18:08, Jacob Kaplan-Moss wrote: > I'd like to officially drop Python 2.3 support in Django 1.1. Discuss. Oh god please, YES! Gimme my decorator syntax sugar, oh yeah. - Ludvig. --~--~-~--~~~---~--~~ You received this message because you are

Re: Django & memcache hashing

On Nov 20, 2008, at 05:20, Ivan Sagalaev wrote: > What concerns me is that this will break the usage of memcached > without > Django's cache API. I had the need a couple of times to do plain > instantiation of memcache.Client and work with it. If it won't see the > cache the same way as Django

Re: Django & memcache hashing

On Nov 20, 2008, at 00:55, Malcolm Tredinnick wrote: > Okay. If we go this path, it's something to include in Django, rather > than recommending yet another caching package. We either make it a > configuration option to force python-memcache or cmemcache or we just > "Do The Right Thing", with

Re: Django & memcache hashing

On Nov 20, 2008, at 00:11, Malcolm Tredinnick wrote: > That's possible. The hash function in the pure-Python memcached > wrapper > is replaceable (it's an attribute), so I was looking at replacing it > with the version from cmemcached. Using a third hashing algorithm > would > be a bit silly,

Re: Django & memcache hashing

On Nov 19, 2008, at 12:26, taleinat wrote: > What about having Django's memcached cache backend implement its own > hashing algorithm? This could be the "standard" one used in > libmemcache and cmemcache, or perhaps a consistent hashing algorithm > [1] such as libketama[2]. As I said in the

Re: Remove "old docs" message from Django docs

On Nov 19, 2008, at 00:13, Russell Keith-Magee wrote: > That is exactly what _is_ happening. You only get the olddocs > parameter if you are visiting from a djangoproject.com/docs URL. If > you go in via docs.djangoproject.com, you don't get the olddocs > warning. > > The confusion may be caused

Re: Django documentation index redesigned

On Nov 19, 2008, at 00:11, Andrews Medina wrote: > > On Tue, Nov 18, 2008 at 5:47 AM, Mike Scott <[EMAIL PROTECTED]> wrote: >> +1! >> >> Just one suggestion - if the final "bateries included" could be >> split into >> contrib apps, and core library that'd be nicer. > > +1 Why are you +1ing a

Re: Remove "old docs" message from Django docs

On Nov 19, 2008, at 00:13, Russell Keith-Magee wrote: > That is exactly what _is_ happening. You only get the olddocs > parameter if you are visiting from a djangoproject.com/docs URL. If > you go in via docs.djangoproject.com, you don't get the olddocs > warning. > > The confusion may be caused

Re: RequestContext rarely used (branched from Feature reviews for 1.1)

> Then why not just change the docs/tutorial to use or mention > direct_to_template instead? > > Granted, there is a bit of momentum behind render_to_response, but if > the docs are changed it will just be the status quo until that time > people start catching on to the simpler method. Isn't

Re: Multi-Threaded Dev Server

Django isn't thread-safe, and we know that. The best solution I can come up with would be to use the type of multitasking given by the processing library in py2.6. http://pypi.python.org/pypi/processing Ludvig Ericson --~--~-~--~~~---~--~~ You received this message

Re: ANN: Django 1.0.1 released

s to how this can happen. The reason is that MANIFEST.in doesn't tell setuptools to include those directories in the distribution. http://code.djangoproject.com/browser/django/trunk/MANIFEST.in - Ludvig Ericson --~--~-~--~~~---~--~~ You received this message be

Re: Ticket 9483

ilter better, it might be > worthwhile to put it under the localization stuff. You try making an implementation of the actual English title casing rules, and let me know how that goes. :P str.title is a very simple title casing function, and there's a reason for that.

Re: Ticket 9483

On Nov 4, 2008, at 15:26, H. de Vries wrote: > From a publishing point of view, I don't know for sure Python's method > is correct. Personally, I don't think so. I'd have to say, if Python's misbehaving, Python should be patched. And also, I'm strictly against making the title filter not

Re: Arbitrary objects in urlconf

On Oct 29, 2008, at 18:23, Ludvig Ericson wrote: > class MyTest(object): > def resolve(self, request, path): > if request.get_host().is_very_nice(): > urlconf = x1 > else: > urlconf = x2 > return x2.resolve_and_stuff(reques

Arbitrary objects in urlconf

be backwards-compatible, as it only adds. It'd allow for a lot of cool stuff too. And some dumb. But, as a wise man once said, "With great power comes great responsibility." Ludvig Ericson --~--~-~--~~~---~--~~ You received this message because you are

Re: Proposal: Decouple messages from contrib.auth

in any regard. Ludvig Ericson --~--~-~--~~~---~--~~ 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 g

Re: admin.autodiscover() uses method that cannot find files inside of eggs: possible fix included

> So, what we want the autodiscover to do is to run > from import admin > which would be > mod = __import__(appname, {}, {}, "admin") I should proof-read more. from import admin is the same as admin = __import__(appname, {}, {} ["admin"]).admin _but_ our interest lies within executing

Re: admin.autodiscover() uses method that cannot find files inside of eggs: possible fix included

On Oct 23, 2008, at 16:53, Kurt wrote: > > Could always use the super hacky "check the ImportError message for > the name of the admin module" to decide whether to reraise the error > or not. Please don't. The solution lies within the fourth argument to __import__. The statement from x.y

Re: Newbie Question on Forms

On Oct 12, 2008, at 06:41, Russell Keith-Magee wrote: > Apologies for firing prematurely. Dude. Ludvig Ericson --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post

Re: Django & memcache hashing

hat all your Django setups are using the same memcached library. You can tell Django to only use one library through the `KITTENS_AND_BEER` setting. > Your violence towards animals is noted with disappointment. However, > when I rule the world there may be a place for you in

Django & memcache hashing

uot; - I'm sorry, but you'll have to choose. This took _ages_ to track down, and caused personal loss as well as execution of a number of kittens. Ludvig Ericson [EMAIL PROTECTED] --~--~-~--~~~---~--~~ You received this message because you are subscribed to

Re: dealing with legacy tables without primary key

On Oct 2, 2008, at 10:31, Eric wrote: > > Hi, > I saw few questions from people who wonder how to manage tables > without primary key (when using inspectdb on a legacy db); > A great hope is born: I just discovered that this problem could be > adressed, at least it works with sqlite: > > just

Re: admin doesn't allow more than one null fk where unique=True

NBI'm not saying this is an error of Django, I'm just saying IntegrityError bubbles up at times. NB**2 The exception's type differs between backends. Ludvig Ericson [EMAIL PROTECTED] --~--~-~--~~~---~--~~ You received this message because you are subscribed

Re: Inner imports in core code

On Sep 24, 2008, at 18:27, Alex Myodov wrote: > Being curious, had tried several benchmarks as well. > Indeed, the function-level imports have some overhead. But the > overhead becomes less and less important, as long as the function > complexity increases. If a function does nothing except

Re: Inner imports in core code

On Sep 24, 2008, at 14:52, Simon Willison wrote: > Not entirely sure how I managed to miss your benchmark figures when I > read your mail, but I'm wrong here - there's clearly a performance > overhead involved in importing inside a function. It would be > interesting to see how much this affects

Re: Postgresql transaction aborts, despite being in autocommit mode

On Sep 23, 2008, at 18:32, [EMAIL PROTECTED] wrote: > Django's saving can trample data unintentionally, and indeed, we've > seen this in production. Trampling data is an extremely hard to find > problem since it amounts to a race condition. Since this could be > easily avoided in several

Re: Signal Connection Decorators

nd matches these two styles. (math.sqrt, str.encode, etc.) Ludvig Ericson [EMAIL PROTECTED] --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email

Re: I want a pony: Distributed RCS

On Sep 11, 2008, at 00:15, Jeff Anderson wrote. Honestly, not that my opinion matters in any way, but: Don't fix it if it ain't broken. Good day to you Ludvig "lericson" Ericson [EMAIL PROTECTED] --~--~-~--~~~---~--~~ You received this message because you are

Re: Signal Connection Decorators

On Sep 11, 2008, at 21:19, Justin Fagnani wrote: > I just got a chance to look at this, and I like it, but have one > suggestion. From a usage standpoint, wouldn't it be simpler to have > the decorator just be the signal name, like @pre_save? I can't see any > situation where you'd use a

Re: I want a pony: Django Cheeseshop

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sep 10, 2008, at 18:30, mrts wrote: > as Django and Python communities are different, overflooding > CheeseShop > with Django apps does not serve Python community at all. Sounds like an "issue" with PyPI at worst -- actually a potential

Re: Title of admin app index view is untranslatable

On Aug 28, 2008, at 17:24, Rudolph wrote: > Jacob marked it post-1.0 because of the "string freeze", but it > doesn't change or add any strings since the title was already marked > as translated. This patch just fixes a bug (actually it just moves one > bracket). I'd like propose to change back

Re: Solved: DNS for *.djangoproject.com broken

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jul 22, 2008, at 16:40, Jeremy Dunck wrote: > In general, expect DNS hiccups for a while; the whole world is > patching right now. Off-topic, yes, but I have to ask, what do you mean? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin)

Re: QueryDict.iteritems behaves differently than QueryDict.items

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jul 4, 2008, at 00:45, Jure Vrscaj wrote: > Could this be fixed in 1.0? It breaks compatibility, I know. Although I'm not in any kind of position of making such a decision, I can make an educated guess: no. The reason is that most developers

Re: FormWizard - GETs on all but last step?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jul 1, 2008, at 18:56, Honza Král wrote: > That's -1 from me. I am not opposed to the idea in general, I just > don't feel it's needed and should be in the code. Sounds more like a -0 to me. -1 is, as far as I have seen, strong rejection.

Re: The block tag has multiple meanings

On Fri, Jun 27, 2008 at 4:33 PM, Antonis Christofides <[EMAIL PROTECTED]> wrote: > There are essentially two things that you can do with a block: > (1) define it (or redefine it); and (2) insert it somewhere in a > template. The block tag thus performs different functions depending > on

Re: Community representation, or, #django user "Magus-" needs to go far away

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jun 25, 2008, at 23:47, James Bennett wrote: > 3. As someone who hangs out in the channel pretty much 24/7 I can > vouch for him being helpful. An instructive example is to run "grep > thanks #django.log | grep -c Magus", and then compare to

Re: List of DDN Tickets

On Jun 23, 2008, at 19:45, AmanKow wrote: > Actually, 'required' is an argument to the *Model* field constructor, > and models are *not* always initialized from html forms. The field > certainly doesn't have to be represented as a checkbox in a form, > either. > [...] Yes, all of that is

Re: List of DDN Tickets

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jun 19, 2008, at 08:32, [EMAIL PROTECTED] wrote: > I'll go ahead and add http://code.djangoproject.com/ticket/5957 to the > list of DDN tickets that could use a resolution pre-1.0, IMO this > ticket should be pretty noncontroversial and is a clear

Re: Translation tickets

On Jun 16, 2008, at 01:38, Jacob Kaplan-Moss wrote: > No, actually, they can't - language maintainers have access to their > language(s) only and should only commit there. Then maybe you should oversee your system. http://code.djangoproject.com/changeset/7549 > It's true we need someone to step

Re: Translation tickets

On Jun 15, 2008, at 23:24, Marc Fargas wrote: > Languages like es, ca, etc which are spoken by lots of people have no > trouble in this. But it's not easy, i.e. the 5 tickets I spoke about > are > for "rare" languages. It the case of Hebrew it's even harder because I > can't type it's

Re: Translation tickets

On Jun 15, 2008, at 19:15, Marc Fargas wrote: > Hey, > There a few translation tickets (5 right now). > > Normally Malcolm takes care of all translation stuff that has not been > delegated (you know, some translations are directly dealt by its > maintainers). But as Malcolm is offline those

Re: Django community aggregator and non-English posts

On Jun 13, 2008, at 17:58, Tom Tobin wrote: > > The Django community aggregator includes non-English posts, which are > unfortunately pure noise for those of us who don't understand other > languages. Can we either restrict the aggregator to English posts, or > at least create sub-feeds for

Re: i18n improvements

On Jun 10, 2008, at 12:28, mrts wrote: > * contrib.localflavor should be deprecated and transferred to a > separate project or contributed to Babel. > > It is incomplete by nature as covering all regions/postal codes in > the world takes a lot of effort. > That effort is out of Django's

Re: Lost stdout and stderr on fcgi with Django

> Can you suggest any documentation I should read that describes how > FastCGI handles PIPES and file channels. The FastCGI spec. should be fine. > I thought something like that was happening but, if that was the case > wouldn't the output to stderr and stdout end up in the rendered pages >

Re: Aggregation Updates

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > s = 'abc' > t = s[:] > s is t >> True >> >> I'm willing to be corrected here, but my understanding was that for >> loop iteration was one of those optimization cases. > > It looks like it's an immutable-optimization from my further >

Re: Aggregation Updates

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > To my understanding, a slice isn't automatically a copy - it will be > in most cases, but there are cases where the bytecode compiler will > use the original list as an optimization. One example: > s = 'abc' t = s[:] s is t > True

Re: broken pipe issue with runserver #4444

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > I'm +1 on this. An exception should only appear on the console if > something serious is broken. The term you're looking for is "error", not exception. An exception can be expected. Where would you fellows suggest we catch this exception, and

Re: broken pipe issue with runserver #4444

While writing a little patch to get rid of the (annoyingly loud) 'broken pipe' exception/traceback; i found that there actually a ticket for it # which is marked won't fix. Is it really a problem at all? Ludvig "toxik" Ericson [EMAIL PROTECTED]

Re: Runtime initialisation of db_table from context

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > At a very high level, I have an application, which holds many > organisations, and these organisations each contain many products. I > may need to at times, partition the product data, so that some >

django,contrib.admin and validation

there'll be a change after the sprint, I don't know -- and it might interest you that the whole admin app is being rewritten, see newforms-admin. Sincerely, Ludvig Ericson --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google

Using newforms with several models

t doesn't make sense, obviously - but when they get more, you start to get code duplication, seeing as each form needs two lines on both 'sides' of the if statement. Sincerely, Ludvig Ericson --~--~-~--~~~---~--~~ You received this message because you are subscribed