Re: Ticket #25236: Remove ifequal from the template language

I commented on the ticket - it's been redundant since Django 1.2 when the smart if was introduced. +1 to deprecating it. On 6 August 2015 at 17:15, Daniel Greenfeld wrote: > No modern project uses ifequal. No one recommends it. I argue it is taking > up valuable bytes in the project. Let's remov

Re: Ticket #25236: Remove ifequal from the template language

ifequal is technical debt in Django. It's a legacy way of doing things which we would not add now. Sure, we don't have to remove it, it isn't blocking us from doing anything else and it isn't broken, and it doesn't need much maintenance. However, as with all technical debt, it has a cost. It's add

Re: #25227 Add utility method `get_updated_model()` to `ModelForm`

I agree that this is an anitpattern. I'm not fond of `get_updated_instance()` as a name, I'm not sure what the correct option is here. Arguably we should split save() into two parts - ModelForm.update_instance() and ModelForm.commit(). ModelForm.save() simply calls these two functions, with the lat

Re: Ticket #25236: Remove ifequal from the template language

I think Tim's suggestion of releasing the tag as a separate library which can be included in builtins answers Karen's concerns about updating 3rd party templates. I admit that is a case I had not considered. Marc On 7 Aug 2015 15:31, "Tim Graham" wrote: > I put together a pull request to see how

Re: Generic forms (ModelForm) provide HTML for a form! Can generic views (DetailView) do same?

The problem with bootstrapping code like this is that it's great for a super simple project, but you instantly want to customise it for any project of any serious scope. It seems to me a perfect candidate for a simple external project, although you may wish to have a different API so it's more reu

Re: Document/make public prefetch_related_objects

Nothing on `query` is public at the moment - I can see the merit in adding a public API to do this kind of work though. Can you open a ticket? https://code.djangoproject.com/newticket On 14 August 2015 at 13:26, Adam Johnson wrote: > *prefetch_related* is great, but it would be nice to be able t

Re: Django Admin New Look

+1 to the svg option. On 16 August 2015 at 20:00, elky wrote: > Hi guys, > > I made double work for vector icons - now we have Font and SVG icons. > Let's choose what to use. > > *Quoting my comment > from SVG > discussion here:* > > Well,

Re: Django Admin New Look

I don't know about schedule, but caniuse reports IE8 browser usage at 1.5%, more than IE9 or IE10. There's an argument we shouldn't be "enabling" people still using XP who are stuck on IE8, and this is a decreasing problem, but I don't think we can tie ourselves to Microsoft's support dates. On 1

Re: Enhancement to the call_command function to allow the use of modules as arguments

This is a deliberate approach you would use - South used it for years to customise syncdb. call_command is intended as a python API for testing `$ django-admin foo`. Two of your arguments are based around IDE usage, which I don't think is a valid argument, and the third is about reducing string ma

Re: Django ORM query syntax enhancement

I strongly agree with the third party approach. On 18 Aug 2015 17:49, "Anssi Kääriäinen" wrote: > I'm still thinking we shouldn't integrate any new query syntax into > 1.9. Instead lets make it easy to create 3rd party apps that offer > different querying syntax, and then lets see which solution

Re: draft blog post for Oracle help

Hi Jani, Thanks so much for sticking your hand up to help maintain Oracle! It is an important part of our ecosystem. Marc On 19 August 2015 at 07:45, Josh Smeaton wrote: > I'll also stick my hand up to be involved with the Oracle backend, but not > the Oracle GIS backend. I don't have a lot of

Re: Django Admin New Look

FWIW, I can see the arguments here and I would definitely like to move to jquery 2 and drop old browsers (aggressively). Actually having a solid browser support policy, a redesign etc would be a great time to do this as well. I can see we are likely to get some backlash, but maybe less than I thin

Re: Pre-DEP: community support of unmaintained versions of Django

Very happy with 1.6.11.x On 19 August 2015 at 16:31, Carl Meyer wrote: > On 08/19/2015 09:28 AM, Donald Stufft wrote: > > On August 19, 2015 at 11:25:55 AM, Carl Meyer (c...@oddbird.net) wrote: > >> In my ideal world, the version number would help convey unofficial-ness > >> a bit more strongly,

Re: Django Admin New Look

