Re: Feature proposal: selection of views and tables for inspectdb

One correction, inspectdb doesn't currently create models for views, but this isn't the first time that code caused confusion, see https://code.djangoproject.com/ticket/25038. I agree that fixing the inspect SQL would be the ideal solution. José, I didn't follow the conversation closely enough

Re: Form field labels change proposal

t+1 version it > is effectively removed. > > As soon as the PendingDeprecation is added, the entry should be added to > the docs with example CSS to make your own templates/styling capitalize the > labels - and/or mention the `capfirst` template filter. > > Thoughts? &

Re: Ask for help

Please write to django-users (as I see you already did), this mailing list is for the development of Django itself. On Thursday, November 19, 2015 at 12:26:34 PM UTC-5, Cision Lee wrote: > > *I meet some errors when I migrate database, and the error code is > following:* > > Operations to perfor

Re: Form field labels change proposal

t, > ensuring that it gets only emited once during the lifetime of a thread? > > On Thursday, November 19, 2015 at 7:27:18 PM UTC+1, Tim Graham wrote: >> >> How would a developer acknowledge/silence that deprecation warning? It >> seems to me that if it's emitte

Re: Form field labels change proposal

way to tackle this. > > I'd be happy to write the patch for this myself if no objections turn up. > > On Thursday, November 19, 2015 at 10:49:49 PM UTC+1, Tim Graham wrote: >> >> The best solution I can think of at the moment would be a setting >> allowing users to

Re: Form field labels change proposal

carded >>> it because it would be 'yet another setting'. But this one would ofcourse >>> be temporarily, and if that's been applied successfully in the past, then >>> that's probably the best way to tackle this. >>> >>> I'd be

Re: Django-oscar PicklingError caused by None session on submit

Please write to django-users (as I see you already did) as this mailing list is for the development of Django itself. It isn't a second level support channel if no one answers your post there. On Saturday, November 21, 2015 at 10:26:13 AM UTC-5, 张小西 wrote: > > Hello everyone, > Thank you for rea

Fellow Report - November 21, 2015

Triaged --- https://code.djangoproject.com/ticket/25757 - Don`t create session automatically for anonymouse user (duplicate) https://code.djangoproject.com/ticket/25763 - Django missing repr friendly formatting of request (wontfix) https://code.djangoproject.com/ticket/25775 - Method log

[ANNOUNCE] Django security releases issued (1.7.11, 1.8.7, and 1.9rc2)

Today the Django team issued multiple releases -- Django 1.7.11, 1.8.7, and 1.9rc2 -- as part of our security process. These releases address a security issue, and we encourage all users to upgrade as soon as possible. More details can be found on our blog: https://www.djangoproject.com/weblog/

Keep django/django-old GitHub repo?

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 across any. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Djan

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

There's an accepted ticket for adding aliasing to values(): https://code.djangoproject.com/ticket/16735 The current patch there hijacks values() **kwargs for the mapping of renamed fields which would prevent adding other kwargs like "nested" without disallowing those values as aliases. I guess

Re: Allow impossible model validation (mainly admin and generic forms)

Would Django itself ever raise ValidationError in Model.save()? I wonder how you propose converting something like an IntegrityError from the database into an "friendly" exception for the user? On Wednesday, November 25, 2015 at 9:23:05 AM UTC-5, Vlastimil Zíma wrote: > > Django assumes that all

annoyance with Python 3.2 support in Django 1.8

Django 1.8 is the last version to support Python 3.2. Python 3.2 is scheduled to be end of life at February 2016 [1] while Django 1.8 is scheduled to be supported until April 2018. The latest security release for the 3.2 series, Python 3.2.6 contained a regression that causes 30 admin test fail

Re: annoyance with Python 3.2 support in Django 1.8

ob/master/gallery/test_admin.py#L199-L205 > > Best regards, > > -- > Aymeric. > > 2015-11-26 1:36 GMT+01:00 Tim Graham >: > >> Django 1.8 is the last version to support Python 3.2. Python 3.2 is >> scheduled to be end of life at February 2016 [1] while Djan

Re: 1.8 shipping invalid .py files in the startapp template

I believe this is a new issue in 1.9, not 1.8 as the subject says, correct? I wouldn't mind seeing it fixed as old versions of pip report a SyntaxError when installing Django (this doesn't affect the install, but creates confusion for users and resulted in at least two bug reports like https://

