Question about support dates

Hi, The release notes of Django 5.0 state: "Third-party library support for older version of Django¶ Following the release of Django 5.0, we suggest that third-party app authors drop support for all versions of Django prior to 4.2. At that time, you should be able to run your package’s tests

Re: Feature request: making gettext more robust

Hi Gergely, What helps for me is Django rosetta, https://django-rosetta.readthedocs.io/ . It makes filtering on untranslated or fuzzy translations very easy. Best regards, Wim PS Sorry for the late response. Op zaterdag 17 juni 2023 om 16:01:04 UTC+2 schreef Shai Berger: > Hi Gergely, > > On

Re: Django security releases issued: 4.0.4, 3.2.13, and 2.2.28

Hi, Thanks for the release! This has not directly to do with the security release, but I have a question about this remark: "Django 2.2 has reached the end of extended support. The final security release (2.2.28) was issued today. " As I understood it, Django 2.2 will be supported until the

Re: Replacing the contrib.sites Site model with a setting?

Hi all, I'm in favour of defining the sites in settings. In addition, it would ease transferring db dumps from live to test servers and it would prevent db queries. I wonder, because we define sites in ALLOWED_HOSTS as well, whether we can combine these settings. For scheme, what are

Re: change commit message format to present tense?

I agree with Reinout and on the use of the present tense, so a commit message would read: "Adds password validation to prevent the usage of ..." My mind finds this way easier to understand than: "Add password validation ..." Wim On Monday, 27 June 2016 13:55:54 UTC+2, Daniele Procida wrote: >

Django website ssl-certificate expired

Hi guys, Apologies if I am posting in the wrong group, but the certificate of djangoproject.com expired today (4 May). Wim -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group

Re: Making max_length argument optional

:01:52 UTC+1, Florian Apolloner wrote: > > -1 on adding an arbitrary default like 100/128… If people choose a > CharField the should set max_length manually. In that sense I am for option > 3. > > Cheers, > Florian > > On Saturday, February 27, 2016 at 1:55:23 PM UTC+1,

Re: Making max_length argument optional

Hi guys, I'd like to reach consensus about https://code.djangoproject.com/ticket/14094 In the discussion, I saw three options: 1. Adding a default max_length = None, which may in practice differ per database backend. 2. Adding a default max_length of a value which can be used across

Re: structural & functional review of django documentation

Hi Doug, I get lost regularly in Django's docs as well, so you are not alone there. I think it is a good proposal to add: "find what you were looking for" or "was this page helpful" or "rate this page on its organization, clarity, brevity, etc." data on every single existing page of the

Proposal: by default, don't populate a modelformset with all model instances.

By default, when you create a formset from a model, the formset will use a queryset that includes all objects in the model (e.g., Author.objects.all() ). In most use cases, people will want to use a specific subset of data and will construct queryset by hand. Or they want to use an empty

Re: Password validation in Django revisited

Hi Markus and Aymeric, In my opinion, it is very safe and consistent to use password validation in all instances and places. It definitely prevents people from using admin/admin and markus/markus as a login, which sounds safe to me. If you don't want that, you can change the validators

Re: @csrf_protect annoying on django.contrib.auth.views.login

Hi, We are experiencing the same problem when a user changes his language. We are using a post form for that, see: https://roominreturn.nl . 1. What is annoying is that the csrf Forbidden page is a yellow page and is shown to the end user. We would never want to confront a visitor with a

Re: Idea/request for help: Django Developers Community Survey

Hi, "How often would you like to see new major version of Django released?" currently lists three options, which are close to one another. I would like to have: 12 months, as well as an open option. Is it an idea to add those? Detailed release schedules are not necessary, in my opinion. "I

Re: Two phase cleaning of models/forms

Great proposal and I'd love it on forms. I'm not sure about models, though. I always use forms for sanitization. On Wednesday, 25 March 2015 10:37:43 UTC+1, guettli wrote: > > Up to now the validation/cleaning of a attribute can not access the > value of an other attribute. > > The work

Re: improving debug logging in development

This may sound stupid, but I actually use Logbook for logging because I find it easy to use. On Monday, 23 March 2015 18:48:26 UTC+1, Tim Graham wrote: > > The alternative to a new setting would be to revert the "merging" behavior > of the django.utils.log.DEFAULT_LOGGING and settings.LOGGING

Re: Psycopg2 version support

