Why was the ENABLE_PSYCO setting removed?
Hey everybody, I googled and looked into the changeset, but I couldn't find anything about why the setting was removed... I'm not trying to criticize the change, really, but unlike many other changes there doesn't seem to be a discussion in django-developers on file or anything and I find the release notes a bit cryptic, saying "If you still need to use this...". In what way is it not desirable anymore? IIRC, when the patch was first proposed it was said that it sped Django up at about a factor of 2.0, so if somebody could shed some insight on this decision I'd appreciate it very much. Thanks, keep up the good work and best regards from Germany, Jonas --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Why was the ENABLE_PSYCO setting removed?
On Mar 25, 1:18 pm, "yi huang" <[EMAIL PROTECTED]> wrote: > On 3/25/07, Jonas Maurus <[EMAIL PROTECTED]> wrote: > > > > > Hey everybody, > > > I googled and looked into the changeset, but I couldn't find anything > > about why the setting was removed... I'm not trying to criticize the > > change, really, but unlike many other changes there doesn't seem to be > > a discussion in django-developers on file or anything and I find the > > release notes a bit cryptic, saying "If you still need to use > > this...". In what way is it not desirable anymore? > > > IIRC, when the patch was first proposed it was said that it sped > > Django up at about a factor of 2.0, so if somebody could shed some > > insight on this decision I'd appreciate it very much. > > > Thanks, keep up the good work and best regards from Germany, > > Jonas > > Because you can use middleware to do > that.http://code.djangoproject.com/wiki/PsycoMiddleware > > --http://codeplayer.blogspot.com/ man, now I feel stupid :-). I didn't realize that someone already implemented this and the size of the middleware-class clearly suggests why it's the right decision to do it this way. Thanks for your quick reply. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Newforms: colon after label
On Mar 27, 11:39 pm, "SmileyChris" <[EMAIL PROTECTED]> wrote: > On Mar 28, 9:03 am, "vfoley" <[EMAIL PROTECTED]> wrote: > > > Hello, > > > I rewrote the forms portion of an application by using newforms. It's > > pretty nice, however there is something extremely annoying: newforms > > automatically adds a colon after labels (hopefully, my formatting is > > correct): > > This is the way that it has been decided to handle the labels in the > "lazy" methods. You aren't forced to use these methods. > > > P.S: This code is from 0.96, I haven't checked the Subversion tree. > > You won't see any difference, except that I have a ticket which will > only add the colon if there is no other punctuation to be added soon. > Hrm... I guess a ' ' could be added to my check for punctuation, in > which case it would leave the colon off if you ended in a space. Meh, > maybe that's a bit to "magic". I think that this is a very bad solution. If the framework does something small magically, like adding a colon, there has to be a way to remove it without a *big* change like, for example, writing a custom template, referencing every form-field by itself, just to remove a colon. Also, there simply are languages where this punctuation doesn't make sense. Adding it automatically then telling international users that they have to write a lot more code, because english developers wanted to save one character is bad, I think. Imho, adding even more magic to make it go away, makes even less sense. Not to mention that there are a lot of layout choices that would make this colon superfluous. What's wrong with name = forms.CharField(label='Your name:')? I'd definitely go for removing this altogether before it's to late. Best regards from Germany, Jonas --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Newforms: colon after label
On Mar 29, 2:07 pm, "bromer" <[EMAIL PROTECTED]> wrote: > On Mar 29, 1:38 pm, "Jonas Maurus" <[EMAIL PROTECTED]> wrote: > > > Also, there simply are languages where this punctuation doesn't make > > sense. Adding it automatically then telling international users that > > they have to write a lot more code, because english developers wanted > > to save one character is bad, I think. Imho, adding even more magic to > > make it go away, makes even less sense. > > > Not to mention that there are a lot of layout choices that would make > > this colon superfluous. > > > What's wrong with > > name = forms.CharField(label='Your name:')? > > > I'd definitely go for removing this altogether before it's to late. > > I think there are lots of situations where you need to normalize the > labels with some string. Why not just make it an optional parameter to > the Form class with a default value.. maybe ":"? > > Rune so that would make name = forms.CharField(label='What role do you want to play?') into name = forms.CharField(label='What role do you want to play', punctuation='?') for *sometimes* saving you from typing one character? I still think it makes no sense to append anything at all. Not to mention the pending unicodization... the Japanese, Chinese, Korean and Cyrillic alphabets don't use western punctuation... Unless there's a better argument than sometimes saving one character or being backwards-compatible to 0.96, I'm still against this. However, I don't carry much weight around here ;-) cheers, Jonas --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Newforms: colon after label
On Mar 29, 3:10 pm, "Todd O'Bryan" <[EMAIL PROTECTED]> wrote:
> On Thu, 2007-03-29 at 13:02 +, Jonas Maurus wrote:
> > > I think there are lots of situations where you need to normalize the
> > > labels with some string. Why not just make it an optional parameter to
> > > the Form class with a default value.. maybe ":"?
>
> > > Rune
>
> > so that would make
>
> >name = forms.CharField(label='What role do you want to play?')
>
> > into
>
> > name = forms.CharField(label='What role do you want to play',
> > punctuation='?')
>
> > for *sometimes* saving you from typing one character? I still think it
> > makes no sense to append anything at all. Not to mention the pending
> > unicodization... the Japanese, Chinese, Korean and Cyrillic alphabets
> > don't use western punctuation...
>
> > Unless there's a better argument than sometimes saving one character
> > or being backwards-compatible to 0.96, I'm still against this.
> > However, I don't carry much weight around here ;-)
>
> I think he was suggesting in the form, not each field:
>
> form = forms.Form(punct='')
>
> would let you create a form with no colons. You could also do something
> like
>
> form = forms.Form(punct='-->')
>
> or whatever. This would also allow you to override the punctuation based
> on locale. Seems like a not bad solution. People who hate the colons
> could create their own subclass of Form and use it instead of the
> default form and then they wouldn't have to set the punct value each
> time.
>
> Todd
You're of course right.
I see that this would allow Django to be backwards-compatible by
introducing this new parameter, so I could go for that because I think
backwards-compatibility is very important. I still disagree with the
concept anyway because I think that:
* it's a newbie-trap ("where does this colon come from it's neither
in the template nor in my string???"and
* it doesn't really save any significant amount of time or space (12
characters saved on a form with 12 fields) and
* it splits your label string between two classes so it's a concern
for l10n and
* it's not very friendly to languages that don't use english/western
punctuation
So I guess it comes down between backwards-compatibility and "doing
the right thing as currently defined by Jonas Maurus". I think that
it's clear that requiring to write a full template for all form-fields
just to remove the colon would be really bad, at least. Btw, how does
the Django-community usually decide such a thing? by a vote like in
Apache projects? or do we wait for one of the core developers to show
up? :-)
cheers
Jonas
--~--~-~--~~~---~--~~
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: Templates: short comments {##} eats text
On Apr 6, 9:11 pm, "tonnzor" <[EMAIL PROTECTED]> wrote:
> Short templates comments {# #} are odd if used incorrectly - it eats
> text.
>
> This template (invalid comments):
>
> Hello
> {# this
> comment
> has
> newlines #} World! {{ "some more text" }}
>
> Now produce this output (text "World!" is eaten):
>
> Hello
> some more text
>
> Yes, the comments are invalid, but in this case it should be ignored
> and printed as-is:
>
> Hello
> {# this
> comment
> has
> newlines #} World! some more text
>
> I'm sure that things must work or do not work, not "work sometimes" or
> "do not work and have some side effects".
>
> See also ticket #3888 (http://code.djangoproject.com/ticket/3888)
If it can be changed, I'd also like to see only one comment style: {#
[text] #} with the {##}-notation supporting multiple-line comments. {%
comment %} can either get continued support or be deprecated.
I don't agree with the comment on #3888 that {# ... #} is like "//" in
C-like languages as "//" doesn't require a terminator (like "*/") and
therefor always effects the full line. Thus, "{# ... #}" is much more
like "/* ... */" or "". A "start-comment" - text - "end
comment" style notation should treat all included text as a comment,
including newline and carriage-return characters. Under no
circumstances should it affect anything coming *after* it, so that is
certainly a valid bug. At least an error message has to be generated
in this case, at which point we could also just allow multi-line {##}-
style comments.
I'd like that functionality especially as it would allow for the easy
construction of well-formatted templates that produce spaceless mark-
up like:
{# eliminate the newline
#}xyz{#
#}
at least until the spaceless-filter is changed so it actually produces
spaceless mark-up :-) and it would allow for well formatted comments
like:
{#
# multi-line comment
#
#}
which I find more aesthetically pleasing than the {% comment %} - {%
endcomment %} blocks.
At least a consistent design decision is needed for the 1.0-release.
cheers and happy easter
Jonas
--~--~-~--~~~---~--~~
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: Backwards incompatible changes
On Apr 6, 2:16 pm, "Russell Keith-Magee" <[EMAIL PROTECTED]> wrote: > Hi all, > > A few backwards incompatible changes have been raised on the list in > the last week or so: > > - Removing auto_add_now and auto_add > - Removing LazyDate > - Renaming localflavour.usa to localflavor.us > > This raises the question - do we have any particular timeline or > strategy for making these changes? Is there any particular reason to > hold off on making these changes, or should we just jump in a make > them, along with making a note in the backwards-incompability section > of the wiki, and posting a message to django-dev (or should that be > django-users) that gives notice of the change? > If there's anything to be learned from the Apache Tapestry-fiasco then it is that you have to make breaking changes at once and if possible only once. Each time you force your user-base to upgrade all their applications (forms -> newforms, pre-magic -> magic-removal) you essentially loose half your userbase. It rebuilds over time, but do it too often and nobody cares about you anymore. (You can look at GMane's statistics for comp.lang.java.tapestry, it tells an interesting story). So I'd say: make the next release painful and then stop until 1.1. Make all the changes now, including full unicodization and newforms- admin and if it's still on the map the "Admin"-class-removal that was being discussed a while ago, so that people know what amount of work will be necessary if they upgrade two months from now instead of making them go back through all their old code again and again and again... you get the idea. my $0.02, as if anyone cared ;-)... happy easter to all of you! Jonas --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
#19316 broke the external API of django.views.generic.View by changing where self.request is set
Hey everyone, #19316, or more specifically https://code.djangoproject.com/changeset/12cf9d2be3cccb2ff63d78e93f97188040488a3d seems to have broken the documented API of View. In https://docs.djangoproject.com/en/dev/ref/class-based-views/base/#django.views.generic.base.View.dispatch, dispatch() seems to be part of the external API of View. We happen to call dispatch() directly on View subclass instances in django-flows (https://github.com/laterpay/django-flows, specifically https://github.com/laterpay/django-flows/blob/develop/flows/handler.py#L413). Due to the change set above, calling dispatch() on FormView subclasses will now always fail as FormView expects self.request to be set, but that will only happen in the closure returned by as_view(). I think that the change in #19316 should be backed out or alternatively dispatch() should be removed from the public API as _dispatch, at which point the constructor to View() should also be made private. Right now however, people are encouraged to override dispatch() in subclasses, so I think the change is just broken. To summarize: Unless I missed something, it seems to me that dispatch can't be reliably called from the outside without setting up the instances .request, .args and .kwargs attributes. I hope somebody here can take a look and tell me if I'm way off course or whether this is a legitimate bug :). Thanks and best regards, Jonas -- 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. For more options, visit https://groups.google.com/groups/opt_out.
