Re: Kickstarter for Django Admin?

Hi, I already wanted to look at hyperadmin, but got caught up reading what HATEOAS is and how it works first ;) I do have one question if you don't mind: With a REST/HATEOS backend you'd export links with appropriate rel attributes to tell the client what we can do. So far so good, but let's

Re: ALLOWED_HOSTS : Cannot allow hosts with single label

Hi, it's hard to say anything without knowing your real alias, the tests work for me as soon as I remove the underscore which is indeed not allowed in hostnames! Regards, Florian -- You received this message because you are subscribed to the Google Groups "Django developers" group. To

Re: Problem with creating a one-to-one instance

Hi Carsten, first of all, django-dev is not a second level support list, so for the future please refrain from posting here just because you get no answer on the user list. As for the issue on hand, try accessing ma.vbp_id after you assign the instance, this should give you some clues.

Re: [GSoC 2013] contribute to django-deployer for deploying django to PaaS easily

Hi, On Saturday, April 20, 2013 8:03:43 PM UTC+2, LittleQ@NCCU, Taiwan wrote: > > cuz seems like there's no #django-dev, so feel free to add my XMPP > directly: littl...@gmail.com There is #django-dev (sic) on irc.freenode.net. Regards, Florian -- You received this message because you are

Re: [GSoC 2013] contribute to django-deployer for deploying django to PaaS easily

Hi, aside from what Russell already pointed out, I would like to add a few points: * You list "Refactor for Expandability" as last on your schedule. I think it should be at the start, eg compare different solutions like GAE, heroku, Gondor, find a common subset and then write the backends

Re: Changing deferred model attribute behavior

On Thursday, April 25, 2013 7:06:06 PM UTC+2, Adrian Holovaty wrote: > > Also, I should mention that this should be *optional* behavior, as the > current behavior is reasonable for the common case. The API for specifying > this "load everything" behavior is a separate discussion. Perhaps a

Re: Test failures under Oracle

Hi, now that the 1.6 release plan is out, I'd like to push this topic again. If you are using Oracle, now is the time to fix those bugs. Personally I am toying with the idea of dropping Oracle support from core if we can't ensure it's quality. Regards, Florian -- You received this message

Re: Data concurrency, consistency and serializabe

Hi, this question seems to be more suited for django-users. django-developers is for the development of Django itself. Regards, Florian -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving

Re: test discovery

Not good, at least our Jenkins runner which should generate xml output doesn't like it :/ On Saturday, May 11, 2013 5:36:55 AM UTC+2, Carl Meyer wrote: > > I merged this patch tonight. Thanks to everyone who contributed! Now let's > see how the CI servers feel about it... > > Carl > > On

Re: test discovery

