Re: Proposal to upgrade django.core.mail to Python's modern email API

[Paolo Melchiorre]

I agree with the approach suggested by Tom.

And thanks for proposing this enhancement.

Ciao,
Paolo

On Thu, Jun 27, 2024, 11:14 Tom Carrick  wrote:

> I'm in favour of this change, and nice that you're thinking about the
> future, but if you're going to write a ticket for this I would focus it on
> purely the strictly necessary parts to update to the new API, and when that
> is done, make more proposals to simplify the API as you suggest.
>
> I say this just with the goal of getting something that is easy to agree
> on merged, before dealing with potentially contentious things
> like EmailMultiAlternatives, MIMEBase, etc.
>
> Ignore me if this is irrelevant and those things are indeed necessary, my
> knowledge on the topic is a bit lacking.
>
> Tom
>
> On Thu, 27 Jun 2024 at 03:28, Mike Edmunds  wrote:
>
>> Since the early feedback seems positive (though we're still waiting for
>> more votes), here's some additional detail on the changes I think would be
>> involved to update django.core.mail to use Python's modern email API.
>>
>> (See my earlier message
>>  
>> for
>> background on Python's legacy vs. modern email APIs and why updating is
>> useful.)
>>
>> Note: Django and Python both have classes named EmailMessage. I'm using
>> "Django EmailMessage" to refer to django.core.mail.message.EmailMessage,
>> and "Python EmailMessage" (or sometimes just "modern API") to refer to
>> Python's modern email.message.EmailMessage.
>> Necessary work
>> 
>>
>>1.
>>
>>Update tests.mail.tests to use modern email APIs
>>
>>Where a test relies on legacy implementation details, try to rewrite
>>it to be implementation agnostic if possible; otherwise try to retain the
>>spirit of the test using modern APIs.
>>
>>Retain all security related tests, with updates as appropriate. (Even
>>where we know Python's modern API handles the security for us, it doesn't
>>hurt to double check.)
>>
>>Probably need to add some cases for existing behavior not currently
>>covered by tests, particularly around attachments and alternatives.
>>
>>Remove a test case *only* if it's truly no longer relevant and can't
>>be usefully updated. (And perhaps leave behind a brief comment explaining
>>why.)
>>
>>(Legacy email APIs used in tests.mail.tests: email.charset,
>>email.header.Header, MIMEText, parseaddr. Also message_from_… currently
>>defaults to legacy policy.compat32.)
>>2.
>>
>>Update django.core.mail.message.EmailMessage to use modern email APIs
>>
>>Change Django's EmailMessage.message() to construct a modern
>>email.message.EmailMessage rather than a SafeMIME object (which is based 
>> on
>>legacy email.message.Message with policy=compat32). Add a
>>message(policy=default) param forwarded to Python's EmailMessage
>>constructor.
>>
>>Hoist alternative part handling from Django's EmailMultiAlternatives
>>into Django's base EmailMessage to simplify the code. (More on this 
>> below.)
>>
>>In _create_alternatives(), use modern add_alternative()
>>
>> 
>>  and
>>friends to replace legacy SafeMIME objects.
>>
>>In _create_attachments(), use modern add_attachment()
>>
>> .
>>Handle (legacy Python) MIMEBase objects as deprecated, and convert to
>>modern equivalent. This is a relatively complex topic; I'll post a 
>> separate
>>message about it later. (I also have some questions about how best to
>>handle content-disposition "inline" and whether we want to somehow support
>>multipart/related.)
>>
>>Remove the private Django EmailMessage methods
>>_create_mime_attachment() and _create_attachment() (without deprecation).
>>
>>(Legacy APIs used in django.core.mail.message: email.message.Message,
>>email.charset, email.encoders, email.header, email.mime, email.utils)
>>3.
>>
>>Deprecate unused internal APIs from django.core.mail.message
>>
>>Django will no longer need these (Python's modern email API covers
>>their functionality), but they may be in use by third-party libraries:
>>- utf8_charset
>>   - utf8_charset_qp
>>   - RFC5322_EMAIL_LINE_LENGTH_LIMIT
>>   - BadHeaderError^ (more details below)
>>   - ADDRESS_HEADERS
>>   - forbid_multi_line_headers()^
>>   - sanitize_address() (more details below)
>>   - MIMEMixin
>>   - SafeMIMEMessage
>>   - SafeMIMEText^
>>   - SafeMIMEMultipart^
>>
>>(Items marked ^ are exposed in django.core.mail via __all__. I
>>haven't looked into the reason for that.)
>>4.
>>
>>Update django.core.mail.__init__ to avoid EmailMultiAlternatives, and

Re: Proposing the removal of Oracle from the Django supported backend databases

[Paolo Melchiorre]

Hi Mariusz,

On Thu, Aug 3, 2023 at 8:47 PM Mariusz Felisiak
 wrote:
> I'm quite surprised that you've started a new thread for something that was 
> already discussed, you could always add a comment to the existing thread e.g. 
> https://groups.google.com/g/django-developers/c/dg8BUVHKOo4/m/5uFVmdWCAwAJ

I was not aware of this thread, thanks for linking it.

>> I wanted to share the frustration of seeing yet another great new ORM 
>> feature blocked due to Oracle compatibility: 
>> https://github.com/django/django/pull/16417
> I'm not sure how you reached this conclusion. This is not blocked due because 
> of Oracle compatibility. I will review it and try to merge it before the 
> Django 5.0 feature freeze. You have to be patient, it has nothing to do with 
> Oracle

It was not my intention to push you into reviewing this PR given how
much you already do. But it seems to me that without Oracle
compatibility this functionality would have been ready for a long
time. However, this reflection of mine was born after seeing the
difficulty of the original contributor to add support to Oracle, at
the same time I also watch again Carlton's keynote at PyCon Italia
2023 because the videos have recently been published. Lastly, while
volunteering at the DSF booth at EuroPython 2023, I happened to meet
an Oracle Django developer for the first time, who admitted that he
had never contributed to the Oracle backend itself.

>> Over the last few months, I've tried to encourage newcomers and young users 
>> to contribute to Django and they almost always ran into the need to provide 
>> compatibility to Oracle, so much so that they eventually gave up 
>> contributing.
> Really? Django is not only the ORM. It is easy to demonize Oracle. I'm 
> working with contributors on daily basis, and  don't remember anyone who 
> would resign because we have builtin Oracle backend. We don't have much more 
> open tickets in the Oracle backend then in others. The number of unsupported 
> features is similar to SQLite or MySQL.

In my personal experience, the people I collaborate with at work or
meet in the local communities where I go to talk about Django all have
experience with Open Source databases and none have ever worked with
Oracle, which makes it very difficult for them to try to contribute in
Django's ORM why should they ensure compatibility for this DB without
ever having seen it.

>> The point is that I think Oracle is a historical anomaly among the database 
>> backends supported by Django because it is the only one that is not Open 
>> Source, it has irrelevant usage numbers
> It's not an anomaly. Oracle support was a conscious decision, keeping the ORM 
> features Oracle-compatible is a good battlefield, that helps keeping the ORM 
> friendly for 3rd-party database backends as we have more feature flags and 
> hooks for custom behaviors.

I think this would be the same if the Oracle backend was a third-party
package, perhaps maintained by the same company

>> ... and the company that earns from it does not contribute in any way to its 
>> maintenance or support
> Should be also drop support for Windows for exactly the same reason? 
> (rhetorical question)

I don't know, I haven't used Windows since 2000 :-)

Anyway, tornado to talk about Database, SQL Server is a third-party package

>> I, therefore, suggest that we start a discussion on removing Oracle from 
>> supported databases.
> This was already discussed. I'm still strongly against it.

Thank you for your point of view, and also for all the extra work you
do to help Django contributors who are having trouble making their
functionality compatible with Oracle.

