Re: Feature proposal: Allow shadowing of abstract fields

Oh, I guess Marten never got around to sending an updated pull request with that commit. I don't know of any plans for work on virtual fields. On Friday, July 24, 2015 at 8:03:59 PM UTC-4, Aron Podrigal wrote: > > What was the approach Loic has planned? As Marten had an implementation > here [

Re: Feature proposal: Allow shadowing of abstract fields

What was the approach Loic has planned? As Marten had an implementation here [1] just without the locking functionality. Is all the work related to virtual fields done yet? [1] https://github.com/knbk/django/commit/7ac5b58587ea2a153766d1601965734731609cdf On Jul 24, 2015 7:44 PM, "Tim Graham" wr

Re: Feature proposal: Allow shadowing of abstract fields

Loic indicated the latest approach isn't ideal and said he might work on the issue. https://github.com/django/django/pull/4184 On Friday, July 24, 2015 at 6:59:56 PM UTC-4, Aron Podrigal wrote: > > Bumping up on this again, what are the plans for moving this ahead. -- You received this messag

Re: Feature proposal: Allow shadowing of abstract fields

Bumping up on this again, what are the plans for moving this ahead. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to djang

Re: Should we use __slots__? (and benchmarking memory usage)

On 07/24/2015 09:11 AM, Tim Graham wrote: > I'm interested in this old ticket about adding __slots__ to some of > Django's classes to reduce memory usage: > https://code.djangoproject.com/ticket/12826 > > I wonder if anyone has some experience with __slot

Should we use __slots__? (and benchmarking memory usage)

I'm interested in this old ticket about adding __slots__ to some of Django's classes to reduce memory usage: https://code.djangoproject.com/ticket/12826 I wonder if anyone has some experience with __slots__ and could speak to whether this seems like a

Re: A modest proposal - more blocks in admin templates

Great. I'll do that. Cheers for the advice. On Friday, 24 July 2015 15:55:24 UTC+1, Tim Graham wrote: > > I'd start small, for example, by fixing the existing ticket I pointed out > and any others that are related. Create a new ticket for any other changes. > > I think there might be a tiny perfo

Re: A modest proposal - more blocks in admin templates

I actually think documenting which blocks we have is a good way to be able to change them ironically - we currently don't allow much change in admin templates to avoid breakage elsewhere, this would give us at least a way to say "the HTML generated in block X in template Y is changing". There could

Re: A modest proposal - more blocks in admin templates

I'd start small, for example, by fixing the existing ticket I pointed out and any others that are related. Create a new ticket for any other changes. I think there might be a tiny performance penalty to parsing blocks (someone else can probably speak better to this). Also, too many blocks might

Re: A modest proposal - more blocks in admin templates

In terms of increasing the likelihood of a patch that will get merged: 1. Is it better to leave the documentation issue to one side for now? 2. Would it be better to tackle a subset of the admin templates first or is it better to try and swallow this whole? 3. Would a core committer need to adopt

Re: A modest proposal - more blocks in admin templates

As in something like, "We won't make changes to template blocks without a mention in the release notes."? If we need to make a change for a good reason, I am not sure what a deprecation would look like, if at all possible. On Friday, July 24, 2015 at 9:37:18 AM UTC-4, Collin Anderson wrote: > >

Re: A modest proposal - more blocks in admin templates

The documentation could give better backwards compatibility guarantees. On Friday, July 24, 2015, Tim Graham wrote: > There is at least one ticket about adding more blocks to the admin > templates: https://code.djangoproject.com/ticket/14810 > > You can browse the "contrib.admin" component in Tr

Re: A modest proposal - more blocks in admin templates

There is at least one ticket about adding more blocks to the admin templates: https://code.djangoproject.com/ticket/14810 You can browse the "contrib.admin" component in Trac to find related issues: https://code.djangoproject.com/query?status=assigned&status=new&component=contrib.admin&stage=Ac

Re: Simplifying MANIFEST.in

Pull request is https://github.com/django/django/pull/5039 if someone could double check it. Thanks for the feedback and check-manifest suggestion! On Wednesday, July 22, 2015 at 9:44:10 PM UTC-4, Markus Holtermann wrote: > > On Wed, Jul 22, 2015 at 09:40:08AM -0700, Tim Graham wrote: > >Lately

A modest proposal - more blocks in admin templates

Happy to do some work on this but wanted to get some feedback first. Loose methodology: 1. Skim the most popular admin extensions that exist on django-packages etc 2. Look out for places where they've had to copy entire admin templates to only override a small part 3. Add new {% blocks%} into t

Re: Major features for 1.9

Probably templete based wizard rendering and tasks in 1.9 would be great! On Friday, July 17, 2015 at 11:19:38 PM UTC+6, Tim Graham wrote: > > Currently we have two items on the roadmap: > https://code.djangoproject.com/wiki/Version1.9Roadmap > > PostgreSQL Full Text Search