Re: Redis cache support in core

me options in settings.py automatically (copy-pasting settings is about as bad as looking up packages) but honestly I'm used to having to rewrite settings all the time and don't know much about available built-in automaton. Ivan. On Fri, 28 Jun 2019, 04:30 Josh Smeaton, wrote: >

Re: Redis cache support in core

very hard to provide `django.core.cache.backend.redis.Redis Cache` that depends on django-redis and is an alias for `django_redis.cache.RedisCache` -- it's basically the way it works with DB backends, I don't see why it wouldn't be a good idea for cache as well. Ivan. On Thu, Jun 20, 2019, 04:02 Josh S

Re: Redis cache support in core

How about making one of the third-party packages an optional dependency? Celery, for example, does that: you can just install celery[redis] without having to figure out what other packages you need to enable redis support. Ivan. On Wed, Jun 19, 2019 at 6:44 AM Josh Smeaton wrote: > There

Re: Proposal to format Django using black

renaming all your variables so that you don't have to think about naming them? Must be even better for productivity. Ivan. On Wed, Apr 17, 2019 at 12:35 AM Josh Smeaton wrote: > Ivan, what you’re talking about is subjective code formatting, and lends > itself to extreme bikeshedding

Re: Proposal to format Django using black

er is a great way to keep issues detectable by flake8/pylint to a minimum. Ivan. On Sat, Apr 13, 2019 at 6:35 PM Herman S wrote: > Hi. > > I propose that Django starts using 'black' [0] to auto-format all Python > code. > For those unfamiliar with 'black' I recommen

Re: Proposal to re-open #27017 (updating only dirty fields in save())

g on their values and I would really like if there was a simple standard way of tracking dirty fields and saving only them in a reliable way. I'll be grateful if someone finally makes it happen. Ivan. On Tue, Jan 29, 2019 at 4:43 PM Patryk Zawadzki wrote: > I feel conflicted here as I

Re: revisiting the Python version support policy

Yep, I'm definitely in favor of dropping 3.5 early and using all the nice features extensively. Especially type annotations. All projects I work on use 3.6 or later for quite some time now, whatever debian guys might feel about stability. Ivan. On Wed, Jan 23, 2019 at 12:16 PM Josh Sm

Re: A faster paginator for django

you ever release any code, feel free to ping me for review or testing, chances are I like your library and won't have to implement mine :) I have too many library ideas and not enough time to work on them all, collaboration could be much more better. Ivan. On Wed, Dec 5, 2018 at 3:15 PM Sa

Re: Make `raw_id_fields` the default functionality in the admin

e something simple and effective for when you prefer to use the default classes wherever possible. Ivan. On Sun, Oct 21, 2018 at 10:48 AM Aymeric Augustin < aymeric.augus...@polytechnique.org> wrote: > Hello, > > The default widget is fine for configuration tables with no mo

Re: Standalone is_safe_url() function

Yeah, it can be pretty useful at times, for example, in api clients. I used it quite a few times and had no idea it's not a part of the public api. Ivan. On Sun, Oct 28, 2018 at 12:29 PM Adam Johnson wrote: > I needed that functionality on another project that doesn't use Dja

Re: Idea: Allow queryset.get() and queryset.filter() to accept a positional argument for implicit primary key filtering

ut some of them might not for will in the current queryset api. Ivan. On Thu, 1 Nov 2018, 19:41 Ivan Anishchuk, wrote: > Not closely related, but what about composite keys? I think having such an > implicit arg interpretation would make it much more complicated to use, > say, a combinati

Re: Idea: Allow queryset.get() and queryset.filter() to accept a positional argument for implicit primary key filtering