I reiterate that my only intention was to understand if I were the
only one to have this point of view without wanting to criticize
anyone's work or past choices, things simply change in the field of
information technology and choices could be reviewed after years.

Ciao,
Paolo

-- 
Paolo Melchiorre

https://www.paulox.net

-- 
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 django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAKFO%2Bx6VjKOBpUtujXh-SJ3wjfO3sfLz4ekMRukiBNfy2W-FMw%40mail.gmail.com.

Proposing the removal of Oracle from the Django supported backend databases

[Paolo Melchiorre]

Hi all,
I wanted to share the frustration of seeing yet another great new ORM
feature blocked due to Oracle compatibility:
https://github.com/django/django/pull/16417

In the past, I too have had to put a lot of effort trying to make a PR
compatible with Oracle, making the overall contributing experience
much less pleasant and holding me back from contributing, especially
in the early days.

Over the last few months, I've tried to encourage newcomers and young
users to contribute to Django and they almost always ran into the need
to provide compatibility to Oracle, so much so that they eventually
gave up contributing.

I stress that I am absolutely not criticizing the contributors (very
few) in the community who help overcome the difficulties with Oracle.

The point is that I think Oracle is a historical anomaly among the
database backends supported by Django because it is the only one that
is not Open Source, it has irrelevant usage numbers (see Django
Developers Survey 2022 Results
https://lp.jetbrains.com/django-developer-survey-2022/#horizontal-bar-chart-862)
and the company that earns from it does not contribute in any way to
its maintenance or support (see Carlton Gibson keynote at PyCon Italia
2023 https://youtu.be/AHjnGtaWDjU?t=836)

To add to all this we consider that developing for Oracle is much more
difficult than for the other Open Source databases supported by Django
and above all the new contributors to the ORM have a frustrating
experience and therefore they are less and less.

I, therefore, suggest that we start a discussion on removing Oracle
from supported databases.

Ciao,
Paolo
-- 
Paolo Melchiorre

https://www.paulox.net

-- 
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 django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAKFO%2Bx6WXzhhKPoDVodD_dKQEkyLKT3hJOA26seC6%2B3Tb1QrXQ%40mail.gmail.com.

Re: Fellow Reports - April 2023

[Paolo Melchiorre]

Welcome Natalia 🤗

On Tue, Apr 11, 2023, 17:04 Natalia Bidart  wrote:

> Week ending April 9, 2023
>
> Hello! I'm Natalia (AKA nessita), the new Django Fellow. I officially
> started on April 1st (really :-)) though I had a slow start since I had a
> long-time planned vacation.
>
> So far I have held catch up calls with both current and former Django
> Fellows (thanks Mariusz and Carlton for your patience and support!), and I
> have been deep diving into documentation.
>
> I'm looking forward to working with you all!
>
> Thank you!
> Natalia.
>
> --
> 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 django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CA%2BfOnFbRDqYGpBGPTB28EknOuP8PQcAJTvYwNGuqNKmL0zeHtQ%40mail.gmail.com
> 
> .
>

-- 
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 django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAKFO%2Bx5wD9E8uiMFPMhSkQwotwAC4CKFMH_CQR6gkVW3U65P1A%40mail.gmail.com.

Re: Proposal for Django Core Sprints

[Paolo Melchiorre]

Hi 'st...@jigsawtech.co.uk',
I'm sorry but I can't find your name in the email.

In my proposal I explicitly propose that the few people invited should
be financed in various ways, precisely to avoid excluding someone.

Grazie,
Paolo

On Thu, Oct 27, 2022 at 8:02 AM 'st...@jigsawtech.co.uk' via Django
developers (Contributions to Django itself)
 wrote:
>
> Hybrid sound the best way, with remote first as otherwise you are excluding 
> people who would need air travel that's not covered by someone else and can 
> be very expensive how and are thus increasing a carbon footprint for 
> something that really doesn't need it
>
> On Thursday, 27 October 2022 at 01:49:53 UTC+1 pa...@melchiorre.org wrote:
>>
>> Hi Andrew,
>>
>> Thanks also to you for your very detailed answer.
>>
>> On Thu, Oct 27, 2022 at 1:54 AM Andrew Godwin  wrote:
>>
>> > ... trying to organise an additional in-person event that a large number 
>> > of contributors are expected to go to is difficult
>>
>> I am aware that this proposal of mine to the DSF board is not easy,
>> but I think it could have positive effects as I have seen it happen in
>> the past and as it still happens today in other communities.
>>
>> > ... who do you invite (and presumably help pay for)? We no longer have a 
>> > core team ...
>>
>> I understand that the term "core" has triggered some old discussion
>> that I am not aware of, but in my proposal it refers to the scope of
>> the code to work on.
>>
>> > ...it's a hard metric to gauge.
>>
>> This is something that we could decide together.
>>
>> > ... while I do believe it should be a hybrid event, I also think it should 
>> > not be a remote-only event.
>>
>> On this point you seem to agree with my proposal
>>
>> > The final question I would raise is that of location ...
>>
>> I tried to give general indications on the location in my proposal so
>> that I could then decide a place based on the actual participants of a
>> given sprint, without imposing a predefined location or nation.
>>
>> > I didn't even discuss how we might fund this...
>>
>> Surely here too I left generic indications, because it seemed to me
>> more than once to understand that the DSF board would not have too
>> many problems in receiving new funds as long as they were destined for
>> a specific objective.
>>
>> For example, imagine a sprint working on only one of the proposals you
>> listed in your last talk, it could be a point that many may have an
>> interest in financing directly.
>>
>> Grazie,
>> Paolo
>>
>> > On Wed, Oct 26, 2022, at 4:01 PM, Paolo Melchiorre wrote:
>> > Hi everyone,
>> > Following Andrew Godwin's example, I too share with you a proposal
>> > that I made during DjangoCon US 2022 and that I have already shared
>> > with some of you.
>> > Inspired by an article by Will Vincent, I wrote my proposal for Django
>> > Core Sprints, and its genesis, in an article and would also like to
>> > have the opinions of the Django community members interested in the
>> > idea:
>> > https://www.paulox.net/2022/10/26/about-my-proposal-for-the-django-core-sprints/
>>
>> --
>> Paolo Melchiorre
>>
>> https://www.paulox.net
>
> --
> 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 django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/994f5282-05b0-465b-8d13-851109f985c2n%40googlegroups.com.



-- 
Paolo Melchiorre

https://www.paulox.net

-- 
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 django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAKFO%2Bx6Vg400ANY074e9P69DVC1F0M5s9rM9oQ1s_sJsY6LHqg%40mail.gmail.com.

Re: Proposal for Django Core Sprints

[Paolo Melchiorre]

Hi Andrew,

Thanks also to you for your very detailed answer.

On Thu, Oct 27, 2022 at 1:54 AM Andrew Godwin  wrote:

> ... trying to organise an additional in-person event that a large number of 
> contributors are expected to go to is difficult

I am aware that this proposal of mine to the DSF board is not easy,
but I think it could have positive effects as I have seen it happen in
the past and as it still happens today in other communities.

> ... who do you invite (and presumably help pay for)? We no longer have a core 
> team ...

I understand that the term "core" has triggered some old discussion
that I am not aware of, but in my proposal it refers to the scope of
the code to work on.

> ...it's a hard metric to gauge.

This is something that we could decide together.

> ... while I do believe it should be a hybrid event, I also think it should 
> not be a remote-only event.

On this point you seem to agree with my proposal

> The final question I would raise is that of location ...

I tried to give general indications on the location in my proposal so
that I could then decide a place based on the actual participants of a
given sprint, without imposing a predefined location or nation.

> I didn't even discuss how we might fund this...

Surely here too I left generic indications, because it seemed to me
more than once to understand that the DSF board would not have too
many problems in receiving new funds as long as they were destined for
a specific objective.

For example, imagine a sprint working on only one of the proposals you
listed in your last talk, it could be a point that many may have an
interest in financing directly.

Grazie,
Paolo

> On Wed, Oct 26, 2022, at 4:01 PM, Paolo Melchiorre wrote:
> Hi everyone,
> Following Andrew Godwin's example, I too share with you a proposal
> that I made during DjangoCon US 2022 and that I have already shared
> with some of you.
> Inspired by an article by Will Vincent, I wrote my proposal for Django
> Core Sprints, and its genesis, in an article and would also like to
> have the opinions of the Django community members interested in the
> idea:
> https://www.paulox.net/2022/10/26/about-my-proposal-for-the-django-core-sprints/

-- 
Paolo Melchiorre

https://www.paulox.net

-- 
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 django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAKFO%2Bx7gQFCz0dg%2BL73tHyYw9wDs_v2GXH0%3D6vAxu-VQSeKWNQ%40mail.gmail.com.

Re: Proposal for Django Core Sprints

[Paolo Melchiorre]

Hi James,

First of all, thank you for your feedback.

On Thu, Oct 27, 2022 at 1:10 AM James Bennett  wrote:
> * They should be designed around the assumption of remote-first, not "hybrid" 
> or in-person-first, ...

My proposal is that of hybrid sprints for the reasons I have listed in
my article, remote-first or remote-only sprints are totally another
proposal that maybe someone will do.

> * ... it would make more sense to formally attach the sprint to a major event 
> like one of the DjangoCons.

There are already sprints at the end of the various DjangoCon, I am
trying to propose something in addition to them.

> Meanwhile, I think it is absolutely essential to drop the "Core" naming ...

The word "core" refers to the fact that the sprints I propose are
exclusively dedicated to the Django code, unlike what happens now in
the sprints at the end of DjangoCon where people sprint on different
things.

To avoid further misunderstandings, I reiterate that the sprints I
propose are in some way similar to what already happens in other
communities, for example CPython [1] and HPy [2].

Grazie,
Paolo

[1] 
https://discuss.python.org/t/rsvp-2022-core-dev-sprint-oct-3-7-sunnyvale-ca-usa/18420
[2] https://hpyproject.org/blog/posts/2022/07/dusseldorf-sprint-2022/

> On Wed, Oct 26, 2022 at 3:01 PM Paolo Melchiorre  wrote:
>> Following Andrew Godwin's example, I too share with you a proposal
>> that I made during DjangoCon US 2022 and that I have already shared
>> with some of you.
>> Inspired by an article by Will Vincent, I wrote my proposal for Django
>> Core Sprints, and its genesis, in an article and would also like to
>> have the opinions of the Django community members interested in the
>> idea:
>> https://www.paulox.net/2022/10/26/about-my-proposal-for-the-django-core-sprints/
-- 
Paolo Melchiorre

https://www.paulox.net

-- 
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 django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAKFO%2Bx4Oxxtdaf_LjERnS_z2d_awbVe5uWS3fam_EJYWT9%3DiKw%40mail.gmail.com.

Proposal for Django Core Sprints

[Paolo Melchiorre]

Hi everyone,

Following Andrew Godwin's example, I too share with you a proposal
that I made during DjangoCon US 2022 and that I have already shared
with some of you.

Inspired by an article by Will Vincent, I wrote my proposal for Django
Core Sprints, and its genesis, in an article and would also like to
have the opinions of the Django community members interested in the
idea:
https://www.paulox.net/2022/10/26/about-my-proposal-for-the-django-core-sprints/

Ciao,
Paolo
-- 
Paolo Melchiorre

https://www.paulox.net

-- 
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 django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAKFO%2Bx6FAf-M14fKx5QS1K8rru2L3mOiR1R%3Dn6FzDk%3DrnaUq3A%40mail.gmail.com.

Re: Proposal: Add An in-memory data storage backend in Django

[Paolo Melchiorre]

Yes, exactly.

Paolo

On Fri, Oct 21, 2022, 10:59 Joshua Thomas  wrote:

> Not to speak for Paulo, but I believe he meant using in-memory storage as
> a file storage backend, not data/database backend.
>
> On Thursday, October 20, 2022 at 4:50:49 PM UTC-7 shang.xia...@gmail.com
> wrote:
>
>> Hi,
>>
>> I may be missing some context here but is this something distinctly
>> different from setting SQLite to use in-memory storage [1]? 🤔
>>
>> [1] https://www.sqlite.org/inmemorydb.html
>>
>> David
>>
>> On Fri, 21 Oct 2022, 04:30 Paolo Melchiorre (paulox), <
>> pa...@melchiorre.org> wrote:
>>
>>> Hi all,
>>>
>>> there is a package that provide in-memory data storage backend, but it's
>>> now abandoned.
>>>
>>> Having support for in-memory data storage could be very useful for
>>> Django itself and furthermore it would involve adding a small code with
>>> tests that do not justify the creation of a fork of that old package.
>>>
>>> We are talking about this during the sprints at DjangoCon US 2023 in San
>>> Diego with Josh Thomas and Mariusz Felisiak proposed to us to ask here on
>>> this list.
>>>
>>> What do you think about adding an in-memory data storage backend
>>> directly in the Django core?
>>>
>>> Ciao,
>>> Paolo
>>>
>>> --
>>>
>> 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 django-develop...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/django-developers/e0f6d509-20d7-4eef-b570-cc53611dca01n%40googlegroups.com
>>> <https://groups.google.com/d/msgid/django-developers/e0f6d509-20d7-4eef-b570-cc53611dca01n%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>> --
> 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 django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/2fe8f558-da42-4510-a8fa-344627652129n%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/2fe8f558-da42-4510-a8fa-344627652129n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>

-- 
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 django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAKFO%2Bx7W8vgVYDNiG%2B8j3q1kP2%2BEuf9ffwAk7fQXZ%2BWWX_rJsQ%40mail.gmail.com.

Re: Proposal: Add An in-memory data storage backend in Django

[Paolo Melchiorre]

Actually we're talking about an in memory data storage backend in addition
to the filesystem storage
https://docs.djangoproject.com/en/4.1/ref/files/storage/

On Thu, Oct 20, 2022, 16:50 David Sanders 
wrote:

> Hi,
>
> I may be missing some context here but is this something distinctly
> different from setting SQLite to use in-memory storage [1]? 🤔
>
> [1] https://www.sqlite.org/inmemorydb.html
>
> David
>
> On Fri, 21 Oct 2022, 04:30 Paolo Melchiorre (paulox), <
> pa...@melchiorre.org> wrote:
>
>> Hi all,
>>
>> there is a package that provide in-memory data storage backend, but it's
>> now abandoned.
>>
>> Having support for in-memory data storage could be very useful for Django
>> itself and furthermore it would involve adding a small code with tests that
>> do not justify the creation of a fork of that old package.
>>
>> We are talking about this during the sprints at DjangoCon US 2023 in San
>> Diego with Josh Thomas and Mariusz Felisiak proposed to us to ask here on
>> this list.
>>
>> What do you think about adding an in-memory data storage backend directly
>> in the Django core?
>>
>> Ciao,
>> Paolo
>>
>> --
>> 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 django-developers+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/e0f6d509-20d7-4eef-b570-cc53611dca01n%40googlegroups.com
>> <https://groups.google.com/d/msgid/django-developers/e0f6d509-20d7-4eef-b570-cc53611dca01n%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
> --
> 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 django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CADyZw-64SU%2BdwjKDGmzCZpz06VZ-QUxjb3%2B9RGFp8vqbJSd58Q%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CADyZw-64SU%2BdwjKDGmzCZpz06VZ-QUxjb3%2B9RGFp8vqbJSd58Q%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>

-- 
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 django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAKFO%2Bx6%3Da-hcWCitN54mPZyHc1VTaxfTDHwvG1VGymX%3DjUBVug%40mail.gmail.com.

Re: Proposal: Add An in-memory data storage backend in Django

[Paolo Melchiorre]

Yes, the package is that one and Josh mentioned it in the related issue
https://code.djangoproject.com/ticket/34110

But that package is unmantained and the feature that it provides can be
very useful to have directly in the Django core.

On Thu, Oct 20, 2022, 18:00 'Tobias McNulty' via Django developers
(Contributions to Django itself)  wrote:

> Hi,
>
> I also may be missing some context, but is this the mentioned package?
> https://github.com/waveaccounting/dj-inmemorystorage
>
> I have not used it, but it looks like a useful tool to have!
>
> Tobias
>
>
> On Thu, Oct 20, 2022 at 7:50 PM David Sanders <
> shang.xiao.sand...@gmail.com> wrote:
>
>> Hi,
>>
>> I may be missing some context here but is this something distinctly
>> different from setting SQLite to use in-memory storage [1]? 🤔
>>
>> [1] https://www.sqlite.org/inmemorydb.html
>>
>> David
>>
>> On Fri, 21 Oct 2022, 04:30 Paolo Melchiorre (paulox), <
>> pa...@melchiorre.org> wrote:
>>
>>> Hi all,
>>>
>>> there is a package that provide in-memory data storage backend, but it's
>>> now abandoned.
>>>
>>> Having support for in-memory data storage could be very useful for
>>> Django itself and furthermore it would involve adding a small code with
>>> tests that do not justify the creation of a fork of that old package.
>>>
>>> We are talking about this during the sprints at DjangoCon US 2023 in San
>>> Diego with Josh Thomas and Mariusz Felisiak proposed to us to ask here on
>>> this list.
>>>
>>> What do you think about adding an in-memory data storage backend
>>> directly in the Django core?
>>>
>>> Ciao,
>>> Paolo
>>>
>>> --
>>> 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 django-developers+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/django-developers/e0f6d509-20d7-4eef-b570-cc53611dca01n%40googlegroups.com
>>> <https://groups.google.com/d/msgid/django-developers/e0f6d509-20d7-4eef-b570-cc53611dca01n%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>> --
>> 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 django-developers+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/CADyZw-64SU%2BdwjKDGmzCZpz06VZ-QUxjb3%2B9RGFp8vqbJSd58Q%40mail.gmail.com
>> <https://groups.google.com/d/msgid/django-developers/CADyZw-64SU%2BdwjKDGmzCZpz06VZ-QUxjb3%2B9RGFp8vqbJSd58Q%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
> --
> 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 django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAMGFDKRiEsi7BqaNUJGFWNYqpfP3Cq8TVx3fQYuuYp9ii-injw%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CAMGFDKRiEsi7BqaNUJGFWNYqpfP3Cq8TVx3fQYuuYp9ii-injw%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>

-- 
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 django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAKFO%2Bx7G7jfkbAG7uOnTjkunTOxuY0H4ZTXL1Ci-QCKiY%3D6Lqw%40mail.gmail.com.

Proposal: Add An in-memory data storage backend in Django

[Paolo Melchiorre (paulox)]

Hi all,

there is a package that provide in-memory data storage backend, but it's 
now abandoned.

Having support for in-memory data storage could be very useful for Django 
itself and furthermore it would involve adding a small code with tests that 
do not justify the creation of a fork of that old package.

We are talking about this during the sprints at DjangoCon US 2023 in San 
Diego with Josh Thomas and Mariusz Felisiak proposed to us to ask here on 
this list.

What do you think about adding an in-memory data storage backend directly 
in the Django core?

Ciao,
Paolo

-- 
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 django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/e0f6d509-20d7-4eef-b570-cc53611dca01n%40googlegroups.com.

Generated Field

[Paolo Melchiorre]

Hi all,

I am at PyCon DE 2022 in Berlin with Markus and I shared with him this
idea that I have been thinking about for a few months, given his
interest I also share it with you.

I figured we could add in Django a "GeneratedField" which accepts a
"base_field" attribute in a similar way to "ArrayField" and then an
expression to generate a value for the field.

For example this model:

class Album(models.Model):
   ...
   title = models.CharField(max_length=120)
   search = GeneratedField(
 SearchVectorField(),
 F('title')
   )

would generate an SQL code like this in PostgreSQL:

CREATE TABLE album (
 ...
 title char(120),
 search tsvector GENERATED ALWAYS AS title STORED
);

I found some documentation for different database backend about
generated column (or similar names)

# SQLite
https://www.sqlite.org/gencol.html
https://www.sqlite.org/releaselog/3_31_0.html

# PostgreSQL
https://www.postgresql.org/docs/12/ddl-generated-columns.html
https://www.postgresql.org/docs/12/release-12.html

# Oracle
https://oracle-base.com/articles/11g/virtual-columns-11gr1

# MySQL
https://dev.mysql.com/doc/refman/5.7/en/mysql-nutshell.html
https://dev.mysql.com/doc/refman/5.7/en/create-table-generated-columns.html

# MariaDB
https://mariadb.com/kb/en/changes-improvements-in-mariadb-102/
https://mariadb.com/kb/en/generated-columns/

I'd love to hear your thoughts on this idea and if you think it might
be something worth continuing to investigate.

Greetings from PyCon DE 2022 in Berlin,
Paolo

--
https://www.paulox.net

-- 
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 django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAKFO%2Bx5GHUEVdzi2awYtH5C17tTPTPh%2ByoDP%3DKC18pF8%2Bi_7PA%40mail.gmail.com.

Re: Preparing Django code for the Black stable release

[Paolo Melchiorre]

Hi all,

Black 22.1.0 has just been released
https://github.com/psf/black/releases/tag/22.1.0

It seems the time has come to put DEP 0008 into practice and "run
Black on the entire Django code repository and make a single commit".

Ciao,
Paolo

On Wed, Oct 20, 2021 at 10:52 PM Paolo Melchiorre  wrote:
>
> On Wed, Oct 20, 2021, 21:51 Mariusz Felisiak  
> wrote:
>>
>>
>>> I was thinking we can start right now using black in a branch and see which 
>>> issue will show up and start fixing them.
>>
>>
>> We don't want to merge multiple commits related to black. According to the 
>> "Implementation" section in DEP 0008, we're going to run Black on the entire 
>> Django code repository and make a single commit. Running black should not 
>> encounter any issues …
>
>
> Okay, I also hope the migration to Black will be this smooth.
>
> So now we just have to wait for 2022.
>
> Ciao,
> Paolo
>
>


-- 
Paolo Melchiorre

https://www.paulox.net

-- 
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 django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAKFO%2Bx6dZAw7ftsGvJOV5crHazXLW4RST_t26JDHFcqA1uNXEA%40mail.gmail.com.

Re: Deprecate CICharField, CIEmailField, CITextField

[Paolo Melchiorre]

Hi Mariusz,

I agree with you on deprecating and then removing CI fields.

I only would suggest adding some examples of migrations from CI fields
to collations in the deprecation notes to help users to easily
migrate.

So +1 for me too.

Ciao,
Paolo

On Tue, Jan 25, 2022 at 1:39 PM Mariusz Felisiak
 wrote:
>
> Hi y'all,
>
> Django 3.2+ supports "db_collation" [1] for "CharField" and "TextField" 
> along with migration operations ("CreateCollation()", "RemoveCollation") and 
> the database function "Collate()" [3]. Moreover CI fields and the entire 
> "citext" module are discouraged since PostgreSQL 12 [4] in favor of 
> collations. I think it's time to deprecate CI fields from the 
> "contrib.postgres" in favor of "CharField" and "TextField" with case 
> insensitive collations (and remove them in Django 5.0).
>
> Best,
> Mariusz
>
> [1] https://code.djangoproject.com/ticket/31777
> [2] https://code.djangoproject.com/ticket/32046
> [3] https://code.djangoproject.com/ticket/21181
> [4] https://www.postgresql.org/docs/12/citext.html
>
> --
> 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 django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/833bb13b-3db1-f35b-3d51-a2a4671b45a9%40gmail.com.



-- 
Paolo Melchiorre

https://www.paulox.net

-- 
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 django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAKFO%2Bx5j8Y6%2BMH_%2Bug-BGKZ6qaWD9tRWVLXLOXhmTQuvrN8tzw%40mail.gmail.com.

Re: Preparing Django code for the Black stable release

[Paolo Melchiorre]

On Wed, Oct 20, 2021, 21:51 Mariusz Felisiak 
wrote:

>
> I was thinking we can start right now using black in a branch and see
>> which issue will show up and start fixing them.
>>
>
> We don't want to merge multiple commits related to black. According to the
> "Implementation" section in DEP 0008, we're going to run Black on the
> entire Django code repository and make a single commit. Running black
> should not encounter any issues …
>

Okay, I also hope the migration to Black will be this smooth.

So now we just have to wait for 2022.

Ciao,
Paolo

-- 
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 django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAKFO%2Bx53pmuLxc68_R7VtKgq_cVSmo1PGcUumG73pZ%3D3g7MAvg%40mail.gmail.com.

Re: Preparing Django code for the Black stable release

[Paolo Melchiorre]

On Wed, Oct 20, 2021, 11:37 Mariusz Felisiak 
wrote:

>
> I think we can start prepare this great migrations of the Django code so
>> we will be ready when Black 22.0 will be released and we can finally
>> benefit from this change.
>>
>
> Do you have any specific steps in mind? I'm not sot sure how we need to
> prepare. Implementation, as described in
>
DEP 0008
> ,
> should be rather straightforward and I don't think anything needs to be
> done in advance. We (Fellows and OPS team) should be able to implement it
> within a few days.
>

Hi,

I was thinking we can start right now using black in a branch and see which
issue will show up and start fixing them.

Ciao,
Paolo

>

-- 
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 django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAKFO%2Bx6hUfgmiZ%2BeL3EYDw6jHsZ0u0bqYNb4hQSPepgvEVewiQ%40mail.gmail.com.

Preparing Django code for the Black stable release

[Paolo Melchiorre]

Hi all,

More than two years ago the 'DEP 0008: Formatting using Black' was accepted 
with the constraint to wait until Black got to a stable release:
https://github.com/django/deps/blob/main/accepted/0008-black.rst

As you can see from this pull request in the Black code the first stable 
release is expected for January 2022:
https://github.com/psf/black/pull/2529

I think we can start prepare this great migrations of the Django code so we 
will be ready when Black 22.0 will be released and we can finally benefit 
from this change.

We have now more than 2 months to work on this.

Ciao,
Paolo

-- 
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 django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/8bcec02b-6917-4d9a-9e65-eef375de73b9n%40googlegroups.com.

Re: makemessages management command should not touch POT-Creation-Date

[Paolo Melchiorre]

Hi all,

I'm also in favour of the change, I also find  the current behaviour annoying.

Paolo

‪On Tue, Aug 31, 2021 at 1:10 PM ‫אורי‬‎  wrote:‬
>
> I also find it annoying that one line changes always even if there are no 
> changes in translations. I prefer the file not to change at all if nothing 
> has changed.
>
> On Tue, Aug 31, 2021 at 11:03 AM 'Adam Johnson' via Django developers 
> (Contributions to Django itself)  wrote:
>>
>> I'm in favour of the change. Leaving the file as-is when no actual data 
>> changed just makes sense to me.
>> The original discussion didn't touch upon the --update flag, so maybe it 
>> didn't exist then, or the participants didn't know about it. Its existence 
>> really weakens the argument that “we shouldn't redefine the meaning of 
>> gettext's header fields”.
>>
>> On Mon, 30 Aug 2021 at 23:55, Daniyal Abbasi  
>> wrote:
>>>
>>> I was recently working on some git hooks with the makemessages command and 
>>> I noticed that the "POT-Creation-Date" was always updated even if no 
>>> strings were added, removed or relocated.
>>> I created a ticket (#33056) and was redirected to #6106 which is the 
>>> original ticket which was closed over 11 years ago. However, I'd like to 
>>> bring this into discussion and hoping to open this issue once again.
>>> If the po file exists, the makemessages command uses `msgmerge` in the 
>>> `write_po_file` method to get the contents of the po file. (Refer this). 
>>> However, msgmerge is not ran in the update mode using the `--update` flag.
>>> I propose on added this flag and making other suitable modifications as 
>>> this causes a lot of issues with source control and git hooks. I've created 
>>> a sample PR for the same.
>>> Looking forward to hear what everyone thinks about this!



-- 
Paolo Melchiorre

https://www.paulox.net

-- 
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 django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAKFO%2Bx6BMofvMDsQtqMtNJ1FwWu%2BQxTeKPXmDdQOW4v1zA7ZYQ%40mail.gmail.com.

Re: Translations

[Paolo Melchiorre]

Hi Zain,

I think you can ask on the specific mailing list for this subject
https://groups.google.com/g/django-i18n

Paolo

On Mon, May 10, 2021, 22:36 Zain Al-abdeen  wrote:

> hi ,
> i want to translate the django website and documentation ,
>
> can anyone show me the way to do this?
>

-- 
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 django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAKFO%2Bx4dc5F6x8Mtt4jA_irLe8Y7tOvrbXJB%2B%2B2mKoDSsjty%2Bg%40mail.gmail.com.

Re: Status of 3.2 release blockers.

[Paolo Melchiorre]

I agree with Adam.

I've also left a small comment on the PR.

Paolo

On Tue, Jan 12, 2021 at 5:59 PM Adam Johnson  wrote:
>
> I think it's worth merging into 3.2. The change is quite small, the potential 
> benefits are quite large, and some users live LTS to LTS so could be left 
> without an option for a long time.
>
> I've left some review comments on the PR.
>
> On Tue, 12 Jan 2021 at 15:29, Paul Ganssle  wrote:
>>
>> Yeah, sorry I didn't get around to this until so close to the deadline. 
>> December was a lot crazier for me than I had hoped. ☹
>>
>> One thing I'll note is that this PR to allow using zoneinfo timezones is 
>> mostly just adding tests. The substantive changes to the codebase are very 
>> light, and there should be no behavioral change for users of pytz or current 
>> users of other time zone providers (assuming such people exist). There 
>> appears to be a nominal attempt to support non-pytz zones in 
>> django.utils.timezones, so possibly this PR just improves support that was 
>> already intended to be present in the first place.
>>
>> I do think it would be good to make it possible for people to do some 
>> conversion over ahead of time if possible, particularly since no deprecation 
>> warnings will be issued prior to the change away from pytz.
>>
>> Best,
>> Paul
>>
>> On 1/12/21 10:12 AM, Carlton Gibson wrote:
>>
>> Hi all.
>>
>> Paul Ganssle has followed up his earlier PoC PR, and the previous 
>> discussion, with a smaller PR in order to allow using zoneinfo timezones 
>> without an error:
>>
>> Add support for non-pytz zones
>> https://github.com/django/django/pull/13877
>>
>> The idea is to target 3.2 for this. (Recall for 4.0 we'll switch to 
>> zoneinfo, allowing folks to opt-in to the pytz compatibility shim, if 
>> needed.)
>>
>> First glance, it looks OK, great even (absolutely as expected from Paul).
>>
>> I don't have capacity to properly sit down with it before the feature freeze 
>> (due Thursday) though.
>> So if it were just me, I'd have to say it's too hot, too close to the 
>> deadline, and we should just target 4.0
>>
>> However, maybe others, and the Technical Board who have the authority to 
>> specify, think that this is something we should take the extra time if 
>> needed and make sure we get in for 3.2?
>> (Any extra eyes reviewing would help in that case.)
>>
>> As per Aymeric's point on the previous discussion, it's likely this doesn't 
>> affect most of our users.
>> Paul's concern is that Django incompatibility (along with Pandas he 
>> mentioned in discussion) is blocking adoption throughout the community.
>> That's not necessarily our problem, but maybe this is a small enough change 
>> that we should be flexible here?
>> With 3.2 being the next LTS, it'll be around for a while (which is relevant 
>> I think).
>>
>> Can I ask for opinions please? Again, the option is to say that we'll 
>> squeeze this in if review is fine.
>> The feature freeze isn't cast in stone, but we do have to draw the line 
>> somewhere.
>> This one is sufficiently interesting that Mariusz and I don't want to just 
>> decide with consultation.
>>
>> Thanks.
>>
>> Kind Regards,
>>
>> Carlton
>>
>>
>>
>>
>> On Monday, 4 January 2021 at 10:56:42 UTC+1 Carlton Gibson wrote:
>>>
>>> Hi all,
>>>
>>> Happy New Year!
>>>
>>> Time to begin release process for the next major release, Django 3.2!
>>>
>>> Reference: https://code.djangoproject.com/wiki/Version3.2Roadmap
>>>
>>> The 3.2 feature freeze is scheduled for January 14.
>>> We'll probably release the alpha that day.
>>>
>>> We have a few larger patches we want to finish reviewing:
>>>
>>> https://github.com/django/django/pull/11929 - Fixed #26167 -- Added support 
>>> for functional indexes.
>>> https://github.com/django/django/pull/13618 - Fixed 30360 -- Support 
>>> rotation of secret keys.
>>> https://github.com/django/django/pull/13435 - Fixed #32018 -- Extracted 
>>> admin colors into CSS variables.
>>> https://github.com/django/django/pull/11026 - Fixed #29010, Fixed #29138 -- 
>>> Added limit_choices_to and to_field support to autocomplete fields.
>>>
>>> We'll update this thread for any schedule changes.



