Re: Proposal new Django Admin css style

On Tuesday, August 12, 2014 12:26:45 PM UTC+2, Thiago Avelino wrote: > > Not a Django core part of the topic, as it was? > But still a valid point. That said, I find the current style way nicer than the proposed one. Cheers, Florian -- You received this message because you are subscribed to

Re: Proposal: Password Validity Layer

On Tuesday, August 5, 2014 8:45:05 PM UTC+2, Collin Anderson wrote: > > Could we handle it with model validation on a custom user model? Maybe add > a validate_password() method on the user model? I don't think so, using a custom user just for password validation is way to much work given that

Re: Django and BREACH (remember that?)

On Monday, August 4, 2014 4:21:43 PM UTC+2, Michael Mior wrote: > > This looks good, although it seems like there should be a config setting > as I could imagine some use cases where the application expects the token > not to change in this way. I'm not sure how common this and whether or not >

Re: Django and BREACH (remember that?)

On Monday, August 4, 2014 11:01:14 AM UTC+2, Adam Brenecki wrote: > > What is wrong with xor+base64? Not that Vigenère cipher is complex, but we >> have a pretty hard stance against implementing "crypto" on our own. >> > > Nothing, really; that's probably what I would have used had FunkyBob not

Re: Django and BREACH (remember that?)

Hi, On Monday, August 4, 2014 3:15:15 AM UTC+2, Adam Brenecki wrote: > > So, a while ago, BREACH happened, and Django's CSRF implementation was > vulnerable, as was Rails'. The paper that discussed it described a > mitigation (and a Rails patch had already been made), so I implemented that >

Re: Updating the organization of the Django Project

+1 On Wednesday, July 23, 2014 3:30:13 PM UTC+2, Aymeric Augustin wrote: > > Hello, > > I’ve been working on updating our organization: > https://github.com/django/django/pull/2947 > > This proposal attempts to address several issues with our current > organization. There’s no short version

Re: [New feature request] Prefer:Safe request header

Hi, On Wednesday, July 23, 2014 1:58:26 PM UTC+2, S4mmael wrote: > > It would be really nice to have some mechanism intended to work with this > header in Django. A kind of miidleware or a decorator maybe. > What's wrong with "if request.META.get('prefer') == 'safe'"? Cheers, Florian -- You

Re: Documentation enhancement for class based GenericView

Hi Wayne, On Wednesday, July 16, 2014 3:48:34 PM UTC+2, Wayne Ye wrote: > > >- When GET a resource, I want to do a counting job to record total hit >on this specific resource > > Override dispatch or get, count and delegate to the parent. > >- When a posted form is invalid, I

Re: use semantic versioning after 2.0?

On Monday, July 14, 2014 9:50:53 PM UTC+2, Aymeric Augustin wrote: > [snip] +1, please leave it there -- 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

Re: Per-country URLs

On Tuesday, July 8, 2014 4:42:45 PM UTC+2, Aymeric Augustin wrote: > > Surprisingly, the call to get_language() is in RegexURLResolver, not in > LocaleRegexURLResolver. That's at least a code smell and possibly a flaw in > the current implementation. > Yes, I was surprised by that too when I

Re: modelformset_factory and unique_together don't always validate unique fields

On Thursday, July 3, 2014 3:03:25 PM UTC+2, Jon Dufresne wrote: > > > Also, even if we find a place to show > > the errors, the user is (usually) in no position to correct them (after > all, > > there is no field he could change to fix it). > > I don't follow. In my specific example the user

Re: modelformset_factory and unique_together don't always validate unique fields

Hi Jon, To me this is no shortfall but expected and good behaviour, including other fields in the validation (i.e. fields not on the form) would be very confusing. Where would errors show up? Also, even if we find a place to show the errors, the user is (usually) in no position to correct them

Re: Response Fixes

On Wednesday, July 2, 2014 3:36:22 PM UTC+2, Łukasz Rekucki wrote: > > It doesn't just alter it, but makes it conform to HTTP standard. While > most browsers will accept relative urls, I don't think Django should > sacrafice backwards compatibility for an arcane CGI feature. Internal

