Set a reasonable default for EMAIL_TIMEOUT

s coming from, instead of spending hours to debug it like I did in the past week. Alternatively, we could set a default timeout only if "socket.getdefaulttimeout()" returns None, just to avoid applications stalling indefinitely, which is something that has been happening to me lately. Bes

Re: Set a reasonable default for EMAIL_TIMEOUT

Hi there, yes I can add EMAIL_TIMEOUT in my applications and I am already doing that. The reason I wanted to bring this up here is that I care about Django. This behavior goes against a well known concept of the Unix Philosophy which is to "Write programs which fail in a way that is easy to dia

Re: Set a reasonable default for EMAIL_TIMEOUT

:27 PM UTC-3 Federico Capoano wrote: > Hi there, > > yes I can add EMAIL_TIMEOUT in my applications and I am already doing that. > > The reason I wanted to bring this up here is that I care about Django. > This behavior goes against a well known concept of the Unix Philosoph

virtual fields and the migration framework

field with the data that is probably stored in another concrete field Thank you for your attention. Best regards Federico Capoano -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe fro

Re: virtual fields and the migration framework

own. > > Note that this is just a shot in the dark. I didn't try it out myself. > > /Markus > > On Tuesday, April 21, 2015 at 7:53:04 PM UTC+2, Federico Capoano wrote: >> >> Hi everyone, >> >> some time ago I submitted this ticket: >> https://code

Re: Idea/request for help: Django Developers Community Survey

Great idea. The questions look good enough to me. I love django-apps or libraries shipped in python packages. One of the reason I love Django is the fact that it didn't frenetically add stuff to the framework just because it's cool. The good thing of python packages is that you can get some data

Re: virtual fields and the migration framework

erico On Wednesday, April 22, 2015 at 9:54:39 AM UTC+2, Federico Capoano wrote: > > Hi Markus, > > thank you very much for your suggestion. I'll try it later this afternoon > and come back to report. > > Federico > -- You received this message because you are su

Re: virtual fields and the migration framework

I think the correct syntax is: cls._meta.add_virtual_field(self) The problem is that if I use this syntax it seems that the admin ignores these fields, what happens is that the changes I make to the virtual fields are ignored. These are the test results related to the VirtualField implementati

Re: virtual fields and the migration framework

Yes I am on 1.7 because 1.8 is not supported yet but I'm working on it. I'll come back when I'll have more info. Federico On Thursday, April 23, 2015 at 8:09:42 PM UTC+2, Florian Apolloner wrote: > > > > On Thursday, April 23, 2015 at 6:59:58 PM UTC+2, Federi

Re: Feature: Support Server-Sent Events

Hey Emil, On Sunday, May 31, 2015 at 10:52:26 AM UTC+2, Emil Stenström wrote: ... > Also, I don't think you would need to mix redis (or any other persistent > storage) into this. The connected clients could simply be stored in an > in-memory array, that is discarded if the server crashes. When

Re: django.channels: "async" for Django

Hi Andrew, i have been taking a look at your work because I find it interesting and I also think that django should have some core mechanism for integrating websockets. I was wondering, have you also tried one of the other popular django websocket apps? Have you found any interesting one that

Re: virtual fields and the migration framework

o it seems I'm not the only one who would like to have flexible/dynamic models :-) Federico On Saturday, April 25, 2015 at 11:48:25 AM UTC+2, Federico Capoano wrote: > > Yes I am on 1.7 because 1.8 is not supported yet but I'm working on it. > > I'll come back when

Support for UNLOGGED tables in PostgreSQL

I just ran into this ticket: https://code.djangoproject.com/ticket/24306 I found myself in a situation where it would be really useful. Two questions: - has anybody verified that UNLOGGED tables really perform faster when running tests with Postgres? - is this feature on the TODO list

Re: Support for UNLOGGED tables in PostgreSQL

gines. The best thing would be to have a subsection called "How to speed up tests with Postgres" or something similar. What do you think? Federico On Monday, July 13, 2015 at 5:54:08 PM UTC+2, Aymeric Augustin wrote: > > Hello Federico, > > 2015-07-13 16:26 GMT+02:00 Fede

Re: Proposal: deprecate and remove egg template loader

