Re: On returning appropriate subclass instances when querying a model with subclasses
On Sun, Aug 23, 2009 at 1:54 PM, Andrea Zilio wrote: > > So seems that this idea was in fact rejected because of the O(# of > nodes in the inheritance tree) joins > needed to get all the fields from subclass tables. > You may want to loook at Alex's post on the subject: http://lazypython.blogspot.com/2009/02/second-look-at-inheritance-and.htmlfor a solution to apply on your own projects. Note that his code was written before Malcolm wrote proxy classes, Alex's code could now be improved to not query the subclasses but return proxy classes to them effectively avoiding the O(#..) queries untill you try to access subclass data ;) Regards, Marc --~--~-~--~~~---~--~~ 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 group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
About an UPDATE.txt file
Hi there, Right now Backwards Incompatible changes are documented in a wiki page, with some disadvantages: * There's a reference in documentation to the wiki (install.txt:182) * When commiting those changes the wiki has to be updated by hand. * Some people expect either a Changelog or UPDATE file to live in the source tree of a project, it's a common practice. * Packagers would have to either refer to it, or copy the page to a doc folder. Including an UPDATE.txt file (either in the root folder or in docs/) could provide some advantages: * Patches could provide the necesary notes to this file if needed so the commiter would not need to edit the wiki. * The file can be included in releases so everybody gets it * It's really easy to find such file, specially in the root folder * The documentation could, simply, include this file I think that the nicest advantage is the first one, as patches do already have to provide documentation it's not that hard to document if a patch is supposed to break something, and that could take out some work load from commiters. If you like the idea I volunteer to compile an initial UPDATE.txt and a diff for contributing.txt pointing about that (and filling a ticket!) Awaitting your comments, Marc PS: Anybody knows if malcolm is ok? (just worried, offline for one-two months). -- http://www.marcfargas.com -- will be finished some day. signature.asc Description: Esta parte del mensaje está firmada digitalmente
Re: About an UPDATE.txt file
El sáb, 07-06-2008 a las 17:54 -0700, [EMAIL PROTECTED] escribió: > I'd be +1 on this, the only downside is that whoever commits the patch > will need to insert the correct revision at commit time. You can't do so unless you do svn info, svn commit both very fast. That would go on a new section of my firs mail called "disadvantages of doing so", didn't think about that :) > PS: http://www.pointy-stick.com/blog/2008/05/21/not-here-right-now/ Fine, me or Google Reader missed that one (and I double checked before asking!) thanks for the pointer ;)) Thanks, Marc -- http://www.marcfargas.com -- will be finished some day. signature.asc Description: Esta parte del mensaje está firmada digitalmente
Re: About an UPDATE.txt file
El sáb, 07-06-2008 a las 19:53 -0500, James Bennett escribió: > On Sat, Jun 7, 2008 at 7:46 PM, Marc Fargas <[EMAIL PROTECTED]> wrote: > > Right now Backwards Incompatible changes are documented in a wiki page, > > with some disadvantages: > > And in the release notes when a new release happens. Yes, notes that are not: * In the tarball * Linked from the Downloads page * Linked from the install doc (the onlyone referenced from the Download page) In brief, Release Notes (as far as I know) are only published in the blog when the release is made, and are not linked from anywhere. And yes, the Release Notes inside the tarball would do the job, but commiters still need to keep the wiki up-to-date by hand. I was thinking in an UPDATE.txt like the UPGRADE.txt from Asterisk[1] or the CHANGES file [2] Those are meant to serve as Release Notes for the most part (so i.e. You would write the introduction of the Release Notes on the blog, then copy the relevant part of UPDATE.txt and you're done). Ok, less work for you then! :) Regards, Marc [1]: http://svn.digium.com/view/asterisk/trunk/UPGRADE.txt?revision=120567&view=markup [2]: http://svn.digium.com/view/asterisk/trunk/CHANGES?revision=121042&view=markup > > -- http://www.marcfargas.com -- will be finished some day. signature.asc Description: Esta parte del mensaje está firmada digitalmente
get_{next,previous}_by_someDateField()
Hi, There are two things about get_NEXT/PREVIOUS_by_DATEFIELD() which I'm not sure if a bug should be filled agains (almost sure anyway). given a simple model like: class TestModel(models.Model): date = models.DateTimeField(auto_now_add=True) m = TestModel() m.get_previous_by_date() Will fail with an exception which says "Cannot use None as a query", maybe that error could be a bit more self-explicative, like "Cannot query next/previous items without being saved". Which brings up the other issue, when previous/next is called the resulting query that Django will use includes two filters: WHERE (date < self.date) OR (date < self.date AND id < self.id). I don't get the reason for the second filter, but this makes next/prev unusable with unsaved objects. Is this second filter really required? Or could it be either: * Removed * Added only when the object has an id In any case, the error when using both function on unsaved objects could be a bit more explicative. I'll fill tickets and provide patches according to your comments, so please, comment :) Thanks, Marc -- http://www.marcfargas.com -- will be finished some day. signature.asc Description: Esta parte del mensaje está firmada digitalmente
Re: get_{next,previous}_by_someDateField()
El mar, 10-06-2008 a las 09:54 -0400, Karen Tracey escribió: > I agree the error message could be better. > Thanks for the elaborate and concise answer, I'll work on a nicer error message then ;) Should the error raise a ProgrammingError or ValueError ? -- http://www.marcfargas.com -- will be finished some day. signature.asc Description: Esta parte del mensaje está firmada digitalmente
Claiming tickets (was: Django development staleness)
El mié, 11-06-2008 a las 08:45 +0800, Russell Keith-Magee escribió: > Trac contains all the information you need. If a ticket is open and > it's not assigned to somebody, then it's a safe bet that nobody is > looking at it. If it _is_ assigned to somebody, but there hasn't been > any activity (comments/patch uploads etc) recently, it's also a safe > bet that nobody is working on it. I would not be that sure on the last sentence, there are tickets that have no activity for a while (i.e. the ones I own can be 5 months staled) but they're not really abandoned, they're just waiting to move from a state to the other and while the patches do not conflict with trunk there are no changes. To cite an example, I updated #3148 two weeks ago after 6 months only to update the patch. For that, contributing.txt has a section title "Claiming tickets". Maybe it can be improved adding something like pinging the assignee (that is now left to core developers). Maybe when #6320 gets in. Something like changing: Core Django developers go through the list of claimed tickets from time to time, checking whether any progress has been made. If there’s no sign of progress on a particular claimed ticket for a week or two after it’s been claimed, we will unclaim it for you so that it’s no longer monopolized and somebody else can claim it. To something like: If a claimed ticket seems to be abandoned you can ping the developer, with a comment on the ticket, to see if he/she is still taking care of the ticket or not. Leave some time, like 1 or 2 weeks for the developer to respond and if you have no answer or the developer says he/she is no longer interested in the ticket either claim it, or unassign the ticket. The only issue here is that only core developers can unassign tickets, but atleast the pinging step can be performed by other people, thus taking off some load from the core developers. I'll wait for your opinions on that. Cheers, Marc -- http://www.marcfargas.com -- will be finished some day. signature.asc Description: Esta parte del mensaje está firmada digitalmente
Triaging: Google's AppEngine support policy
Hi there, I'm trying to clean the Unreviewed tickets list a bit (from 108 to 73 right now) and I'm now at #7008. #7008 is about "Session backend for Google's App Engine" and before moving it to Accepted, Design Decission or wontfix I thought it was worth bringing this here. Althought, right now, there don't seem to be more tickets about GAE it's possible that tickets start appearing asking for different things from GAE namely a database backend. So, the question is, will Django (post-1.0) want to include this things: * in core * in contrib.gae (or something like that) * no And, if "no" then, should #7008 go away, or can it be accepted? Regards, Marc -- http://www.marcfargas.com -- will be finished some day. signature.asc Description: Esta parte del mensaje está firmada digitalmente
Re: RFC: Django 1.0 roadmap and timeline
Hi there, El mié, 11-06-2008 a las 21:03 -0500, Jacob Kaplan-Moss escribió: > * Two beta releases. > > All "maybe" features must be completed by the first beta; after that, > Django will enter feature freeze for about a month while we kill bugs. > > * At least one -- and hopefully only one --release candidate. The candidate > release will mark a total freeze (as well as a string freeze for > translators); only outright bug fixes will be accepted past this point. Disclaimer: I don't want to say anything bad about the triaging process neither stale tickets. I'm trying to bringup an issue that could either screw the Schedule or leave us with rc tickets after release. So, please, do not interpret this as a critic. On my today's triaging session (64 unreviewed left now) I spotted a few bugs in Unreviewed of those kind that should be fixed before 1.0, first examples: * #6710, sslmod ignored in psycopg2 * #6997, Paginator fails with one element * #7064, Decimal validator fails when both params are equal. * #6948, join filter, string literal escaped (it should not). * #6928, commit_on_succes + KeyboardInterrupt hide exceptions. Those five have been in Unreviewed for between 2 and 3 months and, I believe, are those kind of bugs that we'd like to fix before 1.0 Now, the thing is that we all know that core developers can't take a look at the patches currently open to pick those that should be fixed before 1.0 and there's no way right now that triagers can pick those for them (except compilling a list and mailling it). But the issue is not with the tickets, it's on the fact that bugs filled againts the beta/rc releases and that should be fixed could stay in the limbo too long, and that what can screw the Schedule. If core developers miss a ticket that has to be pre-1.0 it will be missed. The point is, as triagers are supposed to have good criteria on that, to enable the "Milestones" again and restrict the Milestone field to be only settable by Triagers? I think somebody asked for the milestones in these thread, I'm just telling one reason to have it. Regards, Marc PS: Note: telenieko in TRAC is me (Regarding [7632]) -- http://www.marcfargas.com -- will be finished some day. signature.asc Description: Esta parte del mensaje está firmada digitalmente
Re: RFC: Django 1.0 roadmap and timeline
El sáb, 14-06-2008 a las 13:28 -0700, Charlie escribió: > I'm curious if there are any plans to support simple urls for "RESTful > resources" in Django, especially before the 1.0 release. It's not on the roadmap to 1.0 so it won't be there, there's a project around that see this list archives on this same week. -- http://www.marcfargas.com -- will be finished some day. signature.asc Description: Esta parte del mensaje está firmada digitalmente
Re: RFC: Django 1.0 roadmap and timeline
El dom, 15-06-2008 a las 14:11 +0800, Russell Keith-Magee escribió: > Based purely upon the ticket titles, they certainly sound like good > candidates. Thanks, my criteria is now completely flawed! ;) > You have been doing a lot of good triage work over the last few days Thanks again :) > have you got a list of the tickets that _you_ think are 'must have' > for v1.0? No, but I can do it while triaging and sent it to you. But then I'll move to the full ticket list, not only Unreviewed ;) > Adding a 'bug' or 'feature' as a keyword on the tickets is one way to track > this. I thought about that, but the same that happened with priorities could happen there, that is: People could add those keywords trying to give visibility to their tickets. That's what I asked for a field only seteable by triagers ;) Regards, Marc -- http://www.marcfargas.com -- will be finished some day. signature.asc Description: Esta parte del mensaje está firmada digitalmente
Translation tickets
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 tickets are there hoping to get into at some point in time. Then, I don't know how Jacob set the locale/ permissions, but if they are set permissive enought I'd like to volunteer to take care of Translation tickets of non-delegated translations. If you don't mind. Regards, Marc -- http://www.marcfargas.com -- will be finished some day. signature.asc Description: Esta parte del mensaje está firmada digitalmente
Re: Translation tickets
El dom, 15-06-2008 a las 22:54 +0200, Ludvig Ericson escribió: > Well, the thing is, we really want two eyes on tickets regarding > translations. It doesn't have to be a maintainer, but anyone who can > assure that some translations don't say "Cancerface" in the target > language. So, I guess if you can find people to double-check the > translations, commit it. 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 characters on Google to check phrases :) But the main question is how permissive are the permissions Jacob gave to translators. If they're enough permissive then the question is if I can commit those. If there are no volunteers to double check I'll check random phrases with google (when possible). > Also, recurring translators that aren't maintainers could be trusted I > guess. Very recurring translators commit directly (like es,ca), others attach patches to trac and get then commited by Malcolm. Those are the ones that are now getting stalled. I'll post to django-users asking for double checks, let's see how that works ;) -- http://www.marcfargas.com -- will be finished some day. signature.asc Description: Esta parte del mensaje está firmada digitalmente
Re: RFC: Django 1.0 roadmap and timeline
El lun, 16-06-2008 a las 11:28 +0800, Russell Keith-Magee escribió: > A bug/feature keyword won't > give you anywhere as much attention, but it will help us filter out > features from the list of work we need to focus on. I took the other way around, I'm adding the keyword "post10" for tickets that can wait until 1.0 so a negative filter would give you "pre10" and "yet-to-be-marked-tickets". Hope that makes life a bit easier (but I've only marked about 5 tickets). Regards, Marc -- http://www.marcfargas.com -- will be finished some day. signature.asc Description: Esta parte del mensaje está firmada digitalmente
Re: RFC: Django 1.0 roadmap and timeline
El lun, 16-06-2008 a las 10:00 -0700, [EMAIL PROTECTED] escribió: > I really like the roadmap, but I'm wondering where the docs- > refactoring work comes in? It in "Maybe" features, second from the bottom on http://code.djangoproject.com/wiki/VersionOneFeatures -- http://www.marcfargas.com -- will be finished some day. signature.asc Description: Esta parte del mensaje está firmada digitalmente
Re: Support for ON DELETE and ON UPDATE in foreign keys
El jue, 19-06-2008 a las 11:00 -0400, Michael Glassford escribió: > * If settings.DATABASE_HANDLES_ON_DELETE=True, the SQL that is generated > by manage.py contains ON DELETE clauses where on_delete= is > specified. > > * If settings.DATABASE_HANDLES_ON_UPDATE=True, the SQL that is generated > by manage.py contains ON UPDATE clauses where on_update= is > specified. That information should be provided by the backend, not in the settings file (which are supposed to be backend independent). signature.asc Description: Esta parte del mensaje está firmada digitalmente
Re: Experimental Git repository available
El jue, 19-06-2008 a las 14:03 -0700, Michael Elsdörfer escribió: > FWIW (I'm currently playing around with all three of them), bazaar > appears to support pushing into svn as well. Yes, with bzr-svn. Didn't play too much with that one. But Bazaar is slow, *really* slow. -- http://www.marcfargas.com -- will be finished some day. signature.asc Description: Esta parte del mensaje está firmada digitalmente
Re: Experimental Git repository available
El jue, 19-06-2008 a las 17:14 -0500, Jeremy Dunck escribió: > git-svn init -s http://code.djangoproject.com/svn/ git-svn init -s http://code.djangoproject.com/svn/django Unless you want djangoproject.com also ;) signature.asc Description: Esta parte del mensaje está firmada digitalmente
DDN: Contrib apps testing their own views (#7521)
Hi all, You may have noticed that [7716] raised a few bugs around (#7514, #7517 and #7521) the nice one is #7521, which is now marked DDN. The issue raised by this ticket is that "mange.py test" would fail to run tests when you had contrib.auth in your INSTALLED_APPS. That is because [7716] introduced and urls.py for testing contrib.auth views. And there's no guarantee that the user's project will have those urls included, which would lead to failed tests. That means, that right now, contrib apps cannot test their views because they could lead to failed tests on projects. (i.e. [7716] was reverted in [7726] to avoid upsetting users). But oviously, contrib apps should (to not say must) test their views to be sure that code released works! Hence, there should be a way for contrib apps to have an urls.py and test it. I can think of two options right now: * manage.py test should not run django.contrib.* tests, those are supposed to have been run in runtests.py and working fine (that's the point of being a contrib app: django developers take care of it!). * mange.py test should make sure that django.contrib.*.urls are included and disable tests that would fail, or include such urls. I'd really be +1 on the first options, there's no point on testing contrib apps in the user's project (for the same reason we do not run the whole testsuite from the users project). Side note, any NFA developer: when you merge from trunk please clean django/contrib/auth/tests/forms.py#L23 as #7514 fixed this on trunk. -- http://www.marcfargas.com -- will be finished some day. signature.asc Description: Esta parte del mensaje está firmada digitalmente
Re: Spam detection
El jue, 26-06-2008 a las 13:31 -0700, Jacob Kaplan-Moss escribió: > Help me out here: how can I make it more obvious? You missed that; > others often do to. Can you share with me some insights on how you > missed it? The sentence should be more prominent, I know nobody that will read that many lines, so maybe bolding "spam" and "register for an account" would make those a bit more visible. Next step would be on the reject message "PLEASE, PLEASE *REGISTER* FOR AN ACCOUNT TO AVOID BEING REJECTED BY *SPAM* FILTER". Not sure avoid the caps... Maybe point 1 is enough. Regards, Marc -- http://www.marcfargas.com -- will be finished some day. signature.asc Description: Esta parte del mensaje está firmada digitalmente
Re: DDN: Contrib apps testing their own views (#7521)
El jue, 26-06-2008 a las 06:58 +0800, Russell Keith-Magee escribió: > >> My preferred solution here would be to provide a way for test cases to > >> substitute a top level URL pattern object for the duration of the > >> test. For example: > > A patch in these lines is now attached to #7521, the patch right now: * Adds the "urls" parameter, and a new method to TestCase called "_post_teardown", it's called at the end of __call__. * Adds a "clear_url_cache()" method to django.core.urlresolvers (To clear the resolver cache when swapping urlconfs) * Adds two TestCases to check the "urls" parameter, they must be run in order... * modifies fomtools.tests to use the urls paremeter instead of it's own hack (which should be broken somehow for the cache thing). * docs!!! The only thing not added to the patch is reverting [7726], it's on my git branch thought, http://www.marcfargas.com/gitweb/?p=django.git;a=shortlog;h=trac/7521-test-urlconfs Hope this patch is ok! Marc -- http://www.marcfargas.com -- will be finished some day. signature.asc Description: Esta parte del mensaje está firmada digitalmente
Re: Clarification on what is getting into v1 & Ticket 3148
El mar, 08-07-2008 a las 01:24 -0700, [EMAIL PROTECTED] escribió: > So our team is very fond of Ticket 3148 "Add getters and setters to > model fields" which is in the "ready for checkin" stage. Does that > mean it will be merged to the trunk soon (and thus become part of v1 > release)? Not exactly, "Ready for checkin" means that the ticket has everything it needs to be checked in. But does not say in what time. As it does not do something fancy it can get in either before v1 or later, it depends on if somebody has time to commit it. > If not, what is the designation for tickets that will be part of v1? Look here: http://code.djangoproject.com/wiki/VersionOneFeatures Those are the ones that *must* or *may* be for 1.0 Regards, Marc -- http://www.marcfargas.com -- will be finished some day. signature.asc Description: Esta parte del mensaje está firmada digitalmente
Re: Clarification on what is getting into v1 & Ticket 3148
El mar, 08-07-2008 a las 19:34 +1000, Malcolm Tredinnick escribió: > I'll also note that that ticket has sort of weaved it's way up to "ready > for checkin" without too much participation from core developers and > it's a bit of a change. Dunno who the anonymous user was, not me ;) I didn't move it back to accepted as all concerns raised for the ticket were solved (including you comment #13). > Since Adrian seems to be the one most interested in it, it's likely to be > him who will eventually address it, but whoever does it eventually, I'm not sure on that point, that interest was showed 1 year and a half ago (comment #1) and was more like a design decission. The last core dev to show up was.. you! ;) > I wouldn't be too surprised to see it bounced back for better design or > technical reasons (just playing the odds -- I haven't > read the ticket after a very early patch some time back). I assume the patch you talk about is the one you commented, the parameter name was changed accordingly. Also Adrian's comment about doing it a bit more pythonic was also addressed. The patch is there, waitting for comments, please raise any technical/design concerns you have so I can address them. Regards, Marc PS: I also don't expect that one to get in for 1.0, I keep it near #689 and #6735 ;) PS: Thanks for the comments on the ticket¡! -- http://www.marcfargas.com -- will be finished some day. signature.asc Description: Esta parte del mensaje está firmada digitalmente
Re: Call for testing: new docs
Hi, On Wed, Aug 20, 2008 at 12:01 AM, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > The docs refactor work is pretty much done; now I need a bunch more > eyes to look things over. There's still a bunch of TODOs (see below), > but it's better than the current docs and maintaining branched docs is > a major pain, so I plan to have this merged into trunk this week. Very Very Very good news! ;) > The best way to send me code is by letting me know about your remote > git repo. I'll try to give some love to it on my spare time, You can fetch some link corrections from my git branch already: http://www.marcfargas.com/gitweb/?p=django.git;a=shortlog;h=docs-refactor http://www.marcfargas.com/git/django.git/ -- http://www.marcfargas.com - will be finished someday. --~--~-~--~~~---~--~~ 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 group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Search facility for new documentation
Hi, The changes to the versionadded and versionchanged tags are done on my git branch. So, when jacob merges them they'll be changed. Regards, Marc On 8/31/08, Ramiro Morales <[EMAIL PROTECTED]> wrote: > > On Sat, Aug 30, 2008 at 6:52 PM, julianb <[EMAIL PROTECTED]> wrote: > >> On this occasion, why not change "New in Django development version" >> remarks to "New in this version"? That makes much more sense, since >> the docs get frozen for each version, so you know now and later this >> was new in dev/1.0/1.1... > > From what i?ve heard I'd say facilities offered by Sphinx > (see http://sphinx.pocoo.org/markup/para.html#dir-versionadded) > are going to be used for this. > > Regards, > -- > Ramiro Morales > > > > -- -- http://www.marcfargas.com - will be finished someday. --~--~-~--~~~---~--~~ 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 group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: djangoproject.com/documentation/ redirected
On Wed, Sep 10, 2008 at 6:43 AM, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > Just a quick note: I've redirected > http://www.djangoproject.com/documentation/ and everything below that > URL tree to the new docs subdomain, http://docs.djangoproject.com/. Nice! Now the only thing left is to have 1.0 docs (aka: docs.djangoproject.com/en/1.0/) and make docs.djangoproject.com redirect there instead of /en/dev/ ;)) ( #8992 ) Regards, Marc -- http://www.marcfargas.com - will be finished someday. --~--~-~--~~~---~--~~ 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 group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: djangoproject.com/documentation/ redirected
On Wed, Sep 10, 2008 at 11:46 AM, James Bennett <[EMAIL PROTECTED]> wrote: > > On Wed, Sep 10, 2008 at 2:52 AM, Marc Fargas <[EMAIL PROTECTED]> wrote: > > Nice! Now the only thing left is to have 1.0 docs (aka: > > docs.djangoproject.com/en/1.0/) > > and make docs.djangoproject.com redirect there instead of /en/dev/ ;)) ( > > #8992 ) > > Yes, and that's holding a bit until we get a few typo fixes and other > things in; then the 1.0 docs will be tagged and frozen. Is it ok to do so without a point release? That way the documentation being distributed in the tarball (and by distribution packagers) would be the same as the on shown in the website as 1.0 ;\ If you're doing so, I rewrote a part of custom-template-tags that got strange with the ..versionchanged:: thing, http://tinyurl.com/docs-1-0-fixes ;) Regards, Marc -- http://www.marcfargas.com - will be finished someday. --~--~-~--~~~---~--~~ 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 group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: I want a pony: Distributed RCS
On Thu, Sep 11, 2008 at 12:25 AM, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > On Wed, Sep 10, 2008 at 3:15 PM, Jeff Anderson <[EMAIL PROTECTED]> wrote: > I know Gary uses Bazaar, and > I wouldn't be surprised to find that one of the other core devs uses > something really exotic like Darcs. Uhh, don't forget the mercurial users out there! I think there's even somebody with SVK around. > 2. SVN, however, is a sort of lowest common denominator of open source > development; we can expect our users and developers to know and > understand it. [...] but it's [git] about as simple to use as a 747. I'd > rather > spend my time helping contributors figure out Django than helping them > figure out DVCS. Agreed, the most you have to explain right now is how to run "svn diff", i.e saying: "Run git diff from the branch you created to the branch you have the upstream repo in" raises the barrier to contribute. But I wouldn't compare it to a 747; Maybe crossing the Ocean without compass neither GPS ;) > -- I've been quite happy with the handful of developers whose git > branches I'm tracking. "quite" means you don't like commits like "Ups forgot that", "Argh, missed that one" in remote branches? They're meaningfull! :) -- http://www.marcfargas.com - will be finished someday. --~--~-~--~~~---~--~~ 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 group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: I want a pony: Django Cheeseshop
Hi,
On Wed, Sep 10, 2008 at 4:31 PM, mrts <[EMAIL PROTECTED]> wrote:
> Apps
> ---
> * extend them with Django-specific functionality to
> o lessen magic: explicitly specify files containing models,
> templates and admin bits, i.e. obsolete all forms of autodiscovery and
> path hacking
> o find a way to expose media
> o handle all issues outlined in #3591
>
I'd say that having CheeShop the only really important thing (my POV)
would be giving developers a few pointers on how to make their apps
more decoupled, i.e:
* Your app templates should all {% extends %} a base.html which is
the "standard" name of the base template.
* Your should work on the content, content-related, and
content-extra blocks to provide content in your example/live templates
* Your URL's should always use named urls (atleast on those meant
to be used by users).
etc. In brief, that kind of things that make an app "plug&play" or
"jumper-based" :)
Now blame me if such document already exists (in docs/), and such
document doesn't need to wait for 2.0 ;)
Regards,
Marc
--
http://www.marcfargas.com - will be finished someday.
--~--~-~--~~~---~--~~
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 group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Need a programmer immediately
On Sun, Sep 28, 2008 at 6:04 PM, KnoxvilleDjangoDev <[EMAIL PROTECTED]> wrote: > > Apologies if I am not asking this question correctly You'd better post to Django-Users (http://groups.google.com/group/django-users ) this group is intended for people developing *Django* that is: The framework itself, it's internals. People building sites *on top of* Django, which is what you may be lookin for, are on the Django-Users groups. Regards, Marc -- http://www.marcfargas.com - will be finished someday. --~--~-~--~~~---~--~~ 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 group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: #689 Honour Webserver Provided Auth (REMOTE_USER)
Hi, On Wed, Oct 1, 2008 at 12:57 PM, Thomas Guettler <[EMAIL PROTECTED]> wrote: > #689 Honour Webserver Provided Auth (REMOTE_USER) > http://code.djangoproject.com/ticket/689 > Why not commit it? It's submited as candidate for 1.1, hopefully it can get it ;) Altough that means I would not longer own the 14th oldest ticket in Django! > PS: The current code is in a git repository linked in the ticket. Yeah mine, hope nobody minds I do not attach updated patches, it's just too time consuming ;) By the way, thanks for testing the code ;) Regards, Marc -- http://www.marcfargas.com - will be finished someday. --~--~-~--~~~---~--~~ 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 group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Branches "trimming" and structure
Hi ppl,
In the contributing docs we can read:
After a branch has been merged, it should be considered "dead";
write access to
it will be disabled, and old branches will be periodically "trimmed."
My English is not very good but I always understood that as "we'll
remove them when they get useless or there are lots of branches in
there", am I wrong?
Please Please Please run lots of "svn rm http"!!
Also, now we have branches/releases/, after clean-up, could we also
have branches/in-progress/ and branches/{dead,done} ? that would leave
things much clearer (and it wouldn't mess up git-svn :P)
Just an idea ;)
Regards,
Marc
--
http://www.marcfargas.com - will be finished someday.
--~--~-~--~~~---~--~~
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 group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
"things are ready" signal?
Hi there, Staring at #8638 I'm trying to find a way to hook code to be run "just after Django is completelly loaded" and found no way ;( The thing is, it's a really nice place to emit a signal if you want to do things "just after things are ready", but there's no signal for it. And, as I found nowhere to hook the code for #8638 I have no idea of where such signal should be emitted from (or that code hooked). So, would a signal there be useful? (no ticket filled yet) And, where can one hook code for that? :) Regards, Marc -- http://www.marcfargas.com - will be finished someday. --~--~-~--~~~---~--~~ 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 group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: "things are ready" signal?
Hi, On Thu, Oct 2, 2008 at 8:55 AM, James Bennett <[EMAIL PROTECTED]> wrote: > Just after *what* is ready, precisely? After "import django" has > succeeded? After settings have been imported? After model caches have > been initialized? After a request handler has been instantiated (which > we already sort of have a signal for)? Or "Just before request handler or manage.py command handling" takes place. "Ready" would mean "When django is imported, settings are ready, model classes are ready". > As it is, you have a signal which fires when we start processing an > HTTP request, and that's what most people should look to since Django > is, fundamentally, about cycles of HTTP request/HTTP response and so > that's the most useful mindset to have. Sure, but if you want to run a code that affects all requests (i.e. "Replace the SMTP Connection class for all requests") you can't be doing that *on every request*, the place to do so would be "just before starting serving requests". > Failing that, there are plenty of well-established Python idioms for > "run this code once and only once the first time I'm imported", which > covers the remainder of the use cases (or really stubborn people who > want to act like Django is a desktop application instead of a web > framework). In the case of the ticket I mentioned it's not that easy, as you won't import anything, you have a setting "DISABLE_EMAIL" which has to do what the testsuite does now: Replace SMTP Connection class. So you need to check this setting *after settings have been loaded*. The only signal you can hook "after settings are loaded" are all fired more than once (class_prepared, request_started, etc). There's no signal that gets fired *once*. So, if you need to hook something that need to run *once* after django loads (at any level) you need to either monkey-patch or patch Django itself. I would say to put a signal on every stage of the load process but one just after settings are ready and one just before starting to serve requests or handling manage.py commands would be a nice one. -- http://www.marcfargas.com - will be finished someday. --~--~-~--~~~---~--~~ 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 group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: "New in development version" equivalent in current docs?
Hi there, On Tue, Oct 7, 2008 at 1:17 PM, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > You can't put anything with spaces in there. It feels a little > inconsistent to put 1.1 in there, since we generally hold off talking > about version numbers from the future so that bug reporters are forced > to use accurate version numbers. > > I'd probably say that we bite the bullet and use 1.1 except then we > should do what one of the Spanish Marc's has suggested in a ticket > somewhere (could I be any less specific on the details, do you think?) > and make the main documentation link point to the 1.0 docs and put a > "development docs this way" sign up somewhere. That's me! There are two consecutive tickets that talk about version[added|changed]. You may be talking about #8992 and there's also #8991 (about when to remove those strings :P) >From my POV, when you commit something to trunk you know it's going to be in the next X.Y release, so it's safe to put the X.Y version "to-be-released-next". I don't really think people need to know in which exact moment of the development process the feature went in (if you are tracking trunk, you *track* it). *Maybe* we could instruct Sphinx in ways to change the X.Y thing "automagically" to "Development Version" when X.Y refers to the yet-to-be-released version. But writting there anything that is not the X.Y of the next version means more work *before release* (change whatever was there to the corresponding X.Y). Just my 0.02, Marc --~--~-~--~~~---~--~~ 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 group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Branches on Github
Hi,
On Fri, Nov 14, 2008 at 6:37 AM, David Cramer <[EMAIL PROTECTED]> wrote:
>
> Not the *best* place to post this, but it does relate to Django dev.
>
> Is it possible, and if so how, could one branch the Django trunk, and
> throw it on Github?
You should really have your own branch made up of SVN, using git-svn
as Malcolm mentioned. Before you get mad trying to get git-svn to
understang tags/ and branches/ you can use this as a guide:
git svn init --prefix svn/
http://code.djangoproject.com/svn/django -T trunk -b branches -t
'tags/*/*'
git svn fetch -r 1:9093
git config svn-remote.svn.branches
git config svn-remote.svn.branches
'django/branches/features/*:refs/remotes/svn/features/*'
git config --add svn-remote.svn.branches
'django/branches/releases/*:refs/remotes/svn/releases/*'
git svn fetch
Note: I just copied this from a blog post I have in the making and my
.zsh_history file, so it may not completely work
See that you first fetch up to r9093 and then mangle the branches
configuration and continue mangling, that's because the
branches/{releases,features} structure was introduced in r9094 and
git-svn will get really mad unless you tell it about the change.
You could optionally drop old history by not fetching all the history
(i.e: change the "1" by a 9090, 9000, etc).
Once you've initialized your repository you can use git-svn normally
(i.e: git svn fetch, git svn rebase) if you play with lots of branches
you can use my super git merger script:
http://www.djangosnippets.org/snippets/1166/
Hope this helps,
Marc
PS: Anyone already using git-svn with django and having it confused
may want to edit .git/svn/.metadata, put 9093 in branches-maxRev, git
branch -rd svn/branches/releases && git branch -rd
svn/branches/features and then git svn fetch. That should do the job.
(git gc could be a good idea also).
--
http://www.marcfargas.com - will be finished someday.
--~--~-~--~~~---~--~~
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 group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: One suggest for a new Lorem Ipsum
On Wed, Nov 26, 2008 at 1:29 AM, Diego Andrés Sanabria Martin (diegueus9) <[EMAIL PROTECTED]> wrote: > Hi, > > In Django in somwhere is a tag Lorem Ipsum, i suggest to use Lorem Ipsum 2 > > http://lorem2.com/ I do not get the point, and by your message I'd say you've not used the lorem tag at all. Django has a tag that generates some random text "similar" to the one in "de Finibus Bonorum et Malorum" (where the "Lorem Ipsum..." text (may) comes from, and does so without any external dependency. From your message I can only understand that you'd like the tag to take the text from lorem2.com? Why would anybody do so? That would need everybody to be online to use the lorem tag, and could mean a foreign web request on every page view... The webdesign contrib is there to provide some "randomness" to help you design your pages, it's not intended to print real passages. And if you want an "online" Lorem generator you'd better use www.lipsum.com which allows you to select what randomness you'd like to get. And explains a bit of the history behind "Lorem Ipsum". Anyway, on future messages, please try to elaborate them a bit more than 15 words, and don't forget to look at the current code, ie: "in somewhere is a tag" doesn't seem like you did much research before posting ;)) Regards, Marc -- http://www.marcfargas.com - will be finished someday. --~--~-~--~~~---~--~~ 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 group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: One suggest for a new Lorem Ipsum
On Wed, Nov 26, 2008 at 10:05 PM, Diego Andrés Sanabria Martin
(diegueus9) <[EMAIL PROTECTED]> wrote:
> My point is to use the text of lorem2.com for the current lorem ipsum
> tag, this text is more effective for test the divs.
Unless you speak Latin, it's unlikely noone will notice the difference
between randomly mixed latin words and words placed in the correct
order.
> I suggest to replace this text with the options of lorem2.com offline
> or more options for the tag lorem, somthing like
> {% lorem short-para %}
> {% lorem long-para %}
Short and Long are very unprecise things, 10 words? 20? 50? You can
now {% lorem 250 w %} to have a paragraph of some custom length
(it's up to you if this is short or long) and {% lorem 1 p %} to let
django decide about the paragraph length.
> {% lorem short-list %}
> {% lorem long-list %}
That's too "generic", would it be an Ordered or Unordered list? I'd
like to apply custom classes to the tags, ...
> Using the text of this website.
Althought we could say the text there is just as random as ours, we do
not know for sure; And unless it's an exact copy of the original Lorem
Ipsum text there maybe a copyright holder behind the text on the
website ;)
> Sorry again, my english is bad.
No problem ;)
Now, seriously, the django.contrib.webdesign tags are there to help in
getting random stuff in templates to help people during the design of
their webpages, so you want *text*, only text. The tagging to put
around the text is up to your. The exception being the paragraphs, as
it's common to have a bunch of paragraphs toghether.
I still really see no benefit in using the text you say or any other
"more perfect lipsum generator". My latin knowledge is limited enought
to not spot the difference ;) I'd even agree to print random English
words, but it won't show up as nice ;)
Regards,
Marc
--
http://www.marcfargas.com - will be finished someday.
--~--~-~--~~~---~--~~
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 group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: one view from multiple models
On Wed, Nov 26, 2008 at 9:03 PM, xshen <[EMAIL PROTECTED]> wrote: > > is there anyone know how to create one view from multiple models? any > input is appreciated You may want to ask in http://groups.google.com/group/django-users This groups is intended for the development of Django itself, not for developing "on-top" of Django, the Django-Users groups is the right place for that. (i.e: Django Users are those who develop sites on top of the framework). Anyway your question lacks a lot of detail, I guess you mean on howto apply a Generic View to multiple Models... Try to explain your use case with a bit more detail on django-users. Thanks, Marc -- http://www.marcfargas.com - will be finished someday. --~--~-~--~~~---~--~~ 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 group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: New in development version or versionadded
On Thu, Jan 29, 2009 at 2:24 AM, Malcolm Tredinnick < malc...@pointy-stick.com> wrote: > > Use "..versionadded::", but make the version be 1.1, not "dev". There's > a patch that we haven't applied yet, but will soon, in Trac to convert > all references to the next version to read "development version" when we > generate the HTML. > For the record; That maybe #9436, http://code.djangoproject.com/ticket/9436 ;) Regards, Marc -- http://www.marcfargas.com - will be finished someday. --~--~-~--~~~---~--~~ 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 group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Can Trac email CC list when bug is fixed?
On Sat, Apr 11, 2009 at 5:52 PM, Carl Meyer wrote: > Is it possible to set up the svn commit hook that marks a Trac issue > fixed so it also emails the CC list for that issue? That's a but in TRAC's svn-commit-hook script, there's a ticket about it in TRAC's TRAC with workarounds and so on http://trac.edgewall.org/ticket/3508. You can fill a ticket in Django asking for some workaround but you shouldn't rely on those mails too much. TRAC sometimes "forgets" to send mails on normal comments anyway; And it won't mail for any commit messages (not only Fixed/Closed but also Refs). I know, that's not nice ;\ Marc -- http://www.marcfargas.com - will be finished someday. --~--~-~--~~~---~--~~ 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 group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: [GSoC] i18n status
Hi Marc, On Mon, Jun 8, 2009 at 4:06 PM, Marc Garcia wrote: > [...] I'll really appreciate your comments, specially the ones complaining > about the code or the way I'm doing something. [...] IMHO; Not very important but I'd strip the "Default " part of the settings comments, even from the pre-existing ones; Only date related settings have this "Default ..." prefix in it's comments and feels very repetitive, we all know global_settings is about defaults. Also, those functions that are going to be deprecated should raise some DeprecationWarning to make sure anybody using them for something gets warned. Also makes it easier for the release+1 to spot thing to remove. I am wondering.. Maybe that's being discussed before, but anyway: >From what I see you intend to have a conf/locale/XX/formats.py being XX the language codes, if this is the case, how will you allow further customization? I mean, right now one can place custom .po files in his/her project path and override Django provided translations, that new behaviour seems to make it hard (if not impossible) to override the date/time (or any other formatting) related translations on a per-locale basis. That goes toghether with allowing per-application "format strings". Nice work! Just my 0.02, Marc -- http://www.marcfargas.com - will be finished someday. --~--~-~--~~~---~--~~ 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 group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: HTTP Errors
On Mon, Jul 27, 2009 at 3:47 PM, Benjamin Wohlwend wrote: > On Mon, Jul 27, 2009 at 3:27 PM, Anton Bessonov > wrote: >> >> class Http403(Exception): >> pass >> > > It isn't quite that easy. Django special-cases Http404 (see > django/core/handlers/base.py:112). Simply raising a self-made Http403 will > result in a HTTP 500 error. You could write an Exception middleware that takes care of processing your "special" exception. Bu anyway, note that you are willing is to give "response" so the right thing to do would be returning a response object: "from django.http import HttpResponseForbidden" and "return HttpResponseForbidden()". The exception is Http404 as in that case there's no one to provide a response! (to say it somehow). Keep in mind that depending on how you do things you could get unexpected behaviours with TransactionMiddleware and maybe other things. Regards, Marc --~--~-~--~~~---~--~~ 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 group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: MEDIA_URL template tag/context processor/etc again
El vie, 25-05-2007 a las 03:20 -0500, Adrian Holovaty escribió: > Given the frequency of this request, I'm OK with adding a context > processor in django/core/context_processors.py that sets a "MEDIA_URL" > variable in the context. I'm also OK with having that be in the > default TEMPLATE_CONTEXT_PROCESSORS. What do other folks think? I thought you'd prefer the templatetag approach from #4105 . For most of the world, me included, we don't care on which approach is taken as long as there's some way to get MEDIA_URL on the templates ;)) Cheers, Marc --~--~-~--~~~---~--~~ 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 group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
PostgreSQL Schemas, again
Hi there, Ticket #1051 is stalled in "Design decision needed" since a long time ago (since January). That ticket only deals with the thing of allowing the user (not the developer) to ser a specific search_path in postgresql from a setting in settings.py, it does not introduce any backwards incompatible change and does not affect any other database engine. Then two questions arise: * Can we set this patch to "Accepted"? there's some people that would benefit from such a small patch (me included!). * How would you write the tests for this? it's been recommended that we could write a test that issues a SET search_path, or create two tables on two schemas and play with them. But maybe this small thing does not require a test, so what do you think? I'd be glad to have question 1 answered so atleast we can know that this will go in once tests are in place if they are needed. Docs are already in the patch. Note that as stated in the last comment this ticket **does not** deal with other requests about application/model wide schemas and so on. Cheers, Marc. --~--~-~--~~~---~--~~ 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 group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: [DjangoProject.com] Volunteering for "Week in Review" postings
El vie, 25-05-2007 a las 07:25 -0500, Clint Ecker escribió: > Hey everyone, > maybe we can work out a nice system for sending the author of these > posts (ostensibly me) pointers to cool articles/news that might > normally be missed and/or come to some consensus of what would be a > good schedule for these posts. I think setting up an area on svn for holding the upcoming articles in .rst or something like "Debian Weekly? News" does is out of choice, but maybe content could be handled on a wiki page or a ticket in trac so it's easy for people to add things and check if they're there before adding them. Sendind the pointers directly to the author can be dangerous because you could receive a hundred times the same thing if it's to "cool" :) About the schedule, I'm +1 on Simon's point, as far as there's something to say a weekly schedule would be nice and will make things easier for people if they want to use trunk but do not want/have the time to keep an eye on the timeline, django-devs, etc. About your volunteering, anything that brings DWN (Django Weekly News) back again is really appreciated! :) My 0.02, Marc --~--~-~--~~~---~--~~ 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 group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
[Triagers/Core] About Stale Tickets
Hi there, Since we got the triagers system patches and bugfixes are moving much faster than before but there are still somethings that get stuck, specially on the "Design Decission Needed" state. In theory, if I got it right, triagers set this state when they think that the scope of a ticket should be brought to discussion on this list (django-developers). It's here, on this part of the diagram where it says "The community and/or core developers decide whether..." and the question arises: What if a ticket is brought to django-developers for discussion and there are no answers either positive or negative? Is the ticket left there to die? Or can triagers assume that if nobody has said anything in some period of time that no developer minds about the changes introduced by this ticket? If you are thinking "What ticket is he talking about?" I'm talking about #1051 which has been around for 1 year and brought for discussion without success two times atleast. But, anyway, I think that the triaging process could be improved if the ones involved can define about this issue: What happens if nobody discusses a ticket when it's brought for that? Cheers, Marc PS: Note that "Design Decision" currently holds 290 tickets, not sure how many can be hanled by "accept/reject if nobody answers about that on django-developers" ;) --~--~-~--~~~---~--~~ 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 group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: MEDIA_URL template tag/context processor/etc again
My count at the end of the thread is: #1278: 4 votes #4105: 4 votes So I thow a coin to the air... oh, it felt off the window! As the main issue with having media_url in templates what the context bloat we could go for the #4105 approach, but as recently Adrian told he's fine on having the context bloat on this specific issue we could go for #1278, but as the thread was about #4105 we could go for it, but as #1278 is older we could go for it... Anyway, one anying thing for newcomers is that they have no way to easily have MEDIA_URL on their templates so their templates can have lots of bad urls (imagine you have all media prefixed with / :)) so we could try to get either 1278 or 4105 checked in. The other issue with 1278 is that you'll have to use RequestContext around, so I'd go for 4105 and it's which I'm using now on my projects. Could somebody with a bright mind and far much more expirience than me throw the coin? ;)) Cheers, Marc El mi�, 25-04-2007 a las 04:33 -0700, Simon G. escribi�: > Evening all, > > There's been a long history of people asking for some way of easily > using the MEDIA_URL setting in templates. At a quick glance, I get > #1278, #3818, #2532, and #4105. > > These have all been marked wontfix, and I closed this last one to > match. The reasoning for the wontfix is that this leads to a slippery > slope of adding everything to the context and it's also quite easy to > implement this on your own. > > However, given the frequency of this request (I've seen it raised a > few times in django-users too), I figured I'd ask if core's still > against this, or whether we want to accept one of these. > > --Simon > > > --~--~-~--~~~---~--~~ 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 group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: MEDIA_URL template tag/context processor/etc again
El mar, 29-05-2007 a las 08:15 +0800, Russell Keith-Magee escribió:
> I make that 5:3 - and not wanting to put a jackboot down on the throat
> of democracy, but #1278 has the support of 4 core developers,
> including the BDFL.
I never was good at maths :) And I didn't perform a really well measured
calculation :)
Anyway, now it's clear that we should go for {{ MEDIA_URL }} which means
that in a near future we'll have MEDIA_URL in templates, hurray! :)
Cheers,
Marc
--~--~-~--~~~---~--~~
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 group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: [Triagers/Core] About Stale Tickets
El mar, 29-05-2007 a las 10:53 +1000, Malcolm Tredinnick escribió: > I didn't respond to your first email about this over the weekend, > because the reply I originally wrote wasn't particularly polite. Thanks for not sending that one then ;) > At some point, you have to accept that this ticket can wait a bit longer. It's > not like no action is happening anywhere in Django. You are in the queue > of things to be processed and being in the queue is better than not > being in the queue, at least. I already run a patched django so I really can wait much longer. I was just worried of not having any reply on my previous requests about #1051. > There are many fish (bugs) in the sea here. Getting hung up on one > particular ticket isn't worth the stress. Uhm. I think I've never been stressed ;) > With best wishes, > Malcolm Really, thanks for such a concise reply (on both things: #1051 and triaging) that was exactly what I was looking for! Cheers, Marc --~--~-~--~~~---~--~~ 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 group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Django Week in Review -- ATTN: Adrian Holovaty
Hi, Just a quick note, on: [...] [5502] -- Stefane Femgier submitted a patch that correctly sets the mime-type for admin media content, and was integrated into the trunk the week. [...] Maybe it should read "into trunk this week" not sure about the "the trunk" but "the week" doesn't make sense (although English isn't my primary language ;) Cheers, Marc El dom, 24-06-2007 a las 21:21 -0500, Clint Ecker escribi�: > Hey everyone. I've got a draft prepared of my first Django Week In > Review for tomorrow. I know that it's extremely long compared to > previous WIRs, but I'm trying to catch up for about 2 month's worth > here ;) > > > I've not been able to get in contact with Adrian this past week to > arrange for posting access on the site, so I hope that perhaps he'll > see this (or someone else who can help me) and get ahold of me > off-list. > > > Here's my draft: http://clintecker.com/django-wir-06252007.html > > > Let me know what you guys think of the tone, my wordiness, how I split > up the post into "random weblinks," changeset roundup, and SoC stuff, > and anything else that comes to mind. Again, please keep in mind that > this sort of length probably won't be typical. > > > Clint > > -- > Clint Ecker > Sr. Web Developer - Stone Ward Chicago > p: 312.464.1443 > c: 312.863.9323 > --- > twitter: clint > skype: clintology > AIM: idiosyncrasyFG > Gtalk: [EMAIL PROTECTED] > > > --~--~-~--~~~---~--~~ 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 group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: ANN: Django sprint, December 1st
Hi ppl, I was looking at SprintIdeas on the wiki and did a bit of cleanup at the bottom. I think we could find a more "agile" way to handle the "Results" part of the page, the way it's done now means that when you edit the ticket during the sprint you then have to edit the wiki page to reflect it. But this last step could be avoided, TRAC can insert a TicketQuery just in the middle of a wiki page: [[TicketQuery(status!=closed&keywords=sprint)]] For example, would put a list of all tickets not closed with the keyword "sprint". If we place this in the wiki page on Results then contributors would only need to set the keyword "sprint" on the ticket when they update it. And the list on the wiki page would be up-to-date and automagically cleaned up! What do you think? Cheers, Marc El mié, 07-11-2007 a las 14:45 -0600, Jacob Kaplan-Moss escribió: > Howdy folks -- > > We had such a great time doing that last sprint, so we're doing it again! > > We'll hold the sprint Saturday, December 1st here in Lawrence, KS, and > virtually around the world. We'll run things much the same as we did > last time: > > We plan to devote at least 24 hours of focused work to get some of > this done in an organized fashion, and also to encourage new people to > contribute. If all goes well on Saturday, we'll probably continue to > Saturday. > > Anybody can participate and contribute, and there's no obligation or > expectation. If you've never contributed to Django before, this is the > perfect chance for you to chip in. > > More information will be posted shortly at > http://code.djangoproject.com/wiki/Sprint1Dec2007. > > Most participants will likely be working from their own homes/offices > in their respective countries, but if you'd like to come hang out with > us in Lawrence, let me know. We can provide transportation to/from the > Kansas City airport (MCI) and can recommend a good hotel in town. > Also, a limited amount of free lodging (i.e. our couches) is > available. > > All participants -- not just those meeting in person -- should add > their names to the wiki page. > > Help us make this thing as successful as the last one! > > Jacob > > --~--~-~--~~~---~--~~ > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-developers@googlegroups.com > To unsubscribe from this group, send email to [EMAIL PROTECTED] > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en > -~--~~~~--~~--~--~--- > signature.asc Description: Esta parte del mensaje está firmada digitalmente
Django internal tests
Hi people, When one "newbie" wants to create a patch with tests for Django (which are a requirement for every ticket) he/She can get a bit confused. Maybe one knows how to write tests for his/her own applications so the first thing to try will be something like: django//tests.py this is only valid with ``contrib`` (django/contrib//tests.py) For the "core" of Django one will go to tests/ and try to figure out how to put his/her new test in there. If the test is a doctest maybe one can handle it (just appending more text to the existing doctests!) but figuring how to create a unittest is harder (I still haven't found how to add a new unittest!) Maybe docs/contributing.txt could be a bit more specific on how to add new tests to tests/, it only points users to docs/testing.txt but it's not "exactly the same". (More probably I screwed something when trying to add my unittest!). Also, how can one run specific tests inside tests/ ? Cheers, Marc signature.asc Description: Esta parte del mensaje está firmada digitalmente
Re: Django internal tests
I must have missed this part, I can now run single tests! Thanks for the pointer Michael. El sáb, 01-12-2007 a las 16:02 -0500, Empty escribió: > Read this page entirely and it should help: > > http://www.djangoproject.com/documentation/contributing/ > > specifically regarding running a single test see: > > http://www.djangoproject.com/documentation/contributing/#running-the-unit-tests > > Michael Trier > blog.michaeltrier.com > > On Dec 1, 2007 3:53 PM, Marc Fargas <[EMAIL PROTECTED]> wrote: > > Hi people, > > When one "newbie" wants to create a patch with tests for Django (which > > are a requirement for every ticket) he/She can get a bit confused. > > > > Maybe one knows how to write tests for his/her own applications so the > > first thing to try will be something like: > > > > django//tests.py > > > > this is only valid with ``contrib`` > > (django/contrib//tests.py) > > > > For the "core" of Django one will go to tests/ and try to figure out how > > to put his/her new test in there. > > > > If the test is a doctest maybe one can handle it (just appending more > > text to the existing doctests!) but figuring how to create a unittest is > > harder (I still haven't found how to add a new unittest!) > > > > Maybe docs/contributing.txt could be a bit more specific on how to add > > new tests to tests/, it only points users to docs/testing.txt but it's > > not "exactly the same". > > > > (More probably I screwed something when trying to add my unittest!). > > > > Also, how can one run specific tests inside tests/ ? > > > > Cheers, > > Marc > > > > --~--~-~--~~~---~--~~ > 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 group, send email to [EMAIL PROTECTED] > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en > -~--~~~~--~~--~--~--- > signature.asc Description: Esta parte del mensaje está firmada digitalmente
Re: Is there a simple way I can find which files still use oldforms, and have no patch?
grep -n -R "from django import forms" grep -n -R "import django.forms" Hope it help ;) El sáb, 05-01-2008 a las 00:41 -0800, shabda.raaj escribió: > I submitted ticket and patch for http://code.djangoproject.com/ticket/6318, > but that is a duplicate of http://code.djangoproject.com/ticket/6083 . > I would like to work on moving files from oldforms to newforms, How > can I find out which files in newforms-admin branch have no patch > against them, so that I do not work on the duplicate of any ticket? > --~--~-~--~~~---~--~~ > 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 group, send email to [EMAIL PROTECTED] > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en > -~--~~~~--~~--~--~--- > signature.asc Description: Esta parte del mensaje está firmada digitalmente
Re: Is there a simple way I can find which files still use oldforms, and have no patch?
You have a few options, * Programatically: You'd need every patch pending to apply on TRAC, apply them and then do the grep thing to see who's left. * Do the grep thing and then search on trac if there are tickets for those things. Tickets are not open in "django/xxx/xyz.py uses oldforms" so there's no magic query you can use :) El sáb, 05-01-2008 a las 05:01 -0800, shabda.raaj escribió: > That would tell me which files are still using oldforms, what I want > to know is which files have oldforms, but no patch created for > them(which are unapplied to the svn). Some trac query perhaps? > > On Jan 5, 5:21 pm, Marc Fargas <[EMAIL PROTECTED]> wrote: > > grep -n -R "from django import forms" > > grep -n -R "import django.forms" > > > > Hope it help ;) > > > > El sáb, 05-01-2008 a las 00:41 -0800, shabda.raaj escribió: > > > > > I submitted ticket and patch forhttp://code.djangoproject.com/ticket/6318, > > > but that is a duplicate ofhttp://code.djangoproject.com/ticket/6083. > > > I would like to work on moving files from oldforms to newforms, How > > > can I find out which files in newforms-admin branch have no patch > > > against them, so that I do not work on the duplicate of any ticket? > > > > > > > > > > signature.asc > > 1KDownload > > --~--~-~--~~~---~--~~ > 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 group, send email to [EMAIL PROTECTED] > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en > -~--~~~~--~~--~--~--- > signature.asc Description: Esta parte del mensaje está firmada digitalmente
Re: Feature Request: "Abstract Model"
Hi Wanrong, Maybe you could live with something like: class common(models.Model): ... Meta: create_db_schema = False class Model_B(models.Model): ... Meta: create_db_schema = True But for this, you'll need to wait for #3163 [1] to be checked-in (and it's still waitting for tests). Cheers, Marc 1: http://code.djangoproject.com/ticket/3163 El sáb, 12-01-2008 a las 14:15 -0500, Wanrong Lin escribió: > Hi, > > I have just started playing with Django and found it a pleasure to set > up web site (even just a toy system so far) using the frame work. Thank > you very much! > > I have a data model case that I think probably is quite common to other > people too, and I did not find a way to do it with current Django, so I > wonder whether the developers can take a look of it. > > My situation is: > > I have quite a few data model classes that share some common fields, so > I have the following model code: > > > class Common(models.Model): > # common fields > .. > > class Model_A(Common): > # extra fields > .. > > class Model_B(Common): > # extra fields > .. > --- > > That works, except that a database table will be created for "Common", > which will never be used by itself. > > So I will just keep "Common" table empty, not a big deal. But, to make > it more elegant (which I suspect a lot of Python programmers are > obsessed about), can we add some kind of mechanism to tell Django that > "Common" is an "abstract model" that is not intended to be used by > itself, so no table needs to be created? > > Thank you for giving it a thought. > > Best regards. > > Wanrong > > > > > > --~--~-~--~~~---~--~~ > 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 group, send email to [EMAIL PROTECTED] > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en > -~--~~~~--~~--~--~--- > -- http://www.marcfargas.com -- will be finished some day. signature.asc Description: Esta parte del mensaje está firmada digitalmente
Re: Feature Request: "Abstract Model"
Hi Wanrong, It's hard to give predictions on open source projects, the last comment on #3163 is advising that he/she cannot write the tests for some reason. And without tests the ticket won't be checked-in. You can always try to give a hand writting suchs tests. Once the ticket has everything it should it doesn't take too long to get checked-in unless: a) no committer sees it (unlikely), b) somebody has concerns about the ticket, unlikely as it's marked "Accepted". So, if you feel brave enought you can take a look at http://www.djangoproject.com/documentation/contributing/ and try to get the ticket's patches to good shape ;) Marc. El dom, 13-01-2008 a las 23:04 -0500, Wanrong Lin escribió: > > Hi, Marc, > > This is great news. I am glad I have not re-written all my models with > all those duplicated stuff (I am sure that wouldn't make me feel I am > following the "DRY" principle). > > Is it possible to give any prediction when this great stuff will be > checked in? Thanks a lot. > > Wanrong > > Marc Fargas wrote: > > Hi Wanrong, > > Maybe you could live with something like: > > > > class common(models.Model): > > ... > > Meta: > > create_db_schema = False > > > > class Model_B(models.Model): > > ... > > Meta: > > create_db_schema = True > > > > But for this, you'll need to wait for #3163 [1] to be checked-in (and > > it's still waitting for tests). > > > > Cheers, > > Marc > > > > 1: http://code.djangoproject.com/ticket/3163 > > > > El s�b, 12-01-2008 a las 14:15 -0500, Wanrong Lin escribi�: > > > >> Hi, > >> > >> I have just started playing with Django and found it a pleasure to set > >> up web site (even just a toy system so far) using the frame work. Thank > >> you very much! > >> > >> I have a data model case that I think probably is quite common to other > >> people too, and I did not find a way to do it with current Django, so I > >> wonder whether the developers can take a look of it. > >> > >> My situation is: > >> > >> I have quite a few data model classes that share some common fields, so > >> I have the following model code: > >> > >> > >> class Common(models.Model): > >> # common fields > >> .. > >> > >> class Model_A(Common): > >> # extra fields > >> .. > >> > >> class Model_B(Common): > >> # extra fields > >> .. > >> --- > >> > >> That works, except that a database table will be created for "Common", > >> which will never be used by itself. > >> > >> So I will just keep "Common" table empty, not a big deal. But, to make > >> it more elegant (which I suspect a lot of Python programmers are > >> obsessed about), can we add some kind of mechanism to tell Django that > >> "Common" is an "abstract model" that is not intended to be used by > >> itself, so no table needs to be created? > >> > >> Thank you for giving it a thought. > >> > >> Best regards. > >> > >> Wanrong > >> > >> > >> > >> > >> > >> >> > >> > > > --~--~-~--~~~---~--~~ > 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 group, send email to [EMAIL PROTECTED] > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en > -~--~~~~--~~--~--~--- > -- http://www.marcfargas.com -- will be finished some day. signature.asc Description: Esta parte del mensaje está firmada digitalmente
#6320, clarifications on contributing.txt
Hi there, A few days ago I filled a bug on "contributing.txt" (#6320) [0] about clarifying what triagers are, what volunteering means and who should do what. That was mostly motivated due some tickets in which volunteers marked as Ready for checking and "more official" triagers prefered this status change to be a bit more restricted (having the volunteers disasspointed as contributing.txt says they can, or should, do so to help). Right now the patch on the ticket distinguishes Triagers in two roles/types: * Trusted Triagers: Those who have proved their triaging criteria and are (somehow) officially recognised as "Triagers". * Community Triagers (Volunteering Triagers or Community Members): Those willing to help that triage bugs while trying to prove their criteria. A few tips are given for this last role, not completely forbidding the most important actions but restricting them a bit like: - Do not close bugs as "wontfix", see the definition of "wontfix" below, but in general, it's a decission in hands of *core developers*. - Do not promote tickets to "Ready for Checkin" unless you feel confident about the patch provided and you are not related to the ticket itself (You know, it's not good to judge oneself's work). - Only close tickets as "invalid" if those are clear cases like help requests which sould be placed to ``django-users`` (tell so when closing the ticket). SimelyChris marked the ticket as "Design decision needed" and asked me to bring the ticket to the list for further discussion. While discussing the ticket I'd be glad if you can propose names for the "Community Triagers/Volunteers/Community Members". I did not call the role "Community Members" to distinguish the volunteers from Community Members, but maybe it would stay clearer with this name. So, comments and critics are really welcome. I just feel that this clarifications should be written in the documentation some day to avoid getting people upset (one could think that things got a bit hot on #399 [1]). Cheers, Marc [0] http://code.djangoproject.com/ticket/6320 [1] http://code.djangoproject.com/ticket/399 -- http://www.marcfargas.com -- will be finished some day. signature.asc Description: Esta parte del mensaje está firmada digitalmente
Re: #6320, clarifications on contributing.txt
El jue, 24-01-2008 a las 20:16 +0900, Russell Keith-Magee escribió: > Thanks for taking the lead on this. Suggestions on how to improve > documentation are always welcome, especially when they are specific > suggestions, backed up by evidence of the existing inadequacy (as you > have done with ticket #6320) and a first draft. Thanks! > [...] Giving a role a specific label distinct from the community as a whole > implies that some form of selection criteria will exist. [...] at least some > of the confusion [...] is to do with the issue of how someone gets > selected as a triager. [...] it would have just lead to the question "How do > I get selected as a community triager?". > [...] I would suggest that a better way to approach this > issue would be to keep the existing core + triager labels. I think SmileyChris comment was on the same direction, so I've just attached a new draft on #6320. It removes the third role while inviting everybody to help out at triaging and giving the points on what they/we should and should not do. There's a sentence I'm not sure about (on how it sounds): "In fact, the only difference between you and a triager[...]" The "you" could also be written as "a community member" or "a volunteer" but I thought "you" could emphatize that if 'you' are reading 'this' you can help with 'that'. Anyway, Draft 2 published! -- http://www.marcfargas.com -- will be finished some day. signature.asc Description: Esta parte del mensaje está firmada digitalmente
Re: Are there any graphical tools for MDA with Django ?
Hi, You should better ask that on the django-users group. This group is intended for *internal* django developenment (that is, the framework itself not stuf on top of it). As an answer, I do not know of any such tool. Cheers, Marc El lun, 04-02-2008 a las 16:58 +0100, Jean-Christophe Kermagoret escribió: > Hi, > are there any tools, like a graphical modeler, to design then generate > Django application, from storage (through generation and configuration > of Django model) to presentation layer (through generation and > configuration of templates) ? > > Cheers, > > Jean-Christophe > -- http://www.marcfargas.com -- will be finished some day. signature.asc Description: Esta parte del mensaje está firmada digitalmente
Re: Model Inheritance
Model inheritance is not there yet. You can take a look at the queryset-refactor branch, since Changeset 7126 moder inheritance begun to take shape. The changeset also includes documentation about that. You can either use this branch or wait until it gets merger to trunk. http://code.djangoproject.com/changeset/7126 Regards, Marc El mar, 01-04-2008 a las 00:31 -0700, jurian escribió: > I think I might have the wrong idea about model inheritance. > > I was using the 'newforms-admin' branch and implemented some model > inheritance just to see if it works and it did. Well, let's say that > it did what I had expected, or wanted it to do at the time. > > class X(models.Model): > x = models.CharField() > > class Y(X): > y = models.CharField() > > class Z(X): > z = models.CharField() > > produced the tables > > x(id, x) > y(id, x, y) > z(id, x, y, z) > > > All I need to know is if this is some kind of fall-back till full- > blown model inheritance is implemented, or if this is just a fluke. > --~--~-~--~~~---~--~~ > 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 group, send email to [EMAIL PROTECTED] > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en > -~--~~~~--~~--~--~--- > -- http://www.marcfargas.com -- will be finished some day. signature.asc Description: Esta parte del mensaje está firmada digitalmente
Re: Easier URL patterns
> El mar, 08-04-2008 a las 04:27 -0500, James Bennett escribió: > Or people could go learn from one of the many thousands of regex > tutorials that's already been written? There's a point at which we > have to assume that people are willing to help themselves out a bit by > learning Python and important programming concepts on their own, or > that they're simply not going to be able to use Django. From tutorial03: If you need help with regular expressions, see Wikipedia’s entry and the Python documentation. Also, the O’Reilly book “Mastering Regular Expressions” by Jeffrey Friedl is fantastic. My fault for not seeing this one before! a paragraph like this one could be on url_dispatch.txt and that should do the job. So I agree with your comment. Regards, Marc -- http://www.marcfargas.com -- will be finished some day. signature.asc Description: Esta parte del mensaje está firmada digitalmente
Re: Easier URL patterns
El mar, 08-04-2008 a las 10:09 +0200, David Larlet escribió: > >>url(r'^(?P[-\w]+)/$', myview), > > > > Note that this example is more complicated than it needs to be. I'd > > write it like this: > > > >(r'^([-\w]+)/$', myview) > In this case, what about a default dictionary of popular regexps? I > use it all the time: Maybe the documentation refactoring could include an Appendix: "Introduction to REGEX" and "The regular expressions you'll find everyday" or something like that. With this, newcomers would have an introduction to regex (not everybody knows it!) and a small cheatsheet with the common ones (\w, \d, ...) -- http://www.marcfargas.com -- will be finished some day. signature.asc Description: Esta parte del mensaje está firmada digitalmente
[triage] Howto emphasize a ticket
Hi there, The triage system is really nice! but there's just one thing, with the removal of priorities when a core developer goes to see the "Read for check-in" tickets it has no way to know that some of those tickets should be taken ASAP, for example: #3336 which solved broken links in djangoproject.com. Is there any recommended way to announce the existance of such tickets or just "ping" here asking for those tickets to be closed ASAP? That would apply also for security related tickets and so on. Just ask the users if they like the broken links in the website :P Cheers, Marc. PS: Oh, please check-in #3336 and update the website ASAP :o) --~--~-~--~~~---~--~~ 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 group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Encouraging contributed documentation
Hi, Answering inline. On 1/24/07, James Bennett <[EMAIL PROTECTED]> wrote: > So I'd like to propose that we draw up some guidelines for > contributing documentation for Django, and begin encouraging > documentation contributions just as much as we encourage code > contributions. +1 ! > Maybe we could even choose some of the more prolific bloggers to form > an official documentation team and work on filling in the gaps and > maintaining the docs we already have? That'd also help take some of > the burden off the core dev team, who currently maintain both the code > and the documentation :) +1 ! They could even fill bugs about documentation errors so volunteers can help to fix them. I'd also ask everybody to fill bug reports when they find inconsistent or outdated documentation on the docs ;) Cheers, Marc --~--~-~--~~~---~--~~ 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 group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
All tickets go to jacob
All new tickets being opened on TRAC are assigned to jacob, not sure if it's to be this way but if it isn't, then you know it's happening! ;) Maybe get the field empty unless somebody assigns it or set it to "anonymous" :) --~--~-~--~~~---~--~~ 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 group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: No. <-- Re: All tickets go to jacob
Thanks for the info! On 1/24/07, Michael Radziej <[EMAIL PROTECTED]> wrote: > > Marc Fargas Esteve: > > All new tickets being opened on TRAC are assigned to jacob, not sure > > if it's to be this way but if it isn't, then you know it's happening! > > No, they don't. It depends on the selected component. > > Michael > > -- > noris network AG - Deutschherrnstra�e 15-19 - D-90429 N�rnberg - > Tel +49-911-9352-0 - Fax +49-911-9352-100 > > http://www.noris.de - The IT-Outsourcing Company > > > > --~--~-~--~~~---~--~~ 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 group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: triage: one third done
Really nice work, congratulations! ;) On 1/24/07, Michael Radziej <[EMAIL PROTECTED]> wrote: > > Hi, > > just to give you an idea how fast we proceed: currently 228 out of > 655 open tickets have been reviewed, and that does not count all > those that got closed during triage! Isn't that nice? > > Michael > > > -- > noris network AG - Deutschherrnstra�e 15-19 - D-90429 N�rnberg - > Tel +49-911-9352-0 - Fax +49-911-9352-100 > > http://www.noris.de - The IT-Outsourcing Company > > > > --~--~-~--~~~---~--~~ 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 group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
triage: Which "state" for #3279
Hi, In the nice graphic on http://www.djangoproject.com/documentation/contributing/#ticket-triage #3279 would go from "Unreviewed" to the left to "worksforme" as the resolution, but what Triage State would it get? "Unreviewed" is not true, as it has been reviewed, but it's not "Accepted" either (at least if we follow the "The ticket is a bug") Any suggestion on which state to set for tickets closed as wontfix/invalid and some "worksforme" ? Maybe we can get the "Rejected" or "Invalid" states for those cases. Marc. --~--~-~--~~~---~--~~ 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 group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: triage: Which "state" for #3279
Thanks Michael for the explanation, I took the ticket as example until you pointed me to comment #9 :) Cheers, Marc. On 1/25/07, Michael Radziej <[EMAIL PROTECTED]> wrote: [...] > This ticket is a bad example. It should be open, and it is only > closed since reopen does currently not work. > > When a ticket is "really closed", then the Triage State does not > matter. Closed tickets simply will not get looked at (except by some > one who is looking for an old bug). [...] --~--~-~--~~~---~--~~ 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 group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Minimum MySQLdb version? (#2765, #3279)
Hi there, The tickets #2765[1] and #3279[2] are about two issues with MySQLdb version 1.2.0, for #3279 there's a patch that adds a warning on install.txt about those issues. But adding a second warning for #2765 like: "the minimum supported version of MySQLdb is 1.2.1p2 if you want to use binary collations or threading." can be a bit obscure for newbies, so the question is: Should this warning above (which mentions the two issues) be placed on the docs or should the docs state MySQLdb version 1.2.1p2 as the minimum version? or maybe somebody has a better option! Cheers, Marc. --~--~-~--~~~---~--~~ 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 group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Minimum MySQLdb version? (#2765, #3279)
err.. sorry, forgot the links for lazy people: [1]: http://code.djangoproject.com/ticket/2765 [2]: http://code.djangoproject.com/ticket/3279 On Jan 26, 12:10 am, "Marc Fargas Esteve" <[EMAIL PROTECTED]> wrote: > Hi there, > The tickets #2765[1] and #3279[2] are about two issues with MySQLdb > version 1.2.0, for #3279 there's a patch that adds a warning on > install.txt about those issues. But adding a second warning for #2765 > like: > > "the minimum supported version of MySQLdb is 1.2.1p2 if you want > to use binary collations or threading." > > can be a bit obscure for newbies, so the question is: Should this > warning above (which mentions the two issues) be placed on the docs or > should the docs state MySQLdb version 1.2.1p2 as the minimum version? > or maybe somebody has a better option! > > Cheers, > Marc. --~--~-~--~~~---~--~~ 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 group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: svn properties ?
Hi, Answer inline On 1/26/07, Honza Král <[EMAIL PROTECTED]> wrote: [...] > yes, but what if you are not working with a checkout, but rather an > exported directory (why should everybody have svn on server and keep > all those .svn dirs?), what will you do then? > I would like to see the revision number SOMEWHERE, preferably > something like django.VERSION.. so I am +1 on this... I'd then advocate for Don Arbow's solution, when you strip all the .svn directories you can add file telling the last revision pulled. something like django.VERSION would need to be updated on every new commit or it's revision would never cjange (note that the keyword Rev is really: LastChangedRevision whose name says it all). You'd need one of those: - a file changed on every commit so it's revision is the last one available - the LastChangedRevision on every file so you know which revision was it last modified, which in turn WOULD NOT tell you which is the current revision of your working copy (you need to grep the whole django/ directory looking for the highest LastChangedRevision). That's why svn info is there ;) --~--~-~--~~~---~--~~ 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 group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Django Builbot (was: dbsync for mysql lacks...)
Hi, inline On 1/30/07, Michael Radziej <[EMAIL PROTECTED]> wrote: [..] > I'm now dreaming of a test service that would automatically run the > testsuite for a given patch (or multiple patches) with all supported > database backends ... Also thought about that, getting up a buildbot for testing the SVN is not hard (it's already done on pybots), running the testsuite for a given patch has a big danger: One could upload a malicious patch just to f**k the buildbot. Some way would be needed to tell the buildbot that a patch is to be tested, then it only has to download the patch from a ticket and start a Build jobs. If the core's around here would like to get up a buildbot that runs the testsuite on the various python versions, and various backends it can be done! (at least on debian.. :P). And if some security measure is provided patches on TRAC could also be tested without trouble maybe a textfield on the ticket telling which patches to check (as some tickets have lots of patches) to be set by a triage member. I could setup the buildbot for testing if it seems to make sense (most of the work is already done on pybots, only playing with all the possible combinations is needed). > Michael Marc --~--~-~--~~~---~--~~ 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 group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Django Builbot (was: dbsync for mysql lacks...)
On 1/30/07, Michael Radziej <[EMAIL PROTECTED]> wrote: > Marc Fargas Esteve: > That sounds interesting. (Did I mention that it should run python > versions 2.3, 2.4 and 2.5? ;-) As Matthew said this could be done with separate buildbots or slaves running different jobs. > I wouldn't mind doing this on my own computer if it's so easy ;-) It depends on how Matthew's buildbot works, normally if you have svn and the required dependencies it just requires a few files and the buildbot package, the hard work is at the master which, at the most part, has already been done by Matthew (get the source, set a project, test it...) Then you can make your computer be a new "slave" that received build jobs from the "master", then the master decides when your slave has to do things. > Perhaps you can pre-build such a thing ready to download for > everybody who is interested? It's probably easier than building a > shared buildbot with proper authentication etc. Don't make any > complicated patch-auto-selection, let the user prepare the source, > and the buildbot runs the testsuite with all backends and the python > versions. For that to be done the user would need all the different python versions and backends (with the required database servers) to run it. A user can already run the tests with one python version and database or more if he/she has them. But it's not an easy thing to package, that's why buildbot was written! > This could be used to test the trunk with each checkin (or daily), > or to test all the patches in stage "Ready for checkin". And I'd > love to have this for triage. Buildbot was written for that, the svn repository can tell the buildbot when a new checking has been done and start a new bunch of jobs against it. Having this in place the part of taking patches from trac is not so hard, the problem is to identify which is the correct patch to test. > Michael Marc --~--~-~--~~~---~--~~ 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 group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Django Builbot (was: dbsync for mysql lacks...)
Hi Matthew On 1/30/07, Matthew Flanagan <[EMAIL PROTECTED]> wrote: > I run the django pybot. It wouldn't be difficult to add other backends > to the tests and is something I've been considering for a while. As > for python versions, pybot only tests 2.5 and trunk > . Testing against 2.3 and 2.4 would have to be done on another buildbot. At least on debian is not hard to have python 2.3, 2.4 and 2.5 available on the same box (simply call /usr/bin/python2.X), also different versions of postgresql can be run side by side (not for mysql). Maybe a single BuildSet could be created that creates a bunch of Builds with the different combinations of python+backend. As far as a slave has the three versions of python and the different backends it could run the tests. (note that for postgresql there are two backends!), Anyway there's always virtualization if you need true isolation and/or different mysql server versions. Sure you have far more knowledge of buildbot than me, so any comments are really appreciated! > I'm fairly busy for the next 2 weeks but I can look at it after that > and hopefully add postgresql and mysql backends on top sqlite that is > being tested already. That would be nice, then the only thing left would be the different versions of python. For which, as you say, those would need to run on a different buildbot (buildd.djangoproject.com ?) Cheers, Marc. PS: I can host a slave and/or the master for the different python/backends buildbot if you wish. --~--~-~--~~~---~--~~ 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 group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Django Builbot (was: dbsync for mysql lacks...)
[note: maybe this message appears twice as I sent it with the wrong reply-to and google-groups likes to reject it, if so, sorry ;) ] Hi Matthew On 1/30/07, Matthew Flanagan <[EMAIL PROTECTED]> wrote: > I run the django pybot. It wouldn't be difficult to add other backends > to the tests and is something I've been considering for a while. As > for python versions, pybot only tests 2.5 and trunk > . Testing against 2.3 and 2.4 would have to be done on another buildbot. At least on debian is not hard to have python 2.3, 2.4 and 2.5 available on the same box (simply call /usr/bin/python2.X), also different versions of postgresql can be run side by side (not for mysql). Maybe a single BuildSet could be created that creates a bunch of Builds with the different combinations of python+backend. As far as a slave has the three versions of python and the different backends it could run the tests. (note that for postgresql there are two backends!), Anyway there's always virtualization if you need true isolation and/or different mysql server versions. Sure you have far more knowledge of buildbot than me, so any comments are really appreciated! > I'm fairly busy for the next 2 weeks but I can look at it after that > and hopefully add postgresql and mysql backends on top sqlite that is > being tested already. That would be nice, then the only thing left would be the different versions of python. For which, as you say, those would need to run on a different buildbot (buildd.djangoproject.com ?) Oh, and congratulations for the django pybot ;) Cheers, Marc. PS: I can host a slave and/or the master for the different python/backends buildbot if you wish. --~--~-~--~~~---~--~~ 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 group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Django Builbot (was: dbsync for mysql lacks...)
Hi, inline On 1/31/07, Matthew Flanagan <[EMAIL PROTECTED]> wrote: > The Django buildbot slave is currently running inside a Solaris 10 > zone so it is virtualized...kind of. > > Let me clarify that testing python 2.3 and 2.4 would require a > separate buildbot master than pybots unless you can talk the pybots > maintainer into running 2.3 and 2.4 tests as well. Why don't you join > the pybots mailing list and ask? As far as I know pybots sets new build jobs when changes occur in the python code base, so If we want to launch build jobs on new commits on django/trunk we'd need to setup a separate master anyway, wouldn't we? Having 2.3 and 2.4 there would make it possible to test django/trunk when commit occur there but not when commit occur on django's SVN. And I think that the original comment of this thread from Michael was to keep django's trunk tested on every commit and trying to test patches from TRAC before they get commited. In this scenario, am I wrong or we do need a separate master? Cheers, Marc --~--~-~--~~~---~--~~ 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 group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Django ORM bug when your app has a model named "ContentType"?
I don't see that as a limitation, think of it as a reserved word! you can use MyContentType. Or maybe a core-dev can think more on this and provide a better solution to allow gaving duplicate names (but I'm not sure if this problem applies to models on different apps or just on "some" models that ship with django, like that one). On 1/31/07, Rob Hudson <[EMAIL PROTECTED]> wrote: > But I don't think Django would want this type of restriction. I've > tried to track how this might get in the SQL myself but it's beyond > me. I'm just offering to help assist or share my model offline if > needed. > > -Rob > > > > > --~--~-~--~~~---~--~~ 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 group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Please encourage PsycoPG 2 usage (not 1!)
And I use windows 3.1 'cause I prefer it! Just joking ;) But psycopg1 is obsolete so newcomers should be recommended to version use 2 unless there are still outstanding issues with it. They can always go to psycopg1 if they want ;) On 2/9/07, Kenneth Gonsalves <[EMAIL PROTECTED]> wrote: > > > On 08-Feb-07, at 9:00 PM, Nicola Larosa (tekNico) wrote: > > > There's still people around that do not use PsycoPG 2, because of that > > obsolete note in doc/install.txt . > > i still use psycopg1 because i prefer it > > -- > > regards > kg > http://lawgon.livejournal.com > http://nrcfosshelpline.in/web/ > > > > > > --~--~-~--~~~---~--~~ 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 group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Please encourage PsycoPG 2 usage (not 1!)
It is obsole because upstream says so: # PsycopgOne -- the original psycopg 1.1.x (now obsoleted by psycopg 2) # PsycopgTwo -- psycopg 2.0, the one you shall use (from: http://www.initd.org/tracker/psycopg/wiki) If upstream says something is obsolete you should stop using it ;) On the benefits I can think of: "Because it is the current version, hence the maintained one" and you should not encourage newbies to use things that have been stated as obsolete by it's authors. And something released six months ago (version 2.0 was released on 8th June 2006) is not that new. the matter is: "Does django has any issue when moving from 1.0 to 2.0"? if it has no issue we shouldn't be encouraging the use of the obsolete version. I do not say "Drop pyscopg1 support" I just say that we should not be encouraging the use of something stated as obsolete unless we have an important reason to do so. About the "hence the maintained one" psycopg1 is unmaintained since 8th October 2005. To check the dates yourself: * http://initd.org/pub/software/psycopg/ChangeLog-1.1 * http://initd.org/pub/software/psycopg/ChangeLog-2.0 Cheers, Marc On 2/9/07, Kenneth Gonsalves <[EMAIL PROTECTED]> wrote: > > > On 09-Feb-07, at 3:08 PM, Marc Fargas Esteve wrote: > > > But psycopg1 is obsolete > > in what way is it obsolete? works fine for me - I dont believe in > upgrading to a new and backwardly incompatible version just because > it is new. What are they benefits of pyscopg2 over 1? > > -- > > regards > kg > http://lawgon.livejournal.com > http://nrcfosshelpline.in/web/ > > > > > > --~--~-~--~~~---~--~~ 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 group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Should newforms security fixes be posted to django-announce?
Hi, inline On 2/9/07, James Bennett <[EMAIL PROTECTED]> wrote: [...] > But on the other hand, if somebody does decide to go a little while > without an "svn up", it'd be nice to have this announced so they know > that they should update (though I have my doubts about how many people > actually subscribe to django-announce). Doubt it, I didn't know it existed! And sure many other don't ;) Maybe it could be announced here or in django-users as if you are using trunk, or any SVN checkout you'll likely be subscribed to at least one of those. And then leave the announce group for things related to stable releases as it should be ;) Jusy my 0.02, Marc --~--~-~--~~~---~--~~ 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 group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Adding support for replacing the auth User model to fit custom needs
Hi, http://www.b-list.org/weblog/2006/06/06/django-tips-extending-user-model does this help? You can extend the User model with another class that gets related to it. Sure it should be documented in djangoproject.com but couldn't find it there... I'll look deeper ;) On 2/12/07, RonnyPfannschmidt <[EMAIL PROTECTED]> wrote: > > The build-in User model is nice in many Cases, but sometimes it just > is a bad limit for Development cause of its limits, but just droping > it would cause the loss of all auth features, and doesnt play well > with 3rd Party apps > > Examples are : > * Email as Username > * _long_ Usernames > * special Characters in Usernames > > > My Proposal is to Hand Developers/Administrators a way to replace the > default User model from Auth by something selfmade. > > The easy Part would be the If clause to import the Alternative Model > > The hard Part is keeping the Interface working well > > > Since not all all apps need the complete User interface > * wikis wont need permissions > * no everyone needs first/last name > * staff, superuser - in my case its all the same > * i want to use mail instead of username > > some need extensions of existing fields > * usernames need to be longer, and support special characters > > and some might need additional parts > * i'd like to add profile data like messaging screen-names and > homepages directly > > it would be nice to have a way to define wich part of the interface is > implemented in the custom model, and what parts my apps need in order > to prevent breaking apps cause of missing interface parts > > > > > --~--~-~--~~~---~--~~ 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 group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Newforms styling suggestion
You could set the additional class to the container so you can use simple CSS selectors to apply different styles to any element from the container and inside it. Setting the class on the label or the input field would not allow to modify the container. My 0.02, Marc On 2/16/07, Waylan Limberg <[EMAIL PROTECTED]> wrote: > > On Thu, 15 Feb 2007 20:58:27 -0500, Adrian Holovaty <[EMAIL PROTECTED]> > wrote: > > > > > On 2/15/07, Brian Morton <[EMAIL PROTECTED]> wrote: > >> I don't know if this has been suggested yet, but has anyone considered > >> an > >> enhancement to newforms to optionally allow a field to have a different > >> class if it has an error? It would be helpful for things like making > >> 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 > > > I'd realy like to see this as well. I suppose either way would work, but > which is used needs to be consistent across all as_methods. Either isn't > always the containing block element or its always the label or it's always > the form element. The more I think about it, different people will want to > apply the style to one of any of those three possibilities. The only way > to be able to do so consistently is with the containing block. Oh, and > rather than "a different class" it should add an **additional** class. We > don't want to remove any classes that already exist. > > > -- > Waylan Limberg > [EMAIL PROTECTED] > > > > --~--~-~--~~~---~--~~ 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 group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Newforms styling suggestion
By container we should mean the most top element so it should be the or that has the label and the input below it ;) On 2/16/07, Ivan Sagalaev <[EMAIL PROTECTED]> wrote: > > Marc Fargas Esteve wrote: > > You could set the additional class to the container so you can use > > simple CSS selectors to apply different styles to any element from the > > container and inside it. Setting the class on the label or the input > > field would not allow to modify the container. > > +1 (if by "container" we mean a , or in predefined methods) > > > > --~--~-~--~~~---~--~~ 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 group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Proposal: Root view
+1, just leave the "urls.py" thing as the default for newcomers. --~--~-~--~~~---~--~~ 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 group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Constraints and MySQL
Hi, On 2/28/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: [...] > Either way, the problem/limitations > with MySQL needs to be mentioned in the documentation (both > serialization and fixtures). Yes, in really big red letters, we could add a directive for the documentation rst for "thinks you should care depending on your setup" or a "Warning MySQL users" and another for "Warning Windows users" for the timezone warning already there :) Could the test be conditional and only run when the database is postgresql? (or is not MySQL) -1 on option 1, and +1 in option 2. We should not remove functionality because MySQL can't deal with that, simply document "this won't work with mysql" :) Cheers, Marc --~--~-~--~~~---~--~~ 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 group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Constraints and MySQL
Hi, On 2/27/07, Geert Vanderkelen <[EMAIL PROTECTED]> wrote: > Because the other Databases have 'limitations' or 'features' or > 'defects' that MySQL might not have or whatever. Django is, as I have > been told, database independent. And Django is working fine with > MySQL, lets keep it that way. I think the problem is that MySQL **has** the limitation, not the other databases. and anyway as Russel pointed out MySQL is not working. The difference is that now **we know it doesn't** reverting 4610 would make us **not knowing** again :) --~--~-~--~~~---~--~~ 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 group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: django documentation - editing
w0w, That's really **cooler** than the previous method. I always wondered how often were the on-line docs updated, now it only depends on the cache :) One thing that is not managed on TRAC are comments on documentation, they are supposed to get "cleaned" when they get incorporated onto the docs, but there's no way to clean them up :) If they're really supposed to be cleaned then the contributing doc should say "If your documentation patches leave some comments outdated record it in the ticket so we can clean them" Just 0.02, Marc On 3/26/07, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > > > On 3/25/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > As James mentioned (indirectly), it's all under django/docs.txt -- we > > basically just run rst2html.py over the results before it is displayed > > on the website. > > [Actually, it's a bit cooler now: the doc views now pull the reST > source directly out of SVN trunk and render them into the cache for > display. Check out the source if you're interested: > > http://code.djangoproject.com/browser/djangoproject.com/django_website/apps/docs/views.py > ] > > Jacob > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: django documentation - editing
Uhm.. when did comments disappear? They're nowhere now! It's nicer that way :) Forget my last comment! On 3/27/07, Marc Fargas Esteve <[EMAIL PROTECTED]> wrote: > > w0w, > That's really **cooler** than the previous method. I always wondered how > often were the on-line docs updated, now it only depends on the cache :) > > One thing that is not managed on TRAC are comments on documentation, they > are supposed to get "cleaned" when they get incorporated onto the docs, but > there's no way to clean them up :) If they're really supposed to be cleaned > then the contributing doc should say "If your documentation patches leave > some comments outdated record it in the ticket so we can clean them" > > Just 0.02, > Marc > > On 3/26/07, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > > > > > > On 3/25/07, Malcolm Tredinnick <[EMAIL PROTECTED] > wrote: > > > As James mentioned (indirectly), it's all under django/docs.txt -- we > > > basically just run rst2html.py over the results before it is displayed > > > on the website. > > > > [Actually, it's a bit cooler now: the doc views now pull the reST > > source directly out of SVN trunk and render them into the cache for > > display. Check out the source if you're interested: > > > > http://code.djangoproject.com/browser/djangoproject.com/django_website/apps/docs/views.py > > ] > > > > Jacob > > > > > > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Support for a binary storage field?
Hi, If you provide a BinaryField it's just a matter of time that "hacks" will start to go out on blogs, the wiki or even django-users to get ImageField and FileField on the database (there's a hack on this already), maybe it's 99% bad but if those fields are provided inside django it will be much better than having lots of hackish ways around. And anyway, there's still a 1% of cases on which it's good design, normally cases of big applications. An argument for supporting Image/Field on DB: Consider a case of multiple frontends with a big big database, having File and Image fields on filesystem forces you to keep the filesystem in sync among frontends. Now imagine you upload a file which is i.e. the image for an article; The article is inserted on the database and the file on the filesystem. All frontends will **immediatelly** show up the article, but only one will have the image! unless you start playing around with NFS or other networked filesystems. It can also be a bit messy to do Point In Time recoveries, with everything on the database you can to a nice PTR without any trouble, if there are things on the filesystem you must make sure both things get recovered to the same point in time, and it's rare to see filesystems backed up **permanently** while point in time recoveries in databases (atleast postgresql) are heavily documented and a good resource for some kind of applications. Third case; Imagine having one single directory holding a project but you run multiple instances of it over different databases (yes, doing tricky things to settings), having things on the filesystem makes things a bit harder. I'm +1 on providing database backed File and Image fields while heavily discouraging it's use on the documentation by providing clear examples of the 99% and 1% sides of the thing so users are aware of which storage method should they choose. Also +1 on the BinaryField, then atleast if one **really** needs to store things on DB it could be done :) Cheers, Marc On 3/26/07, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > > > On 3/26/07, Simon G. <[EMAIL PROTECTED]> wrote: > > So - if we do want a BinaryField we could use #2417 and make it > > suitable for larger binary stores (e.g. the VARBINARY used for MySQL > > has a max length of 255 bytes - perfect for the small bin. chunks > > wanted in #2417, but not for larger data), and then hook it up to > > Image/FileFields for #652. > > > > An alternate solution is to check in #2417 for small binary chunks, > > and then hold 652 back until we decide if we want a LargeBinaryField > > for large binary chunks suitable for file uploads. > > +1 on having a BinaryField. I'd actually like to see BinaryField be > the "larger" binary field, and have a SmallBinaryField alongside for > databases with those types. > > -1 on allowing File/ImageField to be stored in the database. That's > bad design 99% of the time, and will needlessly complicate file upload > code. > > Jacob > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Trac Timeline RSS feeds
Maybe you can't find it because it's "wontfix" :)) http://code.djangoproject.com/ticket/3326 On 3/29/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > > On Thu, 2007-03-29 at 21:05 +0800, Russell Keith-Magee wrote: > > Hi all, > > > > I just noticed that my RSS reader has stopped providing notifications > > of new and closed tickets. > > > > The problem appears to be caused by Django's RSS feed. For example, if > > you follow the RSS link at the bottom of the the default timeline page > > > > http://code.djangoproject.com/timeline > > > > you get an error complaining that: > > > > Ticket changes, Ticket details event provider (TicketModule) failed: > > > > AttributeError: 'NoneType' object has no attribute 'lower' > > > > RSS feeds that don't enable Ticket or TicketDetails appear to be fine. > > > > Looking back, I haven't actually had any Trac RSS updates since late > > January - which as I recall was about when the new Trac version was > > rolled out. > > > > Am I the only one seeing this problem? > > I thought there was a ticket open about this, but I can't seem to find > it now. The None used to be the priority (enhancement, "it's more > important than those other losers", normal, etc). So your timing > observations are consistent, although your attention to detail is > suspect (it's almost April already, dude!). :-) > > Sorry .. I hadn't realised this was a problem, since I use the updates > list these days. > > Malcolm > > > > > --~--~-~--~~~---~--~~ 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 group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: contrib proposal: django-values
Hi, On 4/8/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > * The name "values" is a bit too abstract -- it took me a while to > figure out exactly what this framework *does*. Maybe something like > "editable constants" or "model-specific options" would be more clear. Isn't a constant supposed to be **constant** ? ;) As those values are constant during server lifetime the name could be ok as it's clear. But maybe "modelsettings" would also sound ok unless it's inside a secondary namespace under the model in which case I'd go for "settings". # NEW > BlogEntry.constants.comment_limit On this "settings" sound nicer, for me. Integration with the admin interface would be also a nice thing! Anyway, it's a nice contrib I think almost everyone here has thought about something to handle model specific settings sometime and has large settings.py :) My 0.02, Marc --~--~-~--~~~---~--~~ 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 group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: European VAT registration number validation web service
Hi, Can you provide an URL for those who haven't found such service? (The spanish site for checking VAT's is like... s**t) Maybe the best place to hold this is on it's own project (code.google.com?) as a standalone application that users can checkout and put in INSTALLED_APPS. And when it fine and runs smoothly you can start discussion about including it in contrib. But if it's a SOAP service you'll most likely have external dependencies like a SOAP library and Django has a strict policy on not having external dependencies which would block that from getting in contrib :) Cheers, Marc. On 4/9/07, Frédéric Roland <[EMAIL PROTECTED]> wrote: > > > Hi, > > I found an official web service from the european union to validate VAT > registration numbers using SOAP. > > I will have to use that for my projects but I'd like to share it with > Django community. > > At this time I just started to play with it but I wanted to discuss how > to integrate that and what is the best place for such piece of code. > > Does it belong to Satchmo (eCommerce Framework based on Django), > Django Contrib, Localflavor/eu , ... ? > > Regards, > FR. > > > > > --~--~-~--~~~---~--~~ 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 group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: why index all SlugFields ?
Maybe because there is a high change that you will try to find rows based on this SlugField, so in common cases this INDEX will be nice. Also it's documented on http://www.djangoproject.com/documentation/model-api/#slugfield that this field has an implicit db_index=True, BUT you can always pass db_index=False if you do not want the index. Cheers, Marc On 4/13/07, xav4django <[EMAIL PROTECTED]> wrote: > > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > > Hi. > > When I use a SlugField in a model, > an index for this field is create in postgres. > > Why ? > > (config : django 0.96 / postgresql ) > > A++ Xav. > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.6 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFGH2rD4dg3EDuiPUcRAgmZAJ9qSsRXPZALQ51L0eX67EtAivxl3wCfQARH > /lI6QD8Rxn9MXU5LPfAvxiM= > =+Ssi > -END PGP SIGNATURE- > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [EMAIL PROTECTED] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: problems serving PDF file from view
On 5/21/07, Curtis <[EMAIL PROTECTED]> wrote: > An alternate solution: > > response = HttpResponse(pdf, "application/pdf") > response['Content-Disposition'] = 'attachment; filename=%s.pdf' % > filename > return response I use a similar approach to output PDF's on our intranet applications and I've got no complaints from users (which use IE although they know they **must not** use it). So I can assume that the Content-Disposition does the trick for me too. --~--~-~--~~~---~--~~ 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 group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
