Re: Revisiting multiline tags

Hey, may I suggest writing this up using our new DEP process? I don't mean to make people jump through hoops, but it would be useful for people like me who haven't been following the issue and don't want to wade through dozens of mailing-list messages, comment threads, patches, etc. Here's more in

DEPs: Django Enhancement Proposals

Yesterday at PyCon, about a dozen people from the Django core team had a lunch meeting to talk about various ideas we should implement. One idea was to start doing a Django equivalent of Python's PEPs, which would serve as a formal way to document large new features/changes in Django. The goal wou

Re: Support byte range requests in django.views.static.serve

On Sun, Apr 13, 2014 at 11:30 PM, wrote: > Is the Django community interested in supporting HTTP range requests in > django.views.static.serve > ? > I definitely support this. I've gotten bitten several times by the developmen

Changing deferred model attribute behavior

At the moment, if you call defer() or only() on a QuerySet, then access the deferred fields individually, *each* access of a deferred field will result in a separate query. For example, assuming a User model with username/bio/location fields, this is what currently happens: """ >>> u = User.objec

Re: URL dispatcher fallthrough?

On Mon, Mar 18, 2013 at 10:23 AM, julianb wrote: > Well, at the moment, as far as I am aware, you can't. The first URL will > match everything all the time, not giving the other views a chance to kick > in. > > So I propose some kind of URL fallthrough. The view could do > > raise UrlNotMatched >

Re: Proposal: deprecate and remove django.contrib.comments

On Fri, Mar 8, 2013 at 12:38 AM, Jacob Kaplan-Moss wrote: > On Thu, Mar 7, 2013 at 5:55 PM, Russell Keith-Magee > wrote: >> However, I'd argue against using /dev/null as a disposal mechanism. I don't >> think the code should ever completely disappear. If someone offers to take >> over, that's gre

Update on localflavor move

Hi all, We've been talking about moving django.contrib.localflavor into separate packages, outside of Django proper (https://groups.google.com/d/topic/django-developers/OiyEGmXTifs/discussion). Today I did the work of creating the django-localflavor-* packages and copying code/tests/docs to them.

Re: Python 3: should we apply unicode_literals everywhere?

On Tue, Aug 21, 2012 at 5:46 AM, Aymeric Augustin wrote: > In my opinion, option (2) is a logical move at this point. However I > believe it deserves a public discussion (or at least an explanation). > What do you think? I prefer option 2 as well, because it seems like the Right Thing To Do. Of c

Re: Breaking out localflavor

On Thu, Aug 16, 2012 at 4:38 PM, Russell Keith-Magee wrote: > I agree that this is certainly one way that we could address the > problem. However, localflavor isn't just forms. Some of the packages > (US in particular; and I think there's also a patch lurking for AU) > have database models as well

Re: Breaking out localflavor

On Thu, Aug 16, 2012 at 4:33 PM, Jacob Kaplan-Moss wrote: > An added benefit that you didn't mention is easier maintenance -- each > individual localflavor package could have its own maintainer(s), > meaning they wouldn't have to get the attention of a core committer to > get fixes in. Totally --

Breaking out localflavor

I'd like to move all Django localflavor code into a separate package, distributed separately from Django the framework. WHY? 1. We shouldn't be in the business of updating Romanian phone number rules (e.g., https://github.com/django/django/pull/275). That doesn't belong in a Web framework. 2. Th

Re: GitHub migration done!

On Fri, Apr 27, 2012 at 10:08 PM, Adrian Holovaty wrote: > OK, it's live! > > https://github.com/django/django Hi all, I've written a post-mortem here, for anybody interested in how the process went: http://www.holovaty.com/writing/django-github/ Adrian -- You received t

GitHub migration done!

On Fri, Apr 27, 2012 at 11:50 AM, Adrian Holovaty wrote: > We're going to do the migration to GitHub today. This means we'll no > longer be committing code to our Subversion repository. Committers, > please hold off on making commits until the migration is done. OK

Re: GitHub migration

On Fri, Apr 27, 2012 at 11:50 AM, Adrian Holovaty wrote: > We're going to do the migration to GitHub today. This means we'll no > longer be committing code to our Subversion repository. Committers, > please hold off on making commits until the migration is done. > > I exp

GitHub migration

Hey guys, here's an important heads-up! We're going to do the migration to GitHub today. This means we'll no longer be committing code to our Subversion repository. Committers, please hold off on making commits until the migration is done. I expect it'll be done by late afternoon Chicago time. I'

Re: django.contrib.sites.managers.CurrentSiteManager spanning more than one model

On Thu, Apr 5, 2012 at 11:46 AM, Rory Geoghegan wrote: > We currently have that code written. Is it worth turning that into a > patch for contrib.sites, with unit tests et al, and pushing upstream > into django? Should I fill out a bug? I don't think this added complexity/functionality is worth a

Re: auth.user refactor: the profile aproach

2012/4/5 Ian Lewis : > I'm curious though how the admin fits into your ideas. If you wanted to use > the > admin, would you have to use a User model that has and or supports all the > cruft on the current user model? e.g. username, password, email, permissions > etc. Yes, you'd need to tell the a

Re: Proposal: upgrading the choices machinery for Django

2012/4/3 Łukasz Langa : > Explicit choice values:: > >  GENDER_MALE = 0 >  GENDER_FEMALE = 1 >  GENDER_NOT_SPECIFIED = 2 > >  GENDER_CHOICES = ( >      (GENDER_MALE, _('male')), >      (GENDER_FEMALE, _('female')), >      (GENDER_NOT_SPECIFIED, _('not specified')), >  ) > >  class User(models.Model

Re: auth.user refactor: the profile aproach

On Wed, Apr 4, 2012 at 11:22 AM, Donald Stufft wrote: > Not adding anything, just saying that Architecture Astronaut is the best > term ever for this. Here's the source of that term: http://www.joelonsoftware.com/articles/fog18.html http://www.codinghorror.com/blog/2004/12/it-came-from-p

Re: [GSoC 2012] Enhanced contrib.auth

On Wed, Apr 4, 2012 at 10:16 AM, Stratos Moros wrote: > I'm apologizing for replying to my own post, but there are only two days > left before GSoC's submission deadline and my proposal has received very > little feedback. > > Since other proposals about contrib.auth are being discussed, I was > w

Re: auth.user refactor: the profile aproach

On Wed, Apr 4, 2012 at 9:57 AM, Jacob Kaplan-Moss wrote: > On Wednesday, April 4, 2012 at 9:44 AM, Russell Keith-Magee wrote: > > My point is that there is nothing about this problem that is unique to User. > Django's own codebase contains another example of exactly the same pattern > -- Comments.

Re: auth.user refactor: the profile aproach

On Tue, Apr 3, 2012 at 9:28 AM, Alex Ogier wrote: > I have written up a little bit about the alternate proposal that I made a > while ago, Solution 2a > from https://code.djangoproject.com/wiki/ContribAuthImprovements I just now got around to reading Jacob's solution and Alex's solution. Thanks t

Re: Migrating to 1.4

On Wed, Mar 14, 2012 at 10:22 AM, Dan Fairs wrote: > - We have a custom template tag that derives from ExtendsNode, and overrides > get_parent > - We have a custom Library implementation that overrides inclusion_tag(), > which knows >   about our template lookup logic; it broke because the signatu

Re: Revisiting multiline tags

On Sat, Feb 18, 2012 at 12:04 AM, Glenn Washburn wrote: > I'd like to reopen discussion on the multiline tag issue (see: > https://code.djangoproject.com/ticket/8652) which was closed 3 three > years ago as "won't fix".  The last comment notes that this won't > happen as the decision has been made

Re: Feature Request: Client side validation classes for forms

On Fri, Feb 3, 2012 at 11:46 AM, Karthik Abinav wrote: >   I was thinking about a feature that could be implemented. For common > fields like username having only alphanumeric , or phone numbers having only > numbers, a client side validation need not be written every time.Instead one > could dire

Re: start using less (and bootstrap!)

On Fri, Feb 3, 2012 at 12:25 AM, Harris Lapiroff wrote: > The Django admin is a major—if not *the* major—selling point to > budding developers. I worry that externalizing it (hence making it a > *separate* piece of software that needs to be discovered and > installed, which seems simple but can be

Re: start using less (and bootstrap!)

On Thu, Feb 2, 2012 at 2:49 PM, Sean Brant wrote: > Is this up somewhere public? I've been fighting the urge to do this as > well. Using django-compressor with less on Heroku is a non-starter > since you can't install node. Having this as a Python module would be > handy. Not yet, alas, but hopef

Re: Clarifications to ready for checkin policy / PEP-8 line lengths

On Mon, Jan 30, 2012 at 5:24 PM, Anssi Kääriäinen wrote: > And now for something completely different: what is the current view > of PEP-8 regarding line lengths? It seems lines longer than 80 > characters have been checked in somewhat regularly. How long lines are > OK, then? Yes, long line leng

Re: start using less (and bootstrap!)

On Thu, Feb 2, 2012 at 2:07 PM, Idan Gazit wrote: > * less.js has the distinct advantage of being easier to develop for than > sass for our purposes.If we go with a less.js solution (like bootstrap), we > might not need to require that all edits to admin "source" stylesheets > (less/scss) come wit

Re: Caching back-refernces on one-to-one fields

On Thu, Jan 19, 2012 at 12:15 PM, Carl Meyer wrote: > I don't think Adrian is proposing anything as extensive as #17. What > he's proposing (IIUC) wouldn't change the semantics of your sample code > at all. All it would do is prepopulate the FK field on the results of a > reverse-FK query, so the

Re: Speeding up tests

On Mon, Jan 16, 2012 at 10:46 AM, Anssi Kääriäinen wrote: > I have been investigating what takes time in Django's test runner and > if there is anything to do about it. The short answer is: yes, there > is a lot of room for improvement. I managed to reduce the running > speed of the test suite (on

Re: Caching back-refernces on one-to-one fields

On Wed, Jan 18, 2012 at 1:07 PM, Shai Berger wrote: > I have a small improvement to suggest for one-to-one fields: Make them cache > back-references on related objects. That is, assume Yes! Good improvement. And we should do the same thing for one-to-many fields (ForeignKeys): """ class Author(m

Re: Don't assume that missing fields from POST data are equal to an empty string value.

On Thu, Jan 12, 2012 at 7:40 PM, Tai Lee wrote: > class Profile(models.Model): >    first_name = models.CharField(blank=True, max_length=50) >    last_name = models.CharField(blank=True, max_length=50) >    address = models.CharField(blank=True, max_length=50) > > class ProfileForm(ModelForm): >  

Re: Proposal: drop Python 2.5 support in Django 1.5

On Sat, Dec 10, 2011 at 6:37 PM, Alex Gaynor wrote: > 2.5 is EOL and no longer receiving security patches even, it is > *irresponsible* of us to support it (I claim).  ANyways +1 This is a very good reason I hadn't though of. Anyway, looks like this is a plan! Excellent. Adrian -- You receive

Re: Proposal: drop Python 2.5 support in Django 1.5

On Sat, Dec 10, 2011 at 8:36 AM, Luke Plant wrote: > So, I propose that we attempt to merge the py3k work after the release > of 1.4, rather than let it go stale and lose the good work done so far, > and also drop support for Python 2.5 for Django 1.5. I think both of these proposals are great --

Re: Django 1.4 roadmap

On Tue, Nov 29, 2011 at 6:10 AM, Luke Plant wrote: > On 28/11/11 20:33, Adrian Holovaty wrote: >> I plan on starting this next week. Is there a list somewhere of what >> needs to get done? If not, I can make it, but obviously it'd be great >> if that already existe

Re: PUT and post data

On Wed, Dec 7, 2011 at 8:25 AM, Thibault Jouannic wrote: > I've read the submitting patches doc, but is a git pull request > accepted? For now, no. We'll be moving to GitHub in the near future, but currently we're using Subversion/Trac. Upload a patch via the ticket tracker (code.djangoproject.co

Re: Small problem with HttpResponseRedirect

On Mon, Dec 5, 2011 at 4:00 PM, Cal Leeming [Simplicity Media Ltd] wrote: > _redir = "//your/path/with/an/extra/slash/for/whatever/reason" > HttpResponseRedirect(_redir) > returns "Location: http://your/path/with/an/extra/slash/for/whatever/reason"; > > _redir = "/your/path/with/no/extra/slash" >

Re: Django-nonrel patches

On Sat, Dec 3, 2011 at 4:36 PM, Jonas H. wrote: > On Jacob's suggestion in this thread [1] back in April, I split the diff > between Django trunk and Django-nonrel into logically separated patches. > > I uploaded most of them to the ticket tracker (a few things are still > missing but these are th

Re: Feature proposal: models.CALL_DELETE or effective equivalent

On Thu, Dec 1, 2011 at 11:26 PM, Yo-Yo Ma wrote: > My proposal is to add a new on_delete=models.SET-ish feature (or a new > kwarg altogether) which would, when specified, cause the parent > object's delete to loop through an iterator of the related instances > and call the delete method on each fo

Re: forms/fields/widgets - howto contribute?

On Thu, Dec 1, 2011 at 12:56 PM, Aljoša Mohorović wrote: > i can try working on docs, test stuff or any other task but i need > some guidance and somebody to report to. > would appreciate any help/directions Hi Aljosa, There may very well be tickets in our ticket system devoted to this, so try t

Re: Improving test data experience

On Wed, Nov 30, 2011 at 4:22 PM, Jeremy Dunck wrote: >   1) expand on the testing guide to present fixtures as one option > for test data and point out the options to script fixture generation > or avoiding fixtures in favor of TestCase-called generation, > discussing tradeoffs in the approaches