Re: 1.8 shipping invalid .py files in the startapp template

but I don't see any downside to the proposed change. On Saturday, November 28, 2015 at 10:53:54 AM UTC-5, Florian Apolloner wrote: > > I rather add a check to setup.py and tell people to upgrade pip > > On Saturday, November 28, 2015 at 1:46:48 PM UTC+1, Tim Graham wrote: >> >&

Re: 1.8 shipping invalid .py files in the startapp template

to the proposed change. On Saturday, November 28, 2015 at 11:05:59 AM UTC-5, Donald Stufft wrote: > > > On Nov 28, 2015, at 11:03 AM, Tim Graham > > wrote: > > Claude said, "I also encountered this error when using pip 1.5.6 (default > version in Debian stable).&quo

Re: 1.8 shipping invalid .py files in the startapp template

Django. > So why add a specialcased solution in Django if we maybe should fix > packaging instead? > > On Saturday, November 28, 2015 at 5:03:12 PM UTC+1, Tim Graham wrote: >> >> Claude said, "I also encountered this error when using pip 1.5.6 (default >> versi

Fellow Report - November 28, 2015

I've also been coordinating the next round of fundraising with Adrienne which includes cleaning up the data for our existing donor records and making some improvements to the website for the next campaign. Triaged --- https://code.djangoproject.com/ticket/25799 - list_filter filtering b

Re: 1.8 shipping invalid .py files in the startapp template

Actually, the SyntaxError issue isn't related to pip but to setuptools 5.5 and 5.5.1 (Debian stable ships the latter). Florian, your preference is to decline the change proposed by Chris and just deal with any support queries when people see a log like below? I understand it's not ideal to add

Re: status of 1.9 release blockers

We're on schedule for 1.9 final tomorrow. There are 3 release blockers in Trac, however, 1 blocker affects only master and the other two also affect 1.8 and thus aren't blockers for 1.9. On Saturday, November 14, 2015 at 3:17:27 PM UTC-5, Tim Graham wrote: > > Sorry for the lack

Re: Django 1.9 cache.get_or_set works incorrectly with DummyCache backend

It seems to be an omission in the implementation. Feel free to create a Trac ticket and offer a patch if you can. For future reference, please don't cross post between django-users (appropriate place for "is it a bug?" questions) and django-developers. Thanks! On Tuesday, December 1, 2015 at 7

[ANNOUNCE] Django 1.9 released

Django 1.9 is now available: https://www.djangoproject.com/weblog/2015/dec/01/django-19-released/ With the release of Django 1.9, Django 1.7 has reached end-of-life. Django 1.7.11 is the final release of the 1.7 series and all users are encouraged to upgrade to Django 1.8+ as soon as possible s

Re: is_authenticated as property

Someone created a ticket to raise this issue again. I found several improper usages with GitHub code search. Is there any support for the idea or would it be too much magic? My own opinion is that if you don't have tests to catch the mistake in the first place, you're doing it wrong. https://co

worth adding PyPy to continuous integration?

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 available or behaves differently in PyPy. Is it worth adding PyPy to our continuous integration so we can proactively address thes

Re: annoyance with Python 3.2 support in Django 1.8

r) On Thursday, November 26, 2015 at 9:53:51 AM UTC-5, Donald Stufft wrote: > > > On Nov 26, 2015, at 9:50 AM, Tim Graham > > wrote: > > The thing that makes me a little uncomfortable is promoting the use of > possibly insecure Python 3.2 well after it's end-of-li

Re: Possible bug transaction rollback or SQLite backend

Hi Jonas, I wonder if https://code.djangoproject.com/ticket/24080 might be related. If you could distill the project you linked into a minimal example to reproduce that would be ideal. By the way, "is it a bug?" questions normally go to django-users. Tim On Thursday, December 3, 2015 at 9:02:54

Re: worth adding PyPy to continuous integration?

y potentially at the cost of > certain features. > > There's also the consideration that python2 is going away in django 2.0, > so if pypy3 isn't up to date wrt python3, we'd have to drop pypy. > > On Thursday, 3 December 2015 03:52:24 UTC+11, Marc Tamlyn wrote: >

Re: annoyance with Python 3.2 support in Django 1.8

ue supporting Django on an unsupported version of Python? So far no one has indicated "yes". If you care about Django security updates, shouldn't you care about Python security updates too? On Wednesday, December 2, 2015 at 5:22:46 PM UTC-5, Shai Berger wrote: > > On Wedne