Hi Carl, before I read all the tickets etc; why does runtests.py not use the TEST_RUNNER from settings.py (see https://github.com/django/django/commit/9012833af857e081b515ce760685b157638efcef#L60L149)? We'd need that for jenkins to produce xml files as output. Thanks, Florian -- You

Re: test discovery

On Saturday, May 11, 2013 2:38:23 PM UTC+2, Carl Meyer wrote: > > No good reason, just an oversight I think. If that's all that's needed to > make the CI happy, feel free to change it, should be a simple fix. > Perfect, pushed a fix, let's see what jenkins says. -- You received this message

Reopening/Refixing #20246

Hi, I don't think that the fix of #20246 [0] is correct. You started using \xa0 while Wikipedia clearly suggests that we should use a narrow space instead of a full-space (probably U+202F). This is something we learned during our physics courses too, so it's in line with what science

Re: ORA-01882 [was Re: looking up date as str (fails under Oracle, Ticket #20015)]

Hi Shai On Sunday, May 19, 2013 7:12:12 AM UTC+2, Shai Berger wrote: > > Florian, Aymeric, or any Django/Oracle user in Kenya: How did you overcome > this? > I have no idea, I just bang my head against the CI till it works or falls completely apart (well not really, but you get the gist ;)).

Re: Proposal: add request decompression to gzip middleware

Hi, given that I already think that the GzipMiddleware is a bad idea (it should be left up to the webserver), I don't like the idea of adding this to the current middleware. Any reason why you couldn't do this in the webserver? Regards, Florian -- You received this message because you are

Re: Reopening/Refixing #20246

Hi, On Sunday, May 19, 2013 8:18:48 PM UTC+2, Claude Paroz wrote: > > I'm not completely sure. The narrow space should certainly be used between > a number and its unit symbol (kg, cm, Mb, etc.). So your proposal is at > least valid for a part of the patch. However, for "5 hours, 4 minutes",

Re: Proposal: add request decompression to gzip middleware

Hi, On Sunday, May 26, 2013 3:49:48 PM UTC+2, Sébastien Béal wrote: > > - limit resources available with the resource module. Is there any other > parts of Django using this technique? Using rlimits are imo not an option; as (to my knowledge) it affects the whole process and not just the

Re: SQL from Models

Hi, this list is about the development of Django itself, please take your question to django-users. Thanks, 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, send

Re: Supported Python versions for Django 1.7

Hi, On Friday, June 28, 2013 4:17:22 PM UTC+2, Aymeric Augustin wrote: > > As far as I can tell, there's a consensus on dropping support for Python > 2.6. That will allow us to remove the vendored copy of unittest2 and to > take advantage of datastructures introduced in Python 2.7 like

Deprecate FCGI support in Django 1.7

Hi, I'd like to get rid of everything FCGI-specific in Django sooner or later (rather sooner). Flup isn't maintained since a long time and there is no ticket tracker to report stuff. Graham pointed out that if someone wants to use FCGI they can use

Re: Spam on ticket #542

On Monday, July 15, 2013 3:20:16 AM UTC+2, Ramiro Morales wrote: > > Would it be worth look at the web server log to see if these comments > were effectively created by HTTP POST requests at all? > That's what I did to figure out the ip (which I blocked via iptables before Aymeric played

Re: Deprecate FCGI support in Django 1.7

On Monday, July 15, 2013 7:07:08 AM UTC+2, Russell Keith-Magee wrote: > > I'm not arguing that FastCGI is a good option, just that it's prevalent. > And if we're going to stop supporting it, we need to be aware of who we're > cutting off. > We won't cut anything off (maybe aside from the

Re: Deprecate FCGI support in Django 1.7

On Monday, July 15, 2013 4:14:43 PM UTC+2, Jannis Leidel wrote: > > If you're suggesting to move the FastCGI code into a separate app: +1 > I'd have just dropped it, but yes we can move it out; although someone else will have to step up to continue maintaining it (if there is a need to

Re: Deprecate FCGI support in Django 1.7

On Monday, July 15, 2013 6:20:45 PM UTC+2, Some Developer wrote: > > What about SCGI and AJP support? Is that going? > Yes, it's either all or nothing. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and

Re: Deprecate FCGI support in Django 1.7

On Monday, July 15, 2013 9:55:51 PM UTC+2, Aymeric Augustin wrote: > > - Django's core developers don't use FCGI — at least, I don't know any > active core dev who does. > I do, but with a patched flup and a patched suexec and what else, so I am hardly a typical usecase; and I am in the

Re: docs.djangoproject.com very slow

Hi, should be back to normal by now. On Monday, July 29, 2013 7:46:20 PM UTC+2, Kevin Veroneau wrote: > > Not sure where to report this, but the docs.djangoproject.com is going > very slow today, and I received a "504 Gateway Time-out" from the nginx > server. Any ideas? > -- You received

Re: Support Negative Indexing on QuerySets

Hi Mark, How do you think such support would look like? For negative indices you'd have to know the size of the resultset to be able to do "limit somthing offset length-your_negative_index" -- this doesn't seem to make any sense for an ORM. You can always do list(qs)]:-1] though… Cheers,

Re: Support Negative Indexing on QuerySets

On Tuesday, July 30, 2013 11:34:18 PM UTC+2, Andre Terra wrote: > > On Tue, Jul 30, 2013 at 6:06 PM, Florian Apolloner > <f.apo...@gmail.com > > wrote: > >> You can always do list(qs)]:-1] though… > > > Although you really shouldn't [1]. Right, it depend

Re: Support Negative Indexing on QuerySets

On Wednesday, July 31, 2013 1:03:31 AM UTC+2, Andre Terra wrote: > > On Tue, Jul 30, 2013 at 6:55 PM, Florian Apolloner > <f.apo...@gmail.com > > wrote: > >> Right, it depends on your usecase; I was just trying to point out other >> alternatives aside from

Re: Support Negative Indexing on QuerySets

Hi Wim, On Wednesday, July 31, 2013 12:04:42 AM UTC+2, Wim Lewis wrote: > > On 30 Jul 2013, at 2:06 PM, Florian Apolloner wrote: > > How do you think such support would look like? For negative indices > you'd have to know the size of the resultset to be able to do "limi

Re: Avoid unbounded memory consumption when running `manage.py test`

Hi Matt, On Thursday, August 1, 2013 12:08:23 AM UTC+2, Matt McClure wrote: > > Is the ultimate upstream the CPython repository now? Or a separate > unittest2 repository? For Python >= 2.7 it should be CPython; for everything below the separate unittest2 repository. -- You received this