Re: collectstatic - override default ignore list

I see a point in ignoring hidden and swap files by default. CSV is imo something which shouldn't be used anymore and as such shouldn't be a default. Given that ignoring hidden and swap files should cover 80% of the use cases, I don't see much point in a new setting. Cheers, Florian On

Re: Migrations and Reusable Apps

On Tuesday, June 24, 2014 6:07:05 AM UTC+2, Sebastian Vetter wrote: > > I appreciate the offer and will gladly take it :) I'm currently in the > middle of a migration to Django 1.7 incl. backwards-compatibility. I'm > collecting questions about best practises right now and would love to > get

Re: Why not Single Table Inheritance?

On Wednesday, June 11, 2014 2:16:06 AM UTC+2, Craig de Stigter wrote: > > I reserve judgment on whether STI should be included in core. It works > fine in a third-party app. Some better support for it in core would be > helpful, since currently I'm relying on some unsupported stuff that the >

Re: Add an extra parameter to 'static' tag

Hi Renato, On Sunday, June 1, 2014 4:36:55 PM UTC+2, Renato Oliveira wrote: > > On Sunday, June 1, 2014 3:26:06 AM UTC+2, Renato Oliveira wrote: >>> >>> I open sourced the >>> modification we did (4 or 5 lines plus tests), and was about to send

Re: Add an extra parameter to 'static' tag

Hi Renato, On Sunday, June 1, 2014 3:26:06 AM UTC+2, Renato Oliveira wrote: > > I open sourced the > modification we did (4 or 5 lines plus tests), and was about to send it to > pypi and wondered if it is an improvement to do on Django itself.

Re: "Master/slave terminology" (was: Master/slave trolling pull request accepted to django master branch)

On Tuesday, May 27, 2014 5:38:23 PM UTC+2, Meira wrote: > > This second commit was discussed in a Trac ticket and everyone (even you!) >> was welcome to give their opinion. >> > > That's all nice and good, but why is the discussion taking the course of > whether or not we're accepting the

Re: Great Wall of DEP

Hi, On Thursday, May 8, 2014 2:13:52 PM UTC+2, Carl wrote: > > Just noticed this message, and the DEP PRs are still open a week later. > Can someone shuffle this along, please? > We are in the final stages of 1.7, I personally would rather focus on that first. -- You received this

Re: Feature request: ttl method for cache

Hi Russ, On Tuesday, May 6, 2014 2:54:52 AM UTC+2, Russell Keith-Magee wrote: > > As far as the NotImplemented bit goes - I'd rather see this implemented > for all officially supported backends, rather than only one backend. The > only exception to this would be if there is a fundamental

Re: Revisiting multiline tags

Technically I'd think only core devs would vote. So neither here or there would make a diff imo. P.S.: That said I am not sure we have a formal policy on how we act on DEPs yet (or maybe I should just read DEP 001 more carefully ;)) Cheers, Florian On Wednesday, April 30, 2014 4:02:26 AM

Re: Proposal for prepared statements API

On Tuesday, March 25, 2014 11:57:51 PM UTC+1, Curtis Maloney wrote: > > Firstly -- can we assume anyone using this feature is not a complete > novice, and so will take the caveats mentioned into consideration? > Yes > Yes, prepared statements are local to their connection/session. And would

Re: Migrations in Django 1.7 make unit testing models harder

On Tuesday, March 25, 2014 9:12:42 PM UTC+1, Andrew Godwin wrote: > > So, the functionality whereby you can have apps which do not use > migrations (i.e. that use the old creation backends) is meant to go away in > 1.9. > Uhm, strong -1 here unless you have really convincing arguments, I really

Re: Migrations in Django 1.7 make unit testing models harder

On Tuesday, March 25, 2014 7:14:55 PM UTC+1, Andrew Godwin wrote: > > Yes, the new behaviour is by design, in the sense that the workaround you > mentioned will be deprecated in 1.9 (along with all syncdb-related > functionality). > What exactly will get deprecated here? -- You received this