Hi, I am definitely in favor of just one version requirement in order not to complicate things. So then the minimum version would be either 2.5; or 2.4.5 and write special cases in contrib.postgres to deal with that. Regards, Wim On Monday, 16 February 2015 16:04:50 UTC+1, Tim Graham wrote:

Re: User.username max_length 254

Hi Collin, I would like that, good idea! Wim On Saturday, 7 February 2015 02:10:02 UTC+1, Collin Anderson wrote: > > Hi All, > > I was reminded by: > Allow shadowing of abstract fields > https://groups.google.com/d/msg/django-developers/6zUfnElOIks/8uwXji559EsJ > and

Re: Storage engine aliases?

Hi Jannis, although much work, I would find that brilliant. On Thursday, 2 October 2014 08:47:13 UTC+2, Jannis Leidel wrote: > > > "If something like that were be tried I would also recommend to fix the > ambiguity with regard to “media” and “static” by renaming the first to > “uploads”." > >

Re: The greatest proposal yet: rename this damn group

Hi Russell, Is this an issue we should solve? Because I believe technology can help here. For example, by posing a question when a user is creating a ticket. Ask if it deals with security; then present two clear buttons: "Report a security issue" or "Report something else". (There might be

Re: The greatest proposal yet: rename this damn group

Hi Russell, Did you manage to speak to the technical board about renaming the group? Wim On Tuesday, 9 September 2014 03:49:21 UTC+2, Russell Keith-Magee wrote: > > > On Mon, Sep 8, 2014 at 11:24 PM, Carl Meyer > wrote: > >> On 09/08/2014 08:56 AM, Aymeric Augustin wrote:

Re: Loading timezone naive data into your test database with USE_TZ = True

Hi Robert, Timezones confuse me, maybe Aymeric can answer this one if he has time? Off topic, your question might be a better fit for the django-users mailing list, but perhaps you posted to django-developers intentionally, because you are thinking of a bug report? Wim On Wednesday, 17

Re: Should reverse() return a Unicode string?

Please do. :) - Wim On Thursday, 18 September 2014 22:01:21 UTC+2, Jon Dufresne wrote: > > What do you think? If others agree, I can file a bug and create a pull > request to fix this. > > -- You received this message because you are subscribed to the Google Groups "Django developers"

Re: Unifying locale time formats

Hi everyone, I wonder if we should unify the time format which is sometimes displayed as G:i and sometimes as H:i, where hours are displayed with or without a leading zero. For the same reasons as stated above I think it nicer to be consistent here. I would prefer G:i (hour without leading

Re: Unifying locale time formats

Hi Malte, Sounds like a good idea to remove the seconds. Aymeric says the same. Can you open a ticket and if you want create a pull request? Wim On Wednesday, 10 September 2014 18:26:11 UTC+2, Malte wrote: > > Hi Aymeric, > > Yes, I agree. And backwards compatibility is a concern I share. But

Re: The greatest proposal yet: rename this damn group

Hi Daniel, An idea we spoke about earlier in this tread is to rename the group to Django Contributors, and the slug (and url) to remain django-developers in order to preserve links. Wim On Tuesday, 9 September 2014 22:04:30 UTC+2, Daniel Pyrathon wrote: > > Hi, > > I think that changing the

Re: The greatest proposal yet: rename this damn group

Hi, Good thing to change the group name. For the description, another wording could be: Discussion group for contributing to the Django source code and documentation. Here we discuss new features and updates of the Django project. Wim On Tuesday, 9 September 2014 10:52:09 UTC+2, Robert

Re: The greatest proposal yet: rename this damn group

Or Django contributors? On Friday, 5 September 2014 10:20:51 UTC+2, Tom Christie wrote: > > Options?... > > * Django core > * Django core development > > For comparison the Rails folks have "Ruby on Rails: Talk > " and "Ruby on > Rails:

Re: Requiring GitHub login for actions on Trac

Nice :) On Saturday, 9 August 2014 21:22:07 UTC+2, Aymeric Augustin wrote: > > Uhmm... but I see you moved forward and already did it? > > Yes, I did. > > -- > Aymeric. > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To

Re: Requiring GitHub login for actions on Trac

> > Hi Aymeric, Thanks for your proposal and your work on this! I am in favour of *adding* github as an authentication tool. We would benefit immensily for making it easier for new people to log in and contribute. Would it be possible to add that to Trac, so people who have moral