Re: Validation of m2m

Here's an open ticket about adding model level validation for many-to-many: https://code.djangoproject.com/ticket/12938 On Thursday, December 3, 2015 at 11:04:22 AM UTC-5, Federico Capoano wrote: > > Thanks Aymeric, > > I decided to post this problem on django-developers because I've read this >

Re: Referrer Policy Delivery, Django shouldn't do strict referrer check anymore?

Flávio, thanks -- since you seem to have a good understanding of the limitation, could you submit a documentation patch (or even just provide some draft text here)? On Friday, December 4, 2015 at 8:25:35 AM UTC-5, Flávio Junior wrote: > > Found a issue that already discusses this: > https://cod

Fellow Report - December 5, 2015

Triaged --- https://code.djangoproject.com/ticket/25808 - Setting to allow django.test.Client default requests to follow=True (wontfix) https://code.djangoproject.com/ticket/25840 - cache.get_or_set() works incorrectly with DummyCache backend (accepted) https://code.djangoproject.com/ti

Re: annoyance with Python 3.2 support in Django 1.8

gt;>> drop support in the next dot release of 1.8. 3.2 isn't an easy python to >>> find in the wild as far as I know, so I'd be surprised if there was any >>> real support for it on 1.8 by users. >>> >>> On Friday, 4 December 2015 02:50:24 UTC+11,

Re: Backporting ticket 25548 into 1.9.x

I've done the backport. I think the only reason it wasn't done initially is that there's no indication on the ticket that the issue was a regression. On Sunday, December 6, 2015 at 11:34:47 AM UTC-5, Marc Tamlyn wrote: > > Agreed the reasoning is sound. This is a major bug as far as I'm concerned

Re: What is the purpose of adding `nowrap` class to all ForeignKey fields in django admin objects list?

Did you try looking through git blame to find the commit that added it? https://github.com/django/django/commit/0b53d318 might be what you're looking for. On Monday, December 7, 2015 at 8:33:34 AM UTC-5, alTus wrote: > > Django adds `nowrap` class to your `td` if you specify list_display to > s

Re: Backporting ticket 25548 into 1.9.x

Done in https://github.com/django/django/commit/9c835990ea2911c06a877296fbc25157c1302e1d -- thanks for pointing it out. On Monday, December 7, 2015 at 8:42:09 AM UTC-5, Anssi Kääriäinen wrote: > > On Mon, Dec 7, 2015 at 3:20 PM, Tim Graham > wrote: > > I've done the b

Re: annoyance with Python 3.2 support in Django 1.8

Here's a documentation proposal: https://github.com/django/django/pull/5783 On Saturday, December 5, 2015 at 6:42:18 PM UTC-5, Tim Graham wrote: > > No we haven't done that before. I think advertising it in the blog post > and release notes would be enough. In particular, I&

Re: GenericForeignKey: loosening the requirements on the ContentType reference

I'm having trouble understanding the problem. Could you give some example models and code that demonstrates it? On Tuesday, December 8, 2015 at 8:10:51 AM UTC-5, martin f krafft wrote: > > Hello, > > I hope this is the right place to bring up the following idea, even > if it's in django.contrib

Re: django template modules compiled with cython

Sorry for the ignorance, but I have little idea what cython is and what incorporating this into Django involves. If you could give a little background information that would be appreciated. On Thursday, December 10, 2015 at 1:14:46 PM UTC-5, Florian Apolloner wrote: > > > > On Thursday, December

Re: Multiple Serializer

Please don't cross post messages like this to django-developers and django-users. The latter is the appropriate mailing list for questions like this. On Thursday, December 10, 2015 at 3:37:54 PM UTC-5, miguel angel lopez mendo wrote: > > i have this serializers > > class ValuarCoche(serializer

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

I like the functionality this provides, but the API doesn't seem quite right to me -- namely passing configuration for template loaders through OPTIONS. Since you mentioned "the weird way of passing arguments to template loaders" and the fact that the locmem loader uses it, I'd pose the questio

Fellow Report - December 12, 2015

Triaged --- https://code.djangoproject.com/ticket/25885 - SyntaxError in Django 1.9 install output (invalid) https://code.djangoproject.com/ticket/25883 - Admin Delete Page Incorrectly Counts Related Objects (accepted) https://code.djangoproject.com/ticket/25880 - Forms created by form

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

]), > ], > }, > }, > ] > > # settings/dev.py > > from .prod import * > > TEMPLATES[0]['OPTIONS'].update({ > 'loaders': [ > 'django.template.loaders.app_directories.Loader', > ], > }) > &g

