Re: Feature lists for 1.2

[kmike]

Some features from wiki proposal page don't get their way to google
spreadsheet (ex: 2 cache-related proposals) and they are not mentioned
in the final features page neither in a list of accepted features nor
in a list of rejected features. I understand that there are some valid
reasons for that but, out of curiosity, what are their 'official'
status?

On 23 окт, 22:29, Jacob Kaplan-Moss  wrote:
> Hi folks --
>
> Based on the votes and comments I've received for Django 1.2 I've
> prepared a breakdown of features into high, medium, and low 
> priority:http://code.djangoproject.com/wiki/Version1.2Features.
>
> I've noted associated committers and, where I know 'em, lieutenants.
> Please make corrections if needed.
>
> If you need clarification as to why a particular feature is classified
> where it is, or if you want to see our comments, please check out the
> master vote 
> spreadsheet:http://spreadsheets.google.com/ccc?key=0AtIlKMKDxMBpdGVPVXlTODVLeTBpN
> I'm happy to clarify anything that's not clear, but please lets not
> have an argument about "low" vs "medium" or whathaveyou.
>
> Remember: these are only guidlines. Anything complete by the feature
> freeze deadline (December 22nd) is a candidate for inclusion.
>
> So: we've got sixty days to get new features in - let's go!
>
> Jacob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: decorator_from_middleware change

[kmike]

If you search for `cache_page` decorator than it becomes clear that
traditional approach is to use it in now unsupported way:

myview = cache_page(myviewt, timeout)

For example here:

http://www.google.com/codesearch?hl=ru=N=%22+%3D+cache_page%22++lang:python=rr_r=lang:python

nobody uses `myview = cache_page(timeout, myview)` syntax.

So I suppose this change can broke a lot of third-party apps, for
example django-robots and django-mediafiles.

> I don't know for certain how many people may be using this idiom,
since it was never documented (AFAICT cache_page always documented
itself as putting the timeout first and the view function second), so
I'm not really sure what (if anything) we should do about it.

Not true. cache_page decorator is now documented as putting view first
and timeout second. Take a look at 
http://docs.djangoproject.com/en/dev/topics/cache/#the-per-view-cache

Another thought. If key_prefix is deprecated in cache_page decorator
maybe it should be also deprecated in CacheMiddleware?

On 24 сен, 05:50, Luke Plant  wrote:
> On Monday 21 September 2009 20:27:50 Jacob Kaplan-Moss wrote:
>
> > No, I think this is precisely correct. I've been meaning to do
> >  exactly what you're proposing for a while myself; just haven't
> >  gotten around to it.
>
> > > decorator_from_middleware isn't actually documented anywhere
>
> > I actually avoided documenting it because it's broken. Once you fix
> > it, we should (i.e. I will, if you don't have time) document it.
>
> OK, it's committed now. (r11586, r11593)
>
> Technically this is a bug fix (#6371), so it ought to get backported
> to 1.1.X.  However, it does actually introduce backwards
> incompatibilities with cache_page (cache_page still works exactly as
> documented, but various people were using various undocumented
> features of it).  Also, you could argue it is a new feature - "these
> decorators now work with methods".
>
> So, in light of those things, should it be backported to 1.1.X or not?
>
> Luke
>
> --
> "Pretension: The downside of being better than everyone else is
> that people tend to assume you're pretentious." (despair.com)
>
> Luke Plant ||http://lukeplant.me.uk/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: decorator_from_middleware change

[kmike]

Regarding key_prefix parameter: it's all simply about that:
http://code.djangoproject.com/ticket/11269
My proposal was to move things in opposite direction: to promote
`key_prefix` parameter, document it and make it more useful. If it is
an 'Design decision needed'-type of issue and design decision is made
then OK :)


On 23 сен, 03:16, Luke Plant <l.plant...@cantab.net> wrote:
> On Tuesday 22 September 2009 20:37:05 kmike wrote:
>
> > cache_page decorator previously used to have optional
> >  'key_prefix' argument, not only timeout. Is it gone? Can I use
>
> > @cache_page(3600, key_prefix='vasia')
> > def my_func(request)
> >    ...
>
> That wasn't documented anywhere as far as I can see, so now it's
> gone. I had to make some decision about how far the backwards
> compatibility went, and current policy is to go with documented API,
> which explicitly says "cache_page takes a single argument: the cache
> timeout, in seconds." [1]
>
> If there is some documentation/tutorial about the key_prefix
> argument, or if this change is going to cause lots of breakage,
> perhaps we'll have to revisit this.
>
> For the time being, you can create a 'cache_page' decorator that
> does what you want very easily, as in the example below.
>
> James B - do we have a place to list things like this i.e. things
> that probably should go in release notes?
>
> > Another question: in 'decorator_from_middleware_with_args'
> >  docstring example stated:
> > Use like::
>
> >     cache_page = decorator_from_middleware(CacheMiddleware)
>
> > Is it correct?
>
> Nope, should be decorator_from_middleware_with_args of course,
> thanks, will fix.
>
> Luke
>
> [1]http://docs.djangoproject.com/en/dev/topics/cache/#the-per-view-
> cache
>
> --
> "Pessimism: Every dark cloud has a silver lining, but lightning
> kills
> hundreds of people each year trying to find it." (despair.com)
>
> Luke Plant ||http://lukeplant.me.uk/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: decorator_from_middleware change

[kmike]

cache_page decorator previously used to have optional 'key_prefix'
argument, not only timeout. Is it gone? Can I use

@cache_page(3600, key_prefix='vasia')
def my_func(request)
   ...

Another question: in 'decorator_from_middleware_with_args' docstring
example stated:
Use like::

cache_page = decorator_from_middleware(CacheMiddleware)

Is it correct?

Or maybe I've missed something?

Please excuse my English :)