-- 
Paolo Melchiorre

https://www.paulox.net

-- 
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 django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAKFO%2Bx7sbbZCeJmPGmaf%2BfS8ASCYm-WVxS37nKZAEKFsJ%2BgxXA%40mail.gmail.com.

Re: Django project 503 issue

[Paolo Melchiorre]

Thanks for letting me know.

I haven't checked twitter before sending the email.

Thanks Florian for your work on this.

See you

On Sat, Dec 5, 2020, 18:41 Adam Johnson  wrote:

> This is now resolved thanks to the work of Florian:
> https://twitter.com/fapolloner/status/1335274719348723712
>
> On Sat, 5 Dec 2020 at 17:06, Paolo Melchiorre 
> wrote:
>
>> Hi all,
>>
>> I noticed that the Django project website is responding to an HTTP status
>> 503.
>>
>> I found an issue on github and I added a comment to it.
>>
>> I don't know if there's a better way to report this type of error.
>> https://github.com/django/djangoproject.com/issues/1051
>>
>>
>> Best regards,
>> Paolo
>>
>> --
>> Paolo Melchiorre
>>
>> https://www.paulox.net
>>
>> --
>> 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 django-developers+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/CAKFO%2Bx6gO4hrdXTd45UCvz7cjRhvX3sZJ_dGPJjFortgywdX5A%40mail.gmail.com
>> .
>>
>
>
> --
> Adam
>
> --
> 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 django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAMyDDM1kdko_Hmee-5GFBAqR0f881-52y-MLR%2B90KTfiaXM2CA%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CAMyDDM1kdko_Hmee-5GFBAqR0f881-52y-MLR%2B90KTfiaXM2CA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>