Fellow Report - December 19, 2015

I spent about 2 days this week working on helping Adrienne launch the next round of fundraising (see "Authored" section for some details -- there were also a dozen or so other small pull requests that I didn’t bother to list). There might be some odds and ends to do next week, but I hope to be

Re: Questions pertaining the dubious value and the origin of "common" passwords

Hi, the way I try to answer these types of design decision questions is by using git blame to find the ticket that introduced the feature. From there, you can often find links to the pull request or mailing list discussions which might explain the decision. As noted in the documentation [1], th

Deprecations vs. backwards-incompatible changes for tightening behavior that hides probable developer error

I'd like to ask for opinions about whether or not deprecations are more useful than making small backwards incompatible changes when they move Django in a direction toward unhiding probable developer error. An example from a past release is the validation of fields in select_related() [1]. This

Help needed with the MySQL max index length problem for Django 1.10

I merged the often requested increase of User.username max_length to 254 characters [1] a few weeks ago, however, the ticket was reopened pointing out this issue: "This patch breaks on MySQL installations using the utf8mb4 charset, because it breaks the index length limit - it comes out at a m

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

Could you summarize the pros and cons of this new technique versus the existing @method_decorator() recommendation [1]? Does it duplicate all the functionality provided by method_decorator such that we would no longer recommend that technique in the class-based view docs? [1] https://docs.djan

deprecate or undocument shorcuts.render_to_response()?

In 2010/Django 1.3 when the render() shortcut was introduced Jacob proposed: "I think we should deprecate render_to_response() in favor of render(). render_to_response() is just render(request=None, ...), right? Any reason to keep both around?" Russ replied: "There's no particular reason to kee

Re: deprecate or undocument shorcuts.render_to_response()?

Okay, have pushed the doc changes and created a ticket [1] with the following timeline, "we'll start the deprecation in Django 2.0 which means it'll be removed in Django 3.0 (December 2019)." [1] https://code.djangoproject.com/ticket/25978 On Tuesday, December 22, 2015 at 12:52:33 PM UTC-5, Aym

Fellow Report - December 26, 2015

Triaged --- https://code.djangoproject.com/ticket/25956 - Unexpected fake_initial keyword thrown on migration (invalid) https://code.djangoproject.com/ticket/25913 - --fake-initial not working with apps with other table names (needsinfo) https://code.djangoproject.com/ticket/25958 - Dep

Re: structural & functional review of django documentation

My main concern is that it will be non-trivial to setup that type of feedback system, and I'm not sure how we would go about turning that type of data into actionable tickets. If anyone has experience with such a system, I'd be interested to hear about it. On Sunday, December 27, 2015 at 10:19:

Re: structural & functional review of django documentation

Adding a survey link is not difficult. We conducted a community survey [1] earlier this year with one question related to documentation, "What parts of the Django documentation do you find most useful?" What questions to ask and how to turn the answers into actionable items is the part I'm not s

Re: structural & functional review of django documentation

over the Django repo and post some > findings. > Since there is certainly the big question of "is the information we have > useful"? > The docstrings and sundry that sphinx uses for autodoc generation may need > work before it measures up to the quality standards of our

Re: Help needed with the MySQL max index length problem for Django 1.10

it. > > Collin > > [1] https://youtu.be/qFfjJ8pOrWY?t=2534 > [2] https://serversforhackers.com/mysql-utf8-and-indexing > [3] http://bugs.mysql.com/bug.php?id=68453#c430229 > [4] > https://mariadb.com/kb/en/mariadb/xtradbinnodb-server-system-variables/#innodb_large_prefix > >

Re: delegating our static file serving

I'd like to work together with Dave to develop a proof of concept that integrates whitenoise into Django. I spent about an hour looking through whitenoise and our own static file serving code, and I think integrating whitenoise will yield a simpler user experience with about the same amount of

Re: structural & functional review of django documentation

I've refined Daniele's explanation here: https://github.com/django/django/pull/5888 Let me know if it helps and what could be better. On Monday, December 28, 2015 at 11:31:30 PM UTC-5, Eric Holscher wrote: > > > > On Monday, December 28, 2015 at 4:52:36 PM UTC-8, Daniele Procida wrote: >> >> On