Not closely related, but what about composite keys? I think having such an implicit arg interpretation would make it much more complicated to use, say, a combination of charfield and integerfield as your key (primary or foreign doesn't matter): what does .get(('string', 123)) mean? .get(string=123)

Re: Standalone is_safe_url() function

ct.com/en/2.1/ref/utils/#module-django.utils.http but not a single mention of is_safe_url... Ivan. On Wednesday, October 10, 2018 at 1:06:46 PM UTC+3, Markus Holtermann wrote: > > Hi all, > > Django provides a function `django.utils.is_safe_url()` to ensure that a > given URL (a

Re: Sonar for the Django rpoject

Hello, Here is my blog post <https://sevastoyanov.blogspot.bg/2016/09/install-and-configure-sonarqube-for.html> about setting up SonarQube. I think it takes about 15 minutes, so you can run it yourself if you want (and if you have time of course). Have a good day! Regards, Ivan On

Re: Sonar for the Django rpoject

setting up SonarQube, sonar-scanner and Python plug-in and post it here. It takes not more than 15 minutes, so you can see the issues yourself. Regards, Ivan On Tuesday, September 6, 2016 at 3:32:41 PM UTC+3, Ivan Sevastoyanov wrote: > > Hello, > > I'm back from the vacation. &

Re: Logging config tries too hard

> > It sounds like you are maybe proposing to decide whether to pre-initialize > logging with the built-in default config or not based on whether the user's > LOGGING setting has disable_existing_loggers set to True or False? > Yes, I was thinking on my feet and this was one idea I came up with

Re: Logging config tries too hard

oggers` is explicitly set to False, then we could initialize them as we do now. How does that sound? On Tuesday, September 6, 2016 at 5:44:37 PM UTC-7, Carl Meyer wrote: > > On 09/06/2016 04:57 PM, Ivan Sagalaev wrote: > > I'm > > talking about this function: > > https

Re: Logging config tries too hard

> > Just to be sure, which version of Django are you using? There were some > simplifications in Django 1.9 that attempted to make writing custom logging > configurations easier and further changes in Django 1.10. > I'm using 1.9, but I'm referring to the code in master. > > https://github.

Re: Logging config tries too hard

> > It’s unclear to me as well how the current system is intended to be used. > I can speculate, that the idea was that you *can* disable the existing loggers and define your own, but the effect of it actually disabling all logging from Django instead of it falling through to the custom root lo

Logging config tries too hard

Hello everyone, It's been a while since I last posted here, please forgive if I break any new rules inadvertently. I'd like to revisit a decision made in [18993][]. My use case is very simple and obvious: I want all logging going into stdout. As currently implemented, I can't do it easily with

Re: Sonar for the Django rpoject

ed but in my honest opinion I'm not the right person for doing that. I can copy/paste the rules here but I'm not sure that some of them are understandable from their short description. Regards, Ivan On Monday, September 5, 2016 at 5:40:41 PM UTC+3, James Bennett wrote: > > On Wed,

Re: Sonar for the Django rpoject

plus some other rules. It's just more convenient. Regards, Ivan On Sunday, September 4, 2016 at 2:38:06 AM UTC+3, Sergei Maertens wrote: > > I kind of like these reports, since they can take away some of the early > review work. I would put it on the same level as the `isort` checks

Re: Sonar for the Django rpoject

w the major issues by groups. Regards, Ivan On Wednesday, August 31, 2016 at 2:15:48 PM UTC+3, Tim Graham wrote: > > Any security issues should be reported to secu...@djangoproject.com > , otherwise it's fine to share the information here. > > On Wednesday, August 31, 2016 at 2:25

Re: Sonar for the Django rpoject

t how to export the whole report in a convenient format. Regards, Ivan On Wednesday, August 31, 2016 at 12:55:35 AM UTC+3, Tim Graham wrote: > > Perhaps you could tell us about some of the critical issues so we could > get a sense for that. > > On Tuesday, August 30, 2016 at 4:26:

Re: Sonar for the Django rpoject

steps in my blog so some of the Django members could set up Sonar on his/her machine and see a lot more details and figure out if it's worth it to fix some of the issues. On Sunday, August 28, 2016 at 11:16:57 PM UTC+3, Aymeric Augustin wrote: > > On 28 Aug 2016, at 21:43, Ivan Seva

Re: Sonar for the Django rpoject

OK, I will try to do that on my machine and will post the results here (because frankly speaking I haven't done it before on my own). I don't know when I will have enough time to do it but I guess 3 to 4 days. Regards, Ivan On Sunday, August 28, 2016 at 11:16:57 PM UTC+3, Aymeri

Re: Sonar for the Django rpoject

some "code smells". That way we can prioritize some of the findings for fixing in the next releases. PS: I accept the criticism and won't use guys annymore :) Regards, Ivan On Sunday, August 28, 2016 at 10:23:02 PM UTC+3, Aymeric Augustin wrote: > > On 28 Aug 2016, at 20:46,

Sonar for the Django rpoject

Hi guys, I am new to Django and I want to contribute to the project soon. Sorry for the question if it's not appropriate. Do you consider using SonarQube (or something similar) for code quality analysis? Regards, Ivan -- You received this message because you are subscribed to the G

Re: Must a Django Database Support Migrations?

wing the Zen of Python and making migrations the "one obvious way to do it" and turning them off the not obvious way. Ivan On Wednesday, January 22, 2014 at 5:40:35 AM UTC-6, Andrew Godwin wrote: > > My thoughts in brief on this: > > - Database backends don't support mig

Re: GSoC Meta refactor: Bikeshedding time!!

On 08/20/2014 04:28 PM, Ivan Kharlamov wrote: > On 08/20/2014 03:52 PM, Ivan Kharlamov wrote: >> On 08/20/2014 12:46 PM, Marc Tamlyn wrote: >>> I'd say ArrayField is a straight up data field at the moment. It stores >>> 0-1 lists of data. It's no di

Re: GSoC Meta refactor: Bikeshedding time!!

On 08/20/2014 03:52 PM, Ivan Kharlamov wrote: > On 08/20/2014 12:46 PM, Marc Tamlyn wrote: >> I'd say ArrayField is a straight up data field at the moment. It stores >> 0-1 lists of data. It's no different to CommaSeparatedIntegerField >> (seriously, why does that ex

Re: GSoC Meta refactor: Bikeshedding time!!

On 08/20/2014 12:46 PM, Marc Tamlyn wrote: > I'd say ArrayField is a straight up data field at the moment. It stores > 0-1 lists of data. It's no different to CommaSeparatedIntegerField > (seriously, why does that exists...) > > *If* PG gets the relevant update that will allow `integer[] reference

Re: GSoC Meta refactor: Bikeshedding time!!

On 08/18/2014 02:03 PM, Anssi Kääriäinen wrote: > As for changing ForeignKey to virtual field plus concrete field > representation - I just realized this will be backwards incompatible no > matter what we do regarding categorization. An all-fields including > get_fields() call will return separate

Re: Unexpected behavior in admin views for _popup=1

On 06/26/2014 06:00 PM, e.generalov wrote: > Hello! > > In my AngularJs application I want to reuse some django admin forms (to > "add", "edit" and "delete" orders) > but show them in the iframe instead of popup windows. > > In order to display "add" form in iframe I create a template: > >

Re: Add a generic "getter" filter to the built-in library

y` anyone? I'm not going to say that this is a very big deal, of course, since a custom template filter is easy to write. Philosophically speaking, by insisting that this issue should be solved outside of templates and inside of views, you are putting something that doesn't belong there, si

Re: ImportError: cannot import name actions

en I was running the project with `gunicorn_django` in conjunction with Django 1.6, but I didn't take time to debug and report them since `gunicorn_django` command is deprecated and switching to `gunicorn` command fixed everything. Regards, Ivan > -- > You received this message becau

Re: Django 1.6 and migrating to the new test runner: note on user experience

Hi, Carl, On 09/27/2013 09:01 PM, Carl Meyer wrote: > Hi Ivan, > > On 09/27/2013 03:07 AM, Ivan Kharlamov wrote: >> Maybe I'm a careless kind of guy, but when I test out new versions of >> Django, reading all of the release notes is rarely the first thing that >

Django 1.6 and migrating to the new test runner: note on user experience

ser stories. What do you think? Best regards, Ivan -- 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. T

Re: Is file based cache is safe for concurrent process?

> During cache body creation, concurrent processes can also make useless cache bodies in case usage tmp file (not locking). -- sorry, during cache writing to tmp file... 2013/5/31 Ivan Smirnoff > I was also created the backend, but did not have time to make a fork. > Se

Re: Is file based cache is safe for concurrent process?

13 01:23:52 UTC+1 schreef Russell Keith-Magee het > volgende: >> >> >> On Thu, Mar 28, 2013 at 7:13 AM, Ivan wrote: >> >>> >>> Yes, you are right. But I asked for another reason. >>> For example, I see, that werkzeug's cache write cache tro

ATOMIC_REQUESTS, cache invalidation and concurrent process

With ATOMIC_REQUESTS, after cache invalidation, the concurrent process can re-create cache old data, between deleting of cache and commit. Perhaps this problem should be solved by repeat cache deleting after commit. -- You received this message because you are subscribed to the Google Groups "

Re: Is file based cache is safe for concurrent process?

d first to study the Contributing guide https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/ Thanks for answer. четверг, 28 марта 2013 г., 2:23:52 UTC+2 пользователь Russell Keith-Magee написал: > > > On Thu, Mar 28, 2013 at 7:13 AM, Ivan >wrote: > >> &

Re: Is file based cache is safe for concurrent process?

ked this on django-users. Django-developers is for > discussing the development of Django itself -- it shouldn't be used as > "second tier" support if you don't get the answer you want on django-users. > > Yours, > Russ Magee %-) > > On Wed, Mar 27, 20

Is file based cache is safe for concurrent process?

Hi all. Can anyone tell, does django.cache locks file for writing by concurrent process? -- 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+

Re: Proposal: use SQLAlchemy Core for query generation

вторник, 4 декабря 2012 г., 0:48:04 UTC+2 пользователь Ivan написал: > > >1. Allows to use both, Django-ORM + SQLAlchemy. Single connection. >SQLAlchemy's models are generated automatically form Django's models. >https://github.com/Deepwalker/aldjemy > &

Re: Proposal: use SQLAlchemy Core for query generation

Hi all, I've viewed a few interesting solutions. 1. Allows to use both, Django-ORM + SQLAlchemy. Single connection. SQLAlchemy's models are generated automatically form Django's models. https://github.com/Deepwalker/aldjemy 2. Uses only Django's ORM, but allows to use 4 SQLBuilders

Re: Proposal: use SQLAlchemy Core for query generation

See also syntax evolution of peewee ORM, which initially was Django's lightweight clone. http://peewee.readthedocs.org/en/latest/peewee/upgrading.html#goals-for-the-new-api -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this disc

Re: Redesign of djangoproject.com?

ded) fixing issues, so when you make a repo, please let us know, so I can follow the project. Thanks for the grate job in advance! Ivan -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develo

Re: Revisiting multiline tags

On 02/24/2012 01:29 PM, Chris Northwood wrote: > A +1 from me too, I've really felt the pain on this when doing i18n > templates, I understand the aesthetics, but the aesthetics of > obscenely long tags is also bad imo... > > On 24 February 2012 09:23, Shawn Milochik wrote: >> On Fri, Feb 24, 201

Re: End-user defined fields, how would you approach it?

On 01/29/2012 09:39 PM, Etienne Robillard wrote: > On 01/29/2012 12:31 PM, Ivan Kharlamov wrote: >> On 01/29/2012 09:16 PM, Etienne Robillard wrote: >>> >>> >>>>> For other options checkout this >>>>> guide:http://stackoverflow.com/a/7934

Re: End-user defined fields, how would you approach it?

On 01/29/2012 09:16 PM, Etienne Robillard wrote: > > >>> For other options checkout this >>> guide:http://stackoverflow.com/a/7934577/497056 >>> >>> Best regards, >>> Ivan Kharlamov > > Probably a really mediocre reference assuming its o

Re: End-user defined fields, how would you approach it?

t; > The model that requires custom fields is for example Person. They > might want a custom field to store address, blood type, or any other > thing. > > MANY THANKS in advance! Have a nice sunday! > Bernardo Pires > Bernardo, Hello. For other options checkout this guid

Re: __getattr__ on SimpleTemplateResponse causes problems

Though the patch in the ticket does solve the problem I completely agree with removing the code altogether… I'm not a fan of "helpfully" reformulating exceptions while trying to be more specific. In practice it hurts more than it helps, and this case is just another confirmation. -- You receiv

get_field_display: Django needs a template filter to allow get_field_display for a dynamic field name

return getattr(value, arg)() else: return getattr(value, arg) else: try: return value[arg] except KeyError: return settings.TEMPLATE_STRING_IF_INVALID Here's the corresponding ticket: https://code.djangoproject.com/ticket/1603

Re: RFC: new backports policy

On 04/19/2011 02:35 PM, Daniel Moisset wrote: I'm using 1.3 in production and there's a bugfix I really want, so I do the backport (and write the code, tests, docs). If I submit this to the issue tracker, is there a chance my patch will get into the next minor release, or you won't even consider

Re: #14891, a.k.a. "related managers don't work how we claim they do"

On 04/18/2011 02:59 PM, Carl Meyer wrote: Hmm. Why does it make sense for OneToOneField lookups to behave differently from *_set managers? If I've got a default manager that hides "deleted" objects, for instance: why should deleted objects by default "not exist" when I traverse a reverse FK, but

Re: Accidental logging disabling

On 04/18/2011 08:25 AM, Carl Meyer wrote: FWIW, I don't think changing settings in general to be non-lazy is an option - it will suddenly make a bunch of parts of Django dependent on DJANGO_SETTINGS_MODULE at import time, where currently they only require it at runtime (and even then perhaps only

Re: #14891, a.k.a. "related managers don't work how we claim they do"

On 04/18/2011 11:45 AM, Johannes Dollinger wrote: I'd vote for (C). Deprecate `use_for_related_fields` and always use the default manager for related managers. Then add the possibility to specify custom mangers for individual relations: ForeignKey(Foo, related_manager=RSpecialManager)

Re: #14891, a.k.a. "related managers don't work how we claim they do"

On 04/18/2011 11:16 AM, Carl Meyer wrote: By "just this" I presume you actually mean just the second half of what you quoted ("explicitly set to False")? In other words, you're proposing to make use_for_related_fields work as advertised, but make it default to True instead of False? Not exactly

Re: #14891, a.k.a. "related managers don't work how we claim they do"

On 04/16/2011 04:30 PM, Carl Meyer wrote: in general, related-object access for reverse-FKs and M2Ms, contrary to the documentation, will _always_ use your default manager (actually, a dynamic subclass of it) It kind of makes sense. You don't want your deleted items to appear in results just b

Re: Accidental logging disabling

On 04/15/2011 02:20 AM, akaariai wrote: I have been using setup_environ in my projects, and the lazy initialization in can cause some weird problems, for example if you do manual timing using: start = datetime.now() access settings print 'Used %s' % (datetime.now() - start) You might get weird r

Accidental logging disabling

Hello everyone! I've found a (may be minor) bug with logging and I'm not sure how it can be fixed. Here's a stripped-down example showing the problem: The settings.py simply configures a single root logger: DEBUG = True DATABASES = { 'default': { 'engine': 'django.

Re: HttpRequest.read() issues

Graham Dumpleton: Silly question. Where is the proof that using a limited stream is a performance issue? Last night I actually did test it :-). You're right the difference in performance is less than a statistical deviation between different uploads over network. Tom Christie: Even so, presum

Re: HttpRequest.read() issues

On 04/03/2011 07:03 AM, Tom Christie wrote: It's not very obvious from the docs or source if HttpRequest.read() can always be safely treated as a limited input stream, or if the developer needs to respect HttpRequest.META['CONTENT_LENGTH']. As far as I can tell the intention is that it can alway

Re: Homogenization of User and UserProfile

On 03/18/2011 07:22 AM, Carl Meyer wrote: Don't use AUTH_PROFILE_MODULE or .get_profile(). As far as I'm concerned they bring almost nothing to the table except for the "there can be only one" restriction +1 Just use OneToOneField and the regular ORM access descriptors, and you can have as ma

Re: Homogenization of User and UserProfile

On 03/15/2011 01:49 PM, Michael A. Ryan wrote: In a typical client app, your User object is most likely one robust object which you have to express in Django as both User and UserProfile. It's kind of hard to talk about "typical" Django app because there are so many different of them :-). Howe

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

Hi Russell, I seem to missed this email until lately… Here's my take on it if it still matters. On 01/05/2011 08:29 AM, Russell Keith-Magee wrote: 4) Modify cache_page to force a render of the response. This defeats the purpose of introducing TemplateResponse, and would mean that template r

Re: Fetching results of a query set

On 12/12/2010 06:45 AM, Alex Gaynor wrote: Yes, if you're using iterator you'll have Django storing 100 items at a time. That being said I believe I read that some of the database wrappers do their own caching (it's either mysqldb or psycopg2, I dont' remember which). They both do. They have t

Re: RFC: #12815/#12816 -- TemplateResponse and render() shortcut

On 12/01/2010 05:05 PM, Łukasz Rekucki wrote: from django.conf import settings def without_localization(view): @wraps(view): def decorated(*args, **kwargs): # NOTE: I'm assuming this will actually have any effect - settings caching is a different issue old_value, sett

Re: RFC: #12815/#12816 -- TemplateResponse and render() shortcut

On 12/01/2010 04:26 PM, Łukasz Rekucki wrote: What about view decorators? I don't want to invent use cases here, but if I right now have a view decorator that on it's way out changes something that could alter how a template is rendered (like current language, some settings or the database conte

Re: RFC: #12815/#12816 -- TemplateResponse and render() shortcut

On 12/01/2010 02:52 PM, Łukasz Rekucki wrote: Lots of people find render_to_response so verbose, that they are using direct_to_template() view instead. Django 1.3 deprecates that one, so it would be fair to offer those people a replacement. Forcing them at the same time into the world of lazy bak

Re: RFC: #12815/#12816 -- TemplateResponse and render() shortcut

On 12/01/2010 01:03 PM, Russell Keith-Magee wrote: I'd argue it doesn't simplify anything. It saves you a grand total of 10 characters (plus a couple more on import), but at the cost of the added complexity of having two ways of doing *exactly* the same thing. There is also a loss of explicitness

Re: .limit() on a QuerySet

On 11/29/2010 11:31 PM, Christophe Pettus wrote: Before I put any work into this, I want to know if (a) I'm missing something super-obvious in the QuerySet functionality, or (b) this idea has already been explored and rejected. Hi Christophe, Looks like you're indeed missing queryset slicing

Re: RFC: #12815/#12816 -- TemplateResponse and render() shortcut

On 11/29/2010 02:58 PM, Russell Keith-Magee wrote: My counterargument would be this -- if you use TemplateResponse, there's no need to use a shortcut at all. Yes, this is what I understood from your reasoning. I'm concerned more with documentation. Namely, what are we going to suggest for usag

Re: RFC: #12815/#12816 -- TemplateResponse and render() shortcut

On 11/28/2010 10:13 AM, Russell Keith-Magee wrote: For your consideration, I present a patch to resolve #12815 and #12816, adding a TemplateResponse and a render() shortcut. Thank you! - The render() shortcut doesn't use TemplateResponse. Since render() and TemplateReponse() have exactly th

Re: Gentle Proposal: add 'render' shortcut in 1.3

On 11/02/2010 05:27 PM, Mikhail Korobov wrote: I'm quite busy now and don't think I'll be able to make the patch ready by 1.3 alpha 1. Full feature freeze is expected only by the time of beta so I don't think it's absolutely necessary to push it before alpha 1. Anyway since I care very much

Re: Django/CherryPy problem with POST data

On 11/01/2010 11:21 AM, Mark wrote: Ticket #14594 From a quick look it can be fixed in two ways: - HttpRequest.raw_post_data can always explicitly ask for content_length bytes. If content_length is absent just treat it as 0. - WSGIRequest can wra

Re: Django/CherryPy problem with POST data

On 11/01/2010 08:44 AM, Russell Keith-Magee wrote: The only changes I'm aware of making were related to getting readline() to behave correctly. The patch as submitted didn't return the right values for the readline(len) case. Which call to read() are you saying is wrong? Sorry, my memory has fa

Re: Django/CherryPy problem with POST data

On 11/01/2010 03:06 AM, Russell Keith-Magee wrote: Sounds like a ticket is called for. Mark, can you also CC: me ('isagalaev') on this ticket. I have an idea where it can be broken. I remember that the initial patch was always passing a `size` parameter into .read() of the underlying stream

Re: Gentle Proposal: add 'render' shortcut in 1.3

On 10/30/2010 10:47 PM, SmileyChris wrote: It seems a simple enough proposal that trying to access the content property would raise an error until it is explicitly baked. Problem solved. True. I seem to somehow missed it between the lines. Thanks! I'm +1 on it by the way. -- You received thi

Re: Gentle Proposal: add 'render' shortcut in 1.3

On 10/29/2010 09:38 PM, Carl Meyer wrote: Seems that a template-response-middleware might reasonably want to look at some other response data (headers? or simply extra annotation attributes?) in order to make decisions about what to do. You right. And it's not feasible (or beautiful) to just ri

Re: Gentle Proposal: add 'render' shortcut in 1.3

On 10/29/2010 09:58 AM, Russell Keith-Magee wrote: I agree that it's important to treat people as grown ups. However, this is something that is trivial to do by accident -- for example, printing response.content would be an obvious debug step -- and it will be a non-trivial thing to identify that

Re: Gentle Proposal: add 'render' shortcut in 1.3

Russel: Wouldn't it make sense to put a flag on the TemplateResponse that prohibits accidental baking? Mikhail: So maybe it will be better not to make bake/force_bake public so that users won't be able to shoot themselves in the foot? I don't think it's doable at all. People still can call a

Re: Gentle Proposal: add 'render' shortcut in 1.3

On 10/28/2010 12:24 PM, Mikhail Korobov wrote: The request handling code have to be put into WSGIHandler and into ModPythonHandler so I'll wait until the patch for http://code.djangoproject.com/ticket/9886 will be landed. I'd say it's even worth to wait for http://code.djangoproject.com/ticke

Re: Gentle Proposal: add 'render' shortcut in 1.3

On 10/27/2010 04:55 PM, Mikhail Korobov wrote: 1. 'Border' middleware is a backwards-compatible change, the requirement to bake response in middleware isn't. The difference is only that you propose to execute 'bake' in the end of response cycle and I propose to execute it at the beginning of the

Re: Gentle Proposal: add 'render' shortcut in 1.3

On 10/25/2010 04:33 PM, Russell Keith-Magee wrote: * The problem with messages is a big one -- probably even a show-stopper if we can't find a way to reconcile the general use case that it represents (i.e., we don't just need a fix for contrib.messages -- we need to explain how/why the problem

Re: Gentle Proposal: add 'render' shortcut in 1.3

Hi Russel, On 10/22/2010 05:20 AM, Russell Keith-Magee wrote: Jacob has already marked #9886 RFC, and on first inspection, the patch looks good to me too; I want to have a closer look before I commit, though. If you want to proceed assuming that #9886 will be committed (i.e., make the fix for #1

Re: Gentle Proposal: add 'render' shortcut in 1.3

On 10/21/2010 03:22 PM, Ivan Sagalaev wrote: On 10/21/2010 11:49 AM, Mikhail Korobov wrote: 2. Does TemplateResponse allow pretty exception pages or not? Is Ben's issue resolved? I'll look into it this evening (MSD). So I did. There are actually two problems: - Exceptions i

Re: Gentle Proposal: add 'render' shortcut in 1.3

On 10/21/2010 11:49 AM, Mikhail Korobov wrote: 2. Does TemplateResponse allow pretty exception pages or not? Is Ben's issue resolved? I'll look into it this evening (MSD). -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this g

Re: Gentle Proposal: add 'render' shortcut in 1.3

On 10/21/2010 11:10 AM, James Bennett wrote: Django cares about whether your views meet the following criteria: 1. Is a callable object. 2. When called, accepts an instance of HttpRequest as its first positional argument. 3. When called, returns an instance of HttpResponse or raises an exception

Re: Gentle Proposal: add 'render' shortcut in 1.3

On 10/21/2010 01:39 AM, Mikhail Korobov wrote: 1. Developer writes a view and want to reuse it (e.g. change the context). My assumptions was: a) Class based views are now the recommended way to write reusable views This is where our views differ. I have to admit that I didn't follow closely t

Re: Gentle Proposal: add 'render' shortcut in 1.3

On 10/20/2010 11:51 PM, Mikhail Korobov wrote: #12815 is about introducing TemplateResponse. Is the patch with 'render' shortcut returning just HttpResponse acceptable? I think that TemplateResponse is less useful after class-based views make their way into trunk so 'render' shortcut shouldn't bo

Re: Refactoring and file-like interface for HttpRequest

On 10/02/2010 01:54 AM, Jacob Kaplan-Moss wrote: On Fri, Oct 1, 2010 at 4:46 PM, Ivan Sagalaev wrote: During a sprint before 1.2 I was proposing to commit my ticket [9886] that deals with adding a .read() method to HttpRequest. Adrian suggested that it was too late then and it's bett

Refactoring and file-like interface for HttpRequest

Hello everyone! During a sprint before 1.2 I was proposing to commit my ticket [9886] that deals with adding a .read() method to HttpRequest. Adrian suggested that it was too late then and it's better to bring it up during 1.3 cycle. So here it is. Basic summary of changes is in the first co

Re: ANN: Improving our decision-making and committer process

On 09/30/2010 01:22 PM, Russell Keith-Magee wrote: So, let me be clear on what you're proposing: you acknowledge that the triage process is backlogged. Your proposal is to put extra workload onto the core team - the one group that is already a bottleneck in the process. Pretty much. I just don'

Re: ANN: Improving our decision-making and committer process

On 09/30/2010 03:46 AM, Russell Keith-Magee wrote: Accepted tickets can be: * Purely accepted, indicating that someone has verified that the problem exists, but not how to solve it * Accepted with a patch that is wrong in some way (e.g., fixing the symptom, not the problem) * Accepted wi

Re: ANN: Improving our decision-making and committer process

On 09/30/2010 01:40 AM, Chuck Harmston wrote: In my world, the "accepted" status should only be used in one circumstance: when a person is actively developing under or maintaining a patch for the ticket. It's an indicator that someone has taken ownership of a ticket, to prevent duplication of eff

Re: ANN: Improving our decision-making and committer process

Hello Jacob and everyone. On 09/29/2010 09:59 PM, Jacob Kaplan-Moss wrote: Starting today, we're going to be making some minor but significant changes to the way the Django core committer team "does business." That's about time :-). Congratulations and thank you! I have a comment and a sugges

Re: #717 (If-Modified-Since checked for exact match) should be fixed

On 09/22/2010 12:13 PM, Luke Plant wrote: On Tue, 2010-09-21 at 11:40 -0700, julianb wrote: Uuh, so what's with this? Nothing happened with the ticket and no further comments here either... :( I accepted it on Trac, please see my comments there. Also, you mentioned about the 'condition decora

Re: Proposal: First-class WSGI support in Django 1.3 / twod.wsgi

On 05/26/2010 03:02 PM, Gustavo Narea wrote: Among many other things, one of the components alone provides solutions to some enterprise requirements for Django: * It’s now possible to run code at startup

  1   2   3   4   5   6   >