Re: [GSoC] Proposal. Translation of admin.

Hi Alexey, first of all I hope you are aware that the deadline for proposal submission is today. That said, applications require a solid proposal similar to https://gist.github.com/chrismedrela/82cbda8d2a78a280a129 (length and structure wise). If this email is intended to be your proposal, I

Re: Add support for get_or_none?

On Thursday, March 20, 2014 2:01:25 PM UTC+1, Cal Leeming [Simplicity Media Ltd] wrote: > > I'll give it a couple more days for a BDFL to gives the thumbs up/down. > Well, we don't have BDFLs anymore and Shai already said he is -0 on it, count me in with a relatively strong -0 too. I'd be a

Re: Add support for get_or_none?

On Friday, March 14, 2014 4:50:49 PM UTC+1, Michael Manfre wrote: > > On Fri, Mar 14, 2014 at 11:15 AM, Cal Leeming [Simplicity Media Ltd] < > cal.l...@simplicitymedialtd.co.uk > wrote: >> >> >>> .get(or=None) (of some description) would be my preference, but even >>> that is ugly and

Re: [GSoC 2014 proposal]. Improving admin translation and formalizing Meta objects.

Hi Alexey, On Wednesday, March 12, 2014 7:52:59 PM UTC+1, Алексей Сидаш wrote: > > Russian localization of django admin is poor. It is even worse then my > English :D. > How so? Can you provide a few examples -- I know that numbering can be a problem for Russian translations, but that's hardly

Re: requiring login to perform Trac actions?

On Tuesday, March 4, 2014 8:39:36 AM UTC+1, Anssi Kääriäinen wrote: > > I'd like to have some security against reporting as somebody else. > Currently one can report or comment anonymously and mark reporter as core > committer. This is too easy to abuse. +1 for requiring login. At least >

Re: my admin theme

Hi, On Monday, March 3, 2014 11:35:31 PM UTC+1, adam spence wrote: > > I was wondering what you thought of my proposal to contribute my bootstrap > admin theme? > If you are refering to https://groups.google.com/d/msg/django-developers/0fD9zGtOhMg/vAdAOvxikFAJ -- you already got the answer of

Re: index_together should also have the same convinience as unique_together

Hi, there is no need to mail django-developers when you open a PR -- we do monitor the relevant lists. Cheers, Florian -- 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,

Re: [GSOC] Shifting to Py.Test and Improving the Test Suite

Hi Akshay, On Thursday, February 27, 2014 8:50:32 PM UTC+1, Akshay Jaggi wrote: > > *Why Py.Test?* (http://pytest.org) > >1. Widely Used > > So is nose and unittest, you'll need to add a bit more info to such statements. > >1. Better reporting > > Better how exactly? > >1.

Re: [GSOC 2014] Project Idea

Hi, I am not really sure what you are trying to propose here; generally a proposal should look something along the lines of https://groups.google.com/d/msg/django-developers/CD7OrkJ63zc/VRv2igHJxyIJ -- eg you'll have to do some research on the topic and write up a proper proposal. Cheers,

Re: GSOC 2014 Project Proposal

Hi, On Saturday, February 22, 2014 5:47:00 PM UTC+1, Devashish Badlani wrote: > > Every beginner I feel first starts with TheDjangoBook itself,he may switch > to some other source later. > Every beginner I see in #django starts with the tutorial as they should. > I feel keeping the book

Re: GSOC 2014 Project Proposal

To me the Djangobook is basically (sadly) a dead resource, developing sample projects against the content/topics of Djangobook is not really a GSOC project imo. On Saturday, February 22, 2014 1:36:30 PM UTC+1, Devashish Badlani wrote: > > I have been an Ex technical editor at Brogels,I have

Re: Using namedtuple instead of pure tuples

On Saturday, February 22, 2014 5:24:39 PM UTC+1, Adam Kaliński wrote: > > What do you guys think? > Sounds good, you might check if namedtuple has negative performance effects (I doubt it, but who knows). The reason we didn't add it yet is that it just exists since 2.6. cheers, Florian --

Re: Ticket #9?

On Sunday, February 16, 2014 3:13:28 AM UTC+1, Justin Holmes wrote: > > I didn't mean to suggest that it was nefarious. It's just that that > ticket had some... sentimental value. ;-) > I am pretty sure it's implemented by now:

Re: GSoC query

On Saturday, February 15, 2014 5:01:09 PM UTC+1, anubhav joshi wrote: > > Well I will see what I put in my proposal..it will be based on > aggregation/annotation as well as improving the error message part as > before...I might now look to other things as well like improving tests as >

Re: #19182 backport request

On Friday, February 14, 2014 6:49:26 PM UTC+1, Chris Wilson wrote: > > I'm afraid that the documented feature is totally broken. > I have to disagree, the feature works as advertised as long as you don't use the combination of a custom filter and span relations. Regards, Florian -- You

Re: The unsettings project

Hi, On Friday, February 14, 2014 3:18:08 PM UTC+1, Schuyler Duveen wrote: > > This work started at the Chicago DjangoCon sprint this past September. > Justin Holmes and I were talking to Adrian (and then roped in Jacob). > After discussing the problem and working out a possible way to move >

Re: #19182 backport request

Hi, as Tim noted on the ticket, we are not going to backport this as per our policy. Cheers, Florian On Friday, February 14, 2014 1:53:21 PM UTC+1, Chris Wilson wrote: > > Hi all, > > I just ran into bug #19182 : > > ModelAdmin filtering didn't

Re: DisallowedHost causes 500 errors.

Hi Cliff, just as a side note, the fact that you get those error in your inbox is also a sign of a missconfiguration of your webserver. The Django error is so to say a last resort, on a properly configured system those requests would never reach Django at all. Regards, Florian On Thursday,

Re: Firebird backend for Django 1.6.x is updated (RC state)

Nice, can you also upload wheel packages? On Wednesday, February 12, 2014 2:19:11 PM UTC+1, mariuz wrote: > > Here are a few fixes for v1.6.x Release Candidate 1 commited into > master > > Fixed missing

Re: The unsettings project

On Tuesday, February 11, 2014 8:33:09 AM UTC+1, Aymeric Augustin wrote: > > On 11 févr. 2014, at 03:27, James Farrington > > wrote: > > If you haven't heard about unsettings, it is an attempt to move away from > using the settings global. There was a discussion at

Re: Check Framework Feedback

On Thursday, February 6, 2014 12:31:43 AM UTC+1, Carl Meyer wrote: > > > However, I can see how this might be slightly contrary to expectation > > for Python developers generally. I'd be interested in hearing other > > opinions on this. > > I don't think there's a reason to require the

Re: django_bash_completion in Pypi Package

On Monday, January 6, 2014 7:57:50 AM UTC+1, Brett Nekolny wrote: > > Please let me know if anyone has thoughts regarding this proposed diff. I > would love to be able to get django_bash_completion from my pypi install of > Django, but that just doesn't seem to be possible without this fix. >

Re: Forbidding double imports

Kill double imports with fire :þ (and now) -- 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