-- 
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 django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAKFO%2Bx5JZ1MmzY%2Bu6a1tta192HvaHbZ78ZPWKRcwOdAtqiifwg%40mail.gmail.com.

Django project 503 issue

[Paolo Melchiorre]

Hi all,

I noticed that the Django project website is responding to an HTTP status 503.

I found an issue on github and I added a comment to it.

I don't know if there's a better way to report this type of error.
https://github.com/django/djangoproject.com/issues/1051


Best regards,
Paolo

-- 
Paolo Melchiorre

https://www.paulox.net

-- 
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 django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAKFO%2Bx6gO4hrdXTd45UCvz7cjRhvX3sZJ_dGPJjFortgywdX5A%40mail.gmail.com.

Re: Model Generation for CSV, XLS Files

[Paolo Melchiorre]

On Fri, Nov 27, 2020 at 5:51 AM Muskan Vaswan  wrote:
> I want to know what functionality already exists that makes it easier to 
> directly load a large data set into a django model from a CSV file (going 
> with the simplest format or now).

Hi Muskan,

In PostgreSQL I use the COPY FROM to load a large set of data directly
into the database table from a CSV file.
https://www.postgresql.org/docs/current/sql-copy.html

In a Django project I used Django Postgres Copy to load 1M lines CSV
file in 1 second:
https://github.com/california-civic-data-coalition/django-postgres-copy