Re: Regression in ValidationError in 1.7

Hi Russ, Good point and thanks for testing! For me, this should definitely be listed in the release notes and we should provide people a hint of how to fix it as well. IMO we do not need to support a non-documented feature. Wim On Friday, 27 June 2014 07:58:27 UTC+2, Russell Keith-Magee

Re: Add support for get_or_none?

Hi Cal, When we proposed to add get_or_none() , we actually ended up adding a first() -method. The primary motives were to have a clearer name and to stay in line with other existing api's. In my opinion, get_or_none is too much a duplicate of first and I am therefore -1 of it being added.

Re: #20824 - Email-based auth contrib module; some help required

Hi Tilman, Thanks for bringing this up. I lowercase my e-mail addresses every time - and when I forget I am wading through a pile of shit. (excusez le mot) Your solution looks neater, because it maintains user input. I have had users who used stefan.joos...@gmail.com once and later on:

allow list_display in admin to traverse onetoonfields and foreign key relations

Hello, Right now I have a School model containing a OneToOne-relation to User. In the admin, in search_fields, I can use double underscores to search in related fields, for example: search_fields = ('place__name', 'school__name') But in list_display, I can't. For example, list_display

Re: ValidationError for fields

Hi Loic, That's nice! It looks very powerful, saving lines of code and being more clear. How about: form.add_errors(dictionary) ? Because then we can either add one or more errors at the same time. Wim On Wednesday, 21 August 2013 02:31:07 UTC+2, Simon Litchfield wrote: > > An improvement

Proposal: remove triage stage someday/maybe

Hi, When triaging tickets I came across the triage stage Someday/Maybe. The docs say I shouldn't use it. :) I think they are right. For me triaging tickets is all about making a decision. I make a choice between either: "yes, good idea", or "no, we definitely don't want that". Someday/maybe

Re: Revisiting multiline tags

Hi Jacob and Adrian, Reading this long thread with many +1s makes me think of truncatechars which is not a good feeling. I wondered if you are using internationalisation? If so have you run into the same problems or is it easy to circumvent for you? Or am I missing something and are all

Proposal: rename django-developers to django-contributors

Hi all, Many people post django-users questions to this group by accident. I find the name of our group to be misleading: it seems to refer to people who develop in django, but actually it is meant for people contributing to django. To limit confusion, my proposal is to rename

Re: Ticket #13910: Generator based rendering (streaming) of templates

Hi Roger, Probably the best way to get some love is to do a 5 for 1. Did you hear of that before? It means that if you look into five tickets and/or patches from other people, that you state here: I did a five for one. In my experience, core contributors are very willing to give a hand then.

Re: Django runfcgi umask: what is it meant to do and why?

Hi Juan, Thanks for your detailed examination and report. The best way to proceed is definitely to create a ticket in trac: https://code.djangoproject.com/newticket . Then, if you are willing and like to become a contributor, you can either add a patch or create a pull request on github.

Re: Improving ForeignKeyRawIdWidget (raw_id_fields in admin)

Hi Richard, Thanks for your rationale. Sounds like a good feature to me. Probably the best way to proceed is to make a ticket at: https://code.djangoproject.com/newticket , attach a patch or pull request and then we go forward. Best regards, Wim On Wednesday, 12 June 2013 19:33:31 UTC+2,

Re: first() and last(), earliest() and latest()

Hi Selwin, Considering "There should be one-- and preferably only one --obvious way to do it", I definitely prefer to rely on order_by to do the ordering, not on first. .order_by('name').first() is clear and readable in my opinion. Wim On Sunday, 12 May 2013 06:55:04 UTC+2, Selwin Ong

reconsider re-opening ticket 901

Hi, Following up on the discussion on: https://groups.google.com/forum/?fromgroups=#!topic/django-developers/DUQtBrM2iTs I'd like to start a clear discussion about re-opening ticket 901. https://code.djangoproject.com/ticket/901 Ticket 901 was marked 7 years ago as won't fix and has been

Re: Perception of attitude in tickets

Hi Simon, Luke and Aymeric, Simon, first of all, thanks for your feedback. Core developers, I think Simons comment is a thing we should take seriously. A ticket was closed and people didn't understand the process and re-opened it. I believe we could have explained more clearly: 1. our

first() and last(), earliest() and latest()