Re: Using setuptools to make django-admin.py runnable on Windows (#21340)

Just so we are all on the same page here (summarizing discussions from IRC etc): * We are not going to support setuptools and distutils, this makes the setupprocess difficult to debug and test imo. * Given Donald's "okay" we might switch to setuptools completely * There seems to be a bug in

Re: Self-referenced template recursion handling

templates just to get self referencing templates wouldn't be nice, I think we can agree on that? On Monday, December 9, 2013 7:09:48 PM UTC+1, Florian Apolloner wrote: > > > > On Monday, December 9, 2013 5:18:16 PM UTC+1, Goinnn wrote: >> >> 2013/12/9 Florian Apoll

Re: Self-referenced template recursion handling

On Monday, December 9, 2013 5:18:16 PM UTC+1, Goinnn wrote: > > 2013/12/9 Florian Apolloner <f.apo...@gmail.com > > >> On Monday, December 9, 2013 12:43:04 PM UTC+1, Goinnn wrote: >>> >>> 1. Efficiency: If this new solution slows the compilati

Re: Self-referenced template recursion handling

On Monday, December 9, 2013 12:43:04 PM UTC+1, Goinnn wrote: > > 1. Efficiency: If this new solution slows the compilation/find/render > template, I dislike it > Lots of "ifs" which are not really worth discussing before we run actual benchmarks; also I think that it won't be slower since

Re: Using setuptools to make django-admin.py runnable on Windows (#21340)

On Wednesday, December 4, 2013 11:20:39 PM UTC+1, Donald Stufft wrote: > > entry points are kinda wonky with pip 1.4, pip 1.5 makes them sane. You > would not need a Windows specific Wheel with pip 1.5 > Is there a test-pypi where I could upload Django packages to test this? -- You received

Re: Using setuptools to make django-admin.py runnable on Windows (#21340)

PM UTC+1, Florian Apolloner wrote: > > > > On Wednesday, December 4, 2013 8:24:49 PM UTC+1, Remram wrote: >> >> December 4 12:43, Florian Apolloner >>> >>> To my understanding of >>> https://github.com/pypa/pip/blob/develop/pip/req.py#L633 pip will

Re: Using setuptools to make django-admin.py runnable on Windows (#21340)

On Wednesday, December 4, 2013 8:24:49 PM UTC+1, Remram wrote: > > December 4 12:43, Florian Apolloner >> >> To my understanding of >> https://github.com/pypa/pip/blob/develop/pip/req.py#L633 pip will use >> setuptools for installing -- so why do you ne

Re: Using setuptools to make django-admin.py runnable on Windows (#21340)

Hi Remram, On Wednesday, December 4, 2013 4:56:55 PM UTC+1, Remram wrote: > > November 24 14:37, Florian Apolloner >> >> I am pretty much against setuptools and given that pip is somewhat >> becoming the defacto-standard to install stuff >> > > I comp

Re: Using setuptools to make django-admin.py runnable on Windows (#21340)

Hi, I am pretty much against setuptools and given that pip is somewhat becoming the defacto-standard to install stuff; I'd ask Donald what can be done here (cc'ed him). I don't think it's a good idea to fix this in Django since this is imo a problem in Python itself. Regards, Florian On

Re: Should AdminSite be able to handle different namespace?

On Thursday, November 14, 2013 12:32:51 PM UTC+1, German Larrain wrote: > > So the name of the "other admin" becomes the prefix to the URL names for > the purpose of reversing them. > Not prefix, the prefix is usually always "admin:", since that's the application namespace; what you should

Re: Should AdminSite be able to handle different namespace?

We might have to fix the docs there :) On Thursday, November 14, 2013 12:47:31 PM UTC+1, Florian Apolloner wrote: > > > > On Thursday, November 14, 2013 12:32:51 PM UTC+1, German Larrain wrote: >> >> So the name of the "other admin" becomes the prefix to

Re: Should AdminSite be able to handle different namespace?

with `model_name` when using Django 1.6 > return '%s:%s_%s_%s' % ( > admin_site, > model._meta.app_label, > model._meta.module_name, > view) > > Just my 2 cents. > > Germán > > On Wednesday, November 13, 2013 9:06:50 AM UTC-3, Florian Apolloner wrote: >&g

Re: Should AdminSite be able to handle different namespace?

Hi Russ, On Wednesday, November 13, 2013 2:16:13 AM UTC+1, Russell Keith-Magee wrote: > > The use case was simple -- deploy two instances of admin in a single > project. For example, you might have a truly 'access-all-areas' admin, and > a cut down/modified admin for trusted editors that has

Re: How to livereload Django templates?

Hi Nikolay, this mailing lists is about the development of Django itself; you might wanna ask that on django-users Regards, Florian On Monday, November 11, 2013 5:45:42 PM UTC+1, Nikolay Georgiev wrote: > > Do you know some tips or concrete steps on how to livereload Django > templates? > >

Re: Should AdminSite be able to handle different namespace?

Hi Russ, On Saturday, November 9, 2013 11:34:53 PM UTC+1, Russell Keith-Magee wrote: > > I'm a little concerned about this talk about deprecation here -- the > app_name exists for a reason, and at time the app_name feature was added, > it worked (to the best of my knowledge, anyway). > It

Re: Should AdminSite be able to handle different namespace?

Hi Vajrasky, On Saturday, November 9, 2013 4:47:35 PM UTC+1, Vajrasky Kok wrote: > > While working on this ticket, I was pondering whether we should really fix > this or not because one of the core developers said, > Imo fixing this won't be easy; see for instance how admin_urlname filter is

Re: WSGI Regression 1.4 -> 1.5?

First of all, using prefork and daemon mode is probably not the best choice you can make. I'd assume you are storing state in the process in your auth backend somehwere… On Friday, November 1, 2013 11:30:04 AM UTC+1, HM wrote: > > I have an auth-backend inheriting from model backend that works

Re: Django mysql over ssl (2026, 'SSL connection error: Failed to set ciphers to use')

Hi, this mailing list is about the development of Django itself; please post your questions to django-users -- also read https://code.google.com/p/modwsgi/wiki/ApplicationIssues#SSL_Shared_Library_Conflicts Regards, Florian -- You received this message because you are subscribed to the

Re: Feature Request: Bulk Insert on Fixtures (loaddata)

Patches welcome I'd say, the only issue I see is that we loose the ability to provide good information which object caused the bulk_create to fail; any ideas on that? Cheers, Florian -- You received this message because you are subscribed to the Google Groups "Django developers" group. To

Re: Backwards compatibility and field validation

On Friday, October 18, 2013 12:03:42 AM UTC+2, lucmult wrote: > > I think it's reasonable to assume that by default we want our data to be > consistent. > I disagree, everything which isn't coming from user input should not need validation, since you really __should__ know what you are putting

Re: Backwards compatibility and field validation

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…

Re: Idea about authentication

<ram.r...@gmail.com > > wrote: > >> Submitted patch: >> >> https://code.djangoproject.com/ticket/21105#comment:1 >> >> On Sunday, September 15, 2013 10:09:55 PM UTC+3, Donald Stufft wrote: >> >>> >>> On Sep 15, 2013, at 2:59 PM, Fl

Re: Is "transaction.atomic" in 1.6 supposed to work this way?

On Sunday, September 22, 2013 8:38:10 PM UTC+2, Shai Berger wrote: > > I would take Anssi's suggestion another step forward -- or backward, > depends > where you're looking from :-) -- stop marking transactions for rollback. > Make > save() and associates use savepoints, only on PostgreSQL,

Re: Revert 165f44aa?

On Saturday, September 21, 2013 7:50:34 PM UTC+2, Aymeric Augustin wrote: > > But whenever the with statement spills over two lines, which happens in a > majority of cases, I find it worse than two with statements. It's > especially bad in the transactions tests — I worked in this area today.

Re: get_cache and multiple caches

On Saturday, September 21, 2013 2:12:31 AM UTC+2, Curtis Maloney wrote: > Is there anything else? > Ain't that enough? :p -- 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,

Re: Default session data serializer doesn't support extended data types

On Friday, September 20, 2013 4:40:39 PM UTC+2, Curtis Maloney wrote: > > And the answer is: there's no way for a matching Decoder to know when to > decode any of these types, since there's no schema available. > Good point, it would be doable by serializing into something like '{_type:

Re: get_cache and multiple caches

Hi Tom, On Friday, September 20, 2013 5:04:41 PM UTC+2, Tom Evans wrote: > > On the other hand each call to get_cache('foo') now requires access to > TLS. TLS is slw. Going through something slow to get to something > that is supposed to be a speed up... > You are making a good point,

Re: Default session data serializer doesn't support extended data types

On Friday, September 20, 2013 3:52:30 PM UTC+2, Davide Rizzo wrote: > > On Friday, September 20, 2013 2:55:33 PM UTC+2, Florian Apolloner wrote: >> >> Btw could it be that you are mixing out Encoder and Serializer? >> > > No, I say Serializer when I mean... we

Re: get_cache and multiple caches

Hi Tom, On Friday, September 20, 2013 3:29:03 PM UTC+2, Tom Evans wrote: > > Before you > go too far down the thread local route, could you verify that > retrieving cache objects from a thread local cache is in any way > faster than simply recreating them as demanded. > The main issue here

Re: Default session data serializer doesn't support extended data types

On Friday, September 20, 2013 10:24:00 AM UTC+2, Davide Rizzo wrote: > > - using the raw JSONEncoder by default is not offering any significant > security advantage over using an extended encoder. I feel like it's going > to discourage coders to use JSONSerializer at all. > Btw could it be

Re: get_cache and multiple caches

On Friday, September 20, 2013 8:58:25 AM UTC+2, Curtis Maloney wrote: > > I guess the remaining question to address is : close() > Leave it as is I think. > Thinking as I type... it wouldn't hurt, also, to allow a cache backend to > provide an interface to a connection pool, so the manager

Re: Default session data serializer doesn't support extended data types

Hi Davide, On Thursday, September 19, 2013 4:46:44 PM UTC+2, Davide Rizzo wrote: > > The inconvenience is breaking compatibility with all third party apps that > rely on storing extended data types (such as those supported by > DjangoJSONEncoder) with the default settings. Properly serializing

Re: get_cache and multiple caches

Hi, On Wednesday, September 18, 2013 1:29:25 PM UTC+2, Curtis Maloney wrote: > > 1) Can we share "ad-hoc" caches -- that is, ones created by passing more > than just the CACHES alias. > Imo no, you probably have a good reason if you create ad-hoc ones > 2) What to do about

Re: Question about new tests

Hi Justin, many core developers haven't been at DjangoCon US, so would you mind to summarize a few things like: What is the roadmap, how do you plan to tackle things; who is involved + whatever else you think would be nice to know for someone who more or less heard the first time of this from

Re: Idea about authentication

a longterm solution). Cheers, Florian On Sunday, September 15, 2013 10:27:16 PM UTC+2, Ram Rachum wrote: > > Submitted patch: > > https://code.djangoproject.com/ticket/21105#comment:1 > > On Sunday, September 15, 2013 10:09:55 PM UTC+3, Donald Stufft wrote: >> >> >&g