Re: Allowing models to influence QuerySet.update

On Tue, Nov 29, 2011 at 3:27 PM, Kääriäinen Anssi wrote: > Is this correct for delete? A quick test (A1 is a model which I have hanging > around - details about it aren't important): > > from django.db.models.signals import post_delete > > def foo(*args, **kwargs): >    print args, kwargs > post_

Re: Django 1.4 roadmap

On Mon, Nov 28, 2011 at 6:40 AM, Russell Keith-Magee wrote: > So -- what we need is for someone in the core team who is able to find > the resources in their schedule to commit to shepherding a release. > Speaking for myself, I know that this almost certainly isn't going to > be me -- my work life

Re: Feature request: ForeignKey through parameter

On Thu, Oct 28, 2010 at 2:54 AM, Roald de Vries wrote: > I quite often reference foreign keys of foreign keys of foreign keys... > Wouldn't it be nice to have a 'through'-parameter for ForeignKey's? > >    class A(Model): >        b = ForeignKey('B') >        c = ForeignKey('C', through='B', relat

Re: More efficient negative lookups

On Wed, Oct 27, 2010 at 4:55 PM, Jacob Kaplan-Moss wrote: > However, just for the record I think the reason we decided to remove > __ne is the first place was that its existence introduces a weird > inconsistency with regard to other lookup types. That is, if there's a > "ne" why isn't there a "ns

More efficient negative lookups

Hi all, I'd like to fix an inefficiency in our ORM's negative lookups. A long, long time ago, we had an "ne" lookup for QuerySet.filter(), which would let us do "not equals" lookups, like this: MyModel.objects.filter(slug__ne='ignoreme') Unfortunately, we removed this lookup type in http://code

Re: django.contrib.comments is judging me

On Thu, Oct 7, 2010 at 9:42 AM, Jacob Kaplan-Moss wrote: > You know, I really don't think this is a big enough deal to bother > being completely picky about the deprecation policy here. It's a silly > setting that should have been removed pre-open-source when we did the > whole Django/Ellington sp

Re: django.contrib.comments is judging me

On Wed, Oct 6, 2010 at 10:09 PM, Owen Nelson wrote: > Moving forward, I'll be skipping the comment-specific setting and simply > setting PROFANITIES_LIST to ().  Any chance we'll see the setting removed in > the near future? Yes, it's about time we got rid of this $&*@ thing! (That was too easy.

Re: Conventions around plugable backends

On Mon, Dec 7, 2009 at 6:17 AM, Russell Keith-Magee wrote: > So, I'd like to call for a quick BDFL judgement. Everyone else should > feel free to weigh in with opinions if they have opinions, > preferences, or especially compelling arguments either way. My preference is (slightly) for class-based

Re: Proposal: enable CSRF middleware by default

On Thu, Mar 19, 2009 at 9:03 PM, James Bennett wrote: > Too late now since it's already committed, but I've got some serious > reservations about this one. More development effort should have gone > into improving and refactoring the middleware before it got > automatically enabled. Hmm, yeah...

Re: Proposal: New transaction API with multiple databases

On Fri, Mar 13, 2009 at 7:00 PM, Jacob Kaplan-Moss wrote: > Like James, I'm concerned with getting a 1.1 release that's as > high-quality as possible, and I'm concerned that a big change like > this late in the game could be too destabilizing to hit our (already > delayed) release timeline. On to

Proposal: New transaction API with multiple databases

I've been trying to get a multiple-database setup working with Django. Thanks to some trunk changes from the past few days (not to mention all of Malcolm's work with queryset-refactor, etc.), doing SELECTs from multiple databases is now pretty easy -- and I'd even call it "clean"! But INSERTs, UPD

Re: More multi-database plumbing (WAS Re: Changing DatabaseWrapper._cursor() to take a dict instead of settings)

On Fri, Mar 13, 2009 at 11:12 AM, Alex Gaynor wrote: > To give an idea of what I've suggesting I drew up a small diff(full test > passage): http://dpaste.com/14018/ I like this. It's straightforward, and it's backwards-compatible. One particularly nice thing about it is that it gives people the

More multi-database plumbing (WAS Re: Changing DatabaseWrapper._cursor() to take a dict instead of settings)

On Thu, Mar 12, 2009 at 11:53 PM, Alex Gaynor wrote: > Great, since we've moved so quickly on improving our plumbing for this there > was one other idea I wanted to put forth(since I believe it needs to happen > for any multidb implementation).  In terms of plumbing the cornerstone of my > multid

Re: Changing DatabaseWrapper._cursor() to take a dict instead of settings

On Thu, Mar 12, 2009 at 7:59 PM, Alex Gaynor wrote: >> I've created a ticket here: >> >>    http://code.djangoproject.com/ticket/10487 >> >> If anybody (Alex?) wants to code up a patch, I'll get it in ASAP. >> >> Adrian > > I've gone ahead and uploaded a patch(at this rate they'll be nothing to d

Re: Changing DatabaseWrapper._cursor() to take a dict instead of settings

On Wed, Mar 11, 2009 at 11:39 PM, Yuri Baburov wrote: > Maybe let's go a bit further towards pool of db connections and wrap a > bunch of lines importing backend into some function that depends on > engine argument? > And later call it with settings.DATABASE_ENGINE to import default backend. > >

django.db.backends refactored; hacks and third-party backends might break

To the maintainers of third-party Django database backends (like DB2, etc.) and whoever else is hacking/patching/corrupting the code in django.db.backends for fun or profit -- With the help of Alex Gaynor, I've just checked in a light refactoring of the database backends such that Django database

Re: Changing DatabaseWrapper._cursor() to take a dict instead of settings

On Tue, Mar 10, 2009 at 9:15 PM, Alex Gaynor wrote: > I've posted a patch, but I'd like to here from one of the external DB > backend maintainers, I know we technically don't have any backwards > compatibility requirement here, but I don't think we want to jerk them > around too much.  Another th

Re: Changing DatabaseWrapper._cursor() to take a dict instead of settings

On Tue, Mar 10, 2009 at 12:55 PM, Alex Gaynor wrote: > I've been looking at adding multiple database support to Django for a little > while now and as a part of my plan of action the first step is to remove all > references to the global settings in django.db.backends.* and replace them > with a

Changing DatabaseWrapper._cursor() to take a dict instead of settings

I'm working on adding multiple-database support to an application and am building a custom manager that lets me specify which DATABASE_NAME to use for a particular model. It looks something like this: class OtherDatabaseManager(models.Manager): """ This Manager lets you set the DATABASE_N

Re: Flatpage signal?

On Fri, Jan 23, 2009 at 6:16 PM, Jeremy Dunck wrote: > I'd like to do some processing any time a flatpage is requested. > > I can accomplish this by using a view middleware and testing for the > resolved view, but it seems a like a signal would be useful so I could > have a reference to the flatp

Re: Javascript issue on admin interface with prepopulated_fields

On Wed, Jan 7, 2009 at 9:50 AM, Matias Surdi wrote: > To solve this, I modified > ./django/contrib/admin/templates/admin/prepopulated_fields_js.html > > replacing the event "onkeyup" on line 5 for "onchange". > > Do you think this change could be applied to trunk? Do you want me to > submit a tic

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

uri, to answer your question: I try never to send the request object into a template context, except in rare cases like views/templates that do some sort of introspection -- like the Django debug view, for example. If I'm feeling like being DRY about media URLs, I just use a custom template tag

Django documentation index redesigned

After months of being frustrated (and hearing other people being frustrated) with our newish documentation index, I took some time tonight to reorganize the links, to make it easier and faster to find things. Take a look here: http://docs.djangoproject.com/en/dev/ I opted for a much more compact

Re: Feature reviews for 1.1

On Thu, Nov 13, 2008 at 1:48 PM, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > I've also reviewed most of the features on the list. I'll talk about the > review process -- and how y'all can contribute -- below, but if you just wanna > see my thoughts, they're here: > http://spreadsheets.google.co

Re: Proposal: Minor admin CSS refactoring

hacks currently used to filter CSS for > IE > 4. Encourage reuse of existing admin styles in custom app admins This all sounds good to me...particularly the part about removing the null.css file! Adrian -- Adrian Holovaty holovaty.com | ever

Re: Recursive inlines in admin?

e "standard" admin for the third-level objects, then use two-level inlines for the first- and second-level objects? Adrian -- Adrian Holovaty holovaty.com | everyblock.com | djangoproject.com --~--~-~--~~~---~--~~ You received this message because you

Re: djangoproject.com/documentation/ redirected

I havent gotten used to the new docs yet ...) The old ones are available here: http://www.djangoproject.com/documentation/0.96/ And don't worry about the new docs...I've been making some improvements to the new index, which I agree could use some work. Adrian -- Adrian Holovat

