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

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):

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 >

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 >

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 >

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,

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.

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,

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

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

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

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

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

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

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

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

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,

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

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.

Re: GitHub migration

On Fri, Apr 27, 2012 at 11:50 AM, Adrian Holovaty <adr...@holovaty.com> 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 don

GitHub migration done!

On Fri, Apr 27, 2012 at 11:50 AM, Adrian Holovaty <adr...@holovaty.com> 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

Re: GitHub migration done!

On Fri, Apr 27, 2012 at 10:08 PM, Adrian Holovaty <adr...@holovaty.com> 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 -

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.

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

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

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

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

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

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 =

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

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!

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 >

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

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"

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 =

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

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): >    

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

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

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

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 >

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

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

Re: Django 1.4 roadmap

On Tue, Nov 29, 2011 at 6:10 AM, Luke Plant <l.plant...@cantab.net> 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

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

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.

Django wiki changes

to get the code, how to contribute and what we're currently working on. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To

Re: Django with CherryPy 3.0

your problem? 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-devel

Re: Django wiki changes

to do this. Maybe a Trac expert will enlighten us... Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post t

Re: New branch: newforms-admin

about this: Suggest some concrete changes you'd like to make, and I'll try to avoid making those changes. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups &

Re: New branch: newforms-admin

that maintained this decoupling -- i.e., a ModelAdmin class doesn't know its model. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django dev

Re: Critical ticket: can cause data loss

plications of this patch mean it's not acceptable for this patch to > sit in the queue - it needs to be fast-tracked. Could somebody provide some unit tests that isolate the problem? I've never mucked with the GenericForeignKey code -- perhaps Jacob or Russell could chime in here for the fix?

Re: [triage] Howto emphasize a ticket

e of high-priority tickets is exactly what you did: send a message to this mailing list. The reason we'd rather not expose a "priority" field in our ticket system is that people abuse that, giving artificial priority to their own tickets, often anonymously. I've fixed #3336, by the

Re: Django with CherryPy 3.0

Ajax-induced stalling. What do you think? Anybody willing to update the patch and post it into our ticket system? Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Gro

Re: svn properties ?

rance, but what would this accomplish? 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 dj

Re: triage: one third done

, guys! 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-developers@googlegroup

Status update on newforms-admin branch

infastructure would let you create your own inline types by implementing an Inline subclass. What sort of hooks would an Inline class need? And are there any thoughts or other ideas/proposals while we're focusing on this? Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~

Re: SVN triggers to Trac

I have > closed. > > Is this a problem that others have seen? Is this a known change in > behaviour, or am I missing something obvious (or doing something very > stupid)? I've noticed that, too. I haven't had a chance to fix it, and I was hoping Jacob would take a look, as he was the Trac upgrad

Re: Not querying related record on form creation

choices. > > I better like first option. What do you think? The first option sounds better to me, too. Are you willing to code up a patch? Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ You received this message because

Re: # 2070 cleanup and review

oad.py > middleware.py > using-feedparser.diff > using-feedparser.2.diff > modpyton-ok-needs-fcgi-testing.diff > modpyton-ok-needs-fcgi-testing.2.diff > > Remove comments up to 01/25/07 OK, I've removed those attachments. I'd rather not remove comments, just for p

Re: Not querying related record on form creation

On 2/5/07, Ivan Sagalaev <[EMAIL PROTECTED]> wrote: > Adrian Holovaty wrote: > > The first option sounds better to me, too. Are you willing to code up a > > patch? > > Here it is: http://code.djangoproject.com/ticket/3436 Excellent. Thanks, Ivan! Adrian -- A

Re: [Changeset] r4473 - django/trunk/tests

uses the settings.py in an > almost entirely unmodified form Thanks for saving me the typing, Russ! :-) Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Gro

Re: [4394] broke QuerySet.iterator() interface

Thanks for the patch! 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 dja

Re: newforms admin: decouple TEMPLATE_STRING_IF_INVALID?