Re: Idea about authentication

Hi Ram, On Sunday, September 15, 2013 12:34:03 PM UTC+2, Ram Rachum wrote: > > Florian, I'm not sure that you read my message carefully enough. I'm *not > *proposing to reduce the time that PBKDF2 takes to hash. > By replacing the password with a hash before running it through PBKDF2 you are

Re: Idea about authentication

On Sunday, September 15, 2013 11:45:29 AM UTC+2, Ram Rachum wrote: > What if instead of calculating the PBKDF2 hash of the password, we'll > calculate the PBKDF2 hash of its SHA1 hash? Then the time of checking > passwords wouldn't depend on their length, and we wouldn't even have to > place

Re: Performance optimisation documents, ticket 20877

Hi Daniele, On Friday, September 13, 2013 4:18:05 PM UTC+2, Daniele Procida wrote: > > Any further comments would be welcomed. There's some disagreement about > the appropriateness of the last section, < > https://github.com/django/django/pull/1463/files#L5R318> so it would be > particularly

Re: get_cache and multiple caches

Hi, On Monday, September 2, 2013 6:39:09 AM UTC+2, Curtis Maloney wrote: > > Whilst it's conceivable some cache backend will have the smarts to > multiplex requests on a single connection, I suspect that's more the > exception than the case. > Agreed > Obviously, the default would be one