Re: djangoproject.com/documentation/ redirected

www.djangoproject.com/documentation/0.96/ > and > http://www.djangoproject.com/documentation/0.95/ Hey, you're right! I got confused by our inconsistency: for the 0.90 and 0.91 docs, we use /documentation/0_91/ (note the underscore instead of the period). Thanks for pointing this out, Adrian

djangoproject.com/documentation/ redirected

ion, but we could pop 'em online if there's an outrage. Adrian -- Adrian Holovaty holovaty.com | everyblock.com | djangoproject.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers"

Re: DjangoCon

this page: http://search.twitter.com/search?q=djangocon Adrian -- Adrian Holovaty holovaty.com | everyblock.com | djangoproject.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post t

Re: ANNOUNCE: Django 1.0 released

still be the case, over the next year or so? > > In other words, should I (or typical users) download the official 1.0 > version, or will it still be advised to track the development version? I think it's too early to tell, but the cool stuff is always going to be in trunk. Adrian

Re: Will oldforms completely go after 1.0?

k when forms was called newforms!" Adrian -- Adrian Holovaty holovaty.com | everyblock.com | djangoproject.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post

Re: #7666: Default managers should not restrict access to single related objects

e who have created custom managers. Other solutions? Adrian -- Adrian Holovaty holovaty.com | everyblock.com | djangoproject.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. T