Hi all, We struggled to get a proper definition for a first() and last() method vs. earliest() and latest() . I'd like to make one proposal. After that, I really like your opinion on which syntax you prefer. First, let me give you a lenghty introduction. We discussed several use cases on this

Re: [Future feature?] Viewsets

Hi, Just wanted to draw your attention to a proposal made by Zachary Voase, which you might be unaware of. It has no code, but is just a proposal, having a very clean api IMHO. http://zacharyvoase.com/2013/01/22/django-objviews/ Cheers, Wim On Saturday, 26 January 2013 04:04:57 UTC+1,

Re: Form.set_data method

Interestingly enough, it reminds me of the pattern proposed by Daniel Greenfeld and Miguel Araujo, who used a pattern: form = MyForm(request.POST or None) http://blip.tv/djangocon/advanced-django-form-usage-5573287 Wim On Thursday, 31 January 2013 07:08:52 UTC+1, Shai Berger wrote: > > On

Re: BigAutoField

Hi Steve, Django is an open source product made and improved by many volunteers. Probably you are reffering to: https://code.djangoproject.com/ticket/14286 What needs to get done to get the patch accepted in Django, is that somebody (really anybody - could be you) looks at the latest patch

Re: A.objects.getdefault

ser.objects.exclude(a=b).filter(c=d).last('id') > if user: ># do things... > > > If last() and first() are introduced, perhaps we can also deprecate > latest() in the future because they're very similar. > > What do you guys think? > > Best, > Selwin > >

Re: FloatField, localize and Django settings

Hi Michael, sounds very reasonable to me. Could you please file a bug ticket for that at https://code.djangoproject.com/newticket ? On Tuesday, 22 January 2013 21:30:09 UTC+1, Michael Anckaert wrote: > > Hello everyone > > I came across an issue where my CBV and an automatic ModelForm gave me >

cycle in nested loops

Hi, Quoting ticket 5908 : "Under the following example, I would expect the cycle tag's internal counter to be reset after leaving the inner loop. That way it'd be 'nesting safe' :-) {% for group in grouped %} {% for item in group.list %} ...

Shouldn't Textarea be CamelCased as TextArea?

Hi guys, I was just wondering, and maybe my English language skills are insufficient. Django defines several widgets, like: TextInput PasswordInput HiddenInput DateInput DateTimeInput TimeInput Textarea Why isn't Textarea CamelCased: TextArea, like the other widgets? It seems inconsistent.

Re: A.objects.getdefault

Hi, Ticket 19326 has been marked as ready for check-in for some time. Can some-one have a look at it? https://code.djangoproject.com/ticket/19326 Thanks, Wim Op donderdag 29 november 2012 23:45:38 UTC+1 schreef Wim Feijen het volgende: > > Hi Anssi, > > When I thought about

Re: A.objects.getdefault

? Unfortunately, I was not able to comprehend the workings of clone so I am not sure. Regards, Wim Op donderdag 29 november 2012 08:12:28 UTC+1 schreef Anssi Kääriäinen het volgende: > > On 29 marras, 01:13, Wim Feijen <wimfei...@gmail.com> wrote: > > Hi, the patch has been upd

Re: A.objects.getdefault

Hi, the patch has been updated and now works. Still, feedback would be appreciated. So, Anssi, Jacob? - Wim Op maandag 19 november 2012 22:48:36 UTC+1 schreef Wim Feijen het volgende: > > Hi, > > I do like the first() method and went ahead and *tried* to implement it. > &g

Re: Redesign of djangoproject.com?

Oops sorry Dana! Thanks Jacob, that's good to hear! Op dinsdag 9 oktober 2012 23:26:42 UTC+2 schreef Dana Woodman het volgende: > > Glad you like the design, but I'm a he. :) > > On Tuesday, October 9, 2012 11:58:58 AM UTC-7, Wim Feijen wrote: >> >> Hi Jacob, >&

Re: Redesign of djangoproject.com?

Hi Jacob, I was wondering whether there were any entries and whether a decision has been taken to appoint a benevolent redesigner? Personally I really liked Dana's proposal, marketing-wise, and considering she raised the question, I would certainly support her. My apologies if I missed a

Re: A.objects.getdefault

For me, get_or_none would prevent a lot of boilerplate code in my views, so I am in favor of adding the method. Wim Op dinsdag 9 oktober 2012 19:15:55 UTC+2 schreef ptone het volgende: > > Unsurprisingly - this has come up before: > > Earlier discussion > >