I know my answer is not useful for other supported database backends,
I only tried to share my experience.

Best,
Paolo

-- 
Paolo Melchiorre

https://www.paulox.net

-- 
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 django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAKFO%2Bx6SgAwv%2ByRoCKCYU_vWvuSYfxub_2x2HZESVECWuJ4OaA%40mail.gmail.com.

Re: Revisiting Python support for after Django 3.2 LTS

[Paolo Melchiorre]

Hi all,

On Thu, Nov 19, 2020 at 9:01 AM Carlton Gibson  wrote:
> ...
> Thus on the current policy we should drop support for both Python 3.6 and 
> Python 3.7 when we branch Django 3.2 — i.e. for Django 4.0.
> ...
> I think we should drop Python 3.6 at this time ...
>
> I think though that dropping support for Python 3.7 would be a little 
> aggressive ...

I agree with you.

Python 3.7 is still the default version in the stable version of
Debian 10 (Buster) with LTS until 2024.

Kind regards,
Paolo
-- 
Paolo Melchiorre

https://www.paulox.net

-- 
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 django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAKFO%2Bx67iV6ENfs1WF7eGo9qMr%2BAMVpKOOJ9JZ_pwSWfsJeSgg%40mail.gmail.com.

Re: Updating the documentation search

[Paolo Melchiorre]