Re: Django releases

On Sat, Jun 7, 2008 at 2:06 PM, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > * Start a "train release" schedule: schedule a couple of 1.0 betas, a > rc or two, and then a final release. Features that are done by the > dates get released, those that aren't, don't. Make these dates > aggressive bu

Re: API question for model saving

tionality? Name-wise, I suggest the use of force. ;-) force_create=True force_update=True Adrian -- Adrian Holovaty holovaty.com | everyblock.com | djangoproject.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Group

Re: Queryset-refactor merge in newforms-admin branch broke date_hierarchy filter

-- it was in the handling of dates(), not in the admin code. I've fixed it in [7486] and added unit tests in [7485]. Adrian -- Adrian Holovaty holovaty.com | everyblock.com | djangoproject.com --~--~-~--~~~---~--~~ You received this message because you are su

Re: Queryset-refactor merge in newforms-admin branch broke date_hierarchy filter

k at it now... Adrian -- Adrian Holovaty holovaty.com | everyblock.com | djangoproject.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to djang

Re: SVN Milestones

eta. Given that SVN has a number of tricky/backwards-incompatible changes (everything-Unicode and template auto-escaping), it'd be less of a hassle in the long term if we included all of those changes in one big release. Adrian -- Adrian Holovaty holovaty.com | everyblock.com