I think this is a bit of a misnomer - if we include a jQuery without IE8 support we will start dropping IE8 from the CSS, our own custom javascript, new jquery features, community plugins will drop it etc etc. For 1.9 itself it may simply be a case of swapping in a different jQuery version, but it

Re: Password validation in Django revisited

I agree with Aymeric and Markus that createsuperuser should not validate strength of passwords when DEBUG is on. Having to use a secure password for development/test accounts is an unnecessary level of interference for users. I agree its safer to prevent using admin/admin in production and this is

Re: Adding a URL tagging feature

Some quick thoughts: - I'm unconvinced that selecting urls by a given type is a common use case - can you expand on that? - Implementing the detection and usage of tags as middleware seems not as nice as in decorators to me, especially as the middleware tree can be... unpredictable in its behaviou

Re: status of 1.9 release blockers

2 PM UTC-4, Tim Graham wrote: >>> >>> Status with 2 weeks and a weekend to go until alpha (Monday, September >>> 21). >>> >>> Planned major features for 1.9: >>> >>> PostgreSQL Full Text Search (Marc Tamlyn) >>> >>> I haven

Re: moving the class-based View base class out of django.views.generic?

The idea has been discussed before and was rejected as needless code churn if I remember correctly. I'm afraid I can't remember when or where this discussion happened, it could have been an in person one at a sprint, I can't immediately find a record on this mailing list. Perhaps the fact it's come

Re: Django ORM query syntax enhancement

I don't think complex cases need to have __ equivalents, but I also dispute that long chains like that are necessarily a bad API, I don't find your option 1 particularly neat compared to option 2. Worth noting though that you've used a 2-valued function there which is not a lookup in the same sense

Re: Fellow Report - October 17, 2015

This is awesome news for Django's status in enterprise, great work everyone. I hope something comes from the Microsoft Fellow concept, that would be brilliant. On 20 October 2015 at 15:18, Michael Manfre wrote: > > On Tue, Oct 20, 2015 at 3:02 AM, Aymeric Augustin < > aymeric.augus...@polytechn

Re: makemigrations --exit; exit status feels backwards from conventions

I see what you mean and the inherent problems with the design. However fundamentally the command you are running is "make some migrations", and the "I don't have any to make" step is clearly an error case, not a success case. In particular it would be very wrong for the real "I want to make some mi

Re: Why passing request, *args, **kwargs in dispatch method for generic views

This would cause too much churn for user code - there are millions of CBVs in the wild with customised dispatch/get/post/etc methods which expect these variables and perhaps use them directly. Unfortunately this ship has sailed. On 23 October 2015 at 14:45, Tom Christie wrote: > Although those v

Re: Django 1.9: default='' no longer permitted on model field (with blank=False)

I disagree with this system check and I would like to see it reverted before 1.9 final. I admit that my opinions here are skewed by the fact that I think model level validation is fundamentally not well implemented by Django at all. I work to a philosophy that there are two places where validation

Re: Python 3.5 Support in Django 1.8.x?

FWIW, I think we should add 3.5 support to 1.8. On 23 October 2015 at 17:08, Tim Graham wrote: > Officially Django 1.8 doesn't support Python 3.5. In practice, I think it > probably works. See details in https://code.djangoproject.com/ticket/25502 > about why the 1.8 test suite doesn't pass with

Re: a standard descriptor signature?

Sounds good to me. There's not any (good) reason why anyone would be calling these with kwargs that I can think of so we're safe from a compat perspective. Marc On 26 October 2015 at 03:25, Loïc Bistuer wrote: > +1 > > > On Oct 25, 2015, at 23:09, charettes wrote: > > > > Now that Curtis did a

Re: Provide a way to pass kwargs when initializing the storage class

I'm definitely in favour of a format allowing multiple storage back ends referred to by name. For larger sites it is not unusual to manage files across multiple locations (eg several S3 buckets). The storage param to FileField would be allowed to be the key, and there would be a get_storage functio

Re: Proposal: add new template tag "age"

Agreed, this does not belong on core. In particular the formatting of a duration varies widely depending on the expected age range, languages and site context. Naturaltime is one implementation, the specific case you seem to be hinting at is a count of years, which is definitely too particular for

Re: Oracle GIS update

Thanks for getting it running at all! It looks to me like those tests just need to be less accurate for Oracle, good plan. Did you have any specific changes to make to get it to run at all? If so we should include those soon, irrespective of whether the fixes for these other tests make it into 1.