Re: prevent brute force attacks by acting on several failed logins, for example by using a captcha

Hi Paul, Thanks for your review and remarks. I will think on it more, and will write a longer response later. For the moment just this quick reponse: I was thinking of adding a recaptcha implementation, based on the work of others, if that would work with licenses. But probably that choice

filter users by group in the admin user_list

Hello, When using groups, it would be handy to filter users by group. Ticket #16835 proposes to add this to the admin by default. Do we need to limit the number of groups displayed, if there are many many groups? (I am not sure if people are using groups that way, I use them primarily to manage

Re: django messages framework

Using render_to_string, you can use a template, and it is backwards compatible. Would that work? Wim -- 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

Re: prevent brute force attacks by acting on several failed logins, for example by using a captcha

Hello, Thanks for the pointers. Based on the previous discussion and the comments at Simon Willison's blog on ratelimitcache, here is a first draft of my proposal: 1. Considering that Django's admin and default login schemes are currently unprotected against brute force attacks by default, and

Re: prevent brute force attacks by acting on several failed logins, for example by using a captcha

Thanks guys for the support. For reference, there is a previous thread "Brute force attacks", here: http://groups.google.com/group/django-developers/browse_thread/thread/71877ef02fb7c054/0b44e048b5bf4b77 Which does not mention captcha's btw. Luke, I'll think about it, but it will take some

prevent brute force attacks by acting on several failed logins, for example by using a captcha

Hello, Would it be a good idea to write a ticket and patch to stop brute force attacks, either by requiring people to fill in a captcha after several failed login attempts; or by setting a time delay? Mozilla Secure Coding Guidelines recommend in doing so, see:

gunicorn in docs

Hello, After watching glyphs talk [1], do we want to add a gunicorn installation instruction to the installation docs? What is your opinion? Wim [1]: http://blip.tv/djangocon/keynote-glyph-lefkowitz-5573264 -- You received this message because you are subscribed to the Google Groups "Django

Should user passwords be more strict?

Having just finished a discussion on security, I'd like to raise a concern of mine. By default, users can have a one-character password. When their accounts get hacked, we suffer the consequences as well. Should we be more strict in that? Wim -- You received this message because you are

Re: please reopen ticket 15567

Ladies and gentlemen, Thanks for all the feedback, a patch is in ticket 16837: https://code.djangoproject.com/ticket/16837 Feel free to try and review the patch. Best regards and for now, good night. Wim On 13 sep, 23:42, Jacob Kaplan-Moss wrote: > Hi folks -- > > I agree

Re: please reopen ticket 15567

Hi, thanks for your quick responses! Flavio, Jan and Florian, it only "gives away information" when an attacker guesses both the username and the password right. But if he can guess those right, he could already access the users information using the normal login! So giving this message does not

please reopen ticket 15567

Hello, When a user tries to login on the admin, with correct username & password, but is_staff is set to False, the error message is misleadingly wrong: "Please enter a correct username and password. Note that both fields are case-sensitive." Ticket 15567 deals with this and is currently marked

Re: plea for re-opening ticket 13125 marked as won't fix

On Sunday, September 11, 2011 8:52:03 PM UTC+2, Wim Feijen wrote: > > > 3. Because the user is still logged in, (maybe for two weeks, or for > > whatever expiration time the developer has set) > > Imo in that case the developer should write a middleware that logs the user > ou

Re: plea for re-opening ticket 13125 marked as won't fix

Paul, On further thinking, I do believe that the current behaviour of login_required should be considered a bug. Wim On 10 sep, 02:03, Paul McMillan wrote: > No. Django makes an incredibly strong promise about backwards > compatibility to its users. Security releases are the

Re: plea for re-opening ticket 13125 marked as won't fix

The case is as follows: 1. An active user is logged in and has a valid session. 2. The user is inactivated by a system admin, who wants to disable the user. 3. Because the user is still logged in, (maybe for two weeks, or for whatever expiration time the developer has set), he passes the

https://www.djangoproject.com/download/ is down!

The download page for Django is down. I also filed a ticket, so this is a duplicate message. Wim -- 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

Re: Proposal for a new templatetag definition syntax

Hi Alex, Probably I am thinking way too simple, but if you gave me a free choice of how to write templatetags in my code, I would prefer: def mytag(foo, bar): # some code return output or: class MyTag(Tag): def __init__(self, foo, bar): self.foo = foo self.bar =