Re: get_cache and multiple caches

Hi, On Sunday, September 1, 2013 4:34:54 AM UTC+2, Curtis Maloney wrote: > > I've a possible solution - > https://github.com/funkybob/django/compare/simple_caches > > Basically, the existing API and behaviours are still available through > get_cache, but you can avoid duplicate instances of

get_cache and multiple caches

Hi, so when reviewing https://github.com/django/django/pull/1490/ I once again ran over an issue with our current caching implementation: Namely get_cache creates a new instance every time which is kind of suboptimal if you don't store it as module level variable like we do with the default

Re: deprecating ipaddressfield

On Sunday, August 25, 2013 12:07:11 AM UTC+2, Michael Manfre wrote: > > IPAddressField is meant for IPv4 addresses and GenericIPAddressField is > for both IPv4 and IPv6. Most backends define different database data types > for each of those fields. E.g. mysql is char(15) vs char(39). Forcing the

Re: Featurereuqest: Helpfull tracebacks

On Friday, August 23, 2013 4:52:16 AM UTC+2, Ben Finney wrote: > > I didn't see a traceback. The OP gave only the error message. How do you > know they are getting the model name? > If he had shown his full traceback you'd see how django came to execute this query; when it reaches your code

Re: Featurereuqest: Helpfull tracebacks