Re: [Feature Request] Performant values_list query

To give some brief historical context: values_list has been around a LONG time, so I wouldn't say anyone has consciously designed it with performance in mind above "it's faster than complete model loading". The most noticeable thing which your code does not do which an implementation of values lis

Re: Non-atomic migrations in Django?

+1 to idea and API. I've wished I had this recently - even if it's just so I can check up on the progress of a slow running data generation migration so it flushes the data every few 100 records. On 24 November 2015 at 16:07, Aymeric Augustin < aymeric.augus...@polytechnique.org> wrote: > I like

Re: Bringing some popular must have django tools/packages under django org umbrella

This is something the core team discussed in Amsterdam. I believe there was consensus to trial it with Django registration. I should catch up with James and see if it is transferred. If this goes well I see no reason why not. The biggest problem is the selection of packages, we have historically w

Re: Make template caching a feature of the Django template engine

So. If I understand correctly, this would deprecate the existing cached template loader, replace it with a more powerful, debug ready version (on by default?). Assuming this is what you mean, I wholeheartedly support this. There's no reason not to be performant by default. Marc On 23 Nov 2015 2:16

Re: Keep django/django-old GitHub repo?

As there are no active PRs there any more I'm pretty sure it can be ditched. On 25 November 2015 at 14:36, Tim Graham wrote: > Does https://github.com/django/django-old provide any value? I think it > can be deleted. Maybe there are a few links to the pull requests there but > I've never come ac

Re: Add an optional parameter to values() that returns a nested dictionary for foreign keys

I can see a use for this, but the API is unsure. Given that from a performance point of view it should be possible to do this as a transform after a values query (in most cases using a similar lazy sequence-like object will maintain the performance you need), can I propose implementing it as an ext

Re: worth adding PyPy to continuous integration?

If we can get it running on the CI reasonably easily I see no reason why not. On 2 December 2015 at 16:46, Tim Graham wrote: > Once in a while, we get a ticket about failures when running the Django > test suite on PyPy. Sometimes they are bugs in PyPy, other times we use > something that's not

Re: Backporting ticket 25548 into 1.9.x

Agreed the reasoning is sound. This is a major bug as far as I'm concerned and I'd like to see it backported. Thanks for bringing it up. Marc On 6 Dec 2015 1:05 p.m., "Shai Berger" wrote: > On Sunday 06 December 2015 14:52:08 Aymeric Augustin wrote: > > > On 6 déc. 2015, at 10:49, James Bennett

Re: Split DeleteView into a more generic ConfirmView

Hi Lennart, I certainly like the idea and have written at least two implementations of `ConfirmView` in my projects before. Without getting into specifics, I'm not sure how we feel about adding more generic views like this, even where it does make sense. To me a good initial course of action could

Re: Split DeleteView into a more generic ConfirmView

to target > django-braces. Will take me a few days tho, because I am loaded with > (school) work right now :). > > --Lennart > > On Tuesday, December 8, 2015 at 10:38:01 AM UTC+1, Marc Tamlyn wrote: >> >> Hi Lennart, >> >> I certainly like the idea and have writ

Re: Channels integration plan, first draft

[Note: I have not read all the channels docs, sorry if some of these points are covered there.] On a packaging note, is there a way to use django[channels] type syntax like flask does? I'm not familiar with the restrictions of this but it may remove the need for try/except imports. I'm also curio

Re: Decoupling the ORM

