Re: When your settings module causes an `ImportError`
It seems to me like the biggest problem with a settings module not importing is that it's not safe to display a full error message about that file. You can't tell if DEBUG is on, and there may well be information in the settings that is a Bad Idea to leak on a production server. Also, as a friendly heads-up, if you need to try/catch the ImportError at some point, you'll probably want to catch SyntaxError too. They're pretty similar in this situation, with both roughly meaning "The module failed to load." -FM On Sun, May 16, 2010 at 11:56 PM, Russell Keith-Magee wrote: > On Mon, May 17, 2010 at 6:10 AM, cool-RR wrote: >> Hello all. >> >> This is my first time on Django-developers. >> >> I remember that a few months ago, when I was doing some Django work, >> there was something that annoyed me. I hope I'm remembering this >> correctly, please correct me if I'm wrong. It happened sometimes that >> the settings module in my project/app will cause an ImportError inside >> itself. This will be caught by the `except` in the block that tries to >> import the settings module, and this will cause it to raise another >> ImportError saying that the settings module wasn't found or caused an >> ImportError. This would make it difficult to understand how exactly >> the settings module was causing the ImportError. >> >> Is this precise? Does this still happen? > > Yes, there are places where import errors get swallowed, which can > lead to confusing or misleading stack traces. Some of these cases have > been improved in Django 1.2, but I'm sure there are many still > lurking. If you want to know if a specific case is still broken, > you'll need to test that case and let us know. > >> Because I have just implemented something that solves this annoyance >> for my own project, (which is unrelated to Django but also has a need >> to import a settings module, similarly to Django.) In my solution, if >> the settings module doesn't exist, I can get an ImportError (if I >> wish, I can also make it fail silently), but if there's an ImportError >> inside, I will have that error raised as itself, and not caught by my >> logic, making it easier to debug. >> >> I'm basically just trying `imp.find_module` before I import. > > You may want to check the newly added django.utils.module_loading; > this is a module that provides utilities for checking the existence of > modules independently of the import proces (which was the cause of > several of the import problems previously). > >> Would you have any interest in me patching Django to use this logic? > > We'd need to see the patch. Also, keep in mind that anything touching > the import logic is about 5 times harder than you think it is, even > when you take this advice into account :-) In particular, you need to > keep in mind > importing from eggs and importing from custom module loaders, both of > which behave in ways that are subtly (but significantly) different to > normal CPython module loading. The module_loading tool I mentioned > previously expanded from a 20 line method to a 60 line method because > of these differences. > > Yours, > Russ Magee %-) > > -- > 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.
Re: django template revision (for 1.4?)
I'm mostly just a user, and maybe I'm being dense, here, but I just
don't see the point of this change. Why is {%%} any harder a syntax
than {{{}}} is? Is it an issue of key placement (% is shift-5 for US
keyboards)? And why would you type {%%} and then go back to insert
the keyword when you can just type {% keyword %} straight up?
If typing it is slow (and I don't see why it would be), any editor
more complex than Notepad should be able to have a macro that drops in
{% | %}, where | is the insertion pointer. That doesn't even really
count as "changing the editor".
It seems like we're discussing the color of the bikeshed long after
the thing was already painted. There's no significant benefit to the
change (that I can see), and it's already been noted that it can break
existing behaviour. Why would we change it?
-FM
On Wed, May 26, 2010 at 11:05 PM, Mike Axiak wrote:
> Hello,
>
> Also keep in mind that the triple brackets introduce their own set of
> issues. For example, in LaTeX templates I've seen::
>
> \title{{{ publication.title }}}
>
> Which works perfectly fine right now. Would this work under your proposal?
>
> Cheers,
> Mike
>
> On Wed, May 26, 2010 at 6:28 PM, Daniel wrote:
>> Hello Gregor,
>>
>> Thanks for taking a look. My rationale is, "Why change all the
>> editors in the world for something that can be simplified with an
>> easier syntax?"
>>
>> All of the previous code using the curly-modulo syntax -- {%%} would
>> still be functional for as long as the core developers chose to
>> support it.
>>
>> The only possible breakage (as i understand it at least) would be if
>> the namespace issue I previously mentioned. That would mean people
>> have been naming their variables or tables things like "block","if",
>> etc, which would seem to be pretty poor programming practice in terms
>> of readability. Finally, the triple bracket solution would avoid even
>> that issue if creating a few keywords were to be out of the question.
>> As to your last point, I don't know how many programming languages
>> have implemented their own versions of the DTL, but if this would be
>> an improvement, as I feel it would, then it seems all such
>> implementations would benefit as well.
>>
>> Cordially,
>> Daniel
>>
>> On May 26, 5:32 pm, Gregor Müllegger wrote:
>>> Hi Daniel,
>>>
>>> I think your suggestion might make sense for some people using
>>> autoclosing brackets etc. But having better support for writing
>>> templatetags is just an issue with a text editor which might be
>>> configurable and easy to write a plugin or using a snippet completion
>>> to make life easier for you typing things.
>>>
>>> So in my opinion its unlikely that your proposal will be intergrated
>>> into django because it breaks backwards compatibility without having
>>> any functional improvement. You would need to update all existing
>>> django templates and it also breaks compatibility with implementations
>>> of the DTL in other programming languages.
>>>
>>> Gregor
>>>
>>> disclaimer: I'm not a core-developer and are not responsible for any
>>> design decisions.
>>>
>>> On 26 Mai, 20:24, Daniel wrote:
>>>
>>>
>>>
>>> > Hi, I was just referred here with a suggestion I posted on the django
>>> > ticket tracker. I've been studying the way we do template tags, and
>>> > had a suggestion for how to revise them to make them a bit easier. I
>>> > was thinking that out of the tags, I like the variable syntax the best
>>> > -- {{ variable.attribute }}. I realize that if we were to use the
>>> > double curly brackets on all of the tags, they might conflict with the
>>> > namespace, but it seems like having "block", "if", "elsif", "else",
>>> > "for", and "extends" and their respective 'end'ings as keywords would
>>> > not be burdensome. It's really unpleasant typing {%%} and left arrow
>>> > twice, space, the item name, and space for every tag and for its
>>> > closing tag.
>>>
>>> > An alternative that wouldn't affect the namespace but would still be
>>> > more convenient for both plain typing and possibly for code completion
>>> > (I don't know why eclipse pydev doesn't close these tags) would be
>>> > triple brackets -- {{{ block head }}}.
>>>
>>> > Thanks for your time,
>>> > -Dan
>>>
>>> > p.s. not sure if the code will show up appropriately in the above, but
>>> > hopefully you get the picture. Also, I'm on Windows and/or Linux...
>>>
>>> > Here's the initial reply:
>>> > -
>>> > Change History
>>> > 05/26/10 14:01:25 changed by adamnelson
>>> > status changed from new to closed.
>>> > needs_better_patch changed.
>>> > resolution set to invalid.
>>> > needs_tests changed.
>>> > needs_docs changed.
>>>
>>> > I think it's a reasonable request but this would require a rigorous
>>> > discussion on django developers newsgroup before even having a ticket
>>> > and would be more like a 1.4 thing:
>>>
>>> >http://groups.google.com/group/django-developers
>>>
>>>
Re: django template revision (for 1.4?)
Lazy *is* good. We're too lazy to change the template system without
a good reason, and so far, I haven't heard one. The current syntax is
terse and not really any more difficult to type than the
alternative(s) you've proposed. And it's not likely to appear in the
templated document, which is a Good Thing.
I'm all for streamlining the template system, because I think it's one
of the less-intuitive aspects of Django at the moment (I think PHP has
us beat, and that's really sad), but I don't see how this particular
change would be beneficial.
If you can give us a good reason, I'm sure we'd all love to hear it,
but as far as I've been able to tell, you haven't given us anything
more concrete than "I don't like {% %}." that doesn't apply equally to
your proposed change.
-FM
On Thu, May 27, 2010 at 2:07 AM, Daniel wrote:
> @Luke: I haven't used custom template tags, so I don't know the effect
> that switching to {{}} would do to that. this sounds like the first
> real issue that could just kill it.
> @Josh: it's true that my fingers won't wither away from typing {%
> stuff %}.
>
> i guess i'll spend more time studyin' pydev. switching editors every
> weekend kinda sucks, and generally with autocomplete I prefer things
> to just work.
>
> @Mike: didn't even know people were including Latex within Django.. I
> don't know Latex, and I don't really understand the example.
> something about autoescaping?
>
> @Charlie: The bikeshed should be a light blue, with white trimming. I
> kinda assumed the dev's picked modulo (yes, shift 5) since it was one
> of the more obscure buttons.
>
> whatever happened to lazy is good?
> -D
>
> On May 26, 8:43 pm, Charlie Nolan wrote:
>> I'm mostly just a user, and maybe I'm being dense, here, but I just
>> don't see the point of this change. Why is {%%} any harder a syntax
>> than {{{}}} is? Is it an issue of key placement (% is shift-5 for US
>> keyboards)? And why would you type {%%} and then go back to insert
>> the keyword when you can just type {% keyword %} straight up?
>>
>> If typing it is slow (and I don't see why it would be), any editor
>> more complex than Notepad should be able to have a macro that drops in
>> {% | %}, where | is the insertion pointer. That doesn't even really
>> count as "changing the editor".
>>
>> It seems like we're discussing the color of the bikeshed long after
>> the thing was already painted. There's no significant benefit to the
>> change (that I can see), and it's already been noted that it can break
>> existing behaviour. Why would we change it?
>>
>> -FM
>>
>>
>>
>> On Wed, May 26, 2010 at 11:05 PM, Mike Axiak wrote:
>> > Hello,
>>
>> > Also keep in mind that the triple brackets introduce their own set of
>> > issues. For example, in LaTeX templates I've seen::
>>
>> > \title{{{ publication.title }}}
>>
>> > Which works perfectly fine right now. Would this work under your proposal?
>>
>> > Cheers,
>> > Mike
>>
>> > On Wed, May 26, 2010 at 6:28 PM, Daniel wrote:
>> >> Hello Gregor,
>>
>> >> Thanks for taking a look. My rationale is, "Why change all the
>> >> editors in the world for something that can be simplified with an
>> >> easier syntax?"
>>
>> >> All of the previous code using the curly-modulo syntax -- {%%} would
>> >> still be functional for as long as the core developers chose to
>> >> support it.
>>
>> >> The only possible breakage (as i understand it at least) would be if
>> >> the namespace issue I previously mentioned. That would mean people
>> >> have been naming their variables or tables things like "block","if",
>> >> etc, which would seem to be pretty poor programming practice in terms
>> >> of readability. Finally, the triple bracket solution would avoid even
>> >> that issue if creating a few keywords were to be out of the question.
>> >> As to your last point, I don't know how many programming languages
>> >> have implemented their own versions of the DTL, but if this would be
>> >> an improvement, as I feel it would, then it seems all such
>> >> implementations would benefit as well.
>>
>> >> Cordially,
>> >> Daniel
>>
>> >> On May 26, 5:32 pm, Gregor Müllegger wrote:
>> >>> Hi Daniel,
>>
>>
Re: django template revision (for 1.4?)
My apologies, I did not intend to trigger an offtopic discussion, even
a semi-related one. My intent was merely to point out that Django's
templating system is far from perfect, and that improving it is
definitely a goal of Django, even if we reject a particular change
that may appear to be for the better. I put forward PHP as an
opposing example because, for all the flaws it has, you must admit
that the ability to use the entire host programming language in the
context of a template is both incredibly powerful and quite intuitive.
The natural counter is that, as you have pointed out, it is also
trivial to misuse, and indeed the case may be made that PHP's method
encourages (nay, nearly requires) mixing logic and presentation, which
has major disadvantages.
I did not expand that point in full in an attempt to downplay the
example, but it seems that I created the opposite effect. Again, my
apologies for that.
If we may return to the topic at hand, in my (admittedly uneducated)
opinion, Jacob is going too far to unilaterally declare that the
template syntax will not be changed, without any qualifiers. It is,
however, not a change to be made lightly, and would require a solid
reason and the support (even begrudgingly) of both developers and
users. From both my own impressions and the comments of others, this
particular change does not seem to have anything that even comes close
to a solid reason, nor does it have any apparent support beyond the
person proposing the change.
Thus, while I disagree that "We're not [ever] changing the template
syntax.", I think it's fair to say that this particular change has
been rejected for now. As Chuck pointed out, there is always the
chance that the tides will change at a later date.
If that seems like rough treatment, consider this: If the Django
project was not interested in improving itself, it would have allowed
no room for discussion at all. So while the rejection may seem to be
unanimous, as if we were all jumping in to drown you out, the reality
is that we were trying to give it a chance to win us over, and it just
didn't.
Or, more succinctly: We appreciate the suggestion and applaud your
intent, but *waves hand* "This is not the change you're looking for."
-FM
On Thu, May 27, 2010 at 12:33 PM, Tom Evans wrote:
> I never claimed it wasn't; it was stipulated that Django's template
> system wipes the floor with all others, and it is inconceivable to
> think more favourably of a different system.
>
> I was trying to point out that there are features which are available
> in other template languages, which people may consider to be superior,
> but which do not fit into the django philosophy.
>
> wrt calling functions that take arguments, allow me to re-state: in
> smarty you can call _arbitrary_ functions. Template tags allow you to
> call _specific_ functions. It's a design decision, and I'm very glad
> that you cannot in django - if you've ever had to edit ZPT, you would
> understand.
>
> At the end of the day, if you truly disagree with the syntax/style of
> django's templating engine, it is trivial these days to plug in a
> different engine.
>
> Cheers
>
> Tom
>
> On Thu, May 27, 2010 at 1:23 PM, Chuck Harmston
> wrote:
>> The inability to assign variables is an intentional design decision; one of
>> Django's core tenets is that business logic and presentational logic should
>> be separated. The template language was crafted to provide non-programmers
>> (front-end developers and designers) the ability to work directly on
>> templates without having to touch the business logic. Though there are use
>> cases where defining variables would be helpful, it's a good flag that
>> you're approaching the problem the wrong way.
>> Additionally, you can call functions that take arguments, it just takes a
>> slightly different form than you might expect: custom template tags [2].
>> This allows you to extend the functionality of the template language while
>> still maintaining the separation of business and presentational logic.
>> An interesting historical example of the above two paragraphs: the smart {%
>> if %} tag [1], which was borne of the lack of an ability to use complex
>> logic in Django templates.
>> And the important footnote: I don't mean to stifle your suggestion; quite
>> the opposite, actually! As Jacob has admitted [3], there is an occasional
>> need in the Django for designers to tell the programmers to STFU. To extend
>> the previous example: the smart {% if %} tag was originally shot down but
>> was ultimately implemented in core [4].
>> [1] http://djangosnippets.org/snippets/1350/
>> [2] http://docs.djangoproject.com/en/dev/howto/custom-template-tags/#passing-template-variables-to-the-tag
>> [3] http://groups.google.com/group/django-developers/browse_thread/thread/18bca037f10769e9/cfd908f97b44e324?lnk=gst#cfd908f97b44e324
>> [4] http://code.djangoproject.com/changeset/11806
>>
>>
>> On Thu, May 27, 2010 at 7:36 AM, Tom Evans wrote:
>>>
>
Re: Trac version field
My interpretation of the "version" field is "the most recent version in which the problem has been confirmed". If a user spots something in an older version, it could be fixed or made irrelevant in SVN, leading to a search for a problem which doesn't exist. By that interpretation, updating the version is a mark that you've tested it in a newer version and that the problem still exists as described. -FM On Thu, May 27, 2010 at 1:55 PM, Karen Tracey wrote: > I've noticed a lot of people lately updating the trac version field of to be > more recent. For example changing version from 1.0 to 1.2 or 1.1 to SVN. I > thought this field was supposed to track the version against which a problem > was written -- that is, the version of code in use by the reporter of the > problem. When that is what is kept in the field, then version can be > somewhat useful as an indication of (at least) how long a problem has been > around. It's not perfect -- someone might be using 1.2 and notice a problem > that has been around since day 1, but it is something. > > I'm not sure why people are feeling it is necessary or helpful to change > this field? If a ticket was opened against version 1.1 and is still open, > then we can reasonably assume that it's still a problem in 1.2 and current > SVN. (If it is not, then the ticket should just be closed as fixed.) It's > not necessary to update the version to reflect that an old still-open > problem is still present in current trunk, and I see this kind of update as > generally unhelpful since we lose easy access to the information that the > problem is in fact long-standing and not newly-introduced. I find having > some sense of hold old a problem is to be helpful when looking at fixing it, > since if it is in fact new I'll probably try to figure out what has changed > to cause the breakage whereas if it's been around forever I know that sort > of investigation is not likely to be helpful. > > I don't see any place in the contributing doc that mentions what version is > supposed to be set to, so perhaps my understanding of what it is supposed to > be is just wrong. So I figured I'd post here and ask: what do others view as > the purpose of this field? > > Karen > > -- > 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.
Re: Trac version field
> That doesn't make any sense since a fixed bug would be closed. Not until after time is spent trying to reproduce/understand the bug. If you know when it was last seen, you can confirm that you are triggering it correctly, but that it no longer exists in the current version. >> interpretation, updating the version is a mark that you've tested it >> in a newer version and that the problem still exists as described. > > That doesn't add any information but it rather removes information (in > what version the bug was first found). I wasn't aware that Trac was in the habit of discarding old information. In fact, I get the distinct impression that it specifically states "version changed from 1.0 to SVN." in the change history, and that this would be easy to locate with your browser's in-page search function. -FM -- 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: GSOC 2010: App Loading - Week 1
I think that http://code.djangoproject.com/ticket/13480 may be relevant to your interests. -FM On Fri, May 28, 2010 at 8:22 AM, Arthur Koziel wrote: > Hey there, > > my name is Arthur Koziel and I'll be working on the app loading refactor for > this year's gsoc program. I'm currently a business informatics student in > dortmund, germany and working towards my bachelor's degree. > > I didn't get any coding done this week. I attended the djangocon.eu > conference in berlin and used the chance to discuss the project with my > mentor (Jannis Leidel) in person. However, I've uploaded part of my proposal > to my website [0]. It would be great to get some feedback on that. > > So, what's up for next week? tests! The current app loading implementation > doesn't have any tests and it's important to have the current implementation > properly tested in order to validate the refactored code later on. > > The code will be available in the 'soc2010/app-loading' branch in django's > svn repository [1]. I'll be posting a weekly progress report each friday on > this mailing list. > > Arthur > > [0]: http://www.arthurkoziel.com/gsoc2010/proposal.txt > [1]: http://code.djangoproject.com/svn/django/branches/soc2010/app-loading/ > > -- > 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.
Proposal: Nice(r) error messages when a user-provided module fails to load
It was suggested in bug #13480 that I raise this issue "during the 1.3 feature discussion phase", which we seem to have entered. Essentially, the issue is that a typo in my_app/views.py or any of its dependencies can raise an error on module import and break the entire site, leaving the user with a completely uninformative webserver-provided error page. This error page is /not/ the one provided by Django when DEBUG is enabled in settings.py. Effectively, DEBUG is locked off for this type of error. It's also possible that the standard non-DEBUG error page mechanisms are bypassed as well, but I have not tested this. Adding either of following two lines to the start of my_app/views.py will trigger this behavior: import djagno # ImportError print print "Hello, world!" # SyntaxError. Attached to bug #13480 you will find a proof-of-concept patch that catches both of these errors and reroutes them to the standard (i.e. DEBUG-respecting) error mechanisms. I call it a proof-of-concept because I took the minimum steps necessary to solve the problem as I experience it. Django as a whole might be better served by a more comprehensive solution... or simply one written by someone who has enough experience with Django's internals to see the Right Way to handle things. You are, of course, welcome to use the patch as written if you find it adequate. As I mentioned to Arthur Koziel a few days ago, a cursory glance at his GSoC summary suggests that there may be some overlap between that and this change. I'm not sure whether that's important to this proposal or not. -FM -- 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: Proposal: Nice(r) error messages when a user-provided module fails to load
On Thu, Jun 3, 2010 at 4:38 AM, Russell Keith-Magee wrote: > [...] > Regarding #13480 specifically -- I haven't dug into the problem in > detail, but the approach of telling exceptions apart by inspecting the > number of arguments doesn't fill me with joy. One of the changes in > 1.2 was to improve the ability to distinguish between import errors > caused by missing modules, and import errors caused by problems with > the module being imported; I'd like to think that we are now in a > better position to report the underlying cause of ImportErrors rather > than trying to wrap them. Actually, the check against len(e.args) isn't intended to tell errors apart, just to avoid IndexError when we do check. The real test is the one just after (isinstance(e.args[1], ImportError)). Strictly speaking, len(e.args) could test for < 2, but using < 3 adds a little sanity checking for free. On the other hand, I freely admit that it's not the most elegant solution, hence my continuous grumblings to the effect of "It's a proof-of-concept; feel free to change it!" I put the patch together for two reasons: 1. To solve the immediate problem I had. 2. Because IRC wasn't certain that it was fixable without a major rewrite of Django. Elegance and the Right Way to do things don't factor in to either of those, so I hacked together a quick-and-dirty patch that sufficed. > Also - the patch appears to be against 1.0.2; does the patch still > apply to trunk? 1.2 saw a number of changes to the view handling and > the module loading code, so it wouldn't surprise me if the patch no > longer applies. Per the bug, "Code inspection suggests that the problem still exists in SVN, and the attached patch applies to SVN successfully, albeit with some grumbling about the line numbers being wrong." I also gather that axiak, who bumped the bug version to SVN, tested the patch to see how it worked, presumably against trunk. I have not personally tested it in action against trunk, but all signs point to it working. > [1] http://code.djangoproject.com/wiki/BetterErrorMessages The issues listed there all appear to be cases where error messages are given, but are insufficient or misleading. This issue is, to my mind, somewhat more severe, because no error message is shown to the developer at all. Django itself crashes, the webserver spits out an error, and the real error gets hidden in the server logs. > I'm not convinced there will be a strong overlap here. I'm sure > Arthur's code will probably overlap - after all, he is dealing with > model loading - but I don't see that what he is doing directly relates > to the errors that are raised during loading. I wouldn't be at all > surprised if his new importer just inherits whatever error handling > already exists. Makes sense. Still, it's a good idea for the two to be aware of each other, to avoid stepping on each other's toes more than necessary. -FM -- 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: Decision for ticket #6362 - Remove blank spaces with strip when validating the data
I tend to agree that #6362 should be reconsidered. Realistically
speaking, almost all form fields aren't going to want leading or
trailing spaces. The default case, therefore, should strip them,
while allowing the app writer to override that behaviour in the small
minority of cases where the whitespace is actually important.
Standard design principle: "Make the common case easy, and the
uncommon case possible." I have yet to write a field where keeping
the whitespace would be useful, and have written many where it could
cause problems.
-FM
On Thu, Jun 3, 2010 at 7:12 AM, Thomas Guettler wrote:
> On "strip keyword arg for CharField"
>
> From http://code.djangoproject.com/ticket/4960
> 09/14/07 11:28:49 changed by adrian
> {{{
> Marking as wontfix -- it's too specialized for inclusion in the main library.
> A bunch of us in #django-sprint agreed.
> }}}
>
> We should think about this decision again. The cc list of #6362 is quite
> long. A lot of people (and me)
> want something like this. Ten characters (strip=True), I don't want to type
> more for this, since I would
> use it for 98% of all my CharFields.
>
> Thomas
>
> Steven Davidson wrote:
>> Loving v1.2, my first experience with Django: thanks for all the hard work!
>>
>> However this issue has bitten me twice now. I know it is entirely my
>> responsibility to validate and clean user input as required but I really
>> can't think of a valid use case where trailing white space would occur.
>> Also it can snag a 'feature' in MySQL with unique indexes ignoring
>> trailing spaces for comparison purposes.
>>
>> Any chance of a decision on whether this should appear in 1.3 and in
>> what form?
>
>
> --
> Thomas Guettler, http://www.thomas-guettler.de/
> E-Mail: guettli (*) thomas-guettler + de
>
> --
> 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.