On Thursday, August 22, 2013 6:43:39 AM UTC+2, Ben Finney wrote: > > This could be done by having Django's database interface catch the > error, and chain a new exception from that one: > Knowing the model alone is imo pretty useless since that's in the traceback anyways; also what you suggest

Re: Featurereuqest: Helpfull tracebacks

On Wednesday, August 21, 2013 12:18:24 PM UTC+2, Anssi Kääriäinen wrote: > > Improvements to error messages are usually accepted. This idea, too, if > there is a way to actually do it without ugly hacks. > I doubt there is a way to get that from the error message itself and I'll strongly

Re: Feature request: read-only admin view

On Friday, August 16, 2013 6:19:03 PM UTC+2, Trevor Cox wrote: > > At least two people have already submitted a patch. > Chances that they still work are not really big. > The issue is not the coding but that the feature request is being rejected. > I see 3 core-devs in this thread which seem

Re: Feature request: read-only admin view

As with most open source projects; if you really want to see this done feel free to get coding and submit a patch :) Cheers, Florian On Friday, August 16, 2013 9:01:07 AM UTC+2, Trevor Cox wrote: > > There are lots of reasons why read-only/view permissions are appropriate > for an admin

Re: Deprecation a little harsh?

Hi François, On Tuesday, August 13, 2013 5:46:10 PM UTC+2, François Schiettecatte wrote: > > I have done 1.3.x -> 1.4.x -> 1.5.x and they have all been painless, each > migration taking less than 1/2 day. Point being that back-porting is not > something I would ever need. > It's good to hear

Re: Order of INSTALLED_APPS

On Monday, August 12, 2013 3:41:15 PM UTC+2, Ramiro Morales wrote: > > For translations, we have such documentation already: > > > https://docs.djangoproject.com/en/1.5/topics/i18n/translation/#how-django-discovers-translations > > For templates too:

Re: Deprecation a little harsh?

Hi, On Monday, August 12, 2013 6:21:46 AM UTC+2, Simon Litchfield wrote: > > One of Django's key strengths is the large collection of apps. Some aren't > as regularly maintained as we'd like but we still love them. Is it a little > unreasonable to expect them all to move so fast? > Fast? Imo

Re: Merging Schema Alteration branch

On Sunday, August 11, 2013 12:26:10 AM UTC+2, Andrew Godwin wrote: > > I'll take a look at those over the next few days, Florian, it's the most > serious bug I've seen for a while! > No worries, I was mostly kidding; I want to get this in ASAP too, even with bugs; we'll have quite some time to

Re: GZipMiddleWare documentation

Hi, On Saturday, August 10, 2013 9:54:02 AM UTC+2, Daniele Procida wrote: > > There is this discussion: > which concludes that it shouldn't be deprecated because some versions of > nginx ( don't

<    1   2   3   4   5   6   7   8   9   >