Re: Easier URL patterns

, without modifying any of Django itself, to do this. Just write a wrapper around the patterns() function that parses the syntax and creates "real" regular expressions. Rob, if you're big on this idea, you should implement it and upload it to djangosnippets.org. Adri

Re: Pick a value from list variable in templates

is time. It's quite easy to add custom template filters and template tags. Use them and enjoy them! :-) Adrian -- Adrian Holovaty holovaty.com | everyblock.com | djangoproject.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to

Re: Reorganising management/validation.py

lines. Malcolm, is there anything you're trying to do in the queryset-refactor branch that would be severely compromised by *not* taking this side trip of refactoring? Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ You rece

Re: ModelForms paranoia simplification?

On Thu, Feb 14, 2008 at 1:14 AM, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > Any strong objections to not behaving like Python here? Sounds like it's well worth removing. +1. Adrian -- Adrian Holovaty holovaty.com | dja

Re: Future-proofing django.template (and elsewhere) against circular imports

ing "from django.template.main import *". Adrian -- Adrian Holovaty holovaty.com | everyblock.com | djangoproject.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To

Re: Proposal: deprecated Model.__init__(*args)

more painful, but if we introduce a custom_query() method as Jacob suggested, that would solve it. Personally I tend to use the *args syntax in custom queries, but it's not a huge change to rewrite code to use custom_query(). Adrian -- Ad