I agree that the current uuidfield is a simplistic solution to be used as autofield, and having a way to specify your autofield type globally would be good, equally something like a biginteger field. The complexity involved with doing this (custom RETURNING statements, database level defaults, inte

Re: deprecate or undocument shorcuts.render_to_response()?

I'd be in favour of just undocumenting it for now. On 22 December 2015 at 16:27, Alasdair Nicol wrote: > I think that updating the docs to use render instead of render_to_response > is an good change. Many of the CSRF problems that I see new users > struggling with are solved simply by switching

Re: Add "view_decorators" to django.views.generic.View

Personally, I find that decorators aren't the best way of interacting with CBVs. They're useful when you have a mixed style codebase, but I tend to convert the decorator into a mixin applied at the appropriate point. I think the style of decorating in the URLconf is horrible. Marc On 21 December

Re: admin: implementing list_prefetch_related

Hi Richard, Overriding the queryset is a pretty simple method override, I'm not sure there is sufficient need for prefetching here. In particular, the syntax for prefetch related is much more complex than for select related, so it's less well suited to this kind of shortcut. Marc On 30 Dec 2015 1

Re: Migrations, commands and syncdb

I have generally not kept my migrations so they always work from scratch for similar reasons Luke said - Data migrations are often dependent on the data in the site - this is particularly relevant to content-driven (CMSy) sites where I may need to move a load of page about as a data migration at

Re: Proposal/Discussion: url and template search using the directory structure of apps within django sites

I'm really quite unconvinced by your arguments I'm afraid. In particular one of the strengths of the normal template loader is that it does *not* start locally - so I can use a pluggable application and override templates very easily. The normal pattern for pluggable applications is that they n

Re: Testing generated SQL under different backends

In terms of non-core backends (and I include Oracle in this) - my preferred option would not be to include them all in core Django, but to collate them in and manage them under the Django project - i.e. github.com/django/django-mssql. These are "looked after" by the Django project to ensure tha

Re: Ticket #7220: Last_login in django.contrib.auth should have null=True

There's actually quite a good reason why you can't override model field in Subclasses in the general case - the parent model actually creates a table of its own. In the case of abstract parents this should be possible, even without an override flag. I'm not sure if there are some difficulties in tr

Re: Make sure QuerySet.get() does not fetch more rows than it absolutely needs

I'd be inclined to agree with Anssi that we could do something like LIMIT 21 to just remove the issues with large numbers. I have found it quite helpful to have the exact number when it's small - especially when debugging issues with strange joins etc. On 4 June 2013 15:02, Jacob Kaplan-Moss wro

Re: Patch submission on ticket 20122

No, RFC is for someone else (not a core dev) to mark your patch as correct. In general there's no formal way to get attention, although the 5-for-1 policy can largely guarantee that. Alternatively #django-dev on IRC can be a good place to get someone's attention. Some of us also monitor github PRs

Re: MAC adddres field

Personally, I'm not convinced that it should be part of core Django, especially as only one of the supported databases covers it. There seem to be some implementations about in the wild, though they don't appear to use the PG specific functionality. https://github.com/tubaman/django-macaddress htt

Re: Bugfix contributing

Please open a ticket and the corresponding pull request. You may wish to read https://docs.djangoproject.com/en/dev/internals/contributing/ Marc On 2 July 2013 11:54, Денис Катаев wrote: > Hi Everyone! I've found a django bug without a ticket in model_formset. > I fork a github repo and commit

Re: Extending Django Admin functionality

Please ask questions about using Django on django-users. The topic of this list is the development of Django itself. Thanks, Marc On 2 July 2013 09:46, wrote: > Hello, > > I am a newbie to Django and would like to know if the functionality of > Django admin can be extended to my own needs. > I

Re: Merge policy for cleanup commits

I have to agree with Aymeric, despite being one of those people who wanted to fix this at times in the past. It is worth remembering that some areas of the Django code base are very old, and python coding standards in the community were not as strong when the code was written. Believe it or not, t

Re: Confusion around generic views queryset cloning.

I don't think this should need documenting explicitly. It's the same issue as using mutable default arguments or attributes to a class. If someone is writing their own generic CBVs without understanding I don't see why the queryset case is any more problematic than having a class with an empty list

Re: Deprecate admindocs?

+1 On 25 July 2013 13:29, Aymeric Augustin wrote: > Hello, > > I'd like to deprecate admindocs. Here are my reasons: > > 1) It's called the "documentation generator", but it only operates on > docstrings. This promotes the idea that docstrings are appropriate > documentation, while the Python an

Re: django.utils.functional.cached_property

+1 On 7 August 2013 08:16, Anssi Kääriäinen wrote: > +1 to documenting it. > > > On Wednesday, August 7, 2013 12:28:59 AM UTC+3, Daniele Procida wrote: >> >> Is there any reason why django.utils.functional.**cached_property should >> not be documented, so that it can easily be used? >> >>

Re: Usage and documentation of F()

(Disclaimer: I didn't write any of this code, I'm just working from my own possibly flawed understanding) The main point of using F is not generally for performance per se, rather for database consistency. In the first example, the performance increase is negligable, but you get two significant be

Performance optimisations in the deployment checklist document

I think we should at consider mentioning the `cached_db` session engine in the performance considerations part of the deployment checklist. It's an easy setting to enable which does give a performance boost, although the hit caused by it is decreased now we have persistent connections. That sai

Re: Proposal: remove triage stage someday/maybe

I agree with what Russ and Tim said. -0 On 19 August 2013 02:36, Russell Keith-Magee wrote: > > On Sun, Aug 18, 2013 at 4:10 PM, Wim Feijen wrote: > >> Hi, >> >> When triaging tickets I came across the triage stage Someday/Maybe. The >> docs say I shouldn't use it. :) I think they are right. >>

Re: Performance optimisations in the deployment checklist document

Opened https://code.djangoproject.com/ticket/20938 On 16 August 2013 20:01, Daniele Procida wrote: > On Fri, Aug 16, 2013, Tim Graham wrote: > > >I don't think there's a reason to recommend one of the two cached sessions > >backends over the other as the choice is application dependent, but +1

Re: #19316 broke the external API of django.views.generic.View by changing where self.request is set

Using views externally to `.as_view()` sounds like a potential pitfall to me - I would not suggest that this is part of the public API of a view. Is this in testing code, or production? As for the change itself, this was precisely done *because* we want people to override `dispatch()` - the issue

Re: ValidationError for fields

Yeah I'm definitely on the "document add_error first, ValidationError(dict) as a more powerful alternative". The second option is necessary to do clever things directly from Model.clean() Marc On 20 August 2013 07:07, Anssi Kääriäinen wrote: > On 08/20/2013 08:26 AM, Loic Bistuer wrote: > >> A

Custom prefetches (#17001)

Ticket #17001 concerns the ability to customise the querysets used when using `prefetch_related()`. This has a working implementation with a less than ideal API - see the patches on the ticket. As the API design seems to be the main issue here, Anssi and I bounced some ideas around on IRC, and I t

Re: Custom prefetches (#17001)

The other restriction imposed by your suggested api is that the Count or Model list will presumably only know the standard queryset api - with a queryset= parameter any custom qs methods will work. This is perhaps more necessary in the annotate case as it is naturally a restricted api - select rel

Re: deprecating ipaddressfield

+1 to deprecating the old field. This caused me some confusion. Now migrations are in master, the upgrade path will be much simpler. Is the legacy field releasable as a 3rd party package? It seems to be this would be difficult due to differing behaviour across DBs. Marc On 25 Aug 2013 18:14, "Eri

Re: Custom prefetches (#17001)

.prefetch_related('authors').prefetch_related('authors__books', to_attr='unpublished_books', queryset=Book.objects.filter(published=False)) On 26 August 2013 13:15, Anssi Kääriäinen wrote: > On Friday, August 23, 2013 6:03:13 PM UTC+3, Marc Tamlyn wrote: >>

Re: Model.save() incompatibilities

I think we should implement `select_on_save`. It gives the easiest way for someone to revert the feature if they need to. I know we're adding another Meta flag, but I'm not that concerned about that. On 28 August 2013 09:23, Anssi Kääriäinen wrote: > I just created a new ticket (https://code.dj

Re: version number in Django documentation URLs

What would latest redirect to? Latest stable release? For a doc like release process I reckon pointing to dev would be better anyway. On 29 Aug 2013 23:10, "Daniele Procida" wrote: > RTFD.org can use "latest" for the version number in docs - why don't we? > > It would be nice to be able to refer

Re: Order of INSTALLED_APPS

I don't think it would break South installations as custom app commands will always override builtins. Could you open a ticket for that? The inconsistency is problematic. Obviously it would be backwards incompatible, but we need to gauge the size of the impact. Marc On 1 Sep 2013 21:31, "Kevin Chr

Re: Circular dependency in forms+views+models

I think the main issue here is using the view (name OR instance) as the reference. We really should be pushing naming of urls more in the documentation - they're always mentioned but as a "you might prefer to do this" rather than a "use URL names on every URLpattern and in reverse. You could also u

Re: Circular dependency in forms+views+models

s, > Russ Magee %-) > > On Mon, Sep 2, 2013 at 7:53 PM, Marc Tamlyn wrote: > >> I think the main issue here is using the view (name OR instance) as the >> reference. We really should be pushing naming of urls more in the >> documentation - they're always mentione

Re: Support POST of application/json content type

+1 to providing a better way of accessing JSON encoded post data. -1 to it being munged into request.POST - I feel this is unintuitive. A nice possibility could be a simple piece of middleware which detects `application/json` and attaches request.json as an attribute, if it can decode it. This att

Re: Support POST of application/json content type

The thing with request.POST is that it's kinda unintuitive when extended to other HTTP methods (e.g. PUT). This is why the old request.raw_post_data was renamed request.body. request.POST would behave in the expected traditional web way of picking up form encoded POST data, which would also be ava

Re: Allowing custom attributes in Meta classes

I'm not sure either way on this one. I don't want people to get carries away with Meta, it's not a dumping ground for any old thing you like. That said, for a developer of a third party library which extends the ORM, the inability to extend Meta is very problematic. I think a balance could be foun

Re: Performance optimisation documents, ticket 20877

+1 to what Tim said. Most Django sites performance problems are not at the level of the python code running, rather inefficient databases/caching/templates etc. If your core logic is comparatively slow you're already past a basic optimisation guide. Keep it simple, and BENCHMARK. On 13 Sep 2013 19:

Re: Benchmarking 1.5 vs 1.6

Can't say I'm hugely worried about perfect tracebacks and introspection with internal kind of functions here if it affects performance. The patch looks good. I'd add a comment to say why we're not using @wraps in that context though so someone doesn't go back and add it. On 17 Sep 2013 07:57, "Anss

Re: AbstractUser to get more abstract

The problem you've got here is how it knows to *not* install EmailUser. If it's a model defined in d.c.auth.models, it will get installed, irrespective of whether it is AUTH_USER_MODEL or not. This is where we have to special case the new model somehow so it is only installed if we are using it. Th

Re: AbstractUser to get more abstract

Whilst this works, I'm not sure it was the intention in the design of swappable. Clever though and it would allow the single-app approach. However, we still have the issue of different forms, urls, views etc all based off the changed model. Making these change automatically would be horrible. I s

Re: AbstractUser to get more abstract

I think you'll find that at least the Authentication form is wrong as well - at least in the sense that it calls the field username and it doesn't validate as an email. Once we get better at html5 fields as well, it won't be the correct input type. Admin registration, the management commands, and

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

This is what nested atomics do. In effect savepoints are just creating another transaction inside the existing one (if my memories of Aymeric's talk are correct). On 19 Sep 2013 21:48, "Hannu Krosing" wrote: > On 09/19/2013 04:52 PM, Anssi Kääriäinen wrote: > > After some investigation it turns o

Re: FormSetView and ModelFormSetView

This is partly because there's no obvious correct implementation of them ;) Yes, I think these views should exist. But they go with the same body of work as handling multiple forms, inline formsets etc. At present I have no yet found the time to think about this problem, as a whole and come up wit

Re: FormSetView and ModelFormSetView

t; such as being able to define a clean_* method for subforms/sets. > > > Andy > > > On 20 September 2013 07:55, Russell Keith-Magee > wrote: > >> >> On Fri, Sep 20, 2013 at 2:41 PM, Marc Tamlyn wrote: >> >>> This is partly because there'

Re: Performance Docs

Not sure where the compatibility comment came from as I think that's clearly not right. As for the performance gain, it's true pypy won't give you much of a help until you've fixed your code. Once you have a passably performant site you wish to make very fast, it's a major player in that equation.

Re: Performance Docs

That looks better to me. Still conveys the same message with all the caveats. On 21 sept. 2013, at 10:04, Marc Tamlyn wrote: Not sure where the compatibility comment came from as I think that's clearly not right. The paragraph talks about both Pypy and C libraries. Historically, the Pytho

Re: Revert 165f44aa?

Burn the backslashes! On a more serious note, I think these need to be taken on a case by case basis. Certainly unhelpful it test code though. On 21 Sep 2013 18:50, "Aymeric Augustin" wrote: > Hello, > > I think we went overboard in this commit: > https://github.com/django/django/commit/165f44aa

Re: Hyperlink CSS on djangoproject.com

As someone who has color blindness (off the top of my head I can't remember the exact condition, but it's not simple red-green that 1 in 8 men have) it looks fine to me. Personally I like the distinction between the external and internal links. My guidance for people is generally that if you aren'

Re: AbstractUser to get more abstract

Thanks for compiling a more complete solution. The biggest disadvantage as I see it is that is adds even more complexity to the implementation of those forms. In particular the `setattr` on the form class of a `clean_` method is a really nasty code smell. The code in the `create_user`/`create_supe

Re: Add strutctured settings module to django 1.7?

No, when 12 factor says in the environment, it means exactly that. *NOT* checked into version control, and in the environment of the shell. 12-factor is talking *only* about number 1 for differences in your environments. Yes windows is not very good at environment variables in general, but I would

Re: IRC users invited to support PyCon Ireland Django sprinters

As an FYI, I will also be on site for the sprints, hopefully covering some more experienced contributors, and working through some patches I said I'd review (hi Loic!) but haven't yet. Marc On 3 Oct 2013 17:00, "Daniele Procida" wrote: > I'm running a "Don't be afraid to commit workshop" at PyCo

Re: Design discussion: admin alert messages

Russell makes a valid point. As someone who has color blindness of some variety (which never seems to fit into any of the defined conditions you find listed on the internet...) I personally see almost no difference between the original yellow and the new green for success messages. However, the ico

Re: Specifying the field index types

I believe the basics of how to make it migration friendly would simply be to make sure it is given in the field's `deconstruct` method. The Index class may also need to provide a `as_remove_sql(self, qn, connection)` method which would return the relevant `DROP INDEX` command for the db. I think i

Re: #18659 -- Deprecating request.REQUEST

+1 to deprecating this. In the rare cases where it is useful (mainly 'next' for redirects) it is very easy to work around it not being there - request.GET.get('next', request.POST.get('next')) - so I see no reason for it to always exist. In most cases I feel its use is not a good idea™… Marc On 1

Re: Feature request: New middleware method for "universal" decoration

Keyword argument to patterns() perhaps? On 16 Oct 2013 18:36, "Shai Berger" wrote: > On Tuesday 15 October 2013 11:49:32 Anssi Kääriäinen wrote: > > On Tuesday, October 15, 2013 8:23:38 AM UTC+3, gavi...@gmail.com wrote: > > > This topic was also discussed during the deprecation of > > > Transact

Re: An argument against mark_safe.

Personally I tend to attach data attributes to the wrapping node for the map/chart at HTML escaped JSON and then read them from an external JS file. Especially as that js can be fairly complex it's best to keep it outside the template where it can be compressed. But we digress. I'm in favour of ma

Re: ImportError: cannot import name actions

Can you perhaps try it with a check out of Django and use git bisect to find the cause? That might give us an indication of how the code base has changed to break it for you. Without a means of reproduction it is hard for us to do anything. Marc On 17 Oct 2013 09:12, "rok" wrote: > Hi everyone,

Re: #18659 -- Deprecating request.REQUEST

Seems to me an intermediary step is to add request.DATA (then maybe request.QUERY eventually) as a long term movement towards being better http. It isn't something we should do overnight. I noticed this patch is now in 1.7 and 1.9 will remove request.REQUEST. Marc On 18 Oct 2013 14:55, "Tom Chris

Re: Backwards compatibility and field validation

I think Anssi summed up my feelings on this very well, in particular with the issues with update(). Similarly create() would also bypass as it does not call save() AFAIK. Given these commonly used approaches do not work, and that the name of the method - save() - implies only saving to the databas

Re: ANN: Django Sprint November 23/24, Thinkfarm co-working space, Berlin, Germany

Hi Jannis, Let me know if you're in need of another committer at the sprint. Can't make any concrete promises as yet and I'd need to work out how cheaply I can get there, but I'd love to come assist if that's helpful. Marc Hi all, I'm excited to announce that the next Django sprint will take pla

Re: [ANNOUNCE] Django 1.6 release candidate available

Migrations landed after the feature freeze for the beta and are not quite feature complete yet. They will be part of 1.7. On 23 Oct 2013 13:57, "Elyézer Rezende" wrote: > I think I have missed something or migrations will not be part of this > release? > > I have not found it on release notes. >

Re: How do features get decided for a release?

That's to do with the date a feature lands. Migrations isn't completely feature complete or totally stable yet - squashing migrations actually landed in the master branch this week. When we release the beta, the version goes into feature freeze so only minor bug fixes and any critical issues get m

<    1   2   3   4   >