+1 I am assuming the deprecation is done according to the process that was discussed in the thread "An easier path to upgrade from one LTS release to another". On Sunday, July 12, 2015 at 4:53:23 PM UTC+2, James Bennett wrote: > > There's not much to this, really, except what's in the subject

Re: Support for UNLOGGED tables in PostgreSQL

.postgresql.org/docs/current/static/non-durability.html And then some text with "if you want to run your tests on postgresql please see the docs around non durable postgres" 2015-07-13 18:46 GMT+02:00 Federico Capoano : > Sure, i've just done something similar for this project: &g

Re: Support for UNLOGGED tables in PostgreSQL

That's quite baffling. On Tuesday, July 14, 2015 at 7:03:03 PM UTC+2, Tim Graham wrote: > > I see a thirty second increase in the test suite (from 7.5 minutes to 8 > minutes) on my local machine with: > > sql_create_table = "CREATE UNLOGGED TABLE %(table)s (%(definition)s)" > -- You received t

Re: Renaming the postgresql_psycopg2 backend

I would definitely second this. On Wednesday, July 15, 2015 at 3:17:30 PM UTC+2, Baptiste Mispelon wrote: > > Hi everyone, > > After starting a new project recently and failing three times to type > the name of the postgres backend correctly, I was wondering if there's > really any value in ke

Re: Support for UNLOGGED tables in PostgreSQL

Hey Christophe, On Thu, Jul 16, 2015 at 8:34 AM, Christophe Pettus wrote: [CUT] > > By the way, I would strongly advise *against* *ever* even mentioning fsync = > off anywhere in the Django documentation; that is such a horribly bad idea in > 99.95% of real-life situations that steering people

Re: Support for UNLOGGED tables in PostgreSQL

nternet, but without warnings, and having it in our docs with the warning >>>> will be helpful. >>>> >>>> Having a fast test suite is such an important part of development that it >>>> shouldn't be held back by attempting to protect th

Re: Support for UNLOGGED tables in PostgreSQL

Errata, PR link is https://github.com/django/django/pull/5021 - sorry On Mon, Jul 20, 2015 at 11:42 AM, Federico Capoano wrote: > Thank you for all the feedback. > > I opened this PR with the proposed addition to the docs: > https://github.com/django/django/compare/master...nemesisde

Re: Support for UNLOGGED tables in PostgreSQL

I just changed the URL in the to http://www.postgresql.org/docs/current/static/non-durability.html as suggested. Federico -- 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

Validation of m2m

Hi everybody, I am sure it has happened to many of you. Validating m2m BEFORE saving the relationships is very hard and time consuming. Now this solution: http://schinckel.net/2012/02/06/pre-validating-many-to-many-fields./ Proposes to solve it with a ModelForm in the admin. Cool, that works.

Re: Validation of m2m

If this isn't what happens, please post your code and ask for help on > django-users. > > -- > Aymeric > > 2015-12-03 13:28 GMT+01:00 Federico Capoano >: > >> Hi everybody, >> >> I am sure it has happened to many of you. >> >> Validating m2

Re: Validation of m2m

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-

App label with dot

Defining the app_label of an AppConfig with a dot, like "myproject.subapp" is allowed, but raises an exception in the migration framework (too many values to unpack). Did anybody notice this? Is it supposed to be allowed or not at all? Best regards Federico Capoano -- You rec

SynchronousOnlyOperation: bug or misconfiguration?

I have a celery task which performs queries and network operations. When deployed with celery with gevent concurrency, I occasionally (but not always) get reports of SynchronousOnlyOperation exceptions being raised. I described the problem in detail on StackOverflow: SynchronousOnlyOperation fr

Re: App label with dot