Re: structural & functional review of django documentation

ango dev will be more comfortable finding what they need > within the documentation, am I alone in thinking a much more simple front > page might be useful to the newcomer? > > Regards, > > Tim > > On Tuesday, December 29, 2015 at 11:25:40 AM UTC-5, Tim Graham wrote: >> &

Re: Backwards-compatibility import shims

To save a link click, the question is about moving django.core.urlresolvers to django.urls and whether or not to start the deprecating of django.core.urlresolvers immediately. I don't have a strong opinion myself. On one hand, delaying gives projects more time to update, on the other, I suspect

Re: Backwards-compatibility import shims

cember 30, 2015 at 10:28:02 AM UTC-5, Marten Kenbeek wrote: > > One solution is to create a RemovedInFutureVersionWarning to allow > projects to catch the change when running with -Wall, without committing > to a specific release. > > On Wednesday, December 30, 2015 at 3:05:32 PM

Re: Adding name to fieldsets to improve their validation error text

Hi Ben, >From a quick look, I'd suggest trying an approach similar to how form fields work, with a `default_error_messages` class attribute which can be override by an `error_messages` parameter provided to __init__(). Tim On Thursday, December 17, 2015 at 5:46:04 PM UTC-5, Benjamin W Stookey

Re: Working with Django signals

Please write to django-users as this mailing list is for the development of Django itself. On Wednesday, December 30, 2015 at 5:28:22 PM UTC-5, Bernardo Garcia wrote: > > Hi Django developers community > A great greetings > > I want share with you the following question: > > I have a custom users

Re: structural & functional review of django documentation

Django core developers are not the only public involved. Some might > say they are in service to the public at large. The Django cadre must > regularly ask about the state of public sentiment and satisfaction, because > it is reckless to do otherwise. > > [image: Rplot_pos.png] >

[ANNOUNCE] Django bugfix releases issued: 1.9.1 and 1.8.8

Details are available on the Django project weblog: https://www.djangoproject.com/weblog/2016/jan/02/bugfix-releases-issued/ On a related note: Python 3.2 users, please be advised that we've decided to drop support for Python 3.2 in Django 1.8.x at the end of 2016. We won't break things intenti

Fellow Report - January 2, 2016

A brief update about the Fellowship program: The Django Software Foundation needs to have a big fundraising month in January, otherwise the funding will be exhausted at the end of the month. As you return to work in the new year, please ask your employer to support the DSF if you find this wor

Design design needed: #14093 - Unable to create a new session key on higher traffic

Hi, I wanted to raise this ticket for discussion as to what the best solution might be. As suggested in the ticket, I think adding a setting to control the number of cache attempts instead of hard-coding "1" might be a reasonable approach. I'm not sure if that solution would be considered a

Re: Design design needed: #14093 - Unable to create a new session key on higher traffic

Tom, That definitely seems reasonable to me. Seems like the risk of key collision is low enough that we shouldn't have to loop at all? My only concern regarding uui4 is the risk of collision with multiple web servers. From what I've read uuid1 would prevent that. That being said, I'm not an exp

guidelines for docs/misc/distributions.txt

Hi, http://docs.djangoproject.com/en/dev/misc/distributions/ is rather out- of-date with respective to the versions of Django that are shipping with each OS. A summary of tickets that are currently accepted: 8417 - request to add ArchLinux 8497 - request to add OpenSolaris 9606 - request to add

Re: guidelines for docs/misc/distributions.txt

40 am, Russell Keith-Magee wrote: > On Thu, Mar 5, 2009 at 9:13 AM, Malcolm Tredinnick > > > > wrote: > > > On Wed, 2009-03-04 at 09:28 -0800, Tim Graham wrote: > >> Hi, > > >>http://docs.djangoproject.com/en/dev/misc/distributions/is rather out- >

Re: ModelForm.Meta.overrides

I'd like to revive the discussion here. I think making simple customizations to the default ModelForm fields is a common need that we should try to find some way to address. Another shot at this is "#2000 -- Allow overriding `label`, `help_text` and

Re: ModelForm.Meta.overrides