On Sat, Oct 10, 2020 at 10:56 AM Carlton Gibson
 wrote:
> Hi Paolo,
> Thank you for this! Absolutely super that you’ve taken this on.
> I’ve noted your PRs and they’re on my list to look at, hopefully next week.
> (Others please do too! )

Thanks Carlton,

I've aligned both my PRs with the master branch and updated a bit
after reading some comments from Adam.

Feedback and comments from everyone are welcome to the issue
https://github.com/django/djangoproject.com/issues/1031

Have a good weekends,
Paolo

-- 
Paolo Melchiorre

https://www.paulox.net

-- 
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 django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAKFO%2Bx7FGK5%3Dr%2BB12wLA5pJYx26R-bGyt4sP%3DOBZD41SzJsgmg%40mail.gmail.com.

Updating the documentation search

[Paolo Melchiorre]

Hi all,

Working at my latest talk on full-text search I found out all the
great search-related improvements in latest versions of PostgreSQL and
Django

After my presentations I've also collected a lot of feedback and
suggestions to improve the search function in the djangoproject.com
website from Django users and developers.

I think that can be useful for everyone to improve the search function
in the djangoproject.com website using the latest version of
PostgreSQL and Django.

Here's an outline of improvements I would add to the documentation search:
- Upgrade PostgreSQL from 10 to 12 (to add websearch and more languages)
- Upgrade Django from 2.2 to 3.1 (to add support for websearch query
and highlighted search)
- Add websearch type for search query (to permit control on user search)
- Add highlighted search results (to have better results)
- Improve the UX/UI in the search results page (to help choosing the
right results)