Re: Merging Schema Alteration branch

On Saturday, August 10, 2013 4:41:28 AM UTC+2, Russell Keith-Magee wrote: > > Say… Andrew… there's this guy on a black horse at my front door… says his > name is "Famine"… he wants to talk about the coming apocalypse… :-) > Indeed, I already got migrations which magically unapply themself

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

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: 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: 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 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: 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: 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: 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: 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 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: 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

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: 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

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: 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: 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: 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

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: 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: 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: 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

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

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: Admin-Actions also in the object details view

There is already a ticket for this request: http://code.djangoproject.com/ticket/12090 -- 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

Re: 1.2 beta?

Hi, I am far away from beeing a commiter, but would like to get some thoughts about the AnonymousUser permission checks written down (I'll keep it short to not hijack this thread): By the time I moved permission checks to the backends I didn't thought much about anonymous users (I guess that was

Re: AnonymousUser has_perm/has_module_perms function check authentication backends

On Jan 26, 3:19 pm, Harro wrote: > - If the default backend always returns false for anonymous users then > pluggable apps have to either expect some row level permission system > is installed and used or don't check permissions for things that an > anonymous user can access.

Re: AnonymousUser has_perm/has_module_perms function check authentication backends

> some documentation should also be added. + Tests The question is, whether we want `supports_anonymous_users` to go away at some point or stay forever (I would prefer if it went away and every backend had to support anonymous users; then the patch would need the usual deprecation warnings…).

Re: AnonymousUser has_perm/has_module_perms function check authentication backends

> I would then write a simple decorator which checks the backends for > that flag to determine if we should do a login_required or has_perm > check. > Because a real pluggable app would want to support both :) No it wouldn't. It would either use the permission system or the decorator for

Re: HTML 5

> I'd like to see using the new input types (eg for > email form fields). Since this doesn't break any backwards compatibility > it shouldn't hurt to include this. It is backwards incompatible, every current app which is outputting valid html/xhtml will stop beeing valid; eg this document doesn't

#12804 - decorating admin views marked as invalid

Hi, first of all, I agree with Luke that it's hard to fix this if it's possible at all [1]. The only real problem I have with this ticket beeing closed is the backwards compatibility issue. Decorating admin views worked just fine in 1.1 and r11660 broke it (At least I hope it worked in 1.1, but

Re: #12804 - decorating admin views marked as invalid

r.  I've got it fairly sorted out now, I'll post > tomorrow about this. > > Luke > > On Sunday 07 February 2010 21:11:42 Luke Plant wrote: > > > > > On Sunday 07 February 2010 10:45:29 Florian Apolloner wrote: > > > Hi, > > > > first of all, I agree with L

Re: #12804 - decorating admin views marked as invalid

On Feb 8, 2:44 pm, Luke Plant wrote: > What do people think? +1 for everything which removes the magic from auto_adapt_to_methods. Can't say much about the backwards incompatiblity issue, cause I don't care ;) Of course it would be nice, but given the options I would just

Re: GSoC: App Loading

I don't have much to say, as Alex pretty much covered it; but that's the list: * Assume an app1 which requires another app2 (and has some ForeignKeys to it). Currently that's easy; just import the model and ForeignKey it. How would those imports look like in your case (eg to which models would

Re: default delete() clear() behavior and you.

, Florian Apolloner On Apr 5, 8:06 pm, Kevin howerton <kevin.hower...@gmail.com> wrote: > Hi. > > So I came across a use-case for wanting to delete content (which > django doesn't really handle exactly to my liking).  I just got back > from a vacation in vegas and noticed in a

Re: default delete() clear() behavior and you.

Hi, On Apr 6, 12:19 am, Kevin Howerton wrote: > I only killed one hooker, but it was really small so I don't know if it > counts. Hmmm… > The problem with those patches though are that they don't appear > (correct me if i'm wrong) to account for handling different

Re: Wherein Benjamin Franklin answers questions pertaining to the Django development process

On Apr 20, 10:38 am, Andrew Badr wrote: > Umpires? Strike three off a curveball? +1, though I'd quoted big bang theory, no need for a umpire, bdfl should be more than enough! -- You received this message because you are subscribed to the Google Groups "Django developers"

Re: High Performance solutions are needed to do things like urlretrieve

On Jul 16, 1:51 pm, shi shaozhong wrote: > Any solution for this? Yes; plz post usage questions to django-users. Cheers, Florian -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email

Re: request.is_ajax() and hidden iframe kludge => request.is_framejax()?

Hi, On Jul 16, 7:25 pm, David De La Harpe Golden wrote: > People doing ajax have probably hit the "XMLHttpRequest doesn't do file > uploads (at least not non-browser-specifically), use a hidden iframe > kludge or flash" issue. Anyway, maybe that will change one

Re: djangoproject.com hiccup: community section configured wrong

On Jul 16, 11:20 pm, Jeremy Dunck wrote: > I looked just now, and it looks like the importer ran incorrectly for > one run -- from "My thoughts on DjangoCon Berlin 2010" to "First Post" > on the run at July 9, 2010 at 4:04 PM. Aren't those all from http://nomadblue.com/?

Re: request.is_ajax() and hidden iframe kludge => request.is_framejax()?

On Jul 17, 11:29 am, Gregor Müllegger wrote: > I think Florian meant that its not possible to change HTTP headers by > Javascript XSS attacks (or am I wrong here as well?). Exactly. -- You received this message because you are subscribed to the Google Groups "Django

Re: CSRF Middleware/SSL/Firefox 3.6.8 bug

On Aug 27, 12:20 pm, Mat Clayton wrote: > Any > chance of getting some of the core dev's to think about removing additional > SSL checks, as FF 3.6.8 is a pretty major browser to support and this is > likely to only get worse as adoption increases. Is the additional security >

Re: #12012 Logging: request for comments

Hi, On Sep 25, 1:25 pm, Jannis Leidel wrote: > Given the fact that the current implementation of the app cache does quite a > few hoops to make it possible to implicitely import the models modules by > iterating over INSTALLED_APPS, I'd like to propose to rather move the

Re: #12012 Logging: request for comments

Hi, On Sep 26, 2:55 pm, Russell Keith-Magee wrote: > Yes, there is, and the logging calls I've included in the patch on > #12012 make use of it. All the logging calls take an 'extra' parameter > which can be used to insert relevant context into the logging call, > and

Re: #12012 Logging: request for comments

On Sep 26, 4:13 pm, Jannis Leidel <jan...@leidel.info> wrote: > On 26.09.2010, at 14:45, Florian Apolloner wrote: > Not sure I understand the problem, the app instances are initialized by the > app cache, at the same time as the proposed logging patch would import the > star

Re: Proposal: Meta.required_together

Please post usage questions to the users list. This is already doable with model validation. Florian -- 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

Re: Proposal: Meta.required_together

On Sep 27, 9:22 am, "David P. Novakovic" wrote: > Is it? I read this as different to anything in the ORM. Well either way; he could have been more specific which stuff he is talking about (remember the only classes having Meta are Modelform and Model -- at least does

Increasing the usefulness of ModelAdmin.get_formsets

. Any thoughts? Cheers, Florian Apolloner -- 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

Re: Permission support for admin inlines

Hi, the permission checking should be doable if my ideas from http://groups.google.com/group/django-developers/browse_thread/thread/bfad2774ff7c357b# get in. So if someone can come up with a proper api as suggested by Russell I'd be happy to help codewise (this way we could even work around the

Re: country and states list in registration form

On Nov 16, 6:29 pm, hemi19 wrote: >  If anyone know plz help me Plz post usage question to django-users! Thx, Florian -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to

Re: ModelForm + MultiValueField = form.save() problem

Hi, Plz post usage questions to django-users. This group is about the development of Django itself. Cheers, Florian -- 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.

Re: Should i report this like bugs in TRAC? Generic Views issue? django.13 alpha and svn

+1 on fixing the the verbose_name_plural usage, as __every__ user with an activated language (that is: aside from english) will run into it. Regarding the double entry in the context: I am +1 on leaving object_list in there. This way middlewares (or other generic view mixins) could act on

Re: Opinions on #15012 -- cache_page and TemplateResponse incompatibilities

Hi, Option (5) sounds great; but if you want backwards compat option (1) is the only way to go. cache_page isn't the only decorator affected by this problem; I could imagine there are many decorators in 3rd party apps which try to alter the response. So the question is how much code will we break

Re: Opinions on #15012 -- cache_page and TemplateResponse incompatibilities

Hi, On Jan 6, 12:02 am, Russell Keith-Magee wrote: > There are no backwards compatibility concerns here. We're talking > about the class-based generic TemplateView. Sorry, I just noticed now, that the current function based views are still function based and not

r15401 and removing star imports

Hi, I think the "url" function should get added to the imports in http://code.djangoproject.com/changeset/15401 since many people use it by now. Any thoughts or objections? Cheers, Florian -- You received this message because you are subscribed to the Google Groups "Django developers" group.

Re: r15401 and removing star imports

In previous Django versions it was necessary to import those; that's no longer the case. Cheers, Florian On Feb 5, 11:21 am, lucky wrote: > Look at > thehttp://code.djangoproject.com/browser/django/trunk/django/conf/urls/d... > . > There are __all__ = ['handler404',

Re: the new SELECT DISTINCT query in 1.3 rc1, and how to turn it off

Hi, On Mar 5, 9:30 am, akaariai wrote: > on(primary_key) id, val1, ... from table order by primary_key this > would solve the problem. Is "DISTINCT ON" part of the SQL standard at all? Cheers, Florian -- You received this message because you are subscribed to the Google

Re: uWSGI documentation

On Apr 2, 1:23 pm, James Pic wrote: > I think it should because it's easier, safer, faster and more secure > than flup or mod_wsgi. Also, it made my sysadmin life really easy and > that's something cool to share with the community. +1 on more docs, since uwsgi is quite

Re: Ticket #15860: modelform.is_valid() and modelform.errors fail to anticipate database integrity errors, allows exceptions to reach the user

Hi, On Apr 20, 8:00 am, legutierr wrote: > modelform.is_valid() fails to anticipate database integrity errors > when those errors involve any fields that are not part of that form > itself. That is wanted behaviour, eg consider my workflow: class SomeForm(ModelForm):

Re: "unique_together" only validated in modelform.is_valid() if ALL of the referenced fields (Ticket #13091)

On Apr 23, 7:23 am, Carl Meyer wrote: > This is really giving me the itch to build a new context-manager-based > idiom for ModelForm validation in 1.4 that would allow modification of > the to-be-saved object within the context manager and always perform > full validation of the

Re: "unique_together" only validated in modelform.is_valid() if ALL of the referenced fields (Ticket #13091)

Hey Carl, On Apr 23, 5:55 pm, Carl Meyer wrote: > http://groups.google.com/group/django-developers/msg/3014f29c5125653ais > where it was briefly mentioned by Lukasz, I haven't seen any discussion > since. Thx > In any case, if we have this, I could see switching the admin to

Re: "unique_together" only validated in modelform.is_valid() if ALL of the referenced fields (Ticket #13091)

On Apr 23, 7:12 pm, Florian Apolloner <f.apollo...@gmail.com> wrote: > > In any case, if we have this, I could see switching the admin to use it, > > and perhaps adding an overridable method that's called from within the > > context manager, to allow you to complete/

Re: logging view errors

Hi, On May 10, 11:33 pm, Shawn Milochik wrote: > You and someone on django-users both told me about process_exception, > which I had been unaware of. It looks perfect for what I need. There is also a signal for it:

Re: Error importing template source loader /media/OTHERS/wb development/python/codes/django/django_bookmarks/../django_bookmarks/templates: "Import by filename is not supported." Request Method:

Hi, please post usage questions on django-users, not django-developers. This mailing list is about the django development itself… On May 15, 4:09 pm, kracekumar ramaraju wrote: > I am getting this error > > Error importing template source loader /media/OTHERS/wb >

Re: Deprecation policy for IE6

Hi, On Jun 9, 1:11 pm, Gert Van Gool wrote: > I remember from the HTML5 doctype that some people (with app in enterprises) > need the support Right, but even Google is dropping support for IE < 8 [1]! And if Google is trying to get companies to use newer browsers we

Reversing translated urls in templates

Hi, I would like to get some feedback on https://code.djangoproject.com/ticket/16332 Jacob suggested that the standard url-tag should take a lang argument so we don't need an extra tag (okay, his actual concern was the dislike of the name i18n_url ;)). I would like that idea too, but I am

Reversing translated urls in templates

Hi, I would like to get some feedback on https://code.djangoproject.com/ticket/16332 Jacob suggested that the standard url-tag should take a lang argument so we don't need an extra tag (okay, his actual concern was the dislike of the name i18n_url ;)). I would like that idea too, but I am

Re: Reversing translated urls in templates

On Jun 25, 11:58 am, Jannis Leidel wrote: > As I said initially when we discussed this on IRC, I believe a "i18n_url" is > good enough > and would fit well with the other i18n related template tags. Jupp, I just wanted to here if someone else had different feelings about it.

Re: Django 1.4 Roadmap

Hi, On Monday, August 8, 2011 2:19:07 AM UTC+2, Russell Keith-Magee wrote: > > someone who has the spare time to manage the release process. That's > been me for the last two releases; I'm fairly certain I won't have the > spare cycles to make it three in a row. > Is the release process

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

Stupid question, but why do you let inactive users login at all? I mean is this really a problem of the decorator and not of the login system you use?! -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web

<    1   2   3   4   5   6   7   8   9   >