n would be to refactor the way TEMPLATE_STRING_IF_INVALID works, rather than special-case it for the admin site. (How to refactor it, exactly? I don't know -- it just feels hackish to me.) Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~-

Re: Amendment: Possible improvement to model API

ecify "WHERE" clauses. http://cheeseshop.python.org/pypi/Dejavu/1.5.0RC1 The nice thing about Django is that you can still use the framework (with a couple of limitations) using another model layer, such as Dejavu. Adrian -- Adrian

Re: unicode issues in multiple tickets (#952, #1356, #3370) and thread about Euro sign in django-users

framework to be Unicode-aware? I apologize in advance if you've already brought this up and explained it. Just trying to understand your thinking here. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ You received this message because

Re: Newforms styling suggestion

error > fields highlighted red, etc. Just a thought. Hey Brian, I think we might have discussed this before, but the discussion fizzled out. What would you want to style -- the form HTML tag itself? The ? The table row (in case of as_table())? Adrian -- Adrian Holovaty holovaty.com |

Re: reopened tickets should reset stage to unreviewed

ent. If anybody knows how to accomplish this in Trac, let us know. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post

Re: newforms.util.ValidationError has nothing in common with core.validators.ValidationError. Why?

django.core.validators is going away in the long term. Use django.newforms if you want your code to be forwards-compatible. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ You received this message because you are subscri

Re: max_length vs. maxlength

django-users/browse_thread/thread/a4e09b7b027b56bb/9aaeda1ea5bc87eb Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" g

Re: newforms.util.ValidationError has nothing in common with core.validators.ValidationError. Why?

ng as a perfectionist, chances are that it bothers me even more than it bothers you. :) Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django

Edit inline in newforms-admin branch (ATTN: Joseph Kocherans)

. Joseph, are you around, and what's the status? I can happily take over if you're not in a position to do the implementation. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ You received this message because you are subscribed

Re: [Changeset] r4828 - django/trunk/django/conf/locale/de/LC_MESSAGES

neglected to consider that policy. My mistake! Are there any arguments *for* breaking the policy and including the names? If not, let's roll it back. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ You received this message because yo

Re: {% url %} for generic views (proposal)

ings. We could likely keep it backwards compatible by changing the patterns() function to convert any plain tuple into an object of the type url() returns. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ You received this message becaus

Re: Tags cannot contain newlines

ing-list discussion of the aesthetics of newlines vs. no newlines. Please accept the fact that tags cannot contain newlines. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Goo

Re: {% lorem %} only half checked in

m going to move it into a new django.contrib package; the tag is nice, but it's not fundamentally necessary to the template system. -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google

Re: {% lorem %} only half checked in

bdesign package: http://www.djangoproject.com/documentation/webdesign/ This django.contrib package is for anything and everything that has a "Web design" focus. If you have ideas for other designer-friendly functionality in Django, please suggest them! Adrian -- Adrian Holovaty holovat

Re: Design decision on #3532 -- spaceless templatetag

tely fine with changing {% spaceless %} so that it removes *all* spaces rather than leaving one. Go for it! Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django

Re: Built-in form fields: how "valid" should they require data to be?

is U.S. state abbreviations. That validator checks not only that the abbreviation is two letters, but that it's one of the valid state/territory abbreviations. States/territories don't get added very often, so it's worth the extra level of validation in this case. How does that sound as a

Re: Built-in form fields: how "valid" should they require data to be?

> permanently invalid (there aren't many of these and they're easy to > test for). > > And leave it at that. Sound good to everyone? Sounds good. You've probably already thought of this, but it should accept numbers with or without hyphens, and normalize it to the number *with* hyphens. Adrian

Re: Built-in form fields: how "valid" should they require data to be?

of, well, great local flavor when I first created the package. :) Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To

Re: Local flavours content

have control over, and we end up making subframeworks that let people customize (see, for example, the User.get_profile() stuff). Nebojša, does that help? If you're still unsure, it might help if you gave more specifics on what sort of information/logic you wanted to include. Adrian -- Adrian Ho

Re: Are we dropping auto_now and auto_now_add for 1.0?

be accomplished with "default=datetime.datetime.now", and auto_now_add can be accomplished with a custom save() method. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to t

Re: newforms: better table markup

leave out). -1 on for the same reason. As for "headers," I'm +0. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" g

Re: Stability of LogEntry in django newforms?

so it's probably safest not to interface with it directly in your own code. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers"

Re: Stability of LogEntry in django newforms?

than django-developers. 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-devel

Re: add CACHE_KEY_PREFIX functionality

lobal CACHE_KEY_PREFIX setting, but we're always hesitant to add new settings. What if we removed the CACHE_MIDDLEWARE_KEY_PREFIX, in favor of a new CACHE_KEY_PREFIX setting? Is there a case where the two settings would need to differ? Adrian -- Adrian Holovaty ho

Re: #3075 - Ifequal tag extension to handle mask operators

On 4/5/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > Well, by law of order of operations, the and operator takes priority, > so that would be (a == x and b == y) or c == z. > > However, in the if tag, combination of 'and' and 'or' in the same tag > is not allowed, precisely because the

Re: syncdb and missing many-to-many tables

th Malcolm and Russell and say the best solution is probably to get schema evolution working. Maybe this is our chance to get some momentum behind that? Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ You received this message because

Re: newforms and unicode/bytestrings

ll it's working, I think. I'm 100% for that. Let's do it. If you think a branch would be better for this, we can make that happen, too. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ You received this message because you are s

Re: Edit inline in newforms-admin branch (ATTN: Joseph Kocherans)

.formsets module in the newforms-admin branch. How do you envision that interacting with edit_inline? Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups &quo

Re: [Changeset] r4941 - django/branches/newforms-admin/django/contrib/admin

the absolute-URL creation behind the scenes. It wouldn't be *too* horrible if we required HttpResponseRedirect to take an absolute URL, but I'm a big fan of allowing the relative URLs for convenience. Something interesting to think about, indeed! Adrian -- Adrian Holovaty holovaty.com | djang

Re: Edit inline in newforms-admin branch (ATTN: Joseph Kocherans)

ple of your models? I agree that a better error message would be a good thing, but I'd like to find the exact problem in your models (or bug in the newforms-admin branch) in order to figure out whether to display the message. Adrian -- Adrian Holovaty holov

Re: contrib proposal: django-values

for many people. Nice job, Gulopine! Next steps: Let's discuss these three points I've brought up, and let's play around with the code as it stands so far to see if any other design-level questions creep up. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~

Re: contrib proposal: django-values

, though, along the lines of "localflavor." We need a name that's descriptive but not too generic-sounding. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to t

Re: wrong names in variables. startapp rutine

> Please, see > http://code.djangoproject.com/ticket/3846 Thanks, Mario. I've checked in the patch. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "D

Re: Django is really starting to muddle MVC, and it has me concerned

related purposes. Hi jp, The options that apply to the admin interface have been factored out as options to the admin class. Here's more information: http://code.djangoproject.com/wiki/NewformsAdminBranch Adrian -- Adrian Holovaty holovaty

Re: Django is really starting to muddle MVC, and it has me concerned

arguments, those are still specified in Fields. In my view, those are a bona fide part of model logic -- they describe important metadata about database fields that isn't merely useful by the admin site. Hope this answers your question, Adrian -- A

Re: Oracle patch is ready

, since you've been dealing with query.py and other databasey parts of Django, do you want to take the lead on the merge? Or Jacob? I could get to it next week if you guys are busy. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ You re

  1   2   3   4   5   6   7   >