Proposal to add a flatten() to django.utils

[David Sanders]

Hi folks,

As part of PR 16175 there was some discussion around flattening lists/tuples as part of the solution. I proposed that if we create a flattening function that there'd be some benefit in sharing that in django.utils for other components if needed.

I'd like to garner "approval" + any thoughts on the best way to write such a function.

• I'm aware that django.db expressions have similar-ish flatten() methods
  
• The PR author, Ion Alberdi, has done some nice work in writing up alternatives and measuring performance
• A generator based solution would be nice if it could finish walking early if used with any()
• Opinions on maintainability (readability) vs performance would be great
• Ideally I think it would be great if someone with some experience with performant Python could chime in

Cheers,

David

[Markus Holtermann]

Hi David,

I think, I'm in support for a django.utils....flatten() function with the requirements / constraints you outlined below.

Cheers,

Markus

--

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/CADyZw-5iwZPtsuw4Z%3D8nP16K%3DnP-0EAD5wZ4WaNy40L5oYuzfw%40mail.gmail.com.

[Jörg Breitbart]

+1 for that, though this will need some careful design between perf
optimizations and how much general purpose it should be.

I remember a discussion years ago, whether this should go into python
batteries. Ended up unresolved, as the optimization goals depend alot on
the provided data structures. Maybe this can be avoided in django by
focussing on most typical nested data structures.

Cheers,
Jörg


Am 17.10.22 um 11:59 schrieb Markus Holtermann:

> Hi David,
>
> I think, I'm in support for a django.utils....flatten() function with
> the requirements / constraints you outlined below.
>
> Cheers,
>
> Markus
>
> On Mon, Oct 17, 2022, at 8:31 AM, David Sanders wrote:
>> Hi folks,
>>
>> As part of PR 16175

>> <https://github.com/django/django/pull/16175> there was some

>> discussion around flattening lists/tuples as part of the solution. I
>> proposed that if we create a flattening function that there'd be some
>> benefit in sharing that in django.utils for other components if needed.
>>
>> I'd like to garner "approval" + any thoughts on the best way to write
>> such a function.
>>

>> * I'm aware that django.db expressions have similar-ish flatten()
>> methods
>> * The PR author, Ion Alberdi, has done some nice work in writing up
>> alternatives and measuring performance
>> * A generator based solution would be nice if it could finish

>> walking early if used with any()

>> * Opinions on maintainability (readability) vs performance would be
>> great
>> * Ideally I think it would be great if someone with some experience

>> with performant Python could chime in
>>
>> Cheers,
>> David
>>
>>
>> --
>> 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

>> <mailto:django-develop...@googlegroups.com>.

>> To view this discussion on the web visit

>> https://groups.google.com/d/msgid/django-developers/CADyZw-5iwZPtsuw4Z%3D8nP16K%3DnP-0EAD5wZ4WaNy40L5oYuzfw%40mail.gmail.com <https://groups.google.com/d/msgid/django-developers/CADyZw-5iwZPtsuw4Z%3D8nP16K%3DnP-0EAD5wZ4WaNy40L5oYuzfw%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-develop...@googlegroups.com

> <mailto:django-develop...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/django-developers/a16146bd-41ba-4c8d-aabf-62825a782328%40betaapp.fastmail.com <https://groups.google.com/d/msgid/django-developers/a16146bd-41ba-4c8d-aabf-62825a782328%40betaapp.fastmail.com?utm_medium=email&utm_source=footer>.

--
netzkolchose.de UG (haftungsbeschränkt)
Geschäftsführer: Jörg Breitbart
Handelsregister: HRB 504791 Amtsgericht Jena
Steuer-Nr.: 161/115/07450
USt-IdNr.: DE268234065

[David Sanders]

+1 for that, though this will need some careful design between perf

optimizations and how much general purpose it should be.

Perhaps before optimising we could start out with the basic readable version and tailor it moving forward. It's possible this could be irrelevant if it's only ever used alongside heavier operations like querying a database.

I remember a discussion years ago, whether this should go into python
batteries. Ended up unresolved, as the optimization goals depend alot on
the provided data structures. Maybe this can be avoided in django by
focussing on most typical nested data structures.

 
Interesting… that would explain its absence from itertools. It might be worth me going back through Python ML to see what was discussed.