Syndication feed framework should allow for parsing of URLs in the URLconf (#6304)

se, so if anybody is interested in this, just read the patch, which includes documentation updates. Having dealt with this for the past hour or two, my brain is a bit burned out thinking about it! :-) Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~

Re: #django registration

x27;m happy to take care of this -- I just don't know what's involved in registering a channel. Could you provide some more information on whom to talk to about getting it done? Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~--

Re: Undocumented admin feature for filtering rows?

llenge, it probably falls out of the scope of what the admin site should do. So given your two options, I'd suggest we do the first. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ You received this message because you are s

Re: Model Creation Optimization

x27;t think of a reason it uses dir() instead of hasattr(). I tracked down the change to changeset 2432 on the magic-removal branch in February 2006: http://code.djangoproject.com/changeset/2432 Do all the unit tests still pass if you convert it to a has

Re: ticket open fails

r taking the time to post to the list -- most other people probably would've given up. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django de

Re: Fixing app_label

On Dec 5, 2007 1:48 PM, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > The settings file syntax could look like this: > > INSTALLED_APPS = AppCollection( > App('django.contrib.admin'), > App('ellington.news'), > ) Whoop, I stopp

Re: Fixing app_label

APPS is a tuple/list of strings, then we convert it to an AppCollection automatically. I'm very willing to help implement this, as it's been on my to-do list (and the ticket is assigned to me). Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~--