Re: plea for re-opening ticket 13125 marked as won't fix

I added an active_login_required decorator. See: https://code.djangoproject.com/ticket/16797 Is it a good name? It is a good patch? Or is it stupid? Thanks, Wim On 10 sep, 02:27, Wim Feijen <wimfei...@gmail.com> wrote: > Thanks Paul, > > I like the idea of the additional deco

Re: ticket 13125 is waiting for a design decision for 18 months

t; >> inactive users which is expressed in > >> ModelBackend.supports_inactive_user = True. So I would suggest you > >> write a custom decorator. > > >> On Fri, Sep 2, 2011 at 6:49 AM, Wim Feijen <wimfei...@gmail.com> wrote: > >> > I'd like to draw

plea for re-opening ticket 13125 marked as won't fix

Jakob, thanks for looking into 13125 and taking action on it. I'd like to make a case to re-open ticket 13125. I understand that changing the current behaviour is backwards- incompatible and therefor very unwanted. But, I'd say the current implementation is forward-incompatible: meaning that

Re: authentication by email

Key. " Thanks Russell and I wish you good luck in the Django sprints! - Wim On Aug 26, 5:23 pm, Wim Feijen <wimfei...@gmail.com> wrote: > Hello, > > In the past hour, I did some research on authenticating by email and I > believe Django users would benefit a lot if email a

authentication by email

Hello, In the past hour, I did some research on authenticating by email and I believe Django users would benefit a lot if email authentication was included in contrib.auth . Many people have been working on it, and the latest code I could find is here: https://gist.github.com/586056. I am not a

Re: Forced password reset in django-admin

Hi Bejamin, Sounds like a cool feature: probably when you build such a thing, it will be used by dozens (or thousands). I noticed that I am making a lot of use of custom registration processes. Most of the time, I use django-registration as a solid basis, are you familiar with that? Best

Re: Django Error Display Page

For me, it would definitely be a good idea to change the error page a bit, so at least the actual error message is not in grey but in black, and bigger. People tend not to see it right now, because it looks unimportant. Wim -- You received this message because you are subscribed to the Google

Re: Sprints DjangoCon Europe

More news about the sprints! During the sprints we will have access to the Dialogue Cafe in de Waag building (see: http://www.dialoguecafe.org/). Dialogue Cafe offers facilities for video conferencing. Wouldn't it be great if we could sprint all over the world? Actually, up to now, two locations

Re: Proposal: switch to HTML5 for bundled templates

+1. All major browsers now support html5 and by the time django 1.4 will be released we will be right on time though a bit late. In response to Gabriel, in my opinion, legacy problems should not be addressed by not moving forward, but they can be resolved by either 1. updating or 2. staying on a

Re: ANN: Django 1.3 release candidate available

Great work! As the final release has not yet been announced, did something go wrong? Could you please post a small status update? Thanks, Wim On Mar 4, 7:00 am, James Bennett wrote: > Tonight we're proud to announce the first release candidate for Django > 1.3; if all

Re: Benevolent Dicta^H^H^H Designer for Life

Hi Idan, Those are two great topics, congratulations to you and to us :) and good luck! Wim -- 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

a default max_length

Hi, How do you feel about having a default max_length value for a models.CharField, so we can use it like: class MyModel(models.Model): example = models.CharField() ? What are the pros and cons? Wim -- You received this message because you are subscribed to the Google Groups "Django

Re: An idea to eliminate {% csrf token %}

Hi Luke, Thanks for your quick response. I've read the discussions about CSRF and SafeForm, in fact I already did before posting my message. Because of your excellente wiki the threads were easy to find. I am not talking about SafeForm. I am sorry I wasn't clear before, but in fact, what I want

idea for using RequestContext by default

/ Best regards, Wim Feijen -- 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-developer

An idea to eliminate {% csrf token %}

implementing a less intrusive way of CSRF-safe forms. As you, I am looking for a solution which benefits us most and at the same time, has the least drawbacks. Please correct me if I am wrong and take this message in the spirit it is meant, that is: to describe an idea. Best regards, Wim Feij

Re: Django releases

Jacob, I am very glad this discussion is being held, and with such good arguments. My vote is +1, because I think Django needs another stable release right now. Fortunately, the trunk is stable (thank you!). Rob says that it is good for a software project to have regular releases on a half-year