apps.AppConfig.label > > On Friday, December 18, 2020 at 10:47:45 AM UTC-5 Federico Capoano wrote: > >> Defining the app_label of an AppConfig with a dot, like >> "myproject.subapp" is allowed, but raises an exception in the migration >> framework (too ma

Re: App label with dot

r better here! User-facing > runtime exceptions like unpacking errors are never good. > > This should be quite a simple change to make, I’d suggest opening a trac > ticket first and we can go from there. > > Tom > > On 18 Dec 2020, at 16:38, Federico Capoano > wrote: > >

Default change password UX: area for improvements

be good to raise this here so we may fix it at the root instead. Best regards Federico Capoano -- 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

Admin raw_id_fields should trigger javascript change event

Hi everyone, I have a raw_id_field in the admin and I need to trigger some javascript logic when it's value is filled by the user through the popup, but unfortunately I found out that when the popup is closed and the value is filled into the field the change event is not fired. I found this qu

Testing admin inlines painful to debug ("ManagementForm data is missing or has been tampered with")

While writing tests for the admin, I'm clashing with this error message: "ManagementForm data is missing or has been tampered with". It's not the first time I do this, but every time the process has been extremely painful because the error message doesn't point out the exact problem. This time

Re: Widening participation (Thoughts from DjangoCon)

Hi everyone, It's been great to read some good insights on this discussion. How to attract new contributors from a different demographic (geographic area and age)? Good question. I wanted to share with you my experience as (second year) organization administrator and mentor for OpenWISP

Re: revisiting the Python version support policy

I would ask: what are the pros and cons of dropping support for python 3.5? I think allowing users to easily use and install django based applications is more important than strictly follow a python version support policy. I think that if we drop support for python 3.5, which is the default pyth

Re: Links from django docs to djangopackages.com should be 'officially endorsed' or not?

It seems like a good proposal, It would be good to know why Sergei doesn't think it is appropiate for Django to add links to third party package comparison grids. django-rest-framework links to third party extensions in its documentation and this had a positive effect on the whole DRF ecosystem

[admin] submit_row template tag reusability issue

Hi all, I came across the need of modifying the submit row functionality in the django admin and I found out a small issue which prevents me from modifying the template without rewriting (duplicating) also the templatetag entirely. If you take a look at the code of submit_row templatetag

Re: [admin] submit_row template tag reusability issue

> Feel free to update and/or improve the patch, add tests, and send a pull > request. Thanks! > > > On Monday, February 1, 2016 at 6:18:35 AM UTC-5, Federico Capoano wrote: >> >> Hi all, >> >> I came across the need of modifying the submit row functionality in

Re: [admin] submit_row template tag reusability issue

improvement in that sense but that shouldn't be difficult. The main blocker > to getting it merged looks like "Needs tests." > > On Tuesday, February 2, 2016 at 10:58:40 AM UTC-5, Federico Capoano wrote: >> >> Hi Tim, >> >> thank you for letting me kn

Re: [admin] submit_row template tag reusability issue

tickets, especially during events like sprints. Thanks to Tim for the review. Federico On Monday, February 1, 2016 at 12:18:35 PM UTC+1, Federico Capoano wrote: > > Hi all, > > I came across the need of modifying the submit row functionality in the > django admin and I found out a

Re: Fellow Report - February 6, 2016

Great work! On Saturday, February 6, 2016 at 4:27:42 PM UTC+1, Tim Graham wrote: > > Triaged > > --- > > https://code.djangoproject.com/ticket/26162 - Data loss when > ManyToManyField refers to the wrong table (accepted) > > https://code.djangoproject.com/ticket/26168 - BooleanField is force

Surprising behaviour in case of exception in form widget when DEBUG=False

This never happened to me and I find it very strange. Maybe it's a bug or maybe it's the intended behaviour, but I find it REALLY strange. Consider a widget which, for some reason, raises an exception: class CoolWidget(AdminTextareaWidget): def render(self, name, value, attrs={}): WR

Re: Surprising behaviour in case of exception in form widget when DEBUG=False

es, I think it's {% include %} rendering an empty string if there's an > exception. In Django 1.9, we added a logger for these exceptions to make > debugging easier: > https://docs.djangoproject.com/en/stable/topics/logging/#django-template. > > On Friday, March 11, 2016 at

A New Design for the "Congratulations!" Page

Looks like a great improvement for newcomers! I hope to see this included to Django. Federico -- 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

Re: A New Design for the "Congratulations!" Page

That's a great news, let us know if we can help with more feedback. Federico On Fri, Apr 21, 2017 at 9:20 AM Aymeric Augustin < aymeric.augus...@polytechnique.org> wrote: > On 18 Apr 2017, at 20:31, Tim Allen wrote: > > Your point on design by committee is spot-on; I think that's the direction