Great Idea, I have joined the mailing list to write the same idea.
As I can't find the great difference between Final and Constant, So, I will use
the name Final.
I suggest one the following syntax:
from collection import Final
》x = Final(100)
》print(x)
》100
》y = x*2
》Print(Y)
》200
》print (
Hi all, I came across the following performance issue with the sum function
while summing lists: https://bugs.python.org/issue18305 It's been discussed
previously in this list and other issues.
The rationale in that ticket makes the case that performance won't be fixed
because sum() should not be
This seems sensible to me. I remember Guido vetoing allowing
random.choice() to accept a set, and for the same reason - it encourages
inefficient code.
Rob Cliffe
On 16/06/2021 15:50, Oliver Margetts wrote:
Hi all, I came across the following performance issue with the sum
function while summ
On Wed, Jun 16, 2021 at 02:50:06PM +, Oliver Margetts wrote:
> Hi all, I came across the following performance issue with the sum function
> while summing lists: https://bugs.python.org/issue18305 It's been discussed
> previously in this list and other issues.
Did you actually use sum to conc
>
> The performance error for strings should be considered an anomaly, not a
> feature to be extended to anything that could be used, or misused, with
> non-linear behaviour.
I’m pretty sure that using sum with strings was a real issue in real code
before it was disallowed.
But the irony is tha
On Thu, Jun 17, 2021 at 9:04 AM Christopher Barker wrote:
>
> >
>>
>> The performance error for strings should be considered an anomaly, not a
>> feature to be extended to anything that could be used, or misused, with
>> non-linear behaviour.
>
>
> I’m pretty sure that using sum with strings was a
I came across this just processing JSON data - flattening a list of 'deals'
into a list of individual 'trades'. Flattening nested lists is not
uncommon. And yes sum seemed the natural way to do it at the time.
Yes, you're right some people might find it convenient and use it in the
REPL. It just s
> I'm not sure why it doesn't special-case it to "".join()
One reason might be because you'd have to read the entire iterator to know
if it really was only strings. So there are concerns with generators which
complicate things a fair bit
On Thu, 17 Jun 2021, 12:12 am Chris Angelico, wrote:
> On
On Thu, Jun 17, 2021 at 9:46 AM Oliver Margetts
wrote:
>
> > I'm not sure why it doesn't special-case it to "".join()
> One reason might be because you'd have to read the entire iterator to know if
> it really was only strings. So there are concerns with generators which
> complicate things a fa
On 2021-06-17 00:57, Chris Angelico wrote:
On Thu, Jun 17, 2021 at 9:46 AM Oliver Margetts
wrote:
> I'm not sure why it doesn't special-case it to "".join()
One reason might be because you'd have to read the entire iterator to know if
it really was only strings. So there are concerns with gen
On Wed, Jun 16, 2021 at 7:35 PM Oliver Margetts
wrote:
> I came across this just processing JSON data - flattening a list of
> 'deals' into a list of individual 'trades'. Flattening nested lists is not
> uncommon. And yes sum seemed the natural way to do it at the time.
>
I remember the discussi
On Wed, Jun 16, 2021 at 8:04 PM David Mertz wrote:
> Flattening nested lists is not uncommon. And yes sum seemed the natural
>> way to do it at the time.
>>
>
> I remember the discussion in 2013 about the quadratic performance of
> summing strings. There were proposals for optimization of the s
On Thu, Jun 17, 2021, 1:14 AM Christopher Barker
> I'm sympathetic to raising an exception on `sum(list_of_lists)` similar to
>> `sum(list_of_strings)`. But what exactly is the recommended substitute?
>> We have this:
>>
>> list(chain.from_iterable(list_of_lists))
>>
>
> If you read the BPO the O
On Thu, Jun 17, 2021 at 3:27 PM David Mertz wrote:
>
> On Thu, Jun 17, 2021, 1:14 AM Christopher Barker
>>>
>>> I'm sympathetic to raising an exception on `sum(list_of_lists)` similar to
>>> `sum(list_of_strings)`. But what exactly is the recommended substitute?
>>> We have this:
>>>
>>> list(
On Thu, Jun 17, 2021, 1:38 AM Chris Angelico
> >>> list(chain.from_iterable(list_of_lists))
>
> > More-itertools has flatten():
> https://more-itertools.readthedocs.io/en/stable/api.html#more_itertools.flatten.
> That seems better than a method specific to lists.
>
> ... which is built on top of c
Just trolling along, flattening a list could be written as
functools.reduce(list.__iadd__, xs, [])
Right?
On Wed, Jun 16, 2021 at 22:53 David Mertz wrote:
> On Thu, Jun 17, 2021, 1:38 AM Chris Angelico
>
>> >>> list(chain.from_iterable(list_of_lists))
>>
>> > More-itertools has flatten():
>> h
Still an import for that version!
On Thu, Jun 17, 2021, 2:07 AM Guido van Rossum wrote:
> Just trolling along, flattening a list could be written as
>
> functools.reduce(list.__iadd__, xs, [])
>
> Right?
>
> On Wed, Jun 16, 2021 at 22:53 David Mertz wrote:
>
>> On Thu, Jun 17, 2021, 1:38 AM Chr
On Thu, Jun 17, 2021 at 4:07 PM Guido van Rossum wrote:
>
> Just trolling along, flattening a list could be written as
>
> functools.reduce(list.__iadd__, xs, [])
>
> Right?
>
Insufficiently trolly - lacks walrus operator. :)
>>> l = [[1,2],[3,4],[5,6],[7,8],[9]]
>>> any(map((x:=[]).extend, l))
18 matches
Mail list logo