On 22 сен, 08:04, Luke Plant  wrote:
> On Monday 21 September 2009 20:27:50 Jacob Kaplan-Moss wrote:
>
> > On Mon, Sep 21, 2009 at 1:21 PM, Luke Plant  wrote:
> > > However, decorator_from_middleware is a pain, since it doesn't always
> > > return a an actual decorator, for "historical reasons".  I need to change
> > > this to fix the bug.  Is anyone against this?
>
> > No, I think this is precisely correct. I've been meaning to do exactly
> > what you're proposing for a while myself; just haven't gotten around
> > to it.
>
> > > decorator_from_middleware isn't actually documented anywhere
>
> > I actually avoided documenting it because it's broken. Once you fix
> > it, we should (i.e. I will, if you don't have time) document it.
>
> I've committed my change [1], and also replaced _CheckLogin with my method [2]
> (it was essentially the same method, just generalised).
>
> I haven't added any docs, because I'm not sure it's perfect yet (and also
> because I am lazy and I was mainly working on something else, this just got in
> the way).  In the 'normal' case where you don't need to pass any args to the
> middleware, it is exactly the same (but works for decorating methods now).  In
> the abnormal case, you have to use decorator_from_middleware_with_args, which
> is a pretty ugly name, if explicit.  I don't know if you had other ideas about
> what to do with this.  Changing that name is easy, it's only used by
> cache_page.
>
> Luke
>
> [1]http://code.djangoproject.com/changeset/11586
> [2]http://code.djangoproject.com/changeset/11587
>
> --
> Parenthetical remarks (however relevant) are unnecessary
>
> Luke Plant ||http://lukeplant.me.uk/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: "Delete selected objects" in admin batch edit

[kmike]

It's a very good opinion. I don't want any actions from parent model
admin class too.
Maybe it is worth opening a dedicated ticket?

On 5 апр, 05:56, Alex Gaynor <alex.gay...@gmail.com> wrote:
> On Sat, Apr 4, 2009 at 7:10 PM, kmike <kmik...@googlemail.com> wrote:
>
> > Totally agree, bulk delete shouldn't be enabled by default.
>
> > One more issue with that: it is nice to be able to define actions
> > order in drop-down list. It can be achieved with very simple patch,
> > seehttp://code.djangoproject.com/ticket/10734. But if we have delete
> > action (or any other action) enabled by default, this patch will
> > always put it at top and we will have to overload "get_actions" method
> > again to fix it.
>
> It seems to me that the default behavior of including items from every
> parent class is causing more harm than good.  I'm very tempted to say we
> might be better off just requiring users to either relist every item or do:
>
> class MyModelAdmin(ModelAdmin):
>     actions = ModelAdmin.actions + ['my_action']
>
> Alex
>
> --
> "I disapprove of what you say, but I will defend to the death your right to
> say it." --Voltaire
> "The people's good is the highest law."--Cicero
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: "Delete selected objects" in admin batch edit

[kmike]

Totally agree, bulk delete shouldn't be enabled by default.

One more issue with that: it is nice to be able to define actions
order in drop-down list. It can be achieved with very simple patch,
see http://code.djangoproject.com/ticket/10734 . But if we have delete
action (or any other action) enabled by default, this patch will
always put it at top and we will have to overload "get_actions" method
again to fix it.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---