Re: Using setuptools to make django-admin.py runnable on Windows (#21340)
On Sunday, November 24, 2013, Rémi Rampin wrote: > Hi developers, > > On Windows, running the django-admin.py tool is painful[1], because > .py scripts are not "executable". You might be able to run it using > the full path (if Python is the default handler for .py files, which > it really shouldn't be). Most probably you'll need to copy it to your > project directory and prefix it with "python " each time. There are a few things I do whenever I install python on windows. 1) first, make sure the .py extension is associated with python.exe. 2) add the python directory to my path. 3) add the scripts directory to my path. Then, when any packages install scripts (like django-admin.py), they ‘just work’. If you have multiple versions on python installed, then you can copy python.exe to pythonX.X.exe and make sure the defult version (the version associated with .py) is listed first on your path. The order of dirs on your path in key here, but you can list all the versions on your path. Then you can just type `python3.3` for example, and you'll get that version just like on unix systems. Of course, on unix based systems we all use virtualenv. There are a few windows virtualenv clones implemented for windows either as batch scripts or powershell scripts. You might want to look into those. Although, I haven't used them myself, so I can't speak to their completeness, reliability or usefulness. I always have git installed which comes with mssys and gives me a bash shell on windows - the best solution IMO (although virtualenv can be a little janky). Of course, this has entered django-users territory. And additional discussion about how to work around windows limitations should probably be discussed there. My point is that with a correctly configured system, this is not a problem on windows at all. If there are any changes to make to Django, perhaps the install docs could suggest the additions to the path I mention about as specific to installing on windows. -- Waylan Limberg -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAPubG6FCQraNF-%2BXdpxe2PO7yVfhk_weZ1KKyEtXnOMbMdWuvQ%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Remove download_url from setup.py
On Wed, Apr 3, 2013 at 7:46 PM, Russell Keith-Magee <russ...@keith-magee.com> wrote: > > On Wed, Apr 3, 2013 at 5:29 PM, Donald Stufft <don...@stufft.io> wrote: >> >> Just an idea. >> >> I think it might make sense to remove the download_url from setup.py. It >> has caused problems in the past >> (http://www.djangoproject.com/m/bad-installer.txt) and I don't think leaving >> it there adds much value. It does however add yet another place that a >> package releaser needs to update and makes `pip install Django` more >> fragile. >> >> The only major benefit I can see is providing a download link on PyPI, but >> given that there's a link right 40px or so to directly download from PyPI >> and a giant green download button further up the page I think this benefit >> is minimal. >> >> Thoughts? > > > Responding mostly because nobody else has, not because I have any firm > opinions on the topic. > > Logically, download_url strikes me as being bit odd - the package metadata, > which you obtain by downloading the package, contains the definition for > where to download the package. If the only purpose of the download_url > declaration is to set the link on PyPI, and pip will install from PyPI's > uploaded version of the package by preference, then I don't see any real > benefit in having the download link. > > However, I'll completely defer to anyone with more experience with the > internals of pip or setuptools/distribute/whateveritscalledthisweek. > > Russ %-) > > > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at http://groups.google.com/group/django-developers?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > If I'm not mistaken, the only part of the download url that changes with each release is the version number -- which is referenced only a few lines up. Why isn't the url dynamically created using version? That's what I do for my projects and the problem has gone way for me. -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: Relative path support for TEMPLATE_DIRS and others in settings.py (django ticket 694)
On Wed, Jan 2, 2013 at 1:36 AM, Victor Hooi <victorh...@gmail.com> wrote: > Hi, > > I may have missed it, but has been a fundamental shift in how Django looks > at projects versus applications, and how they should be laid out? > > I get the impression from Alex Gaynor's comments above that the concept of > "projects" is on it's way out? > > I know there was a change in project layout with Django 1.4, but I thought > things were still more or less the same as before - and projects were still > in. > > James Bennett wrote a blog post way back in 2006 about projects versus > applications: > > http://www.b-list.org/weblog/2006/sep/10/django-tips-laying-out-application/ > > I'm wondering if anybody from core is interested in updating that to reflect > current best practices, and the future direction of Django? > James updated his position on that almost exactly one year and one month later: http://www.b-list.org/weblog/2007/nov/09/projects/ My recollection is that the basic premise discussed in that post has been the general view of all core developers since that time (if not before). Search the archives of this list and you'll find various discussions about this - mostly proposals to update the tutorials to not use the "project" concept. Unfortunately, no one has stepped up to do the work. -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg -- 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: Django should not use `force_unicode(..., errors='replace')` when parsing POST data.
Tai, The idea behind errors='replace' is that any chars that cannot be properly decoded as unicode will be replaced with an acceptable unicode char (something like '?'). So, if you want to avoid crashing your program on bad input, this is the only acceptable approach and, I assume, why the current approach was taken way back when Django was converted to be all unicode all the time (internally). However, you bring up an interesting edge case. Apparently the replacement char is causing an invalid SQL statement to be generated - which breaks things in ugly ways. Probably not what we want. I see a couple approaches to this: 1) This could fall under the 'we need better error messages' umbrella and it should be easier to determine what the bad SQL statement was. 2) One could argue that errors='replace' is mangling user input and really an error should be returned to the user, allowing them to fix the error in the form and resubmit. I'm not sure which approach is the way to go here. However, forcing users to deal with encodings is generally a bad idea. Besides, you never can trust a browser to give you what it says it is giving you. In other words, the user may not be able to get the browser to send the correct encoding anyway. For those reasons I'm leaning toward #1. Of course, that begs the question: should Django be doing a better job escaping the data used to build the SQL statement? I guess we won't know unless we get the bad SQL statement. Which takes us back to #1. On Thu, Mar 29, 2012 at 5:42 AM, Tai Lee <real.hu...@mrmachine.net> wrote: > I've just created an essay *cough* I mean ticket about the way Django > silently mangles POST data that is incorrectly encoded, and how this can > send someone (like me) down the rabbit hole trying to debug it, thanks to > "current transaction aborted" database errors. > > This shouldn't normally happen, but it seems that I am unlucky and someone > somewhere is able to get their browser to submit POST data that is encoded > incorrectly. > > I don't want to repeat myself too much and end up writing another essay > here, so I'll just link to the ticket. Just wanted to post this here as well > because jezdez said it might be better suited to discussion on > django-developers. > > https://code.djangoproject.com/ticket/18004 > > Cheers. > Tai. > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/django-developers/-/ByLiu7RzHtIJ. > 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. -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg -- 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: auth.User refactor: reboot
On Tue, Mar 20, 2012 at 1:17 PM, Alex Ogier <alex.og...@gmail.com> wrote: >> Would something like the following alleviate that problem? >> >> class User(models.Model): >> if settings.USE_LONG_USER_FIELDS: >> username = models.CharField(max_length=255, unique=True, ...) >> else: >> username = models.CharField(max_length=30, unique=True, ...) >> ... > > Maybe, but there's a lot more than username length that people want to > change. Adding piecemeal settings to manage all this is putting wallpaper > over gaping holes. It's not a good long-term solution. > I have to agree, but I don't think it was intended to be a long-term solution. All the other proposals include an entire scheme for defining your own User model. But, aren't we eventually going to get the Apps re-factor (from past GSOC) anyway? Why would a scheme be implemented and released to only have another scheme which accomplishes the same thing be included within the next couple releases? Now we have two ways to configure which User model to use. Are we then going to depreciate the method introduced only a release or two before? Sure, the Apps re-factor could be abandoned for one of these other proposals, but the Apps re-factor benefits a lot more than the User model. However, if the Apps re-factor is still a go (when ready), then something like Nan's simple proposal above seems to me like a more sensible intermediate approach. Although I might suggest wrapping the entire model def in a single if statement rather than individual fields. That way, we get the immediate needs (longer email, etc) addressed with an interim solution but have only one path (Apps re-factor) to the broad solution down the road. -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg -- 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: Python 3 and you
pefully, by then, > others will have been running 3.x versions for years, and will have > long since worked out the kinks. > -- > Vernon > > -- > 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. > > -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg -- 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: Reshaping the "Contributing to Django" documentation
On Fri, May 20, 2011 at 5:31 AM, Julien Phalip <jpha...@gmail.com> wrote:
> Hi there,
>
> I've been working on reshaping the documentation about contributing to
> Django, in particular the rather dense historical page [1] and the
> excellent recently added how-to guide [2]. This documentation has sort
> of grown organically over the years and has become a bit difficult to
> read, so I tried to improve things a bit.
>
> I've submitted a patch in the designated ticket:
> http://code.djangoproject.com/ticket/15796
Awesome!
One nitpick thought. I expect that people reporting bugs will go to
the "bugs-and-features" page, which is fine. However, as is often the
case, when their ticket is marked "accepted" (or some other triage
stage) they often get confused about what that means (as we all know).
If they are only looking to get their one ticket fixed, I doubt they
will find on there own the explanations of the various stages now
under "triaging-tickets" ("I just want my one ticket fixed. I don't
have time to work on other peoples tickets, Why would I look there?").
Perhaps a link to those explanations should be added to the
"bugs-and-features" section? Just a thought.
--
\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg
--
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: Contributing Guide Request For Input
On Sat, Feb 19, 2011 at 6:49 PM, Gabriel Hurley <gab...@gmail.com> wrote: > I've added a patch to ticket #14401 based on the contributions people made > to the wiki. This is the final call for comments and review before it gets > officially added. > Thanks! > - Gabriel Hurley I realize the docs don't generally link to specific wiki pages, but following Russ's comment on another thread, it occurs to me that perhaps it would make sense to point people to the "Reports" page were they can find a number of useful trac queries to find tickets to work on. I get the impression a number of people don't realize this page exists then request that feature x be added to trac - only to have it pointed out that feature y accomplishes the same thing. These requests are often motivated by frustration that their pet ticket doesn't stand out in trac queries - when they're just not trying the right queries. Just a thought. On Tue, Feb 22, 2011 at 6:22 AM, Russell Keith-Magee <russ...@keith-magee.com> wrote: > > ... along with 313 other tickets. I've just added this query to the > "reports" page [1], which is itself linked from the > code.djangoproject.com home page. A range of other queries have always > been there, but there wasn't a simple "needs review" query. > > [1] http://code.djangoproject.com/wiki/Reports > -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg -- 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: Problem with ``Model.objects.create``
On Tue, Jan 4, 2011 at 10:54 AM, Yo-Yo Ma <baxterstock...@gmail.com> wrote: [snip] > The difference in Django is that instantiation doesn't represent > "creation". Saving to the database does, and since the ORM is an > abstraction of the database, you don't care that the DB is ok with an > empty VARCHAR value. You only care about your model's required value. > I'm suggesting this: > > class Person(Model): > name = CharField(max_length=50) > > >>>> Person() # Should work fine (assign attributes later, etc) >>>> Person.objects.create() > ... Should raise some kind of exception before allowing your model's > "INTEGRITY" to be violated. > No it shouldn't as no data validation has been run. Remember, like save(), create() does not run validation on the instance before writing to the db. As Russ pointed out, the actual data written to the db is valid as far as the db is concerned. Therefore, you get no errors. If you want to ensure the data is valid (as defined in your python code - not per the db) then you need to validate it in python *before* writing to the db. Therefore, don't use Person.objects.create() That being said, it does strike me as being a little odd that there is no way to validate your data when using create() or get_or_create(). In fact, the docs [1] describe both those methods as shortcuts. But if you're writing an app that always needs to validate your data, then you will never use those shortcuts which makes them rather useless. Of course, they existed long before (the current) model validation mechanism did, so I wonder if it would be reasonable to propose that they (at least optionally) be updated to run validation before saving. Or perhaps a warning in the docs that create() and get_or_create() do not run validation before writing to the db may be appropriate. [1]: http://docs.djangoproject.com/en/dev/ref/models/querysets/#create -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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: #11930 - submitting patches against djangoproject.com files?
On Sat, Dec 4, 2010 at 8:48 PM, Greg Turner <g...@interaction.net.au> wrote: > Hi, > I have a patch for #11930 that in to be applied against djangoproject.com's > base.css file. As far as I can see, base.css is not in the project > repository. Who is the custodian of this file, and the other CSS files? Is > there a reason it's not in the repo? If you go back through the wiki history you'll find this [1] on the startpage: > djangoproject.com: See the full code and templates for the Django-powered > portions of this site (e.g., everything except the ticket system). The Python > code is available under the BSD license, but the templates are copyrighted > by World Online and shouldn't be copied. I always assumed this was why the css wasn't included in the repo. But now that that note has been deleted (4 years ago - wow, time flies...) I don't know what the situation is. Will the community redux change this? [1]: http://code.djangoproject.com/wiki/WikiStart?action=diff=259 -- ---- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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: ANN: Improving our decision-making and committer process
On Wed, Sep 29, 2010 at 7:46 PM, Russell Keith-Magee <russ...@keith-magee.com> wrote: > On Thu, Sep 30, 2010 at 7:26 AM, Luke Plant <l.plant...@cantab.net> wrote: >> On Thu, 2010-09-30 at 01:32 +0400, Ivan Sagalaev wrote: >> >>> My suggestion is about this unfortunate ticket status -- 'Accepted'. >>> This now works as a sort of a dusty shelf: when anyone of the core team >>> looks at the patch and decides that there's nothing wrong with it he >>> puts it on that shelf where the ticket has all the chances to lie for >>> months or even years. And if the author of the patch tries from time to >>> time pitching it to get it into trunk he can easily fall into all sorts >>> of "not-a-good-times": conferences, feature freezes, hot discussions on >>> other topics etc. >>> >>> My proposal is simple: 'Accepted' status shouldn't exist. If the patch >>> is good it should be committed right away. If it's not there have to be >>> an explanation why it needs improvement or why it's going to be >>> wontfixed. Simple waiting doesn't really improve quality of the patch. >>> >>> What do you think? >> >> This doesn't account for these facts: >> >> 1) Accepted != Ready for checkin. >> 2) A lot of triage is done by people without commit access. >> >> Sometimes a ticket stays at 'Accepted' for a long time because it >> doesn't actually have anyone motivated enough to write even a patch, or >> tests etc, which means that it is de-facto low priority, and we >> shouldn't feel guilty about this kind. The ones in the 'Ready for >> checkin' queue are the ones that deserve to be checked in, and it >> currently has only 35 in it, compared to 1226 in 'Accepted'. > > This is an important stat -- but it glosses over the fact that 1226 > "accepted" tickets doesn't necessarily clarify how many of these have > viable patches -- or patches at all. > > Accepted tickets can be: > > * Purely accepted, indicating that someone has verified that the > problem exists, but not how to solve it > > * Accepted with a patch that is wrong in some way (e.g., fixing the > symptom, not the problem) > > * Accepted with a patch that is missing documentation or tests > > * Accepted with a valid patch, just awaiting review by someone else. > > A ticket in the first three conditions patently isn't ready for > checkin. A ticket in the last condition *may* be ready for checkin; we > ask for independent verification before it gets moved to RFC. So, in other words, accepted simply means that the ticket reports a valid bug or feature request that is considered worth fixing, but offers to indication as to the status of any patches for committing. Obviously, some seem to imply the later meaning into "Accepted" which could raise the question regarding whether it is named correctly (I say it is fine). But, more importantly, is there a place were each status is simply defined? Sure there is this: http://docs.djangoproject.com/en/dev/internals/contributing/#ticket-triage But that hardly makes clear exactly what "accepted" actually means. The text in that section is helpful to understanding the basic process, but if someone changes the status of my ticket, there's no definitive place to go and see exactly what that status means. In fact, in reading the list over the last few years, I have the impression that this is a problem that is repeated constantly. People don't understand what the various statuses mean and get frustrated when things do not happen as they expected. I think perhaps clearer documentation would help in this case. -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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: CSRF Middleware/SSL/Firefox 3.6.8 bug
On Fri, Aug 27, 2010 at 8:19 AM, Florian Apolloner <f.apollo...@gmail.com> wrote: > On Aug 27, 12:20 pm, Mat Clayton <m...@mixcloud.com> wrote: >> Any >> chance of getting some of the core dev's to think about removing additional >> SSL checks, as FF 3.6.8 is a pretty major browser to support and this is >> likely to only get worse as adoption increases. Is the additional security >> worth the trade off? > > I doubt that. It will only get worse if users use crappy addons; it's > not a firefox problem per se… > Well, at least your right that it is not (only) a firefox problem. Regardless of what browser I use or what settings I have set, here at work behind a firewall, all HTTP_REFERER headers are striped. If any app requires that header, I can't use it and there is nothing I can do about it, except wait till I get home. As I expect is the case with many, I just don't bother trying later if it didn't work the first time. -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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: Logging in Django
On Fri, May 28, 2010 at 4:39 PM, Mathieu Leduc-Hamel <marra...@gmail.com> wrote: > Oh cool! next time I'll check in the PEP list before... > > But I don't understand how it'll work with older python version, like > the current 2.6 branch ? Vinay has already stated that he is making his code (which is part of python 2.7) available to be distributed with Django so it will work on any version that Django works on. > > On Fri, May 28, 2010 at 4:33 PM, Vinay Sajip <vinay_sa...@yahoo.co.uk> wrote: >> >> On May 28, 9:16 pm, Mathieu Leduc-Hamel <marra...@gmail.com> wrote: >>> I would say, why not use the default python way to config logging, >>> handler and loggers ? it work fine and many projects are using it. >>> That way, we'll be able to use the same logging configuration for our >>> django projects and the different python library that we may use and >>> we the logging is implemented using the default python way. >>> >>> I don't exactly understand why it should be in the settings.py file ? >>> >> >> What's proposed to be in settings.py is the actual configuration, not >> the mechanism. The mechanism will be the new-in-Python-2.7-and-3.2 >> configuration via dictionaries (rather than via Python code or the ini- >> style confguration files - see PEP 391 for more details of the >> rationale behind dict-based configuration). >> >> Existing projects (like Django) can use the standalone dictconfig >> project on BitBucket to get the functionality which will be in Python >> 2.7 and 3.2, for use with earlier versions of Python. So really, >> Django is using the same mechanisms as Python for logging. It's good >> practice to put a shallow interface between the Django and Python >> logging configuration layers, to allow Django to specify sensible >> defaults. (There's an example of that in my Launchpad branch - the >> Django layer adds a default key in the dictionary to specify that by >> default, existing loggers are not disabled when configuration >> happens.) >> >> Logging of third-party libraries and django-apps (which make use of >> logging) in a Django site will be customisable through the logging >> configuration mechanism being proposed. All of Django, your apps and >> their dependencies, third-party apps and their dependencies - if any >> of them already use logging in the conventional way, you will be able >> to modify their logging behaviour through this mechanism. >> >> Regards, >> >> Vinay Sajip >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django developers" group. >> To post to this group, send email to django-develop...@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. >> >> > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@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. > > -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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: Django documentation for newer users
On Fri, Mar 5, 2010 at 11:35 AM, stherrien <shawntherr...@gmail.com> wrote: > What I'm suggesting is that we setup something to allow everyone to > improve the docs with help from the core django group. I think this > would be very helpful to everyone. if one of the core group would like > to help us get setup to do this it would be great. maybe if they setup > a repository with the current online docs online so we can add updates > as we do with django itself. So everyone else already answered your concern above, Anyway, regarding your first question, see the "Global Module Index". It contains full import paths to each module and links to the docs for that module wherever they may be (howtos, ref, etc). But yeah, the individual docs should probably include import paths as well. http://docs.djangoproject.com/en/1.1/modindex/ As far as general organization goes, the "Table of Contents" is more helpful imo. I see the front page as more of a highlight of interesting things intended for those taking their first look at the project, but the table of contents gives a much better overview of how everything is actually organized by document section etc. The urls even match the pattern used here, and the "next" and "previous" links follow the order of documents here. http://docs.djangoproject.com/en/1.1/contents/ Both are linked to from every doc page in the sidebar to the right (In the "Browse" section). > > On Mar 5, 11:20 am, stherrien <shawntherr...@gmail.com> wrote: >> Exactly my point docs need to be more organization to be constructive >> for django users. >> >> On Mar 5, 11:05 am, Jared Forsyth <ja...@jaredforsyth.com> wrote: >> >> > To be honest I am quicker to just go to django's source code rather than >> > the >> > docs, as often I can find what I need there, and the docs aren't (imo) >> > organized enough to provide much of an advantage. >> >> > On Fri, Mar 5, 2010 at 8:46 AM, stherrien <shawntherr...@gmail.com> wrote: >> > > Hi all, >> >> > > I have a request that django documentation show the import locations >> > > for classes like in other well formed docs found on the web showing >> > > the users where the classes can be found for import. I think this >> > > would be handy for newer users and experienced users finding something >> > > new. Documentation on the site is different from page to page. Take >> > > for instance the file object doc page in django doesn't tell the user >> > > where this can be imported which requires you to dig into the python >> > > help pages to try and find it. which is "from django.core.files.base >> > > import File". it would be nice to show this consistently across the >> > > site. I would be happy to help make this happen. >> >> > > -shawn >> >> > > -- >> > > You received this message because you are subscribed to the Google Groups >> > > "Django developers" group. >> > > To post to this group, send email to django-develop...@googlegroups.com. >> > > To unsubscribe from this group, send email to >> > > django-developers+unsubscr...@googlegroups.com<django-developers%2bunsubscr...@googlegroups.com> >> > > . >> > > For more options, visit this group at >> > >http://groups.google.com/group/django-developers?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@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. > > -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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: Sessions: does set_expiry has a max value?
On Thu, Jan 14, 2010 at 10:50 AM, Pablo López <plval...@gmail.com> wrote: > I *did* search in this group... not in others :-) > > Thank you anyway > Ah, well for future reference, django-dev is specifically for the development *of* django. For help with using django you should always go to django-users. -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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: Model validation incompatibility with existing Django idioms
I've only scanned the docs the other day and haven't actually used the
new model validation stuff, so my impressions may be a little off,
but...
On Wed, Jan 6, 2010 at 2:54 PM, Joseph Kocherhans <jkocherh...@gmail.com> wrote:
> On Wed, Jan 6, 2010 at 12:49 PM, Simon Willison <si...@simonwillison.net>
> wrote:
>> A couple of related tickets filed today about model validation:
>>
>> http://code.djangoproject.com/ticket/12513
>> http://code.djangoproject.com/ticket/12521
>>
>> The first one describes the issue best - the new model validation code
>> breaks the following common Django convention:
>>
>> form = SecretQuestionForm( {"secret_question":"foo", "answer":"bar"} )
>> if form.is_valid():
>> p = form.save(commit=False)
>> p.user = request.user
>> p.primary_contact = somecontact
>> p.save()
>>
My initial reaction to this snippet was to wonder why the model was
not being validated after the additional data was added/altered.
Shouldn't you be doing:
form = SecretQuestionForm( {"secret_question":"foo", "answer":"bar"} )
if form.is_valid():
p = form.save(commit=False)
p.user = request.user
p.primary_contact = somecontact
if p.full_validate():# <<<<< note this line
p.save()
[snip]
> Once again, that means ModelForm won't really validate your model,
> only your form. form.save() might still throw a database error just
> like before the merge. We can slap a big warning in the ModelForm docs
> though.
Well, that's why I expected the extra validation check on the model
itself. I understand the desire to have the ModelForm actually
validate the model and work in one step, but sometimes we need the
other way too (as you acknowledge).
> One (probably unhelpful) way to make ModelForm validate your whole
> model would be to add a Meta flag to ModelForm:
>
> class UserForm(ModelForm):
> class Meta:
> # Defaults to False
> validate_model = True
Well, what if one view uses that ModelForm one way and another view
uses the same ModelForm the other way? What about
``form.is_valid(validate_model=True)``?
--
\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@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: Changing the Backend for Error Emails
On Mon, Dec 21, 2009 at 3:25 PM, Mat Clayton <m...@wakari.co.uk> wrote: > Hey all, > > Now that Email Backend's have landed, and we finally got round to rolling it > out in to production, I discovered small niggle with our deployment. > Currently we use an external email provider to deliver email, and the > backends has allowed us to do this fantastically. However when an error > occurs in our main site, which happens in production occasionally :( We very > rapidly eat up all our credits with error emails, one proposed solution > would be to be able to configure an independent backend for crash emails. > Having talked to a few startups using similar cloud technology this seems a > fairly common situation. > > As far as I can could spot, there is no way to isolate the production and > error emails, has anyone else tried this? Also is any chance this might get > into core, if we propose a patch? > I believe this may fall under the logging proposal [1] which has been approved for 1.2. Although, I don't know whether it will be ready or not. Regardless, I would think providing work on this would be the best way to get a solution into core. [1]: http://code.djangoproject.com/wiki/LoggingProposal -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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: What do people think about the get_absolute_url proposal?
On Tue, Dec 15, 2009 at 3:23 PM, Michael Richardson <richardson.michae...@gmail.com> wrote: > > > On Dec 15, 4:35 am, Ivan Sagalaev <man...@softwaremaniacs.org> wrote: >> Mike Malone wrote: >> > Well, not really. It's making a way to generate a URL based on the >> > request object global. I agree that it's not ideal, but it's not the >> > same as just making the request object global. >> >> My main gripe is not globalness of a request object itself (I agree with >> "not ideal" here) but the very idea of constructing a URL from request. >> >> > You wouldn't have any trouble in a standalone script unless you tried >> > to call the get_absolute_url() function. >> >> But I kinda want that. Here's two more usecases where using current >> request for creating URLs is broken: >> [snip] > > With these cases (the former more so than the latter) you are creating > URLs for an entirely separate project, not your own, essentially. You > aren't creating URLs for that particular project, which is where a > request-aware URL creation resource is intensely useful. > > We pass around request objects all over the place in order to get this > functionality. request.build_absolute_uri is great, but it does > require that request object and passing it around - which sucks. > > I am 100% with Mike on this. > The way i see it (which may be wrong), this is not a proposal to make the request object global or replace/refactor the contrib.site app. In fact, some of the use cases mentioned strike me as things that would require overriding the default get_absolute_url method anyway. It seems to me like everyone is arguing over things outside the scope of this proposal. Sure, a better solution than the current site app would be nice, but that's not on the table right now. So given the existing framework, and knowing you can override the default very easily, is seems that Simon's proposal fits the bill. I was going to suggest that the method could accept a request object as an optional argument and fall back to using the site app if no request is provided. But if you have the request, you can get the domain yourself and call get_url on the model. Besides, I'm not really sure how that would translate to use from within the template system. But wouldn't that really come under a future proposal for a better/replacement site app? Or should the current proposal be set aside until that is solved first? Personally, I'd prefer this proposal to land now and hope for a better solution to the limitations of the site app later. That way the API is set and I can start using it. If the stuff behind the scenes changes later that's fine. -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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: Session/cookie based messages (#4604)
On Thu, Dec 3, 2009 at 10:23 AM, Luke Plant <l.plant...@cantab.net> wrote: > On Thursday 03 December 2009 14:18:10 Waylan Limberg wrote: > >> Looking though this patch I couldn't help but notice the new >> get_messages function. What if a project has neither the >> MessageMiddleware nor the contrib.auth app enabled? Sure a reusable >> app could catch the error, but that error will change once all >> support for user.messages are removed in 1.4. Shouldn't the call >> to user.get_and_delete_messages be wrapped in a check that >> request.user exists like the new add_message function does? > > It is - the inline 'get_user()' function does effectively just that: > Right. As Tobias pointed out, the get_and_delete_messages on AnonymousUser returns an empty list. That was the part I missed. Thanks for clearing that up. -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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: Session/cookie based messages (#4604)
On Thu, Dec 3, 2009 at 1:38 AM, Tobias McNulty <tob...@caktusgroup.com> wrote: > Latest patch, including fail_silently, is up for review: > > http://code.djangoproject.com/attachment/ticket/4604/django-contrib-messages-e4da706e1152.diff > Looking though this patch I couldn't help but notice the new get_messages function. What if a project has neither the MessageMiddleware nor the contrib.auth app enabled? Sure a reusable app could catch the error, but that error will change once all support for user.messages are removed in 1.4. Shouldn't the call to user.get_and_delete_messages be wrapped in a check that request.user exists like the new add_message function does? -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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: Enhanced debug output colors: django code is green, user code is red.
On Tue, Nov 3, 2009 at 10:57 AM, Tobias McNulty <tob...@caktusgroup.com> wrote: > On Tue, Nov 3, 2009 at 8:31 AM, Yuri Baburov <burc...@gmail.com> wrote: >> >> On Tue, Nov 3, 2009 at 9:27 AM, Tobias McNulty <tob...@caktusgroup.com> >> wrote: >> > I'm not a big fan of the red/green either. They imply that Django code >> > is >> > "bad" and user code is "good". >> The opposite, in fact. >> Django code is green, "good", user code is red, "untrusted". > > Whoops, my bad. I still think there are concerns about the colors, however. > They imply that something is wrong with the red code, which might not be > the case. There is also the concern of whether or not these colors are > distinguishable to colorblind folks. I think what you need to try to do is > make the user code draw your attention first, and the Django code draw your > attention second. I don't think the current color scheme does that in an > effective way. > Tobias > Actually, they current colors look an awful lot like diffs as they are displayed by on various sites (green lines added, red lines removed). In fact, at first glance, that's what I thought I was looking at. One more reason to change the colors I suppose. -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg --~--~-~--~~~---~--~~ 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: Bug in django\template\__init__.py ??
On Thu, Oct 29, 2009 at 11:07 AM, Waylan Limberg <way...@gmail.com> wrote: > On Thu, Oct 29, 2009 at 10:37 AM, Johan <djjord...@gmail.com> wrote: >> >> I am >> wanting to use the template engine outside the context of a django >> project so I would not have a settings file anywhere on my path. > > This is documented here: > > http://docs.djangoproject.com/en/dev/topics/settings/#using-settings-without-setting-django-settings-module > >> I am >> assuming that the code works in a project context since the project >> would import settings and this 'broken' import would just fail >> silently > > Pay special attention to the last section (Either configure() or > DJANGO_SETTINGS_MODULE is required) of the docs linked above. As > Russell mentioned settings is lazy so you don't get an import error > but you will get a RuntimeError if settings have not been configured > properly when you actually try to use your templates. Doh' sorry that is wrong. Actually you do get an ImportError - but not until the settings are actually accessed (being lazy and all). The RuntimeError is if you call settings.configure() more than once. Thus, the importance of reading that section carefully. :-D -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg --~--~-~--~~~---~--~~ 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: Bug in django\template\__init__.py ??
On Thu, Oct 29, 2009 at 10:37 AM, Johan <djjord...@gmail.com> wrote: > > I am > wanting to use the template engine outside the context of a django > project so I would not have a settings file anywhere on my path. This is documented here: http://docs.djangoproject.com/en/dev/topics/settings/#using-settings-without-setting-django-settings-module > I am > assuming that the code works in a project context since the project > would import settings and this 'broken' import would just fail > silently Pay special attention to the last section (Either configure() or DJANGO_SETTINGS_MODULE is required) of the docs linked above. As Russell mentioned settings is lazy so you don't get an import error but you will get a RuntimeError if settings have not been configured properly when you actually try to use your templates. -- ---- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg --~--~-~--~~~---~--~~ 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: Status of the #6904 ticket (case insensitive sort in dictsort)
On Thu, Oct 15, 2009 at 7:44 AM, Douglas Soares de Andrade <dsandr...@gmail.com> wrote: > > Hi all, > > What is the status of the following ticket ? > > http://code.djangoproject.com/ticket/6904 > Well, the "Triage Stage" is currently set at "Design decision needed" which means that it's waiting for a core dev to review the ticket and either accept or reject it. > I just had this issue in Django 1.1 and i totally agree with mathwizard > said. I don't - and I just posted a comment to the ticket explaining why. If you (or anyone) wants case-insensitive sorting, just create your own custom filter that does just that. You could even copy the built-in filter to your own project/app and use it with a one or two line change. -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg --~--~-~--~~~---~--~~ 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: Adding an option to re-test only failed tests
On Tue, Sep 29, 2009 at 1:58 PM, Simon Willison <si...@simonwillison.net> wrote: > > On Sep 29, 5:03 pm, Rob Madole <robmad...@gmail.com> wrote: >> I've been using nose for our tests, and one of the features that I >> really like is the ability to run the tests again but filter only the >> ones that caused a problem. >> >> I'm thinking it would look something like this >> >> ./manage.py test --failed >> >> Does this sound worthwhile to anybody? > > I don't understand how this works - does it persist some indication of > which tests failed somewhere? If so, where? > My recollection is yes, nose persists which tests passed/failed for the previous run, but I don't recall where. Personally, I've never used this (except to see how it works in nose) because I'm always concerned that while a recent change may fix a failing test, it could cause some other test to fail that previously passed. So I'm going to run the whole test suite anyway - or at least all the tests for that module, etc. Alex suggestion of --failfast seems like a much more useful way to shorten test runs. -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg --~--~-~--~~~---~--~~ 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: Proposal for 1.2: built-in logging with django.core.log
On Tue, Sep 29, 2009 at 4:36 AM, Vinay Sajip <vinay_sa...@yahoo.co.uk> wrote:
>
>
>
> On Sep 17, 9:25 am, Simon Willison <si...@simonwillison.net> wrote:
>> Problems and challenges
>> ===
>>
>> 1. The Python logging module isn't very nicely designed - its Java
>> heritage shines through, and things like logging.basicConfig behave in
>> unintuitive ways (if you call basicConfig twice the second call fails
>> silently but has no effect). This is why I suggest wrapping it in our
>> own higher level interface.
>
> Simon, I'm the author of Python's logging package. Sorry for the delay
> in replying, I've been away from this list awhile. I think the "Java
> heritage shines through" is just FUD. basicConfig's behaviour is fully
> documented here:
>
> http://docs.python.org/library/logging.html#logging.basicConfig
>
> Including the fact that it sometimes (by design) has no effect.
>
> There are a lot of people for whom logging just means writing to a
> file, and that's why they have difficulty understanding why logging is
> designed as it is. I would suggest you take a quick look at
>
> http://plumberjack.blogspot.com/2009/09/python-logging-101.html
>
> and then tell me why you think Python logging isn't well designed for
> its purpose. You can do basic logging with two lines of setup (one
> line if you ignore the import):
>
> import logging
> logging.basicConfig(level=logging.DEBUG,filename='/path/to/my/log',
> format='%(asctime)s %(message)s')
>
> and then
>
> logging.getLogger(__name__).debug("Just checking this works")
>
> Not too sure where the Java heritage is there, or where the hard part
> is.
>
The hard part is that basicConfig only works like that back to Python
2.4 yet Django supports 2.3. When I added logging to Python-Markdown,
this was the hardest part. Figuring out how to configure logging so
that it works in 2.3 as well. The documentation is not exactly helpful
in that regard.
In fact, it was for this very reason that we added our own wrapper
around logging. It didn't seem reasonable for our users to go through
the same pain that we did. Sure we got a few things wrong at first,
but with the help of a few people in the community we worked those out
and our wrapper seems to work ok now. Yes - ok - I get the sense it
could be better.
Ever since then, any mention of logging leaves a bad taste in my
mouth. Perhaps if I was working only in 2.6 or such, this wouldn't be
an issue, but we have promised support back to 2.3.
Of course, it is possible that I'm missing something obvious.
--
\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg
--~--~-~--~~~---~--~~
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: What is the status of auto_now and auto_now_add?
Well, both auto_now and auto_now_add are fully documented [1] and part of the official releases since 1.0. And I note that the docs specifically mention how auto_now_add behaves in the admin (remember the newforms-admin was merged before 1.0 was released). That being the case the devs have committed to long term support. At least, as I understand it, if they were to be removed it would happen only after depreciation warnings etc through multiple releases before they would be dropped completely. Of course, I can't speak for what the core dev's official opinion is of them, but they are all in the middle of DjangoCon this week and generally not checking their email. Thus the quiet on the lists. You'll have to wait a few days for more. Regardless, I think you may be dwelling on some old, outdated info. [1]: http://docs.djangoproject.com/en/dev/ref/models/fields/#django.db.models.DateField -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg --~--~-~--~~~---~--~~ 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: Replacing get_absolute_url, I am against it
On Thu, Sep 10, 2009 at 11:23 AM, drozzy <dro...@gmail.com> wrote: > > Just read the "Replacing get_absolute_url proposal": > http://code.djangoproject.com/wiki/ReplacingGetAbsoluteUrl > > and personally I think adding two functions get_url_path and get_url > is a lot more confusing. One can never remember which one gets the > Absolute url and which one gets the Relative url. Easy, get_url returns the entire url while get_url_path returns only the "path" portion of a url. One could imagine feature creep resulting in 'get_url_protocol', 'get_url_domain' etc. I wouldn't actually recommend those be added, but by thinking about it that way, it trains my brain how to parse the proposed function names. > If it is going to be done I propose adding another function, and thus > have two possible functions on the model: > get_relative_url > get_absolute_url That seems like the obvious solution except that get_absolute_url currently returns a url path. Oops! With the change, everyone's existing code will suddenly break. The only way to fix it is to depreciate get_absolute_url and create new names for the replacements. Oh, and this reference to relative urls. Relative to what? The site root? The app root? The currently viewed page? "get_relative_url" is probably not what you actually want. "get_url_path" is. Of course, this all really a bikeshed issue. Generally, 'he who builds the shed gets to paint it.' -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg --~--~-~--~~~---~--~~ 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: Suggestion: Better way to extend user table
On Thu, Aug 20, 2009 at 9:22 AM, Rob Hudson<treborhud...@gmail.com> wrote: > > Take a look at ticket 3011: > http://code.djangoproject.com/ticket/3011 > I don't know, but that seems a little too "magic" for me. The User model appears to be imported from somewhere else than it actually is. Isn't this what the core devs don't want to do? Anyway, you do realize there is already a set precedence in Django for how to do this sort of thing. See custom comments [1] and get_model(). It seems more likely something like that would actually get in. [1]: http://docs.djangoproject.com/en/dev/ref/contrib/comments/custom/#django.contrib.comments.get_model -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg --~--~-~--~~~---~--~~ 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: 1.2 Proposal: Finish contrib.comments Moderation
Sigh! I guess I sent this out a little prematurely. On Wed, Aug 12, 2009 at 3:50 PM, Waylan Limberg<way...@gmail.com> wrote: [snip] > > 2. Implement ticket #11625 -- Add admin actions to the comments admin. > [snip] > > 3. Using a proxy model and custom manager, create a second admin > instance which only lists comments in moderation and offer the > same admin actions as in 2 above. > [snip] > > 4. Incorporate the existing views into the admin by extending the > base get_urls() method to point to them. > [snip] > > The other piece that is missing IMO is a way to make those admin actions > available on an individual comment. Some times, one actually needs to > read the comment to know if it is spam or not. [snip] Actually, implementing option 4 would accomplish this. The fact is, the existing (undocumented) list view is not needed in the admin as option 2 or 3 would fill that need. Therefore, the only views that we would need to map to admin urls would be the `approve` and `remove` views. We just need a custom template for the add/change view which adds the respective buttons next to delete, save, etc. The common code between the admin actions and the approve & remove views could be factored out into a couple utility functions which, along with the proxy model with custom manager (from option 2) would provide enough for some one to implement there own non-admin solution. That is, if that is even a goal. So, the question is, whether we go with option 2 or 3 (and add option 4), do we want to remove the existing undocumented views and templates for listing and acting on the moderation queue? Or do we want to leave them in (and undocumented) as an example of how it could be done? Of course, I'm assuming we are not concerned about backward compatibility as none of this has yet to be documented. However, if might be nice to depreciate it first for those who dug into the code and are using it. -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
1.2 Proposal: Finish contrib.comments Moderation
Currently, contrib.comments has a very useful (and customizable) mechanism for putting questionable comments into moderation. However, approving/ rejecting comments afterword is still unfinished. There is a set of urls/views/templates which provide a decent way to do this, but it is currently undocumented and therefore (as I understand it) still subject to change. There are a number of different ways this could be addressed: 1. Document the existing code currently available. Pros: May potentially work without admin app (untested by myself). Cons: Requires way too much setup by the user IMO and although the templates look like admin pages, the urls clearly indicate that it is not part of the admin. 2. Implement ticket #11625 -- Add admin actions to the comments admin. Pros: Simple - least amount of work. Cons: Getting a list of comments in moderation is unintuitive (requires user to select the "is_public==False" list filter on the admin page). 3. Using a proxy model and custom manager, create a second admin instance which only lists comments in moderation and offer the same admin actions as in 2 above. Pros: Simple and more intuitive for the end user. Cons: Moderation is on a separate admin page. I haven't actually tested that this works. 4. Incorporate the existing views into the admin by extending the base get_urls() method to point to them. Pros: Uses the existing Code. The new views will actually use admin urls. The views could potentially still be used outside an admin app. Cons: Will require some way (custom templates perhaps) to include links to the new admin views. Interestingly, options 2, 3, & 4 all rely on new features added in 1.1, which may explain why they were not implemented before now. Personally, I'm in favor of 2 (it is my ticket and patch), although 3 may be a nice addition which could always be added later. That said, I do see the attractiveness of 4, although I am unsure of the amout of code we can reuse or the amount of work involved in that option. Any input on these? The other piece that is missing IMO is a way to make those admin actions available on an individual comment. Some times, one actually needs to read the comment to know if it is spam or not. But, reading the comment, then going back to the list view, selecting the appropriate comment from the list and then selecting the admin action seems like a little much. True, the user could set `is_removed` to `True` and save or delete the comment, but then the appropriate moderation signal is never sent and any custom (perhaps trainable) moderation system has no way of getting feedback. Of course, there is no way of doing this last bit now with the existing undocumented code, and it should probably be a separate proposal for a general admin feature, but I included it here in relation to comments for completeness sake. -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg --~--~-~--~~~---~--~~ 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: OneToManyField?
On Wed, Jul 22, 2009 at 4:05 AM, dan<danstad...@gmail.com> wrote: > [snip] > > I think what the original question is asking is, can the definition of > Parent have a "one-to-many" which points to Child? At the database > level there would be no difference: Child would still have the foreign > key field. > Right, and what Russ is saying is that the way models are currently loaded that would break unless you could absolutely guarantee that Parent always loaded before Child (or is it the other way?). As there is currently no way to make that guarantee, Django will not support the option at all. However, if, at some point in the future the ability to make that guarantee becomes available, then they will reconsider this feature. Until then, the way to address this is by improving Forms. -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg --~--~-~--~~~---~--~~ 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: append_slash alternative: remove_slash
On Wed, Jun 17, 2009 at 6:19 PM, donquixote<klabaut...@googlemail.com> wrote: > > On 17 Jun., 03:14, Graham Dumpleton <graham.dumple...@gmail.com> > wrote: >> On Jun 17, 10:04 am, donquixote <klabaut...@googlemail.com> wrote: >> >> > I would still be interested to read some arguments in favour of the >> > trailing slash. From a user perspective, it seems that without is >> > better. >> >> The big issue with trailing slash, is that you should use a trailing >> slash on a URL which represents an internal node in the URL tree which >> can have sub nodes and which is intended to represent some >> conglomerated view or directory listing onto those sub nodes. One can >> probably leave it off where URL represents a leaf node of the tree, >> just not the internal nodes. > > I don't think this fits the mental models people usually have of > websites. "This is a listing with child nodes" vs "This is a single > node." And even then, a single node can have sub-pages - for instance, > a page showing a user profile can have a subpage user/graham/blog. > > It's better to see it this way: Every page is an individual piece of > content for itself, and still every page can have subpages. > > A directory, on the other hand, can have subpages, but is not that > interesting for itself. Which we don't want to happen - we want all > our pages to be interesting! > Think back to the days when all web pages were a collection of static html files. Every directory within the server root had an index page (usually index.html). That page could be found at any of the three urls: `/path/to/dir`, `/path/to/dir/`, or `/path/to/dir/index.html`. Obviously, not optimal. However, the recommendation was that the site author always link to such pages consistently so that only one of those urls would ever be used publicly. I think that's the "mental model" Graham is talking about. As crazy as it sound, I recall seeing someone who didn't like file extensions set up their site so that every single page was an index page -- that is every single page was in it's own directory, which may or may not have children. To easily tell if a page had children or not, a slash was always used by the author for pages that did and not for pages that did not. Granted, the author and a few other dev types who he told about it are probably the only people who ever noticed, but it made him feel better. And that's really what this whole discussion is all about - making the developer who chooses the url scheme feel good about it. The fact is, whether the url I'm told over the phone should have a slash at the end or not doesn't matter - it will lead me to the page I want whether I type that ending slash or not (at least through a redirect). Should Django support either choice by the site dev? Perhaps. Does it really matter though? Not really. Which is probably why the core devs have been completely silent on this issue. If it hasn't happened already, file a bug as a "nice-to-have" feature request, come up with the least invasive patch and wait for Django to get out of feature freeze status (it is currently for the upcoming 1.1 release - bug fixes only right now) and bring it up during the next proposal phase if it matters that much to you. I don't mean to be dismissive of something some of you obvious care a lot about, but this discussion has gone on endlessly and hasn't really gone anywhere. And for the record, no, I'm not anyone important and don't have any inside info on the core devs opinion, but I've seen their silence before, and given Django current state (feature freeze), well... there minds are focused elsewhere. -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg --~--~-~--~~~---~--~~ 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: some observations on form features
On Wed, Apr 29, 2009 at 10:33 AM, ken keller <klr...@gmail.com> wrote: > > form.as_table is appealing but seems limited: Ken, the consensus seems to be that the form.as_* methods are for quick prototyping and not really meant for fine grained control. If you want more control over the output of the form, build it up in the template yourself from the various parts. Remember, you can loop through the fields in your template and render each separately. > * Many forms need field groups to be highlighted. > * Sometimes multiple fields need to be in the same row (e.g., first & > last name). > * The use of for errorlist can cause layout problems. > > Sometimes I need to add non-bound fields to a bound form such as a CAPTCHA. > > Are these problems worth solving? As these are all solvable now simply by ignoring the as_* methods, I believe the answer is no. Of course, I'm not a core dev, so I could be wrong, but my recollection of previous similar requests would seem to indicate otherwise. -- ---- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg --~--~-~--~~~---~--~~ 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: Summer of Code 2009
On Mon, Apr 20, 2009 at 4:04 PM, Jacob Kaplan-Moss <ja...@jacobian.org> wrote: > > We received about twenty proposals, but there was broad agreement > among the mentors that six in particular really stood out. > And yet I only count 5. Looks like you missed: Alexander Gaynor, "Multiple Database Support in Django" Mentor: Russell Keith-Magee In any event, congrats to all. -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg --~--~-~--~~~---~--~~ 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: Why does get_profile exist?
On Mon, Apr 13, 2009 at 4:30 PM, Glenn Maynard <glennfmayn...@gmail.com> wrote: > > Why do get_profile() and AUTH_PROFILE_MODULE exist, instead of just > declaring the Profile to User relationship as OneToOne and using the > auto-generated User.profile relationship? > Well, prior to qs-refactor (just before 1.0), OneToOnes had some issues and the documentation included very strong warnings that they should not be used at all. That being the case, as that time you found almost no use of OneToOne relationships within the community, let alone Django itself. So, at least in part, the answer is for historical reasons. See other reasons discussed elsewhere [1]. Particularly the last section of that post. [1]: http://www.b-list.org/weblog/2006/jun/06/django-tips-extending-user-model/ -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg --~--~-~--~~~---~--~~ 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: django <--> wsgi
On Tue, Mar 31, 2009 at 2:21 PM, Travis Parker <travis.par...@gmail.com> wrote: > [snip] > > 2. settings (views -> apps, dj middleware -> wsgi middleware) > i don't have nearly as nice a proposal for dealing with this. there > are a lot of django views and middleware out there that would be nice > to have usable as wsgi components but which require > django.conf.settings to work. if they are going to go into a wsgi > environment though, it seems a little strange to require a > DJANGO_SETTINGS_MODULE environment variable and a django-style > settings.py. i don't have any great ideas. open for suggestions. > [snip] It seems to be a little known/remembered fact that DJANGO_SETTINGS_MODULE and settings.py are not required to use django code that requires settings. Settings can actually be configured manually within python code calling settings.configure(). This way, you only actually set settings that you need. In fact, outside of the strict situation of a django project, it is the only way I deal with settings when using parts of django. See here for details: http://www.djangobook.com/en/1.0/appendixE/#cn57 However, the trick is that you can only call settings.configure() once and it's possible that multiple middleware will need settings. On top of that, the user may use some of those middlewhere and not others and/or change the order of the middlewhere. You'll need some way to work out whether configure has been called for each middlewhere and only call it the first time. Not fun, but it's got to be better than dealing with DJANGO_SETTINGS_MODULE and settings.py. -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg --~--~-~--~~~---~--~~ 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: Template filters problem introduced in rev 10118
On Tue, Mar 24, 2009 at 9:57 AM, eXt <restless.be...@gmail.com> wrote: > [SNIP] > > This worked before 10118. Starting from 10118 all filter's parameters > are passed as strings (why?) so it breaks my code causing: > > TypeError: slice indices must be integers or None or have an __index__ > method > > It's obvious because I expect "ln" to be an int in this example. > Well, you are using the `stringfilter` decorator, which, according to the docs [1], "will convert an object to its string value before being passed to your function." So, I would say if it worked before, that was a bug. Now it's fixed. You'll have to edit your tag to coerce the string to an integer. Not to hard to do, but a good idea even if it's not necessary. [1]: http://docs.djangoproject.com/en/dev/howto/custom-template-tags/#template-filters-that-expect-strings -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg --~--~-~--~~~---~--~~ 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: #9282 (comment moderation features) and Akismet removal
On Mon, Mar 23, 2009 at 1:23 PM, Eric Florenzano <flo...@gmail.com> wrote:
>
>> James, this is something that can be added later. This is progressive
>> enhancement of the functionality and *if* (not a given) we take what's
>> in #9282 now without blocking on every feature that might be possible or
>> popular, it won't be a shame. It isn't a half-baked implementation, it's
>> just leaving the door open for more additions in the future.
>
> I don't really understand this argument. Maybe I'm not parsing it
> correctly, but I read this as "Your implementation is good, but let's
> not add it now so that we can add it later", which seems a bit
> strange.
>
I'm a little confused about the disagreement here. Perhaps I'm wrong,
but I get the sense that people are asking for two different things.
1. It seems that some are expecting the base CommentModerator to use
Akismet by default. That is a bad idea IMO. The patch as-is is correct
here.
2. While others are expecting a subclass of CommentModerator that uses Akismet.
Whether that happens or not, I don't really care. But whether it
happens when this patch is committed or later shouldn't really effect
whether this patch is ready or not.
Btw, while we're on the subject, this (hopefully option 2 above) would
make implementing Django-Spambayes [1] (a comment filter built on top
of the SpamBayes email filter) easier - with one exception. SpamBayes
is a training system. For the system to work, it needs to be trained
with both "ham" and "spam". Then there is the third state "unsure"
which goes into moderation. The user should then be able to move a
comment between any of those 3 states (retraining the system with each
move). Having only a two state system ("ham" and "unsure") with the
"spam" automatically deleted makes this kind of hard. I realize I
should be able to alter that in a subclass, but it would be nice if
the base class at least considered that a subclass might want to act
that way.
Perhaps an attribute on the class called "delete_spam" (or whatever
color you want to paint that bikeshed) which turned on or off
automatic deleting of unwanted messages. So setting "delete_spam" to
True would get the same behavior we have now while setting it to False
would leave the message in the db, set "is_public" to False, but also
recognize that it has already been moderated (I believe
`comment.is_removed = True` does that).
[1]: http://code.google.com/p/django-spambayes/
--
\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg
--~--~-~--~~~---~--~~
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: MarkupField
James, you nailed it. This is exactly what we need. Well, with one
minor oversight:
On Tue, Feb 24, 2009 at 2:33 AM, James Bennett <ubernost...@gmail.com> wrote:
>
[snip]
> How to handle markup override
> =
>
> That is, also, the solution to the problem of how to do a one-off (or
> more-than-one-but-still-off) override of the default markup type: let
> the ``Markup`` object (or whatever it ends up being called, though
> that's a good name) expose methods for forcibly saving with a
> formatting option of your choice, in much the same way file fields
> already let you hand over some file contents and do manual saving
> trickery.
>
> So, suppose I write a blog entry::
>
> >>> e = Entry.objects.create(title="Foo", body="Lorem ipsum dolor
> sit *amet*")
>
> where ``body`` is a ``MarkupField``. Now, let's say the default on
> this site is Markdown, but I really want Textile instead for this
> entry::
>
> >>> e.body.save_markup(formatter='textile.textile')
>
[snip]
This needs to accept kwargs as well. Lets take the use case were
Markdown it the default. And most of the site is used by trusted users
so Markdown is not in safe_mode (we allow raw html). But now, we have
one field (perhaps comments) which is accessable to the general
untrusted public. In that one case, I still want to use Markdown, but
with ``safe_mode = True``. The only way that will work is to accept
kwargs. So, using the above example:
>>> e.body.save_markup(formatter='markdown.markdown',
kwargs={'safe_mode': True})
--
\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg
--~--~-~--~~~---~--~~
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: MarkupField
On Mon, Feb 23, 2009 at 7:09 PM, dc <dmm...@gmail.com> wrote: > >> * it removes the ability to provide multiple markup_types on a given field > > No if properly implemented. Again, see FileField upload_to for > example. Or see the django-template-utils app [1]. It provides a nice wrapper so that all the formatters use the same API. You probably don't need to do exactly that, but something similar with a dict to map names to functions. Then pass that dict in as an argument. [1]: http://code.google.com/p/django-template-utils/source/browse/trunk/template_utils/markup.py -- ---- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg --~--~-~--~~~---~--~~ 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: MarkupField
On Sun, Feb 22, 2009 at 8:40 PM, James Turk <james.p.t...@gmail.com> wrote: > >> First, I don't think you actually addressed the question mentioned in >> the ticket regarding the 3 fields. It seems the question was whether >> there should be three attributes on the Python model instance, >> regardless of how many columns are stored in the database. On this >> note, though, I do have a thought: specify the markup type as an >> argument to the MarkupField. You already do this with a >> default_markup_type, but I don't see much use in having users specify >> their markup type at the time they enter the text. > > I'm fairly attached to the idea of the type being tied to an instance > and not to the field itself as to me this feels much more flexible > (examples of where I'm using this behavior on live projects are on a > multi-user blogging app we use at my office where I tend to write my > posts in ReST, some coworkers prefer raw HTML, and some also use > Markdown). I agree with you about passing this complexity on to an > end user, comments for instance should support one and only one > format, but by setting a default this is possible (yes it is storing > an extra integer per record in the database but this seems > forgivable). > Actually, I think there's room for a few different behaviors. Not sure that all of them should go in contrib.markup, but I see 4 possible scenarios: 1. James current implementation where each instance has the formatter set for that specific instance. 2. Marty's suggestion where the formatter is hard-coded into the model definition. 3. And a ForeignKey dependent option. Imagine a User or Project specific setting. Perhaps something like: class Project(models.Model): name = models.CharField(max_length=50) formatter = models.IntegerField(choices=MARKUP_CHOICES) class Page(models.Model): project = models.ForeignKey(Project) body = markup.MarkupField(formatter='project.formatter') I would imagine the above would work like Option 2, in that whatever formatter is set for the 'Project' is assumed for all 'Pages' in that project. No need to store the formatter_type separately in the 'Page' model. 4. However, in some situations, I could see Option 3 used in conjunction with option 1. The User sets her default choice in her User Profile. Then, whenever she creates a new instance, the formatter defaults to her preferred formatter. However, this particular instance may use a different type of formatter, so she selects a different formatter on that instance - which needs to be saved specific to that instance. Hmm, guess I'm kind of proposing two different things here aren't I? 1. Per instance formatter or not. I have a couple thoughts about how to differentiate this one. The obvious way would to have two different Fields, one for each behavior. However, what about this crazy idea: only offer one Field, but have to keywords options: "default_formatter" & "formatter" (or whatever color you choose). If "default_formatter" is set, then use that as the default, but give the end user the option of selecting a different formatter per instance. However, if "formatter" is set instead, then set that formatter for all instances with no option for the user to change it. Obviously, it would need to be worked out how to handle having both set (ignore one, generate error, or something else), which could get ugly, but I thought I'd throw it out there. 2. ForeignKey dependent default or not. Again, the obvious way would be with different fields. But what about checking to see if the string passed in matches an existing foreignkey on the model, and using that if it does - falling back to the current behavior if not. Again, this may be a bad idea. Just throwing it out to generate some thinking on it. -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg --~--~-~--~~~---~--~~ 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: MarkupField
On Sun, Feb 22, 2009 at 4:46 PM, James Turk <james.p.t...@gmail.com> wrote: > > > What about other types of markup? > Some have suggested supporting more types of markup but to me this > seems outside the scope of contrib.markup which currently only > supports ReST, markdown, and textile. Should this field not meet some > peoples needs the can add their own custom markup field and base it on > this design. > Well, at the vary least, you could make it easier for one to add their own type of markup. Perhaps make the render-markup function such that one could provide their own render function without needing to subclass the field. Personally, I would use this every time as I will never use the default markdown. I will always be adding in some of the available extensions[1]. Currently, the only way to do that is to write my own render method. It would be nice to just pass that in on declaring the field without creating my own subclass etc. [1]: http://www.freewisdom.org/projects/python-markdown/Available_Extensions -- ---- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg --~--~-~--~~~---~--~~ 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: Multiple attach files...
Hi Marcello, This list it for the development of Django itself. For usage questions, use the django-users [1] list. Or, you may find the django-brasil [2] list more helpful. [1]: http://groups.google.com/group/django-users [2]: http://groups.google.com/group/django-brasil On Mon, Feb 2, 2009 at 11:02 AM, Marcello(Harry) <mbsalgue...@linuxmail.org> wrote: > > Hi every one, > my name is marcello, i'm from brazil, i'm new here and i'm not expert > with django but i try! =) > So... i have some question about multiple attach files, > if multiple attach file have discussed here before!? > Can i try dev this new models class or classes!? > > sorry about my english... > > att, > > Marcello Bontempo Salgueiro. > > > > -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg --~--~-~--~~~---~--~~ 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: module to run django under mod_fcgid
On Mon, Feb 2, 2009 at 8:57 AM, Mike <mike4...@gmail.com> wrote: > > I tried to post this to the django ticket system but got rejected by > the spam filter twice (prompting me to leave a rude message, I > apologize). If there is any interest in this, could someone advise > where to post the code? Thanks. > Hey Mike, If your register [1], the spam filter gets turned off. If you would prefer not to register, you can create a session key with the session settings [2], which will make the spam filter less aggressive. Last I checked, this was explained on the spam rejection page. Once you do that you could put your sample config on this wiki page [3]. Of course, you always could post it to djangosnippets.com as well/instead. That seems to be the go-to place for posting django code snippets these days. [1]: http://www.djangoproject.com/accounts/register/ [2]: http://code.djangoproject.com/settings [3]: http://code.djangoproject.com/wiki/ServerArrangements -- ---- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg --~--~-~--~~~---~--~~ 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: django + rest
Hi Ed. This seems more like a question for the django-users list. django-dev is for the development *of* Django, not development *with* Django. Ask there, and I'm sure you'll get pointers to a lot of helpful resources. For a start, you may want to take a look as Malcolm's recent multi-part series on the subject. Note the third one with regard to content-types. http://www.pointy-stick.com/blog/2008/12/09/implementing-http-services-django/ http://www.pointy-stick.com/blog/2008/12/13/etags-and-modification-times-django/ http://www.pointy-stick.com/blog/2008/12/15/content-types-http-and-you/ On Mon, Dec 29, 2008 at 8:28 PM, Ed Summers <ed.summ...@gmail.com> wrote: > > I was wondering if anyone else on the list has layered a RESTful > service into their django applications. I'm adding an atompub > interface to an existing django project, and I'd like to offer the > ability to POST and PUT to URIs. Part of my problem is that this > service needs to handle large (many megabyte) file uploads, so the > POST and PUT message body needs to be streamed to disk, rather than > held in memory. > > I took a look at the FileUpload functionality in > django.http.HttpRequest and > django.http.multipartparser.MultiPartParser, and it looked like I > could slot in custom handlers as long as the content was POSTed with a > mimetype of "multipart/form-data". Unfortunately I am wanting to allow > clients to POST and PUT arbitrary content (application/zip, > application/atom+xml, etc). > > At the moment I'm rolling my own code to read from request.environ > ['wsgi.input'] but I'm worried that I'm not handling everything > correctly, and am wondering if there exists middleware for handling > this sort of scenario in a cleaner way. Or perhaps there's a more > django-y way of doing it? > > Any info/pointers/tips would be appreciated. > > //Ed > > > > -- Waylan Limberg way...@gmail.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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: The Django form HTML is rendered as TEXT
Hi Dmitri, Welcome to Django. However, this list for the development of Django itself, not development with Django. Please ask your question on the django-users list. <http://groups.google.com/group/django-users> -- Waylan Limberg way...@gmail.com On Thu, Dec 25, 2008 at 10:44 PM, Dmitri_13 <s4shre...@gmail.com> wrote: > > > Hi Guys, > I am new to Django . My Django form HTML is rendered as TEXT . It does not > display the HTML as such. > > Please assist. > > Thanks in Advance > Regards > Dmitri > -- > View this message in context: > http://www.nabble.com/The-Django-form-HTML-is-rendered--as-TEXT-tp21171407p21171407.html > Sent from the django-developers mailing list archive at Nabble.com. > > > > > -- Waylan Limberg way...@gmail.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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: RequestContext rarely used (branched from Feature reviews for 1.1)
On Thu, Nov 20, 2008 at 10:23 PM, Yuri Baburov <[EMAIL PROTECTED]> wrote:
>
> On Thu, Nov 20, 2008 at 9:47 PM, Jeremy Dunck <[EMAIL PROTECTED]> wrote:
>>
>> On Thu, Nov 20, 2008 at 6:19 AM, zvoase <[EMAIL PROTECTED]> wrote:
>> ...
>>> # Using RequestContext
>>> def myview(request, *args):
>>># some code here...
>>>request.render('template_name.html', {...})
>> ...
>>>
>>> That just seems logical to me. Rather than (potentially) break
>>> backwards compatibility, let things be as they are right now and just
>>> add a method to the request.
>>
>> Except that it couples request and response objects to templates.
>
> But render_to_response also does that?
> You want request and response to be loosely coupled? Does it make
> sense? Aren't they coupled in render_to_response and response
> processing code anyway?
>
> Please explain your point a bit more.
>
render_to_response is a "shortcut" that makes a few assumptions to
cover a common use case and helps keep your views DRY. If you changed
your template system or various other pluggable components, you would
either need to write your own version of render_to_repsonse or repeat
yourself often in your views. However, by making render a method of
the request, we are now taking those assumptions another level and
forcing them on the request object itself. That's bad.
You see, anyone can use Django any way they want and don't have to use
any of the "shortcut" helper functions. However, everyone has to use
the request and response objects, so the code needs to make as few
restrictive assumptions as possible in those objects. And yes, making
it easy for someone to use a different template system is a feature
that we want to keep.
--
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: Multi-Threaded Dev Server
On Sun, Nov 16, 2008 at 1:26 AM, Chris <[EMAIL PROTECTED]> wrote: > > I think http://code.djangoproject.com/ticket/3357 should be given > another look at enabling optional multi-threading on the dev server. > 3. Fear of multi-threading bugs shouldn't be a reason to avoid multi- > threading, especially when it could be very useful. We don't even know > if there are multi-threading bugs. And even if there are, they can be > fixed. > Yet, the time spent identifying and fixing those buds means less time developing real features that I need and can use on my production sites. I'd say the developers time is better spent elsewhere. Especially considering there are already working solutions out there. I seem to recall at least one management command someone put together that runs a multithreaded cherrypy server. Why reinvent the wheel? Lets focus on real, useful features. -- 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: login_required
On Mon, Nov 10, 2008 at 2:49 PM, Sebastian Bauer <[EMAIL PROTECTED]> wrote: > > Hello, i think login_required should check that user is not only > authenticated, but also if is active. What do you think about this change? > I see two problems with this: 1. This current behavior is fully documented [1]. In relevant part, the documentation says: > This doesn't control whether or not the user can log > in. Nothing in the authentication path checks the > is_active flag, so if you want to reject a login based > on is_active being False, it is up to you to check that > in your own login view. However, permission checking > using the methods like has_perm() does check this > flag and will always return False for inactive users. 2. Many people have expected the current behavior for some time and such a change would be backward incompatible. Although, I do see that the documentation specific to the login_required view does not specifically mention the behavior. Perhaps a note there would be beneficial. [1]: http://docs.djangoproject.com/en/dev/topics/auth/#api-reference -- 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: [Pony] Per app settings
On Thu, Oct 23, 2008 at 1:29 PM, shabda.raaj <[EMAIL PROTECTED]> wrote: > > I was doing a little research and saw #5049, which was closed as > WONTFIX by Russell, but I cant seem to find the referenced discussion, > and am posting this as maybe this proposal is significantly different > than what was discussed in the past. :) My understanding is that any app specific stuff is to come under the planned INSTALLED_APPS refactor in #3591. There are also some notes on the wiki[1]. Personally, I have no idea if the plan includes a way for app specific settings files or not, so this may or may not address your pony. In any event, I seem to recall is being pointed out before that the settings file is just python code. There is noting stopping you from importing other app specific settings files into settings.py. Presumably, you would want to do such an import at the end of the file so as to override the project defaults. Although, rereading your request, that wouldn't do what you want. The thing is, settings are loaded once at server init and remain unchanged across requests. However, you want settings to change for each request depending on which app a view resides in. That's determined in url resolution. Remember a url.py file in one app could point to a view in another app. Perhaps a wrapper (or decorator) around your views could add the appropriate context. Settings are global and constant, they're not the place for this sort of thing. [1]: http://code.djangoproject.com/wiki/InstalledAppsRevision -- 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: admin.autodiscover() uses method that cannot find files inside of eggs: possible fix included
On Wed, Oct 22, 2008 at 7:16 PM, Clint Ecker <[EMAIL PROTECTED]> wrote: > > Hi all, > I've opened a ticket on this matter (http://code.djangoproject.com/ > ticket/9427) but the gist of it is this: > [snip] > > I'm throwing this out there just to get a wider eye on the patch just > in case there are any edge cases that these changes might affect. > What about an admin.py in an egg that legitimately raises an error on import? If imp.find_module can't find it as you claim, won't that error be eaten? Now, I realize that should probably be caught while testing not in an egg first, but it is a real possibility. Perhaps we shouldn't care about that one though. -- 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: Google maps subclass of GeoModelAdmin
I'm not really sure, nor am I the one to make such a decision, but I wonder if perhaps something like this hasn't been included because of issues with Google's licensing. Of course, not everyone is using GeoDjango in a commercial setting, so your code's still useful. Perhaps you could post it on djangosnippets.org. However, if I'm wrong about the licensing issues, a ticket with a patch would be the way to address inclusion. On Wed, Oct 15, 2008 at 7:07 AM, Thamsanqa <[EMAIL PROTECTED]> wrote: > > Hi > I see that only open street maps are supported by GeoDjango in > django.contrib.gis.admin through the OSMGeoAdmin class which inherits > from GeoModelAdmin. I have discovered that changing this to use Google > Maps is a matter of modifying the template files in contrib/gis/ > templates/gis/admin and then pointing a new class inheriting > GeoModelAdmin to one of them. How can I contribute the modified > templates and subclass to the Django project, that is if there is any > interest in adding this to django ? > > > > -- 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: "things are ready" signal?
On Wed, Oct 1, 2008 at 5:04 PM, Marc Fargas <[EMAIL PROTECTED]> wrote: > > > So, would a signal there be useful? (no ticket filled yet) And, where > can one hook code for that? :) > I seem to recall this request being made from time to time. IIRC, it always turned out that whoever asked didn't really want this, but something else. Therefore, I don't believe anyone has provided a valid use case for such a signal. I'd suggest searching the archives. -- 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: Status report on CPython 2.6
Search the archives. This has been discussed a few times before. I believe someone (Karen?) has even been testing for 2.6 compatibility and a few changesets have been committed specifically for that purpose. IIRC, the policy is to support 2.6 where-ever practical as long as it doesn't break support for 2.3-2.5. Again, the previous discussions will provide answers - although, now that 1.0 is out, I suppose an update on that status wouldn't hurt. On Fri, Sep 26, 2008 at 1:09 PM, zvoase <[EMAIL PROTECTED]> wrote: > > Hi, > Just wondering if I could ask how compatible Django is with CPython > 2.6. I know that it should work fine anyway, but I thought it a good > idea just to check. Has anyone looked into this? > > Regards, > Zack > > > -- 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: Proposal: user-friendly API for multi-database support
On Wed, Sep 10, 2008 at 3:30 PM, Simon Willison <[EMAIL PROTECTED]> wrote:
>
> On Sep 10, 7:13 pm, "Justin Fagnani" <[EMAIL PROTECTED]> wrote:
>> For application-wide db connections, I think it'd be much easier and
>> more portable to choose the connection in settings.py rather than in a
>> Model.
>
> That's a very interesting point, and one I hadn't considered. It makes
> sense to allow people to over-ride the connection used by an
> application they didn't write - for example, people may want to tell
> Django that django.contrib.auth.User should live in a particular
> database. Further-more, just allowing people to over-ride the
> connection used for an existing application isn't enough - you need to
> be able to over-ride the default get_connection method, since you
> might want to shard Django's built in users (for example).
>
> This in definitely one of the use-cases we need to cover.
>
> I'm not sure of the best way to handle it though. The way I see it the
> options are as follows:
>
Would this perhaps be easier to do after the Apps-Refactor (#3591)
lands? I'm not real familiar with that ticket, but if we're trying to
set a connection on a app level - that seems like the easiest way to
do it via settings. Something like:
INSTALLED_APPS = (
app('django.contrib.auth', connection='my_user_db'),
...
)
Not sure how that would work for over-riding the default
get_connection method though. We'd probably still be referring to a
callable by 'dotted.path.to.a.function' syntax. And it would apply to
all models in an app, not just some.
Just a thought.
--
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: Checkboxes in admin
On Fri, Aug 22, 2008 at 1:12 PM, Alex Rades <[EMAIL PROTECTED]> wrote: > > Hi, > Is there a reason for checkboxes (BooleanField) in admin having the > label on the right side instead of left? Isn't that how check boxes are generally displayed? I don't recall them the other way anywhere - and would find that confusing. -- ---- 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: '"%s/" % var' preferred to 'var + "/"'?
On Thu, Aug 21, 2008 at 12:22 PM, Ian Kelly <[EMAIL PROTECTED]> wrote: > > On Thu, Aug 21, 2008 at 10:00 AM, Waylan Limberg <[EMAIL PROTECTED]> wrote: >> I had thought that I read from that same source that formatting is >> faster than concatenation (and that's why I checked there before >> responding), but I don't see that mentioned. Not sure where I got that >> idea or if its even true. > > Formatting is faster than serial concatenation, which often results in > copying the same substring multiple times. A single concatenation is > usually faster than formatting, however. > PEP 8 has something to say about this under "Programming Recommendations": - Code should be written in a way that does not disadvantage other implementations of Python (PyPy, Jython, IronPython, Pyrex, Psyco, and such). For example, do not rely on CPython's efficient implementation of in-place string concatenation for statements in the form a+=b or a=a+b. Those statements run more slowly in Jython. In performance sensitive parts of the library, the ''.join() form should be used instead. This will ensure that concatenation occurs in linear time across various implementations. Of course, this doesn't say anything about formatting - just joins, but concatenation seems to be generally discouraged wherever we look. -- 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: '"%s/" % var' preferred to 'var + "/"'?
Well, according to the python beginners book; "Dive Into Python" [1], string formatting is less error prone as it also does type coercion whereas string concatenation only works when all objects are already strings. When it's possible that a user will be passing in parts of the concatenation, I'd rather be using formatting for that reason alone. I had thought that I read from that same source that formatting is faster than concatenation (and that's why I checked there before responding), but I don't see that mentioned. Not sure where I got that idea or if its even true. [1]: http://diveintopython.org/native_data_types/formatting_strings.html On Thu, Aug 21, 2008 at 11:41 AM, Joost Cassee <[EMAIL PROTECTED]> wrote: > > Hi all, > > Just a quick question to set my head right for future Django > contributions. Why is "%s/" % var better than var + '/'? I can think > of some reasons: 1) consistency with other code, 2) certainty of > string concatenation. But is the second expression not much faster? > (This is an honest question, no criticism or anything.) > > Regards, > > Joost > > > -- 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: Call for testing: new docs
On Wed, Aug 20, 2008 at 2:36 AM, Ivan Sagalaev <[EMAIL PROTECTED]> wrote: > > Jacob Kaplan-Moss wrote: >> I've also put a built version of the docs online at >> http://docs.djangoproject.com/dev/. There are some problems with the >> version online right now; no need for bug reports since I'll be >> changing the online version to better fit into the django site over >> the next few days. > > Hi, Jacob! > > Does "no need for bug reports" apply only to presentation or to content > as well? I'm asking because I've found an old-style `class Admin` your > request declaration in an example in "Django at a glance" and I'm not > sure if such bugs are known. > There's already a ticket for this: #8150. Although the patch might need to be adjusted for the new docs. http://code.djangoproject.com/ticket/8150 -- 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: url template tag, unhelpful when failing
On Fri, Jul 18, 2008 at 3:09 PM, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > > On Fri, 2008-07-18 at 19:30 +0200, Mikael Moutakis wrote: >> Hi >> I've running from trunk and recently switched to the NFA-branch. I >> found that the URL templatetag is unhelpful when failing to match a >> url. I patched my own copy of the function URLNode in >> django.template.defaulttags to return a more helpful error message >> instead of a empty string. Should I file a ticket with the patch or >> should I add the solution as a django snippet instead? Sorry, if this >> is a stupid question, but I'm new to this. I modified the last 3 lines >> of the function below. > > > The basic design rule is that template tags should always fail silently > if there's an error. Some templates and applications rely on this > behaviour. So a change like this runs against that principle. > In other words, a patch like that will likely not get applied. However, others may find it useful, so a snippet may be the way to go. However, I wouldn't just post your patch as a snippet, but post a full working tag that would be added to a users app, which can then be used in place of the one that ships with Django. If your interested in more specifics as to why Django has chosen silent failure, search the list archives. Seems there was a recent discussion about it. -- 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: QManager - suggested inclusion in Django
On Thu, Jul 17, 2008 at 6:46 AM, zvoase <[EMAIL PROTECTED]> wrote: > > Dear Developers, > I've written a module which may be helpful to a lot of Django > developers, and would like to suggest it for trials and testing, and > possible inclusion with Django. Well, for starters, it appears to be licensed under the GPL while Django had a BSD license. As long as the conflict exists, your changes of inclusion are pretty slim, I would think. Either way, don't get your hopes up for inclusion any time soon. Everyone is currently working to get 1.0 out the door and this is not a show stopper for that (it doesn't break backward compatibility of the API - just adds new stuff) so I doubt the core devs will even consider it until after 1.0. In the meantime, review the points on contributing [1] in the docs, continue to maintain your code as separate code and prove your worth as a reliable maintainer. [1]: http://www.djangoproject.com/documentation/contributing > I'm currently just looking for > developers to help test and work with the module; it should be quite > helpful. It certainly looks interesting. Perhaps I'll play with it if I get a chance. > It's also heavily documented - *everything* has a docstring. I hope > you enjoy, I'll say. What, less that 50 lines of code in a 500+ line document? Wow. -- 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: Views returning data only
Vicvicvic,
I think your on to something here. However, we need to remember that
one of the great things about Django views is that they are just
python functions. You can do pretty much anything you want. So, if
someone wants to build up a complete html page in python code without
any templates, they can. It will be a maintenance headache, so it's
not recommended, but its not wrong.
If you want to build up a library of decorators that simplify your
views (and, no doubt, speed up your work), then you are free to do so.
And if you want to share that library with others, that's even better.
In fact, if you search through djangosnippets.com, I believe you'll
find a few snippets that do some of the same things your talking
about.
However, I don't expect that the Django core will take on your
approach as the "preffered" way to do things. The flexibility of the
views to allow various coding styles is one of Django's greatest
strengths. You can do what works for you and I can do what works for
me.
So keep it up. Share your work and make Django a better place for
others who like that style of coding. Just don't expect the entire
community to embrace it as the "only way".
On Tue, Jul 15, 2008 at 6:36 AM, vicvicvic <[EMAIL PROTECTED]> wrote:
>
> In the Django FAQ, we can read this about views:
>
>>In our interpretation of MVC, the "view" describes the data that gets
>>presented to the user. It's not necessarily how the data looks, but which
>>data is presented. The view describes which data you see, not how you see it.
>>It's a subtle distinction.
>
> In my mind, "which data you see" would be equal to a context a view
> returns, not the HttpResponse or the template. Why? Because rendering
> a template is saying "I have this data and I want it presented the way
> this template will present it". If the view is responsible for saying
> that, it is at least partly responsible for telling us how we see the
> data.
>
> Rather, if a view ONLY returned a dataset, something else would be
> responsible for displaying this. In more practical terms, if a view
> returns a dataset, instead of a full response, another mechanism would
> be wholly in charge of formatting the data. This mechanism may then
> choose which template to render, or to not render a template at all,
> and just pass the dataset along.
>
> Why is this useful? For the sake of minimizing views, but provide a
> rich amount of formats. The format-choice mechanism can investigate
> the request (HTTP Requests come with an Accept-header) and see what
> format has been requested. Looking at Accept would be the proper way
> of doing it, but it might be easier to make URLs like /forums/threads.
> (?Phtml|json|xml)
>
> HTML? Render that template. JSON? Render that template (or just
> serialize the dataset). XML? RSS? You get the idea: The formatter
> takes the data and tries to present it, making it a bridge between a
> view and a template.
>
> Furthermore, the same mechanism could be asked to process an
> "internal" request, that is another Python function requesting the
> data. Right now, I have a couple of views which return some data. But
> I'm also building another view, and I want the data from one of the
> first views in this one. I can either duplicate the fetching from the
> first one, or I can send an "internal" request and just get the
> dataset. I pick WHICH data I want and add some to it.
>
> My current solution:
>
> I've written a very crude decorator to demonstrate/use this in my own
> projects, but I'm note sure if posting code looks any good on Google
> Groups. Summarized:
> My decorated views return their dataset as a dictionary.
>
> The decorator takes two parameters: template and formats. template is
> the usual path to a template, but without an extension. formats is a
> tuple of formats (('html','json')) which the view is considered able
> to render.
>
> Upon calling the view, the decorator intercepts its arguments. It
> looks for a format-parameter and an internal-parameter. If internal is
> True, it lets the view run and just returns the resulting dictionary
> to whatever called it. If not, it checks that format is in formats and
> then tries to render_to_response("%s.%s" % (template, format,
> returned_dict, RequestContext(request))
>
> As I said above, the mechanism (in my case, a decorator) should
> probably try to investigate what the request looks like, rather than
> checking for stuff in the URL/other parameters but as I said, it's
> crude. It should also return the proper Content-type.
>
> --
>
> Do you think I have a point? Me not being a Django developer (and not
> a very seasoned Python user at all), I realize I mig
Re: rev 7920 fresh checkout fails tests?
On Mon, Jul 14, 2008 at 12:25 AM, Karen Tracey <[EMAIL PROTECTED]> wrote:
[snip]
> File "D:\u\kmt\django\trunk\tests\regressiontests\admin_scripts\tests.py",
> line 56
> cmd += ''.join(' %s' % arg for arg in args)
> ^
> SyntaxError: invalid syntax
>
> (the caret points to the 'r' in 'for' in fixed-pitch font)
>
> Same django checkout works if I just use python 2.5.1 instead. Is this new
> syntax not supported by 2.3?
>
It would appear so:
Python 2.3.4 (#1, Nov 20 2007, 15:18:15)
[GCC 3.4.6 20060404 (Red Hat 3.4.6-9)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> [a for a in ['1','2','3']]
['1', '2', '3']
>>> ''.join(a for a in ['1','2','3'])
File "", line 1
''.join(a for a in ['1','2','3'])
^
SyntaxError: invalid syntax
>>> ''.join([a for a in ['1','2','3']])
'123'
However in 2.4:
Python 2.4.3 (#3, Jun 8 2007, 04:52:26)
[GCC 3.4.6 20060404 (Red Hat 3.4.6-8)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> ''.join(a for a in ['1','2','3'])
'123'
>>> ''.join([a for a in ['1','2','3']])
'123'
--
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: Ticket #7591: Authenticate By Email Support
Paul, I believe this issue has been brought up in various ways before. I'd suggest searching the list archives and old closed tickets. You'll likely find your answer there. More generally, there is already a mechanism in place to override the default behavior and implement your own (building your own auth backend), so I suspect the core devs would prefer that you do that rather than build everyones minor feature request into the core. Actually, I believe there are at least a few existing solutions out there. A search should turn up a few gems for you. On Wed, Jul 2, 2008 at 11:48 AM, Paul Kenjora <[EMAIL PROTECTED]> wrote: > I've been using Django for a while and recently started contributing to the > trunk. Previously I ran my own branch but sooner or later that gets > tiresome. So I created a ticket the other day: > > http://code.djangoproject.com/ticket/7591 > > The ticket suggests a patch to contrib/auth that will allow authenticate by > email as well as username. The idea was shot down rather quickly without > any particularly good reason. In order for me to continue contributing to > the trunk I'd like to get in line with the thought processes on Django > development. Could someone here please elaborate on why ticket 7591 is a > bad idea? Or better yet why its a worse idea than other approaches? > > > Thanks, > -- > - Paul > > > > -- 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: FormWizard - GETs on all but last step?
On Tue, Jul 1, 2008 at 8:28 PM, Arien <[EMAIL PROTECTED]> wrote: > > On Tue, Jul 1, 2008 at 6:10 PM, Waylan Limberg <[EMAIL PROTECTED]> wrote: >> >> On Tue, Jul 1, 2008 at 5:59 PM, David Durham, Jr. >> <[EMAIL PROTECTED]> wrote: >>> >>> Nice thing about GETs is that users aren't confronted with the dreaded >>> "Data was submitted with POST" confirmation, which is confusing to >>> most people and usually not tested. Basically you end up breaking the >>> back button and the reload button. >> >> Um, this is intentional and a good thing. If you read the spec, not >> only is the difference between GET and POST defined, but the way user >> agents (browsers) should treat them is defined as well. Breaking the >> back & reload buttons is a requirement of the spec to, among other >> reasons, avoid multiple posts by impatient (or double-clicking) users. >> Granted, browsers could provide more helpful messages, but we want >> that behavior for POSTing data. > > What specification requires this? > A number of them actually. To name a few: http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9 http://www.w3.org/TR/REC-html40/interact/forms.html#h-17.13 http://www.w3.org/2001/tag/doc/whenToUseGet.html A decent summary of the issues are found here: http://www.cs.tut.fi/~jkorpela/forms/methods.html -- 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: FormWizard - GETs on all but last step?
On Tue, Jul 1, 2008 at 5:59 PM, David Durham, Jr. <[EMAIL PROTECTED]> wrote: > > Nice thing about GETs is that users aren't confronted with the dreaded > "Data was submitted with POST" confirmation, which is confusing to > most people and usually not tested. Basically you end up breaking the > back button and the reload button. Um, this is intentional and a good thing. If you read the spec, not only is the difference between GET and POST defined, but the way user agents (browsers) should treat them is defined as well. Breaking the back & reload buttons is a requirement of the spec to, among other reasons, avoid multiple posts by impatient (or double-clicking) users. Granted, browsers could provide more helpful messages, but we want that behavior for POSTing data. Which leads me to the question: In what use-case would a FormWizard ever GET? GET is only to be used to retrieve data (i.e.: search results) whereas POST should be used when submitting data to the server. I can't think of any case where a multi-page form would be used to "retrieve" data. I realize Jeremy suggested that POST would still be used on the final page, but even so, the other pages technically are still POSTing data. Perhaps he wants to allow the user to stop part way through a wizard, bookmark the url (with the data entered thus far preserved in the querystring), and allow them to pick up where they left off later.? Interesting, but I wouldn't recommend it. For one, that could result in some long urls (perhaps even longer than the limit). A multi-part form could add up to a lot pretty quick. Second, those would be some ugly urls. And third, as mentioned above, it's not really the proper use of GET anyway. So, unless a strong use-case is provided, I'm -1 on this. -- 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: Spam detection
On Thu, Jun 26, 2008 at 4:34 PM, Marc Fargas <[EMAIL PROTECTED]> wrote: > 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. Yeah, it does kind of get lost in the text there. The first few lines basically say "be sure you actually have an unreported bug." Presumably, the potential reporter thinks: "Yeah, Yeah, I've been through that before so why should I read every point in that list carefully?" True, first time reporters to any project probably should read that, but obviously they don't. Personally, I alway look for a "register" link in the menu - usually in close proximity to the "Login" link. I'd suggest (and have in the past) that a "Register" link be added to every Trac page right next to the "Login" and "Settings" links up in the top right corner. If that doesn't work - then perhaps a dancing animation across the newticket page. Ok, maybe not. :-D -- 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: Experimental Git repository available
On Thu, Jun 19, 2008 at 1:52 PM, Alexander Solovyov <[EMAIL PROTECTED]> wrote: > > On Thu, Jun 19, 2008 at 8:09 PM, Jacob Kaplan-Moss > <[EMAIL PROTECTED]> wrote: >> Yeah, hgsvn is one-way, > > H > >>hg help convert > hg convert [OPTION]... SOURCE [DEST [REVMAP]] > > Convert a foreign SCM repository to a Mercurial one. True, but that doesn't address pushing changes back to SVN, at least not practically. Mercurial's own docs [1] admit this is a problem needing improvement. Compare that with git-svn's dcommit command [2]. [1]: http://www.selenic.com/mercurial/wiki/index.cgi/WorkingWithSubversion#head-15564b76f3172721218d34c912aa0c31e156a94b [2]: http://www.kernel.org/pub/software/scm/git/docs/git-svn.html -- 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: List of DDN Tickets
I had a few comments on some of these and was going to post them to the tickets so they don't get lost, but my browsers acting up and closing when I try to login, so I'm posting here. On Wed, Jun 18, 2008 at 7:58 PM, Jeff Anderson <[EMAIL PROTECTED]> wrote: [snip] > > * http://code.djangoproject.com/ticket/2259 - I think the right action to > take would be to make the PK editable=False. Modifying the pk, to me, seems > like trying to relocate a c++ object instance in memory-- it sounds like a > big pain and not that much benefit (none). Agreed. If a user really wants to edit a PK, then they can either do custom sql or add a new row and delete the old one. > > * http://code.djangoproject.com/ticket/4996 - I don't know if it would be a > good idea to make 'runserver' run as a daemon. Maybe it would be ok of there > was a warning before forking. The argument made in the ticket is that offering a daemon option for runserver could give a false sense of stability of the dev server so it doesn't belong in the core. That said, a use case was made for adding it for dev purposes only. Interestingly, the last activity on this ticket was before apps could add their own management commands [6400]. Seeing the given use case is not likely to be used by most, I'd say this belongs in a third party app (like perhaps http://code.google.com/p/django-command-extensions/) and those few people who have a valid need for it can still get the feature that way. [snip] > > * http://code.djangoproject.com/ticket/6709 - I think this is a no-go. It > would be overly complex. If I'm understanding the request correctly, this could only be used by forms that can only work with js. Generally speaking, creating an interface that doesn't have a fallback when js is disabled is considered bad design. Why would we add a potentially complex feature only for the support of arguably bad UI design? Just a thought. > > * http://code.djangoproject.com/ticket/6932 - Having a list of flatpages > would be good. I am in favor of making them available to the templates; > either in the RequestContext or a templatetag. Either way would probably be > beneficial. The current patch only adds the list of flatpages to the Context in the flatpages view. However, a user could conceivably want access elsewhere in his project. At the same time, we don't want to waste resources on every request when it's not needed. A templatetag makes the most sense to me. It could easily be loaded into any template and used from any app. Additionally, while its a nice-to-have feature, I don't see it as a pre-1.0 deal breaker. Anyone could add a templatetag to there own app. -- 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: #7295: quotes, escaping and translation of string literals in templates
I haven't looked at what your doing real close, but it seems to me your trying to re-implement the shlex module [1] which has been in the Python standard library since 1.5.2. Will that do the trick? [1]: http://docs.python.org/lib/module-shlex.html On Fri, May 23, 2008 at 10:56 AM, akaihola <[EMAIL PROTECTED]> wrote: > > It's confusing that the django.utils.text.smart_split() function un- > escapes quotes and backslashes inside the literal string while > preserving the surrounding quotes: > >>>> print ' '.join(smart_split(ur'arg1 "the \"second\" argument" > "the \\third\\ argument"')) >arg1 "the "second" argument" "the \third\ argument" > > I would find it simpler to just have either > 1) escaped and quoted literal strings, or > 2) un-escaped and un-quoted strings. > > This would also make it simpler to unify the handling of variables and > filter expressions in django/template/__init__.py. > > > -- 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: bug? Issue with markdown, encoding and mysql
On Wed, May 21, 2008 at 2:32 PM, Waylan Limberg <[EMAIL PROTECTED]> wrote: [snip] > in mind that markdown knows (almost) nothing about encodings. It only > works with unicode (or ascii) text. You *must* give markdown unicode > text and it *only* outputs unicode text. It is your responsibility to > deal with whatever encodings you need. It would be almost imposable > for markdown to support every possibility, so it doesn't even try. > Oh, I should mention that this policy has only been strictly enforced on the most recent release (1.7) of Python-Markdown. Previous versions may have appeared to work with some encodings, but it was always buggy. Your encouraged to upgrade to the latest version. -- 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: bug? Issue with markdown, encoding and mysql
This appears to be a usage question. This list is for the development
of Django itself, not developing projects that use Django. Usage
questions should be directed to the django-users list [1].
[1]: http://groups.google.com/group/django-users
That said, it appears that you are taking issue with markdown, which
is a separate library not included with django. Issues with markdown
should be addressed on that projects mailing list [2]. However, keep
in mind that markdown knows (almost) nothing about encodings. It only
works with unicode (or ascii) text. You *must* give markdown unicode
text and it *only* outputs unicode text. It is your responsibility to
deal with whatever encodings you need. It would be almost imposable
for markdown to support every possibility, so it doesn't even try.
[2]:
http://sourceforge.net/mailarchive/forum.php?forum_name=python-markdown-discuss
However, Django does have some handy mechanisms [3] for dealing with
this sort of thing. You might want to check them out.
[3]: http://www.djangoproject.com/documentation/unicode/
Also, why are you importing markdown from the template filter? Why not
just import markdown directly?
On Wed, May 21, 2008 at 2:11 PM, Mike Chambers <[EMAIL PROTECTED]> wrote:
>
> I just ran into an issue where i was getting unicode errors when trying
> to insert data into mysql (via a model).
>
> I had this code:
>
> --
> from django.contrib.markup.templatetags.markup import markdown
>
> def save(self):
>self.content_html = markdown(self.content_source)
>
>super(Chapter, self).save()
> --
>
> self.content_source is utf-8
>
> This would cause a unicode error when the code tried to save the string
> in the DB (mysql) if content_source contained any non-ascii chars.
>
> I was able to fix this by explicitly setting the encoding on the string
> returned from markdown()
>
> --
> from django.contrib.markup.templatetags.markup import markdown
>
> def save(self):
>self.content_html = markdown(self.content_source).encode("utf-8")
>
>super(Chapter, self).save()
> --
>
> However, I would have expected the markdown function to return the
> correctly encoded string.
>
> Here is a simple script that I believe shows the difference in output:
>
> --
> from django.contrib.markup.templatetags.markup import markdown
>
> tmp = u'Andr\202'
> m = markdown(tmp)
> print m
> m = markdown(tmp).encode("utf-8")
> print m
> --
>
> Python 2.5.1 (r251:54863, Jan 17 2008, 19:35:17)
> django.VERSION (0, 97, 'pre')
>
> I am pretty new to django, and dont have much experience working with
> unicode, so I wanted to post here to see if anyone thought that this
> looked like a bug? If so I will log it.
>
> mike
>
>
> >
>
--
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: Rethinking silent failures in templates
On Wed, May 14, 2008 at 10:10 AM, Deryck Hodge <[EMAIL PROTECTED]> wrote:
>
> On Wed, May 14, 2008 at 9:07 AM, Simon Willison <[EMAIL PROTECTED]> wrote:
> > Which leaves us in a tricky situation. A global settings.py variable
> > for "throw errors on missing template variables" is a bad idea as it
> > kills application portability (the PHP magic_quotes problem again - if
> > your application expects that setting off and mine expects it on I
> > can't import your app in to my environment). There might be something
> > we can do with warnings, but it could still end up pretty messy. Needs
> > more thought.
>
> Hi, Simon.
>
> Could you not just tie it to the DEBUG setting? That is the worry,
> after all, right? -- that a production site will 500. Development it
> doesn't matter, and generally, people use DEBUG to distinguish the
> two.
>
Well, say I have a template in which {{ article.something.title }} is
expected to fail silently in some cases. Suppose I also happen to have
another bug later in that template. In development (DEBUG mode on), I
don't want {{ article.something.title }} to generate an error, but I
do want that other later (as yet unknown) problem to give me django's
handy error page. If it always trips up on {{ article.something.title
}}, I'll never get to that other error which happens later in the
processing until I move to production and no longer get nice error
pages to help me find it.
Therefore, I think we need a way to distinguish between what parts of
the template should fail silently, and what parts should not. Perhaps
some sort of filter or tag or combination thereof. Not unlike
autoescaping -- fail by default and fail silently only were
explicitly set. Of course, this opens up a whole can-of-worms
regarding whether one tag affects the whole template, inherited
templates, a block in the template, or just a single variable lookup
or some combination of them all. Ug - don't want to go through that
again.
Hmm, before I posted this, I see that Marty has similar thoughts.
Maybe it's not so crazy after all.
--
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: Callable context variables do not get called during resolution.
On Fri, May 9, 2008 at 8:12 PM, Peter Rowell <[EMAIL PROTECTED]> wrote: > [snip] > In order to delay a *very* expensive DB operation, I decided to put it > in a function and pass the function as a context variable. The > template uses fragment caching with vary_on, so only if the template > fragment is stale would the function be called and invoke the heavy > lifting. > [snip] QuearySets are lazy and, as I understand it, don't get evaluated until they are called in the template. Therefore, if a quearyset call is wrapped in an if statement in the template that evaluates to false, the query should never happen. What are you trying to accomplish that is any different? On Fri, May 9, 2008 at 8:23 PM, Peter Rowell <[EMAIL PROTECTED]> wrote: > > BTW, I tried to add a comment on this to > http://code.djangoproject.com/ticket/7153, > but got "Internal Server Error (Submission rejected as potential > spam)", which struck me as rather rude. :-) > Well, spam littered tickets would be worse. It's the lesser of two evils. You can register [1] for an account and bypass the spam filter -- Or, if you don't what to register, create a session [2] to get the spam filter to go easy on you. [1]: http://www.djangoproject.com/accounts/register/ [2]: http://code.djangoproject.com/settings -- 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: Dev attitude towards Windows and IIS
Another alternative is Django on IronPython. I'm not involved personally, but my understanding is that it currently works (at least to some extent) and there is an effort underway to iron (sorry couldn't resist) out the bugs. I could be wrong, but as IronPython is basically python on .NET, I would think it works fine with IIS. You may want to look into that. On Wed, May 7, 2008 at 1:10 PM, Rajeev J Sebastian <[EMAIL PROTECTED]> wrote: > > On Wed, May 7, 2008 at 10:23 PM, rcs_comp <[EMAIL PROTECTED]> wrote: > > Just remember that there are people out there like me who see a lot of > > potential for Django but are confined to using IIS and MSSQL. Don't > > be skeptical of us, use our interest in Django to make the framework > > that more robust and attractive to a larger number of users. > > I dont run Windows or IIS, so I can't be sure ... but you can try > running django in IIS via fastcgi: > > http://www.caraveo.com/fastcgi/ > > > Also, Apache and nginx run on Windows platform. So those could be > avenues you should explore (considering windows in general, maybe you > should think again about IIS support expecially given the good > alternatives). > -- 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: markdown, unicode, and escaping
On Tue, May 6, 2008 at 10:45 PM, Jeremy Dunck <[EMAIL PROTECTED]> wrote: > > On Tue, May 6, 2008 at 8:21 PM, Waylan Limberg <[EMAIL PROTECTED]> wrote: > > > > Yeah, we probably should mention this in the docs, along with an > > explanation of how to enable Markdown's safe_mode. Sure, it's > > explained in the source, but the other markup filters don't offer any > > extra features so I doubt most people even look unless they encounter > > a problem. > > > Also, with 1.7, django trunk makes safe mode either True or False, but > markdown takes three values (replace, escaped, remove) and True > equates to replace. > I've given that some thought and I'm not sure how to approach it. Truth be told, I never cared for that API change (passing in one of three possable strings), but we wanted to keep some backward-compatability and definitely wanted the 'escape' feature, so in it went. Not sure how to pass that on from the django filter though. Any suggestions? -- 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: markdown, unicode, and escaping
On Tue, May 6, 2008 at 7:30 PM, Jeremy Dunck <[EMAIL PROTECTED]> wrote: > > > I think there should be a branch checking the markdown version, and > passing in a unicode object if markdown.version_info >= (1,7,0,''). Um, what about lines 71-74 [1] does not do this? Yeah the check is the other way, but it has the same effect. Added in changeset 7423 [2] three weeks ago. [1]: http://code.djangoproject.com/browser/django/trunk/django/contrib/markup/templatetags/markup.py#L71 [2]: http://code.djangoproject.com/changeset/7423 > > Also, and probably more important: markdown allows HTML to be passed > in and spit out; the markdown filter marks output as safe. Is it an > intended design choice to have applying the markdown filter result in > unescaped output? Perhaps this side-effect should be noted in the > docs[2]? > Yeah, we probably should mention this in the docs, along with an explanation of how to enable Markdown's safe_mode. Sure, it's explained in the source, but the other markup filters don't offer any extra features so I doubt most people even look unless they encounter a problem. -- 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: QSRF Related
On Tue, Apr 29, 2008 at 1:55 PM, David Cramer <[EMAIL PROTECTED]> wrote: > > 3) This is a pretty major change to Django, and there's nothing on the > page that says "HEY WE JUST CHANGED THE ENTIRE DBAPI ALL YOUR HACKS > WILL BREAK" (I didn't even know QSRF was released until someone > pointed it out to me) > Evidently you missed it, but an announcement was posted both to the users and dev list with links to the updated docs and backward compatibilities etc. You can read that announcement here[1]. It (and the provided links) should answer all (most?) of your questions. [1]: http://groups.google.com/group/django-developers/browse_thread/thread/f4cd02d8d9389669 -- 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: django.contrib.sessions problems
On Tue, Apr 8, 2008 at 4:25 AM, mrts <[EMAIL PROTECTED]> wrote: > > On Apr 8, 12:53 am, Malcolm Tredinnick <[EMAIL PROTECTED]> > wrote: > > > > Agreed, but as previously described, there should be a way to override > > > the default behaviour and retain session data if needed. > > > > No, I don't see any need for this at all. Once you've logged out, the > > session is over. Stuff you want to keep beyond that is not session data. > > So you think "fill your shopping cart, login then logout" should empty > the shopping cart? This feels counter-intuitive, but it doesn't bite > me personally, so dismissing this case is fine by me. > No, as discussed earlier, upon login the data (shopping cart) *should* become associated with the user, not the session. So upon logout, the data is not lost as it is not connected to the session. To the user the data (cart) may *appear* to be lost because they logged out and no longer have access to the user's data, but upon logging in again, they would be able to access it again. Of course, for this to work one would need a carefully crafted model (again as mentioned previously). The data (shopping cart) would need to be attached to the session for anonymous users, but attached to the user for logged in users. Part of logging a user in would be to make that transition of the data from session to user. Then deleting session data on logout becomes a non-issue. -- 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: GSoC2008 Proposal
Have you seen the dbsettings [1] app? If I'm understanding you correctly, it does everything you want. [1]: http://code.google.com/p/django-values/ On Fri, Mar 28, 2008 at 8:15 AM, Alberto García Hierro <[EMAIL PROTECTED]> wrote: > > Hi Django developers, > In first place, let me introduce myself. I'm a free software > developer, mostly focused on PDAs running Linux. I think 90% of the > code I've wrote in my live has been in C, but I've loved Python since > the day I discovered it, five years ago IIRC. > A few months ago I got greatly interested in recommendation systems > applied to social news sites and finally decided to write one of such > sites. That's how I found Django. And let me say it's awesome, almost > everything from the database layer to the templates worked fine for > me, even when I was doing unusual things like ordering the items at > the application level, bypassing the QuerySets. > > Currently, I'm finishing my studies in Informatics (that's how we > call CS here in Europe). If everything goes well, I'll finish them in > September :). > > Well, now let's start with my proposal. I'm also developing a Django > based blog and the biggest annoyance I found is they're no way to set > app specific settings and exporting them to the template without > writing a wrapper for render_to_response (or whatever you use for > rendering your templates) or writing a custom context processor. Both > approaches require to write some boilerplate code, which, having > worked a lot with GLib/GObject, is something I really *hate*. On the > other hand, I also think it annoys the user. Imagine I set up a blog > for someone at one of my servers, but I don't want to give him shell > access. How can he change the blog title or subtitle? Definitely, he > can't do it unless I write some code which modifies settings.py and > reloads it. Not a good solution in my opinion. > > So, I thought that writing a solution for this problem could be both > useful for a lot of people and also make a good GSoC project. My idea > is adding a new (optional) file to the Django apps, specifying some > settings with the default values and if they should be exported to the > template engine. These settings would be kept in the database, > avoiding the requirement for writing to settings.py. However, since > some of these values would be read for every request, caching them and > invalidating the cache (or renewing it's value) when they change seems > logical. In addition, since they won't be a lot of data, that cache > could use a simple dict structure when no cache engine is present. The > project would also include any needed modifications to the admin > interface, so users can edit application settings from it. > > ¿What do you think about it? > > P.S. : Sorry if you get more than one copy of this message. I'm having > problems with my mail server. > > > Regards, > Alberto > > > -- 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: Django + SQLAlchemy as a potential GSoC project
On Mon, Mar 24, 2008 at 5:19 PM, Ben Firshman <[EMAIL PROTECTED]> wrote: > > > On 24 Mar 2008, at 20:48, Rob Hudson wrote: > > > > On 3/24/08, James Bennett <[EMAIL PROTECTED]> wrote: > >> > >> On Mon, Mar 24, 2008 at 3:23 PM, Ben Firshman <[EMAIL PROTECTED]> > >> wrote: > >>> Would proposing a complete replacement be a tad too controversial > >>> for a GSoC > >>> project? > >> > >> > >> Yes. It also wouldn't succeed as a project, because it's the Google > >> *Summer* of Code, not the Google Several Years of Code. > > > > And it sounds like 'empty' and 'brosner' are making good headway on > > it... > > http://blog.michaeltrier.com/2008/3/21/django-sqlalchemy > > > > Yes, but that is intended as purely a separate plugin, not as > something part of Django. The code is there, it would just be a matter > of figuring out the logistics (and politics!) of working it into the > official distribution. > You might want to go read some of the old threads on this list about the branch. IIRC, with queary-set refactor coming the core is not likely to ever include support for an sqlalchemy backend. The core devs have indicated that if and when is matures, it will remain a third party plugin. At most it could be distributed as a contrib app (or similar) with the distribution. Again, this is my recollection, so I could be a little off. The archives should shed more light in that. -- 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: How to stop spam on our groups
On Jan 16, 2008 1:27 PM, Jorge Gajon <[EMAIL PROTECTED]> wrote: > > On Jan 16, 2008 8:57 AM, Jay Parlar <[EMAIL PROTECTED]> wrote: > > > > On 1/12/08, Ned Batchelder <[EMAIL PROTECTED]> wrote: > > > > > > The moderation could be done by member(s) whose time wouldn't be spent > > > enhancing django. I used to volunteer on python.org to maintain the > > > Python Jobs Board, because I wanted to help out, but I wasn't able to > > > contribute in ways that other people already were (sysadmin stuff). > > > Perhaps if there were two or three people who cared about Django but > > > were not otherwise engaged in the improvement of Django, they could help > > > by taking the moderation and/or cleanup task off the shoulders of the > > > maintainers. > > > > > > The problem with this scheme is finding people who will do it reliably, > > > and won't suddenly drop off without warning. > > > > Any estimates as to how much time would be required? I've been > > following -dev and -users since the summer of 2006, and would be happy > > to help. Haven't really posted in 6 months or so, as I'm not currently > > working on any Django projects, but I do read the lists every day. > > > > Same with me, I'm a long time Django user -- still running a couple of > projects on Django 0.90 -- and although I haven't participated in the > lists for quite a while I do read them daily. > > I'd gladly volunteer as a moderator. > Same with me. I'm also a long-time reader with little participation. Although I only subscribe to the digest for the users list, I read every dev message daily. I'll volunteer as a moderator at least for the dev list -- 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: Django Model Inheritance
On Dec 29, 2007 8:49 AM, Sridhar Ratnakumar <[EMAIL PROTECTED]> wrote: > > [that link is going down -- hence, I'm pasting the contents below] > Your willingness to share is much apprciated. However, things tend to become quickly forgoten and lost in the list. Not that we do so on pupose; that's just the nature of the beast. If you are providing a patch, I'd suggest opening a ticket [1]. If you are simply providing a snippet to help other users solve a problem, I'd suggest posting it to djangosnippets.org [2]. For something more involved than a simple snippet, perhaps adding a page to the appropriate section of the wiki [3] would be more helpful. [1]: http://code.djangoproject.com/simpleticket [2]: http://www.djangosnippets.org [3]:http://code.djangoproject.com/wiki/DjangoResources -- 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: Django 1.0 features -- the definitive list
On Dec 4, 2007 10:31 PM, James Bennett <[EMAIL PROTECTED]> wrote: > > On 12/4/07, Ned Batchelder <[EMAIL PROTECTED]> wrote: > > I don't have a suggestion for a replacement, and I don't think it needs to > > be on the 1.0 list (since it can be added without breaking backward > > compatibility), but I think it would be a big plus. > > While I actually like the power and flexibility of regex-based > dispatch, I wouldn't mind seeing something like Joe Gregorio's URI > Templates[1] as an option. That would offer a nice balance between > power and conceptual simplicity, and once it (hopefully) becomes a > published RFC it'd be nice to support the standard. > > [1] http://bitworking.org/news/URI_Templates > Selector[1], a raw WSGI middleware for url dispatching, uses something almost exactly like this. Although, there are a few things we obviously wouldn't want, it provides a decent starting point. I'd suggest ignoring all the "updates" and scrolling down to the basic tutorial at the bottom of the page for the general idea. [1]: http://lukearno.com/projects/selector/ -- 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: from django.template import Template, gives me this output
I'd suggest reading the docs. If your trying to use the template
system by itself. This [1] should answer your question.
[1]:
http://www.djangoproject.com/documentation/templates_python/#configuring-the-template-system-in-standalone-mode
On Nov 30, 2007 3:29 PM, firedancer <[EMAIL PROTECTED]> wrote:
>
> Hi, I just started my django quest,
>
> but when i started the "Template" part , i found out that not
> everything is set correct .
> this is it :
> >>> from django.template import Template
> Traceback (most recent call last):
> File "", line 1, in
> File "/var/lib/python-support/python2.5/django/template/
> __init__.py", line 918, in
> add_to_builtins('django.template.defaultfilters')
> File "/var/lib/python-support/python2.5/django/template/
> __init__.py", line 915, in add_to_builtins
> builtins.append(get_library(module_name))
> File "/var/lib/python-support/python2.5/django/template/
> __init__.py", line 904, in get_library
> mod = __import__(module_name, {}, {}, [''])
> File "/var/lib/python-support/python2.5/django/template/
> defaultfilters.py", line 5, in
> from django.utils.translation import gettext
> File "/var/lib/python-support/python2.5/django/utils/translation/
> __init__.py", line 3, in
> if settings.USE_I18N:
> File "/var/lib/python-support/python2.5/django/conf/__init__.py",
> line 28, in __getattr__
> self._import_settings()
> File "/var/lib/python-support/python2.5/django/conf/__init__.py",
> line 53, in _import_settings
> raise EnvironmentError, "Environment variable %s is undefined." %
> ENVIRONMENT_VARIABLE
> EnvironmentError: Environment variable DJANGO_SETTINGS_MODULE is
> undefined.
>
>
> i'm new to using django ,
> i would like to proceed with it ,
>
> your help will be more then appreciated
>
> firedancer
>
> >
>
--
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
-~--~~~~--~~--~--~---
Add extension support to Markdown filter (ticket #2910)
Unfortunately, I won't be available for the sprint this weekend (except maybe an hour or two). Anyway, ticket #2910 [1] (Add extension support to Markdown filter) has been around for more than a year and now that auto-escaping has landed, I feel is ready for checking in - that is assuming the core devs what to add the feature. So, could someone look at this during the sprint if you have time? If, for some reason the decision is made to not include it, we'll maintain a copy with python-markdown and I'll probably slap a copy up on django-snippets. That said, I'd rather see it included. The list of publicly available extensions [2] is growing (I have a few more in the works) and I know that many people have unreleased extensions they're using privately. A search of django-snippets will turn up a few snippets that are manipulating markdown output without using extensions - mostly because django doesn't support markdown extensions out of the box (there are a few legitimate exceptions). Thank you. [1]: http://code.djangoproject.com/ticket/2910 [2]: http://www.freewisdom.org/projects/python-markdown/Available_Extensions -- 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: Would a web search be a good addition to the contribs framework?
The contrib apps are just normal django apps that happen to be included with the core. Generally, developers simply develop them as a third party app, and if the demand is there and the core devs like/approve it, the app gets added as a contrib app. That decision usuualy only happens after the app exists and is proven. So my suggestion would be to just write your search app as a normal django app and see how things go from there. Most devs use google code (search the existing projects for lots of examples) to track their projects, but other similar systems would work as well. On 10/1/07, shabda.raaj <[EMAIL PROTECTED]> wrote: > > It looks to me that a api to get web search functionality in Django > would be good idea. For example, I generally want to keep track of the > pages linking to my sites. Similarly being able to search from inside > of django might be useful in many cases. > Would a web search be a good addition to the contribs framework? I am > willing to code this. But before doing that, I just want to make sure > it would be useful to people :) > (I just plan to add convinient api for webservices found at > http://developer.yahoo.com/search/ ) > > > > > -- 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: Looking for discussion on #5535
The following are assumptions I would make if both "worked". > UserProfile.objects.get(user__id=3) #Currently works This is obviously a foreign key and clearly refers to the id field of the User model. Nuf' said. > UserProfile.objects.get(user_id=3) #Currently does not work There is no indication here as to whether this refers to a foreign key or not. Change the model to something other than User (which has a know convention) and I would assume this is referring to a user_id field of the UserProfile model. True, the foreign key is most likely stored in a user_id column in the db, but a quick glance at the above query provides no indication of that. It could just be a poorly named column with no relation to User. If it does, in fact, point to a foreign key, my assumption would be that a lighter/faster SQL statement would be generated avoiding the need to access the User table. More likely, the same SQL would be generated for either, so this is just misleading. So among the two above examples, leaving things alone is less confusing, as Marty Alchin points out. However, the ticket also seems to indicate that this works: UserProfile.objects.create(user_id=3) Which is not so consistent. I get the impression that this is the motivation for dcramer's argument. If is works for create, why not for get? Perhaps it shouldn't work for create either, although we probably don't want to go there for backwards compatibility issues. Just my $0.02 -- ---- 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: Time for a new release?
On 8/25/07, James Bennett <[EMAIL PROTECTED]> wrote: > > So I'd ben tentatively -1 on doing a release, and more interested in > finding a solution to the documentation problem -- we're going to need > that solution anyway, or else we're going to end up in hot water every > time there's something new in SVN that doesn't work in the previous > release. > I think James has a point. When we hit 1.0, the primary (first to be seen) documentation should be for the latest release, not trunk. Might as well start doing that now. I've just done a 180 on this. Lets get the docs right, and release only when we're ready. -- 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: Time for a new release?
On 8/25/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > > Hi guys, > > I've been wondering of late if we need to cut a new release. I have a > few reasons: > > 1) Its been six months since the release of 0.96, and we've made some > good progress since then; Looking at the wiki, I couldn't help but notice that the list of BackwardsIncompatibleChanges since the last release is longer than any other. If the list gets to long, it can make it a real headache to upgrade for those who only use official releases. Just a thought. -- 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: auto_now_add overwrites a given date
If your using auto_now_add, then you should want the date auto-populated *every* time. If that is not the behavior you want, then writing you own save method can easily give you the behavior you want. Actually, in your case, you probably want auto_now_add's behavior all the time. That is with the one-time exception of importing your old data. The thing is, auto_now_add's inclusion or exclusion from the model has no effect on the db, so while running your import script you could have commented out or removed the reference to auto_now_add and added it back after the script was done. Not that big of a deal considering you'll likely never run that script again on that model. On 7/4/07, Noam <[EMAIL PROTECTED]> wrote: > > Hello, > > I wrote a script to convert from an old database (turbogears) to > django. It involved a few loops like this: > > for oldm in messages: > newm = models.Message() > newm.date = oldm.date > newm.text = oldm.text > newm.save() > > After running the script, I discovered that all the messages in the > new DB had the same date. This was very strange, because everything > else was ok. This was even more strange, because this worked fine: > > >>> m = models.Message.objects.get(id=1) > >>> m.date = datetime(2007, 4, 4) > >>> m.save() > > It took me a very long and unpleasant hour to discover that it was > because the date field had auto_now_add=True. I fixed my script, so > now the loop looks like this: > > for oldm in messages: > newm = models.Message() > newm.text = oldm.text > newm.save() > newm.date = oldm.date > newm.save() > > The conclusion is that auto_now_add should set the date only if it is > None. Or, another solution: it should set the date upon instance > creation, not upon saving. > > Do you agree? > > Noam > > > > > -- 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: Shared memory across processes
Another problem with a file is that you generally have to rewrite the entire file to update just one value. Suppose process A has read the filed, then process B reads the file. Then process A updates value FOO and overwrites the file. Process B then updates value BAR and overwrites the file. The problem is that process B wasn't aware of the changes made by process A, so the new value for FOO is lost. Sure, you could create some file locking mechanism, by why? Databases address those issues and are very good at it. On 6/26/07, Marty Alchin <[EMAIL PROTECTED]> wrote: > > On 6/26/07, David Danier <[EMAIL PROTECTED]> wrote: > > Or why not use a python-file as "cache"? AFAIK Django already reloads > > the settings-file if is has changes. So why not use this and put the > > settings generated from the DB there (or in some file imported in > > settings.py). A post_save-handler in the settings-module should do the > > rest... > > Sorry if this is stupid and I miss some bigger picture here. ;-) > > I could use a file as cache, yes, but what you're dsecribing wouldn't > really work well in production environments. To my knowledge, Django > reloads itself in its entirety if any loaded modules are changed, not > just a single file. Sure, these things will change rarely enough that > it might be tolerable, but the goal of the project was to avoid > restarting the server, and this method would do exactly that. > Additionally, the autoreload option isn't always available depending > on your setup. > > That said, mod_python does provide its own autoreloading import > system[1], which could probably be used for this, I suppose. By doing > it that way, it would only reload the one file, which should happen > pretty quickly. It's definitely an approach I hadn't considered, so > I'll add it to the list of options. > > -Gul > > [1] > http://www.modpython.org/live/mod_python-3.3.1/doc-html/pyapi-apmeth.html#l2h-32 > > > > -- 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: Shared memory across processes
Carl, Thats application settings which are stored in a db (thus dbsettings - with no space). See http://code.google.com/p/django-values/ for more info. Marty, I have not yet used your app (although I had intended to until I read this) so I assumed you had worked this out already. The thing is, if each process has to look to a central location to retrieve/update, why not use the db as that central location? Perhaps the way to go is to have an option to turn caching on or off. Then, when deployed, the user could use one of a few pluggable backends (your current implementation, memcached, etc) to get caching to work. That way, in the simple case, caching is turned off and it's not an issue. In the more complex cases, the user can choose the caching mechanism that he can provide the dependencies for if need be. On 6/26/07, Carl Karsten <[EMAIL PROTECTED]> wrote: > > Marty Alchin wrote: > > I expect this isn't the best way to ask this, but this is where the > > dbsettings saga has played out so far, and you guys have a good idea > > of what I'm trying to do, so I'm asking anyway. > > > > The biggest hurdle to dbsettings at this point is that it caches > > settings in a standard Python module, which only exists within a > > single process. This was all well and good while developing it, but > > people are now starting to try it under mod_python, which (depending > > on the Apache MPM) creates multiple processes, each with their own > > dbsettings cache. This is fine except when editing settings, since it > > can only update the cache in the current process. > > > > I did a bit of research on this topic, and it seems to be a fairly > > prickly issue. I obviously can't restrict people to mpm-winnt[1], so > > something would have to be done as part of the application. I > > considered simply requiring projects to use Django's cache framework, > > but the only backend that would really do the job is memcached, and > > that again adds another dependency for what should be a simple > > application. > > > > I considered locmem, but as far as I can tell, that's just a > > thread-safe version of simple, so it still doesn't share memory across > > processes. I've also found information on POSH[2] and ZODB[3], but I > > really don't like the idea of relying on yet another dependency for > > this. I'll probably look into both of those to see if there's anything > > generic I can pull out though. > > > > Has anybody on here ever had a need to do something like this? If so, > > are there other decent solutions available? > > > > -Gul > > > > [1] http://www.modpython.org/pipermail/mod_python/2006-August/021939.html > > [2] http://sourceforge.net/projects/poshmodule/ > > [3] http://www.zope.org/Products/ZODB3.2 > > > > Forgive my ignorance, but this doesn't seem like a problem that will come up > too > often, so the solution is going to be pretty custom. > > Why would you be changing db settings on the fly? > > Carl K > > > > > -- 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: textile mysql unicode and newforms
I suspect the Unicode branch [1] addresses the issues you are having.
A few weeks back there was a call for testers as it is now feature
complete. I'd suggest giving that a try.
[1]: http://code.djangoproject.com/wiki/UnicodeBranch
On 6/19/07, vanderkerkoff <[EMAIL PROTECTED]> wrote:
>
> Hello everyone
>
> I'm running django from the trunk, so using the most up to date
> version, python 2.5 with PyTextile 2.0.10.
> mysql5.0.2 with all settings to utf-8 and django content type is utf-8
>
> I'm overwriting the save command on events using newforms, we're
> textiling the input for an html field, here's what I mean.
>
> def save(self):
> import textile
> if self.body:
> self.body_html = textile.textile(self.body)
> super(Event, self).save()
>
>
> it fails with this error
>
> Exception Value:'ascii' codec can't decode byte 0xb4 in position 0:
> ordinal not in range(128)
> Exception Location: /usr/local/lib/python2.5/site-packages/textile.py
> in glyphs, line 2418
>
> My textile settings are
> # Set your encoding here.
> ENCODING = 'utf8'
>
> # Output? Non-ASCII characters will be automatically
> # converted to XML entities if you choose ASCII.
> OUTPUT = 'utf8'
>
> I tried changing my OUTPUT to ascii in textile but got the same error,
> so to me it looks like the form is sending a unicode
> series of bytes to textile which it can't understand.
>
> One way around this is to manipulate the self.summary prior to passing
> it to textile, like this.
>
> self.body = self.body.decode('utf-8')
> self.body = self.body.encode('ascii', 'ignore')
>
> This forces the passing of ascii to textile and it likes that alot,
> and works.
>
> But if a user now copies and pastes the dreaded apostrophe form word
> or another special character unique to word,
> it fails with this error.
>
> Exception Value:'ascii' codec can't encode character u'\u2019' in
> position 5: ordinal not in range(128)
> Exception Location: /usr/local/lib/python2.5/encodings/utf_8.py in
> decode, line 16
>
>
> If I run the super save earlier in the save definition after removing
> the textiling of the body section, and then
> call the data out of the database further down in the save definition,
> and then save it again like this
>
> e = Event.objects.get(id=new_id)
> if e.body:
> e.body_html = textile.textile(e.body)
> super(Event, e).save()
>
> It all works fine, no encoding or decoding needed for pasted
> apostrophes or anything.
>
> Here's the paste of the relevant part of the form with certain
> sections commented out so you can see what I mean.
>
> http://pastie.textmate.org/71702
>
> I found this on the google groups form Ivan Sagalev
> To summarizes: your storage (a database) and your input/output (the
> web)
> really should use utf-8 to avoid problems with "strange" characters.
> If
> you deal internally with unicode (which newforms produce for you) then
> for now you should explicitly encode from it to utf-8 until Django
> starts doing it automatically.
>
> I've also been reading this thread on the google developers group, and
> I'm now completely confused as to what is going on.
>
> unicode issues in multiple tickets
>
> If anyone can tell me if there is some current status on this, or how
> it works right now I'd be really grateful. If I have to encode and
> decode then I
> don't mind, not much anyway :-)
>
>
> >
>
--
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: PhoneNumberField
On 6/13/07, Tai Lee <[EMAIL PROTECTED]> wrote: > > i'd like to see a single generic phone number field, and different > methods attached to it that format it to the required formats. usa, > international, including or excluding country code, using spaces or > dashes, with or without leading zeroes, etc. > This can all be done with a basic CharField in the model and some custom newforms widgets. Which brings the question, why do we even need a PhoneNumberField at the db level? Although I suppose it helps with the admin, form_for_model, etc. -- 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: Can django support easy_install
It appears that this is part of a Goggle SoC project. See this thread for more: http://groups.google.com/group/django-developers/browse_thread/thread/9fe1c3f8dd6f6099/ On 6/4/07, kernel1983 <[EMAIL PROTECTED]> wrote: > > Setuptools is a powerful tools for python. > > When could django support it? At Version One? > > > > > -- 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: Optgroups from nested choices in newforms (discussion of patch on #4412)
On 5/31/07, Honza Král <[EMAIL PROTECTED]> wrote: > Has anything changed since Adrian ruled optgroups as unwanted? > > see > http://code.djangoproject.com/ticket/3262 > and Well, his comment there indicates that the lack of need would not justify an additional widget. As James mentions, #4412 does not introduce an additional widget. > http://groups.google.com/group/django-developers/browse_frm/thread/b27f19d932c84316/37a4fa049dc63733?lnk=gst=optgroup And unless I'm missing something, Adrian's comment in that thread seems to indicate the having optgroups would be a welcome addition. I take that to be a yes to optgroups as long as they don't require an additional widget, but I could be wrong. > > On 5/31/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > > > > On 5/31/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > > > > > (Cleaning up some flagged items I've been meaning to respond to...) > > > > > > On Tue, 2007-05-29 at 03:56 -0500, James Bennett wrote: > > > > I noticed a patch sitting on #4412 tonight which seems interesting but > > > > definitely needs a decision; the idea is that, rather than > > > > implementing a separate widget or set of widgets to handle grouping of > > > > options (via the HTML "optgroup" element), the Select and > > > > SelectMultiple widgets should look at the structure of 'choices -- if > > > > it has a nested structure of grouped choices, those should translate > > > > into optgroups in the rendered widget. > > > > > > > > Personally, I kind of like the simplicity of the approach and the fact > > > > that it handles this use case without needlessly multiplying widgets, > > > > so I'd give it a tentative +1. > > > > Put me down as a +1 as well. > > > > > My only minor concern is that we are letting ourselves in for a large > > > number of queries asking why it doesn't work with models. I think it's a > > > *good* thing model fields still expect a sequence of pairs -- putting > > > presentation into the data representation is uncool -- but that won't > > > stop people trying to extrapolate. That feature should be documented so > > > that it can be properly ignored. > > > > I'm not sure I entirely agree on this. > > > > From a purist perspective, I can see the appeal of keeping the model > > _absolutely_ data based. However, I can think of two practical reasons > > why this isn't necessarily a great idea: > > > > 1) Having to double-define your choice lists - once for the model > > (without groups), and once for the field (with groups) - would get > > tiresome _really_ fast, and would be prone to introducing errors > > (modify one list, forget to update the other). There are ways you > > could avoid double definitions, but this starts to make the right > > harder than the obvious/easy way, which is just inviting difficulty on > > the users lists. > > > > 2) form_for_model can't invent groupings, so it would be impossible to > > autogenerate a form with choice groupings without falling back on a > > field callback. > > > > Given that the groups can be safely ignored on the model, I'm not sure > > I see the practical harm in allowing them in a model definition. > > > > Russ %-) > > > > > > > > > > -- > Honza Kr�l > E-Mail: [EMAIL PROTECTED] > ICQ#: 107471613 > Phone: +420 606 678585 > > > > -- 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: database connection user - newbie question
On Thu, 2007-05-10 at 22:58 +, [EMAIL PROTECTED] wrote: > > I think what you're overlooking is that in some cases the issue of > whether its the "best solution" is irrelevant. If the database is > already in production or the policies are already set or controlled by > an external entity, then debating the merits of the single DB, single > connection philosophy is pointless. > > Since we're all into historical anecdotes :) lets take a look at the > COM/CORBA school of thought. What you seem to be missing is that the core devs are not questioning that. Rather, they are all in situations were they don't need multi-db support. Some here seem to have taken their explaination to mean they don't want mutli-db support. But that it *not* what they said. In fact, when the multi-db branch started (over a year ago) they seemed eager to see something they could include into trunk. Unfortunelty, that something has not materialized as noone (that needs that feauture and can therefore adequeatly test it etc.) has stepped up to the plate to finish development and comitt to long term maintanence. Remember, the core devs are all doing this in their free time not-for-pay. Therefore, they are are scratching their own itch. Your welcome to scratch yours as well. Sure, someone mentioned the possability of some money for development, but that doesn't cover the long term maintianence, which is what the core devs are looking for. This same debate has been played over and over for all of the stagnet branches and, quite frankly, I'm getting tired of the pointlesness of it all. No wonder Adrian and Jacob never (rarely?) respond to these kinds of messages anymore. --~--~-~--~~~---~--~~ 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: Generic view patch submited
On Sat, 2007-05-05 at 16:09 -0300, Mi Reflejo wrote: > I don't know which is the way to submit patches, i just added a ticket > with the attachment (http://code.djangoproject.com/ticket/4225). > > Is this the right way?. > Yes. For specifics see the docs [1]. [1]: http://www.djangoproject.com/documentation/contributing/#submitting-patches > -- 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 -~--~~~~--~~--~--~---