(ticket #2 <https://code.djangoproject.com/ticket/2> that is) On Friday, June 7, 2013 1:36:30 PM UTC-4, Tim Graham wrote: > > I'd like to revive the discussion here. I think making simple > customizations to the default ModelForm fields is a common need that we >

Re: Custom user models don't like non integer primary keys.

Ticket #14881 addresses the issue that django.contrib.auth assumes User.pk is an integer and thus password reset doesn't work. I've updated the original patch and added documentation and a backwards compatibility proposal. Reviews and feedback appre

#10284, #17988 -- should formset.save(commit=False) delete objects marked for deletion?

formset.save(commit=False) on ModelFormSets currently deletes any objects marked for deletion which seems like a bug to me, since I wouldn't expect any data changing operations when using commit=False. I put together a pull request to address #10284<

Re: Deprecate FCGI support in Django 1.7

Here's a ticket and pull request for the deprecation. On Tuesday, July 23, 2013 1:19:28 AM UTC-4, Some Developer wrote: > > On 23/07/13 02:07, Curtis Maloney wrote: > > Well, having started looking over th

Re: Deprecate FCGI support in Django 1.7

Is there a consensus on the project that'll be created to handle this outside of Django? Would be nice to have something to point people to when closing Trac tickets for FastCGI. On Wednesday, July 24, 2013 5:56:45 AM UTC-4, Tom Evans wrote: > > On Sun, Jul 21, 2013 at 8:28 AM, Some Developer >

Re: Performance optimisations in the deployment checklist document

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 on a link to https://docs.djangoproject.com/en/dev/topics/http/sessions/#using-cached-sessions as something to consider. On Thursday, August 15, 20

Re: Django 1.6 release timeline

Obviously, we've missed our target for the release candidate. We're currently targeting the week of August 26 for that, pending no new release blockers. You can help us make our goal by triaging unreviewed tickets

Re: Proposal: remove triage stage someday/maybe

I think the state is useful because it provides a way to filter out tickets that are not immediately actionable (for example, there are several tickets that suggest schema migrations). When migrations land in core, we can then "accept" these tickets. On Sunday, August 18, 2013 4:10:14 AM UTC-4,

feedback needed: session serialization API (1.6 release blocker)

Please take a look at the proposed session serialization API on ticket #20922 and add your thoughts if you have an interest in it. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscrib

Re: New contributor and Git

Sounds good, Paul. Starting small is a good way to get started. On Monday, August 19, 2013 5:06:46 PM UTC-4, Paul C. Anagnostopoulos wrote: > > Thanks, Daniele. That looks like good reading. > > I'm making changes to templates/builtins.txt. I can make the html files > and preview my changes in m

Re: Contenttypes.GenericForeignKey Docs Addition

Hi Mark, Could you open a ticket and add a patch with your proposed change? Tim On Thursday, August 22, 2013 3:37:14 AM UTC-4, Mark Young wrote: > > Could it be mentioned that GenericForeignKey fields can't be accessed in > forms in the docs? Without stackoverflow, I would've probably never fig

Re: Silencing deprecation warnings in the test suite

Thanks for raising the issue. I think I committed the first and last of the three, so I'll fix those. I've also added a ticket to document "how to deprecate a feature" in order to make these guidelines more accessible. https://code.djangoproject.com/ticket/21024 On Monday, September 2, 2013 8

Re: Silencing deprecation warnings in the test suite

I updated the syncdb tests as well since it was straightforward. I get a clean output on Python 2.7. Python 3 still has some issues (e.g. #19905), but these aren't deprecated features. On Tuesday, September 3, 2013 8:46:30 AM UTC-4, Tim Graham wrote: > > Thanks for raising the issue

Re: Order of INSTALLED_APPS

Yes, here's the ticket to add validation for INSTALLED_APPS: https://code.djangoproject.com/ticket/12288 On Monday, September 9, 2013 6:32:48 PM UTC-4, German Larrain wrote: > > Hi guys > > A related question: What about repeated entries of apps in INSTALLED_APPS? > I remember seeing this once a

Re: Performance optimisation documents, ticket 20877

I feel like we open a can of worms if we go down this road. Where do we draw the line between what we do and don't mention regarding *Python* optimization? The Django docs don't need to layout the current state of the Python ecosystem IMO. I don't doubt the info is helpful, but I don't think Dj

Re: Default session data serializer doesn't support extended data types

Hi Davide, Did you take a look at the design decisions as described in the ticket and pull request? We made these decisions in order to push the community toward developing more secure apps and the transition isn't expected to be painless. We had several core developers review the patch and dis

Re: Performance Docs

Aymeric's edits look good to me. Thanks for raising the issue, Alex. On Saturday, September 21, 2013 4:31:33 AM UTC-4, Marc Tamlyn wrote: > > 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 th

Re: Hyperlink CSS on djangoproject.com

See also ticket #14834 "Colour issues in CSS - particularly documentation." However, it may not be worth working on this right now as I believe there's an initiative to redesign djangoproject.com (although it's been nearly a year since the email thread on the topic has been updated). see https

Re: Remove contrib redirect's dependency on sites

Hi Simon, It may be a viable idea, but looking at the code, it's not obvious to me how it would be done. Perhaps you could provide some additional details about what you had in mind. Tim On Monday, September 30, 2013 10:51:58 PM UTC-4, Simon Litchfield wrote: > > Contrib redirects is still a h

Proposal to end the war with flake8 warnings

I'd like to propose cleaning up Django's codebase so that we can run flake8 (with some rules ignored) as a presubmit check (for example, hooked into pull request submissions). Our docs currently state: "Note, however, that patches which only remove whitespace (or only make changes for nominal P

#18659 -- Deprecating request.REQUEST

The ticket now has a patch so I wanted to make sure the consensus is to more forward with this. Here's the rationale from the ticket : request.REQUEST provides indifferent access to request.GET or request.P

Re: sensitive_post_parameters

Posting some of the discussion from IRC: I've done some recent work with sensitive_post_parameters: https://github.com/django/django/commit/2daada800f8e28cc1ba664b3008efaefab8fb570 The general lesson I learned was blacklisting isn't a very comprehensive approach and there are definitely ways yo

Re: Backwards compatibility and field validation

Sounds good. I guess that may be an addition here: https://docs.djangoproject.com/en/dev/ref/models/instances/#validating-objects On Tuesday, October 22, 2013 8:40:46 AM UTC-4, Cal Leeming [Simplicity Media Ltd] wrote: > > It seems there is a split reaction on whether or not models should assume

Re: Getting listed on 'DevelopersForHire' wiki

You may edit the page and add yourself. On Monday, October 28, 2013 1:33:59 PM UTC-4, maceo wrote: > > Greetings, > > I wanted to know the procedure for being listed on the > 'DevelopersForHire' wiki. I have signed up for an account, but didn't want > to edit the page until I clear it with

Re: Django Tutorials

I don't mean to be a downer, but I don't see anything in your outline that's substantially different from what the official Django documentation offers. Is there a reason you think you need to create a new resource rather than improve or expand the official Django docs? Personally, I would rath

Re: Django 1.6 RC1 language key in session

Sounds like a good idea Miguel, please open a ticket or send a pull request that references the original ticket. Just wanted to clarify that the commit you referenced will be part of Django 1.7, not 1.6. On Tuesday, November 5, 2013 11:10:01 AM UTC-5, Miguel Araujo Pérez wrote: > > Hi there, >

Re: mod_wsgi setup

This list is for the discussion of the development Django itself. I see you've already cross-posted to django-users which is the correct list to get help. On Friday, November 15, 2013 4:36:53 AM UTC-5, tin...@gmail.com wrote: > > Hello, > > I am trying to setup a python 2.7 + Django + virtualenv

Re: Prepared statements proof of concept

Here's an accepted ticket to allow the use of prepare statements: https://code.djangoproject.com/ticket/20516 On Wednesday, November 27, 2013 10:35:09 PM UTC-5, est wrote: > > Hi Russ, > > Since 1.6 has pooling support now, what do you think of prepared > statements? > > I strongly suggest we ad

Re: How to integrate Postgresql db with Django,so that data will be retrieved from that postgresql db table and show it on browser via html

Hi, django-developers is for discussing the development of Django itself, not for answering user queries. If you have a "how do I" question, please direct it to django-users. Thanks! On Monday, December 2, 2013 1:03:28 AM UTC-5, Swastik Acharya wrote: > > django 1.4 version > postgresql 9.1 vers

Re: 1.7 Release Schedule

See https://code.djangoproject.com/wiki/Version1.7Roadmap for more details. On Monday, December 9, 2013 3:00:14 PM UTC-5, Andrew Godwin wrote: > > Hi everyone, > > It's time to talk 1.7. We had a core discussion recently and I've stepped > forward to release manage 1.7, and so please direct all c

<    1   2   3   4   5   6   7   8   9   10   >