Re: GSOC Tags
On Tue, 22 Oct 2013, Russell Keith-Magee wrote: > Hi Jasvir, Hello Russell > Frankly -- if something like this has happened, it's because Melange (the I am really amazed that google uses such a software. > We certainly haven't done anything strategically to avoid tagging the > opportunity. Tags are added by Google or by organisations? > As an aside - I'm intrigued where you've found this "search by tag" When we list all organisation of any particular year, we have two search fields there. One is "Name" field and other is "Tags" feild. You can check it in following link. http://www.google-melange.com/gsoc/accepted_orgs/google/gsoc2013 -- Jasvir Singh Grewal Blog: jasvirsinghgrewal91.wordpress.com : [ GNU/Linux One Stanza Tip (LOST) ]### Sub : To randomly play mp3 songs from a directoryLOST #243 mpg123 -z /path/to/mp3s/*.mp3 This will randomly play mp3 songs from the specified folder. [ajitabhpandey (at) users.sourceforge.net] : -- 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/20131022095331.GA5690%40gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Backwards compatibility and field validation
It seems there is a split reaction on whether or not models should assume data is clean, and comes down to design decision. I think that a docs patch explaining this entire concept to new users would be sufficient for now (and I'm more than happy to spend time writing it). Would any of the core devs object to such a patch? Cal On Fri, Oct 18, 2013 at 8:19 PM, Marc Tamlyn wrote: > I think Anssi summed up my feelings on this very well, in particular with > the issues with update(). Similarly create() would also bypass as it does > not call save() AFAIK. > > Given these commonly used approaches do not work, and that the name of the > method - save() - implies only saving to the database - I'm -1 on save() > calling clean(). > > That said, there is an interesting option to explore in ModelForms as to > how to push more if the validation to the database where that's > appropriate. This would increase the performance of write-heavy sites, and > also enforce better data integrity. At the moment all cleaning is done > before the instance is saved, and the assumption is that the instance will > pass db validation. As far as I know, we don't currently have any code > which detects problems there (dB integrity errors) and ties them back to > the fields or instances which have caused the issue. This is obviously > backend-specific code, and is far from straightforward. I think some of the > pending ValidationError changes could make it possible. > > Anssi and Andrew - do you think the dB can actually tell is enough > information to get this right? I guess if not an option would be to fall > back to the current query-creating code to work out why the save failed. > > Most of this is throwing thoughts around, apologies if they're illogical… > > Marc > On 18 Oct 2013 15:18, "Cal Leeming [Simplicity Media Ltd]" < > cal.leem...@simplicitymedialtd.co.uk> wrote: > >> Sorry please ignore my last email, my email client went a bit weird and >> sent the draft whilst I was still editing/thinking. Here is the proper >> version; >> >> This is yet another reason why I don't think it would be reasonable to >> expect field validation within the model. >> >> If the validations were done using DB constraints (as per Anssi's reply) >> then this would be a reasonable expectation, however as mentioned before >> changes in the field data can come from multiple places and it is not safe >> to assume that any data in the model is ever going to be valid. >> >> I think if the developer understands why this is important, they would be >> adding a lot of code to handle these different scenarios anyway, so I don't >> think removing the need to call full_clean() manually would be of much >> benefit. >> >> However that being said, I would be in favour of adding a call which >> allows you to validate changed and/or all fields, making it easier to >> handle these different validation scenarios. (i.e. being able to easily >> detect if it is old data that has caused validation error, or new data). >> >> Cal >> >> >> >> >> On Fri, Oct 18, 2013 at 3:09 PM, Cal Leeming [Simplicity Media Ltd] < >> cal.leem...@simplicitymedialtd.co.uk> wrote: >> >>> This is yet another reason why I don't think it would be reasonable to >>> expect field validation within the model. >>> >>> I also think that introducing such a check would not only lure the user >>> into a false sense of security >>> >>> If the validations were done using DB constraints (as per Anssi's reply) >>> then this would be a reasonable expectation, however as mentioned before >>> changes in the field data can come from multiple places and it is not safe >>> to assume that any data in the model is ever going to be valid. >>> >>> Given the performance concerns and the minimal amount of benefit that >>> validating on save() would give, >>> >>> >>> On Fri, Oct 18, 2013 at 2:42 PM, Florian Apolloner < >>> f.apollo...@gmail.com> wrote: >>> On Friday, October 18, 2013 4:28:21 AM UTC+2, Karen Tracey wrote: > > Wasn't there also concern for double validation performed during form > clean and then model instance save? > Yes, technically we would probably have to track the validation state per field and also track changes to it etc… :( -- 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/31648978-7105-422f-ad62-68943e324a04%40googlegroups.com . For more options, visit https://groups.google.com/groups/opt_out. >>> >>> >> -- >> You received this message because you are subscrib
Re: Backwards compatibility and field validation
Sounds good. I guess that may be an addition here: https://docs.djangoproject.com/en/dev/ref/models/instances/#validating-objects On Tuesday, October 22, 2013 8:40:46 AM UTC-4, Cal Leeming [Simplicity Media Ltd] wrote: > > It seems there is a split reaction on whether or not models should assume > data is clean, and comes down to design decision. > > I think that a docs patch explaining this entire concept to new users > would be sufficient for now (and I'm more than happy to spend time writing > it). > > Would any of the core devs object to such a patch? > > Cal > > > On Fri, Oct 18, 2013 at 8:19 PM, Marc Tamlyn > > wrote: > >> I think Anssi summed up my feelings on this very well, in particular with >> the issues with update(). Similarly create() would also bypass as it does >> not call save() AFAIK. >> >> Given these commonly used approaches do not work, and that the name of >> the method - save() - implies only saving to the database - I'm -1 on >> save() calling clean(). >> >> That said, there is an interesting option to explore in ModelForms as to >> how to push more if the validation to the database where that's >> appropriate. This would increase the performance of write-heavy sites, and >> also enforce better data integrity. At the moment all cleaning is done >> before the instance is saved, and the assumption is that the instance will >> pass db validation. As far as I know, we don't currently have any code >> which detects problems there (dB integrity errors) and ties them back to >> the fields or instances which have caused the issue. This is obviously >> backend-specific code, and is far from straightforward. I think some of the >> pending ValidationError changes could make it possible. >> >> Anssi and Andrew - do you think the dB can actually tell is enough >> information to get this right? I guess if not an option would be to fall >> back to the current query-creating code to work out why the save failed. >> >> Most of this is throwing thoughts around, apologies if they're illogical… >> >> Marc >> On 18 Oct 2013 15:18, "Cal Leeming [Simplicity Media Ltd]" < >> cal.l...@simplicitymedialtd.co.uk > wrote: >> >>> Sorry please ignore my last email, my email client went a bit weird and >>> sent the draft whilst I was still editing/thinking. Here is the proper >>> version; >>> >>> This is yet another reason why I don't think it would be reasonable to >>> expect field validation within the model. >>> >>> If the validations were done using DB constraints (as per Anssi's reply) >>> then this would be a reasonable expectation, however as mentioned before >>> changes in the field data can come from multiple places and it is not safe >>> to assume that any data in the model is ever going to be valid. >>> >>> I think if the developer understands why this is important, they would >>> be adding a lot of code to handle these different scenarios anyway, so I >>> don't think removing the need to call full_clean() manually would be of >>> much benefit. >>> >>> However that being said, I would be in favour of adding a call which >>> allows you to validate changed and/or all fields, making it easier to >>> handle these different validation scenarios. (i.e. being able to easily >>> detect if it is old data that has caused validation error, or new data). >>> >>> Cal >>> >>> >>> >>> >>> On Fri, Oct 18, 2013 at 3:09 PM, Cal Leeming [Simplicity Media Ltd] < >>> cal.l...@simplicitymedialtd.co.uk > wrote: >>> This is yet another reason why I don't think it would be reasonable to expect field validation within the model. I also think that introducing such a check would not only lure the user into a false sense of security If the validations were done using DB constraints (as per Anssi's reply) then this would be a reasonable expectation, however as mentioned before changes in the field data can come from multiple places and it is not safe to assume that any data in the model is ever going to be valid. Given the performance concerns and the minimal amount of benefit that validating on save() would give, On Fri, Oct 18, 2013 at 2:42 PM, Florian Apolloner > wrote: > > > On Friday, October 18, 2013 4:28:21 AM UTC+2, Karen Tracey wrote: >> >> Wasn't there also concern for double validation performed during form >> clean and then model instance save? >> > > Yes, technically we would probably have to track the validation state > per field and also track changes to it etc… :( > > -- > 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-develop...@googlegroups.com . > To post to this group, send email to > django-d...@googlegroups.com > . > Visit this group at http:
Re: ANN: Django Sprint November 23/24, Thinkfarm co-working space, Berlin, Germany
On 21.10.2013, at 15:57, Marc Tamlyn wrote: > Hi Jannis, > > Let me know if you're in need of another committer at the sprint. Can't make > any concrete promises as yet and I'd need to work out how cheaply I can get > there, but I'd love to come assist if that's helpful. Marc, absolutely, the more the merrier! I know that Florian is going to be there and there are rumors that Aymeric will, too. Jannis > Hi all, > > I'm excited to announce that the next Django sprint will take place in > Berlin, Germany on November 23rd and 24th. The event is organized by the > German Django Association (http://django-de.org/) together with the Django > Users Berlin. > > The sprint is hosted at the Thinkfarm co-working space > (http://berlin.thinkfarm.de/) in Berlin Kreuzberg. > > Sprinting will start on Saturday, November 23rd at 10:00 CET and ends on > Sunday, November 24th around 22:00 CET. > > On Friday, November 22nd at 20:00 CET we especially invite newcomers to join > our Django installation party. > > Please don't forget to RVSP: > http://www.meetup.com/django-user-group-berlin/events/146656662/ > > If this is your first time contributing to Django itself and can't make it to > the installation party on Friday please have a look at the contributing guide > (https://docs.djangoproject.com/en/dev/internals/contributing/) and set up > your clone of the Django git repository. > > If we are lucky Django 1.6 will be released before the event so we can > concentrate on those many new features that will be part of Django 1.7 or on > post-release bugfixes. > > If you’re unable to come to Berlin you're still very welcome to contribute to > the sprint online. Sprinters and core developers will be available in the > #django-sprint IRC channel on Freenode (http://freenode.net/). > > We hope you can join us and make it an awesome sprint! > > Jannis > > -- > 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/839533E2-3EC5-4F2E-9B95-574F41BD230C%40gmail.com. > For more options, visit https://groups.google.com/groups/opt_out. > > -- > 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/CAMwjO1HF2bEoMYF%2BwqiHE3uzUuaDiASSHcV14x2dO-UsrxG-%2BQ%40mail.gmail.com. > For more options, visit https://groups.google.com/groups/opt_out. -- 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/0AB263FA-AB60-4ABE-9444-F1B14A51A618%40gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
Bacwards incompatibility of #20346 cache middleware should vary on full URL
Ticket #20346 is the request that cache keys should be generated from a request's full URL rather than path, and the proposed implementation of this is backwards-incompatible. Because the existing keys are a hash of the path, and so, so far as I know, we do not have the original path needed to migrate keys, I do not see how we can migrate existing keys. I am alerting everyone to this and wondering if anyone has ideas which preserve backwards compatibility. If a backwards-incompatible change is necessary, I wonder if it would be appropriate to change cache keys to be more compatible with looking up directly via reverse proxies and webservers. Django cache keys are Django-specific module names and hashes, but it might be desireable to have them be in a simple, readable format such as http://www.example.com/path/to;method=GET;locate=en-us;Vary=Pony;etc. Other programs can easily generate those keys in order to fulfill cache hits. Thanks. Ticket at https://code.djangoproject.com/ticket/20346. -- 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/CAKkhZKz9Q58b%3DdS%3DEw7w6ivqk-Q_Eb_Qeh8N_R9o%2BDZMX%2B1v-A%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: ANN: Django Sprint November 23/24, Thinkfarm co-working space, Berlin, Germany
On 22 oct. 2013, at 19:05, Jannis Leidel wrote: > I know that Florian is going to be there and there are rumors that Aymeric > will, too. Yes, I'm coming! -- Aymeric. -- 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/6944807D-EC87-4693-BFC6-AF1711FEC921%40polytechnique.org. For more options, visit https://groups.google.com/groups/opt_out.
Re: Bacwards incompatibility of #20346 cache middleware should vary on full URL
If all it meant was that currently cached content would effectively be expired, I wouldn't see this as being anything more than an strong note. But as I'm sure people have created their own tools for building the page cache keys to forcibly expire them [and not yet taken advantage of that function being separated to a util module] I'm guessing it'd warrant a warning to catch up. Just my 2c. -- Curtis On 23 October 2013 05:34, j l wrote: > Ticket #20346 is the request that cache keys should be generated from a > request's full URL rather than path, and the proposed implementation of > this is backwards-incompatible. > > Because the existing keys are a hash of the path, and so, so far as I > know, we do not have the original path needed to migrate keys, I do not see > how we can migrate existing keys. > > I am alerting everyone to this and wondering if anyone has ideas which > preserve backwards compatibility. > > If a backwards-incompatible change is necessary, I wonder if it would be > appropriate to change cache keys to be more compatible with looking up > directly via reverse proxies and webservers. Django cache keys are > Django-specific module names and hashes, but it might be desireable to have > them be in a simple, readable format such as > http://www.example.com/path/to;method=GET;locate=en-us;Vary=Pony;etc. > Other programs can easily generate those keys in order to fulfill cache > hits. > > Thanks. > > Ticket at https://code.djangoproject.com/ticket/20346. > > -- > 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/CAKkhZKz9Q58b%3DdS%3DEw7w6ivqk-Q_Eb_Qeh8N_R9o%2BDZMX%2B1v-A%40mail.gmail.com > . > For more options, visit https://groups.google.com/groups/opt_out. > -- 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/CAG_XiSDXwiCSUJi%2BpFpNKHbCdn_NAz3as4-kyzchMp_-f6EcSg%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
[ANNOUNCE] Django 1.6 release candidate available
It's almost here! Tonight we've issued a release candidate for Django 1.6. Information, including links to downloads and release notes, is available on the Django project blog: https://www.djangoproject.com/weblog/2013/oct/22/16c1/ -- 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/CAL13Cg82W91nQKR_PQRBM-76AgpZxWNp6zBRsbUu0fUGJMXyfA%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANNOUNCE] Django 1.6 release candidate available
Looks like an awesome release coming up! Big thanks to the Django team :)
Looking forward to trying it out.
One comment about the fact that set_password() now (correctly) makes blank
passwords valid. I could imagine some users have assumed that
set_password('') was the same as set_unusable_password(). It might be worth
noting more prominently in the release notes since if this is the case,
there are obvious security implications.
--
Michael Mior
michael.m...@gmail.com
Le mardi 22 octobre 2013 23:08:33 UTC-4, James Bennett a écrit :
>
> It's almost here!
>
> Tonight we've issued a release candidate for Django 1.6. Information,
> including links to downloads and release notes, is available on the Django
> project blog:
>
> https://www.djangoproject.com/weblog/2013/oct/22/16c1/
>
--
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/0c2b88c8-4789-44b3-9157-2763c6bcb671%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANNOUNCE] Django 1.6 release candidate available
Kudos for making this happen! Small discrepancy: the blog post states python 2.7 is required; the release notes it links to state python 2.6.5 is still supported, and 2.7 will be required from Django 1.7 onwards. Yishai On Wed, 23 Oct 2013 06:08:33 +0300, James Bennett wrote: It's almost here! Tonight we've issued a release candidate for Django 1.6. Information, including links to downloads and release notes, is available on the Django >project blog: https://www.djangoproject.com/weblog/2013/oct/22/16c1/ --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/>CAL13Cg82W91nQKR_PQRBM-76AgpZxWNp6zBRsbUu0fUGJMXyfA%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out. -- Using Opera's mail client: http://www.opera.com/mail/ -- 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/op.w5d8verb699m7q%40ybxps. For more options, visit https://groups.google.com/groups/opt_out.