I opened the issue 1031 [1] in github with this outline in it and also
the PR 1030 [2] and PR 1032 [3] for the first 2 steps that can be
merged as is (I think) because they contain basic Django and
PostgreSQL improvements.

Adam Johnson has already reviewed the PR 1032 and I'm asking for some
other feedback and reviews on the issue and both opened PRs.

Thanks,
Paolo

[1] https://github.com/django/djangoproject.com/issues/1031
[2] https://github.com/django/djangoproject.com/pull/1030/files
[3] https://github.com/django/djangoproject.com/pull/1032/files

-- 
Paolo Melchiorre

https://www.paulox.net

-- 
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 django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAKFO%2Bx7R4hJ4GY6mwwsEeT%2Bnh6mpM6bgpHpQrjjc%3DTRcWtmSTw%40mail.gmail.com.

Critical hints about Django migrations

[Paolo Melchiorre]

HI all,

I would suggest reading this interesting article by Daniele Varrazzo
(the maintainer of psycopg2 and creator of psycopg3) on Django
migrations.

It contains some criticisms but I also think some interesting hints
for improving Django ORM :
https://www.varrazzo.com/blog/2020/07/25/surviving-django/

See you,
Paolo

-- 
Paolo Melchiorre

https://www.paulox.net

-- 
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 django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAKFO%2Bx6_1qffQt56u58fNuAv6P6_kTkV258t-3ShCQNAkRXvKQ%40mail.gmail.com.

Re: f-strings again.

[Paolo Melchiorre]

+1 to start using and suggesting f-string in new PRs

I agree to avoid bulk updated only to use f-string in old code.

I think we can write a priority list of string formatting styles to
help new and old contributors in following the same code style in all
PRs.

I will suggest this order:
1) f-string
2) %-formatting
3) format

On Tue, Jul 21, 2020 at 10:21 AM Adam Johnson  wrote:
> +1 to allowing f-strings.
> Mariusz' position dropping .format() seems reasonable to me too
> On Tue, 21 Jul 2020 at 09:00, laym...@gmail.com  wrote:
>> I personally like to use f-strings wherever it makes sense, so +1.
>> I agree with Mariusz. I think we should only allow %-formatting and 
>> f-strings from now on.
>> And yes, bulk updates should not be done. ...
>> On Tuesday, 21 July 2020 at 14:28:54 UTC+7 Mariusz Felisiak wrote:
>>> I will not stand against f-strings, I think we can allow them. My main 
>>> concerns is readability. ...
>>> I'm strongly against any bulk updates to conform to this style
>>> I would also be in favor of keeping only %-formatting and f-strings in 
>>> Coding style docs

-- 
Paolo Melchiorre

https://www.paulox.net

-- 
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 django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAKFO%2Bx6JmXnDaamf8TTE5S3XGXGWbV0MfPkKboS6ZgViN0xJRA%40mail.gmail.com.

Re: Loading lzma compressed fixtures

[Paolo Melchiorre]

On 09/05/20 12:39, Tim Graham wrote:

On Saturday, May 9, 2020 at 6:22:13 AM UTC-4, Paolo Melchiorre wrote:

Working at my latest merged PR [1] in Django I saw in the code the lack
of support for lzma compressed fixture for loaddata command so I opened
a ticket [2] and a related PR [3].
I think is a small PR to accept before Django 3.1 feature freeze but it
can be a great improvement in loading big fixtures.
I would ask someone to review my PR [3].
[1] https://github.com/django/django/pull/12871
[2] https://code.djangoproject.com/ticket/31552
[3] https://github.com/django/django/pull/12879
Hi Paolo, Please don't ask for code reviews on this mailing list. It 
just adds noise. Patches are reviewed from "Patches needing review" at 
https://dashboard.djangoproject.com/. At this time there are ~30 patches 
in the queue. Requesting your feature to be moved to the front of 
the review queue the weekend before the feature freeze isn't appropriate.


Hi Tim,

Sorry, I wasn't aware of the dashboard and I definitely didn't want to 
ask my feature to be moved to the front of the review queue.


Next time I won't ask for code reviews on this mailing list.

Thanks,
Paolo
--
https://www.paulox.net

--
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 django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/77a9f90e-d934-b23b-fe71-e3a6d421adba%40melchiorre.org.

Loading lzma compressed fixtures

[Paolo Melchiorre]

Hi all,

Working at my latest merged PR [1] in Django I saw in the code the lack 
of support for lzma compressed fixture for loaddata command so I opened 
a ticket [2] and a related PR [3].


I think is a small PR to accept before Django 3.1 feature freeze but it 
can be a great improvement in loading big fixtures.


I would ask someone to review my PR [3].

Thanks,
Paolo


[1] https://github.com/django/django/pull/12871
[2] https://code.djangoproject.com/ticket/31552
[3] https://github.com/django/django/pull/12879

--
https://www.paulox.net

--
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 django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c8893560-de46-05d2-66d9-42f11f4cb2d5%40melchiorre.org.

Re: Proposal: provide postgresql powered full-text search in djangoproject.com

[Paolo Melchiorre]

Hi all.

Thanks for your feedbacks about my propose to use PostgrSQL FTS in
djangoproject.com

After my talk about "Full-Text Search with PostgreSQL in Django" in the
EuroPython 2017 I organized a sprint to work on a new branch of
djangoproject.com as I proposed.
https://twitter.com/i/moments/886314684588208128

In the last months I've been a little busy but in the last days I found the
time to complete the work started and I create a PR with last version of
djangoproject.com and FTS working wiht PostgreSQL, my PR replace all the
feature of the Elasticsearch  FTS and you can test locally.
https://github.com/django/djangoproject.com/pull/797

Can you send me some suggestions on it thanks ?

Regards,
Paolo

P.S. I've develop the multilingual search too, but it need Django 2.0
version because of this commit
https://github.com/django/django/commit/19b2dfd1bfe7fd716dd3d8bfa5f972070d83b42f

On Sat, Jul 8, 2017 at 8:10 PM, Paolo Melchiorre 
wrote:

> I'm going to start a personal branch with a PostgreSQL full-text search
> functionality for the djangoproject.com website.
>
> I would to sprint on it during the next EuroPython 2017 in Rimini and I've
> added the Sprint proposal in the wiki:
> https://wiki.python.org/moin/EuroPython2017/Sprints
>
>
> On Mon, May 8, 2017 at 6:28 PM, Tim Graham  wrote:
>
>> I agree that eliminating elasticsearch could be a simplification win from
>> a maintenance perspective. For example, I spent some hours a few months ago
>> debugging a problem with a new version of elasticsearch that caused our
>> cluster to run out of memory and lock up every ~24 hours. Also, not having
>> to set up elasticsearch to contribute to the docs.djangoproject.com
>> search is nice. On the other hand, I wonder how moving the search load to
>> PostgreSQL will effect server load, disk usage, etc.
>>
>> On Monday, May 8, 2017 at 11:14:58 AM UTC-4, Tobias McNulty wrote:
>>>
>>> I'm no FTS expert, but based just on the facts raised in this thread, if
>>> using Postgres FTS
>>>
>>>1. would not break existing nor potential search needs (in fact it
>>>might expand the functionality available) and
>>>2. would allow eliminating an entire service from the infrastructure
>>>
>>> that seems like a net win to me and as such at least worth exploring
>>> further. That is not to say I think we should commit to switching, but if
>>> we have volunteers who are excited to flesh out this proposal with some
>>> code and understand there's no guarantee it will actually get merged, I
>>> don't (yet) see a reason to say no.
>>>
>>> On Mon, May 8, 2017 at 10:07 AM, Marc Tamlyn  wrote:
>>>
>>>> Yes, don't need that sorry.
>>>>
>>>> On 8 May 2017 at 14:40, Adam Johnson  wrote:
>>>>
>>>>>  I'm pretty sure our search requirements on dp.com need that,
>>>>>
>>>>>
>>>>> s/need/don't need/ ? 😉
>>>>>
>>>>> On 8 May 2017 at 13:59, Marc Tamlyn  wrote:
>>>>>
>>>>>> I'm not sure I see the benefit here. The strength and purpose of
>>>>>> postgres FTS is that you can combine some FTS behaviour with some
>>>>>> relational queries easily at the same time. I'm pretty sure our search
>>>>>> requirements on dp.com need that, so using a dedicated search
>>>>>> provider is a better option.
>>>>>>
>>>>>> On 7 May 2017 at 13:22, Florian Apolloner  wrote:
>>>>>>
>>>>>>> On Sunday, May 7, 2017 at 12:45:27 PM UTC+2, Adam Johnson wrote:
>>>>>>>>
>>>>>>>> I guess we'd also have the benefit of not having to keep
>>>>>>>> elasticsearch running.
>>>>>>>>
>>>>>>>
>>>>>>> On the contrary, putting it into postgres means we have to care
>>>>>>> about it. Putting it into Elasticsearch means we can let our hoster take
>>>>>>> care about that.
>>>>>>>
>>>>>>>
>>>>>>>> But I'm afraid I'm not familiar with Postgres. Is the FTS in
>>>>>>>> Postgres mostly equivalent to ES, or will some kinds of search queries 
>>>>>>>> be
>>>>>>>> affected?
>>>>>>>>
>>>>>>>
>>>>>>> For the queries we use I think we can get pretty much equivalent
>>>>>>> results.
>>>>>>>
>>>>>>

-- 
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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAKFO%2Bx7tjsSZ-Gf2rzdU_KHotOYnAUOWNHOFTgwvibpC_RtABw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal: provide postgresql powered full-text search in djangoproject.com

[Paolo Melchiorre]

Hi all,

I'm going to start a personal branch with a PostgreSQL full-text search
functionality for the djangoproject.com website.

I would to sprint on it during the next EuroPython 2017 in Rimini and I've
added the Sprint proposal in the wiki:
https://wiki.python.org/moin/EuroPython2017/Sprints

I'll be there on Saturday 15/07/0217 and if someone would to join me I
would be happy.

-- 
Paolo


On Mon, May 8, 2017 at 6:28 PM, Tim Graham  wrote:

> I agree that eliminating elasticsearch could be a simplification win from
> a maintenance perspective. For example, I spent some hours a few months ago
> debugging a problem with a new version of elasticsearch that caused our
> cluster to run out of memory and lock up every ~24 hours. Also, not having
> to set up elasticsearch to contribute to the docs.djangoproject.com
> search is nice. On the other hand, I wonder how moving the search load to
> PostgreSQL will effect server load, disk usage, etc.
>
> On Monday, May 8, 2017 at 11:14:58 AM UTC-4, Tobias McNulty wrote:
>>
>> I'm no FTS expert, but based just on the facts raised in this thread, if
>> using Postgres FTS
>>
>>1. would not break existing nor potential search needs (in fact it
>>might expand the functionality available) and
>>2. would allow eliminating an entire service from the infrastructure
>>
>> that seems like a net win to me and as such at least worth exploring
>> further. That is not to say I think we should commit to switching, but if
>> we have volunteers who are excited to flesh out this proposal with some
>> code and understand there's no guarantee it will actually get merged, I
>> don't (yet) see a reason to say no.
>>
>> On Mon, May 8, 2017 at 10:07 AM, Marc Tamlyn  wrote:
>>
>>> Yes, don't need that sorry.
>>>
>>> On 8 May 2017 at 14:40, Adam Johnson  wrote:
>>>
  I'm pretty sure our search requirements on dp.com need that,


 s/need/don't need/ ? 😉

 On 8 May 2017 at 13:59, Marc Tamlyn  wrote:

> I'm not sure I see the benefit here. The strength and purpose of
> postgres FTS is that you can combine some FTS behaviour with some
> relational queries easily at the same time. I'm pretty sure our search
> requirements on dp.com need that, so using a dedicated search
> provider is a better option.
>
> On 7 May 2017 at 13:22, Florian Apolloner  wrote:
>
>> On Sunday, May 7, 2017 at 12:45:27 PM UTC+2, Adam Johnson wrote:
>>>
>>> I guess we'd also have the benefit of not having to keep
>>> elasticsearch running.
>>>
>>
>> On the contrary, putting it into postgres means we have to care about
>> it. Putting it into Elasticsearch means we can let our hoster take care
>> about that.
>>
>>
>>> But I'm afraid I'm not familiar with Postgres. Is the FTS in
>>> Postgres mostly equivalent to ES, or will some kinds of search queries 
>>> be
>>> affected?
>>>
>>
>> For the queries we use I think we can get pretty much equivalent
>> results.
>>
>

-- 
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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAKFO%2Bx4s_G7SkH6OhLh6Ve48RptGa1RuFDN6gHGfEFrYZYKT5g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal: provide postgresql powered full-text search in djangoproject.com

[Paolo Melchiorre]

On Sun, May 7, 2017 at 9:16 AM, Florian Apolloner  wrote:
> On Sunday, May 7, 2017 at 12:50:02 AM UTC+2, Paolo Melchiorre wrote:
>>
>> Hello,
>>
>> in the djangoproject.com the search is powered by elasticsearch.
>>
>> Since the site uses postgresql as database backend I want propose to use
>> the Full-Text Search function provided by django.contrib.postgres.search
>> module.
>>
>> I presented a talk "Full-Text Search in Django with PostgreSQL" at the
>> last PyConIT 2017 Conference in Florence
>> https://twitter.com/pauloxnet/status/850766131338117120
>> and I proposed a similar talk for the next EuroPython 2017
>> https://ep2017.europython.eu/conference/voting/#ord128
>>
>> If you're interested in this proposal it will be nice to organize a
>> related sprints at the next EuroPython 2017
>> https://ep2017.europython.eu/en/events/sprints
>
> What would be the benefit of using django.contrib.postgresql aside from much
> work?

The benefit would be to have a djangoproject.com made with
technologies the site talks about and to demonstrate what you can
build using only officially documented Django module.

For the work to do this I can candidate myself to work on it!

-- 
Paolo

-- 
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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAKFO%2Bx59T7ykkk9WT%3DoAyvG9xX-vxp4gSN0gLRAmSmz%2Byo1bqQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Proposal: provide postgresql powered full-text search in djangoproject.com

[Paolo Melchiorre]

Hello,

in the djangoproject.com the search is powered by elasticsearch.

Since the site uses postgresql as database backend I want propose to use 
the Full-Text Search function provided by django.contrib.postgres.search 
module.

I presented a talk "Full-Text Search in Django with PostgreSQL" at the last 
PyConIT 2017 Conference in Florence
https://twitter.com/pauloxnet/status/850766131338117120
and I proposed a similar talk for the next EuroPython 2017 
https://ep2017.europython.eu/conference/voting/#ord128

If you're interested in this proposal it will be nice to organize a related 
sprints at the next EuroPython 2017
https://ep2017.europython.eu/en/events/sprints

-- 
Paolo

-- 
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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/2d438f69-cf1c-441e-908e-afc52cf339a4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.