Re: Django 1.0 features -- the definitive list

onths. I designed it to honor the routing_args specification (http://wsgi.org/wsgi/Specifications/routing_args) so that people could drop in Selector and Routes if they so desired. I should clean it up and post it to the list... Adrian -- Ad

Re: DB API - the limiting syntax, is it magic?

l objects in the table. * Do something special with the first one (once the whole list has been retrieved). The ideal API would look like this, and it would only run a single query: objects = MyModel.objects.filter(site=1) first_one

Re: Invalid forms and cleaned_data

useful, even. :-) Adrian -- Adrian Holovaty holovaty.com | djangoproject.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-develope

Re: DB API - the limiting syntax, is it magic?

n the API uses normal Python methods. It's this inconsistency that bothers me. I'm still +1 on fixing this wart, but it won't be the end of the world if nobody agrees with me. I just want folks to understand my reasoning. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --

Re: Django 1.0 features -- the definitive list

45 version", etc. A vehement "no, no, no." Nicknames like this are way too confusing, and they offer no value other than cutesiness. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ You received this message becaus

Re: DB API - the limiting syntax, is it magic?

ich we use a Python "magic-syntax-ism" (like operator overloading, for instance) in the framework, plus the fact that, what, *every* other piece of QuerySet functionality uses a method. It seems bolted on. I'd be +1 on adding a distinct limit() method, and keeping the legacy

Django Web site down for Media Temple scheduled maintenance

d hadn't really paid much attention to the message. :-/ To the sprinters in the Eastern Hemisphere for whom it's already mid-day Saturday, I'm not sure what to say -- there's nothing we can do, unfortunately. Adrian -- Adrian Holova

  1   2   3   4   5   6   7   8   9   >