[Python-Dev] Re: **= does not follow the data model

[Bernardo Sulzbach]

I am also for #2, as I don't think there is any concrete reason for making
**= special.

On Sun, Aug 23, 2020 at 5:05 PM Brett Cannon  wrote:

> If you read the language reference for augmented arithmetic assignment,
> you will note that it essentially says, "call __i__, and if that
> doesn't work call as if you were doing a  b". Unfortunately it appears
> **= does not follow the rule of falling back on the binary arithmetic
> expression semantics. I have a GitHub gist with demonstration code that
> shows this happening in both 3.8 and master (
> https://gist.github.com/brettcannon/fec4152857e0ed551b4da515dc63e580).
> This was reported in https://bugs.python.org/issue38302, although
> initially it didn't cover __pow__, only __rpow__ being skipped.
>
> This appears to happen because the opcode  for **= calls
> PyNumber_InPlacePower() (
> https://github.com/python/cpython/blob/802726acf6048338394a6a4750835c2cdd6a947b/Objects/abstract.c#L1159)
> which calls ternary_op for __ipow__ or __pow__ depending on which is
> defined, but will never try both (
> https://github.com/python/cpython/blob/802726acf6048338394a6a4750835c2cdd6a947b/Objects/abstract.c#L849).
> All of the other augmented arithmetic assignment operators have a special
> binary_iop() function to call which takes care of the fallback logic, so no
> other augmented arithmetic assignments appear to have this problem (I
> tested them all regardless).
>
> I think there are two options to fixing this:
>
> 1. Add a note to the data model that **= is special and does not fall back
> (obviously the most backwards-compatible)
> 2. Fix **= (which makes sense from a language consistency perspective)
>
> Personally, my vote is for #2 as I don't want to have to remember that **=
> is somehow special compared to all other augmented assignments. I also
> don't think the backwards-compatibility risk is at all large since the
> semantics of turning `a **= b` into `a = a ** b` shouldn't really be
> different.
>
> P.S. Why are some of the PyNumber_InPlace*() functions handwritten while
> others are defined using a macro which mirrors the handwritten ones? Just
> something I noticed while investigating this.
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/MJTHPFSHGH7RIEKXQKYUBHCZBW3T3JTR/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/XVYXZ5UGJWKHX632PHQ6TRLPEKSXW2YK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Comparing UUID objects to strings: why not?

[Bernardo Sulzbach]

I think that if the other object is a string, trying to get a UUID
from it to compare UUIDs makes more sense than converting the UUID to
string and comparing strings. Several different strings are perfectly
fine for uniquely identifying the same UUID, so you seem to have
gotten this bit backward, as Tal Einat pointed out.

However, I strongly oppose automatic conversions, and, by proxy, this idea.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/AHACOVSPOVRJ257P2XSPPDA7I6AKE5IJ/
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-Dev] Optimizing list.sort() by checking type in advance

[Bernardo Sulzbach]

On 10/10/2016 03:18 AM, Elliot Gorokhovsky wrote:

Hi,

I posted here a while back asking what you guys thought about
implementing radix sort for strings in list.sort(). You gave me a lot of
reasons why that would be a bad idea. However, it got me thinking, and I
came up with something that you may find interesting.

First, some simple benchmark results (numbers are seconds, check out the
extension module at https://github.com/embg/python-fast-listsort.git):

*** 1e3 ints ***
F.fastsort(): 0.00018930435180664062
F.sort(): 0.0002830028533935547
*** 1e3 strings ***
F.fastsort(): 0.0003533363342285156
F.sort(): 0.00044846534729003906
*** 1e7 ints ***
F.fastsort(): 5.479267358779907
F.sort(): 8.063318014144897
*** 1e7 strings ***
F.fastsort(): 9.992833137512207
F.sort(): 13.730914115905762



The numbers are good. How does this interfere with sorting very small 
lists? Obviously, even if it does not help with very small lists, we can 
always put a threshold on the size and take this path or not.


--
Bernardo Sulzbach
http://www.mafagafogigante.org/
mafagafogiga...@mafagafogigante.org
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Adding NewType() to PEP 484

[Bernardo Sulzbach]

On 06/01/2016 09:44 PM, Guido van Rossum wrote:

Everyone on the mypy team has a different opinion so the search is on. :-(

On Wed, Jun 1, 2016 at 5:37 PM, Hai Nguyen  wrote:

I am +1 for DistinctType (vs others) (no specific reason, just read out
loud).



At least on this thread it seems like (I haven't counted) that distinct 
type [alias] is the preferred option.

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Adding NewType() to PEP 484

[Bernardo Sulzbach]

On 05/31/2016 08:58 PM, Nick Coghlan wrote:

On 31 May 2016 3:12 pm, "Glenn Linderman"  wrote:


On 5/31/2016 12:55 PM, rndblnch wrote:


Guido van Rossum  gmail.com> writes:



Also -- the most important thing.  What to call these things? We're
pretty much settled on the semantics and how to create them (A =
NewType('A', int)) but what should we call types like A when we're
talking about them? "New types" sounds awkward.


back in high school, i was introduced to c programming with the

"disciplined

C" preprocessor [0].
it made the distinction between information type and representation type
(e.g. between the semantic and the implementation).
those new types where created using typedefs and were named 'parallel

types'

below is the relevant part of the dcc presentation:



Interesting! Prior art. And parallel type isn't a bad name...


If I heard "parallel type", I'd assume it had something to do with parallel
processing.



This also happens to me every time I read it.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python parser performance optimizations

[Bernardo Sulzbach]

On 05/29/2016 10:53 PM, Steven D'Aprano wrote:

On Thu, May 26, 2016 at 10:19:05AM +, Artyom Skrobov wrote:
[...]

The motivation for this patch was to enable a memory footprint
optimization, discussed at http://bugs.python.org/issue26415 My
proposed optimization reduces the memory footprint by up to 30% on the
standard benchmarks, and by 200% on a degenerate case which sparked
the discussion. The run time stays unaffected by this optimization.


That can't be right. How can you reduce memory usage by more than one
hundred percent? That would mean you have saved more memory than was
originally used and are now using a negative amount of memory.



It is not. It would be nice to have the values that were used to 
calculate these percentages.

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Adding NewType() to PEP 484

[Bernardo Sulzbach]

On 05/28/2016 12:19 PM, Steve Dower wrote:

Did anyone suggest "distinct type alias"?



I would just like to mention that "distinguished" seems to be more often 
associated with notability and excellence than "distinct", which is 
usually more neutral towards the quality of what it describes.


Unless we want to say that these types are nobler than their 
counterparts, "distinguished" seems worse than "distinct".


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] New hash algorithms: SHA3, SHAKE, BLAKE2, truncated SHA512

[Bernardo Sulzbach]

On 05/27/2016 07:52 PM, Nathaniel Smith wrote:

If we demote them to second-class support (by making them only

> available in some builds, or using a slow pure Python implementation),
> then we'll be encouraging users to use inferior hashes. We shouldn't
> do this without a very good reason.

I agree. And I really think we shouldn't even ship pure Python 
implementations of these hashing algorithms. I am fairly confident that 
these algorithms would be prohibitively slow if written in pure Python.

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] New hash algorithms: SHA3, SHAKE, BLAKE2, truncated SHA512

[Bernardo Sulzbach]

On 05/27/2016 11:31 AM, Daniel Holth wrote:
>

BLAKE2 is important, since it removes the last objection to replacing MD5 -
speed - that has made it hard for cryptography fans to convince MD5 users
to upgrade.



I have had to stick to MD5 for performance reasons (2 seconds in MD5 or 
9.6 seconds in SHA256, IIRC) in scenarios that did not require an SHA*. 
Having BLAKE2 around wouldn't be a necessity, but if it shipped with 
newer versions of Python eventually there would be a commit switching 
the underlying hash function.

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] runtime dlls on Windows

[Bernardo Sulzbach]

On 05/25/2016 04:37 PM, Ryan Gonzalez wrote:

Wouldn't downloading the Microsoft C++ Runtime 2015 also work? Many recent
computers already have it pre-installed.


Even though the download seems to be only 14 MB (I don't have a Windows 
machine, so I cannot assure that just the file on MS website is enough), 
it is an inconvenience. Additionally, I don't know how clear it will be 
for the average Python user on Windows that a C++ runtime is missing.

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Why does PEP 7/8 explicitly suggest 2 spaces after a period?

[Bernardo Sulzbach]

On 05/20/2016 09:27 AM, Brett Cannon wrote:

The period is a full-stop punctuation mark, but visually obscure [1].


It is small. This does not make it hard to notice, however. Not to 
mention that it will usually be followed by a capitalized letter, which 
further highlights it. Commas usually use more pixels or ink and the 
tiny size of the period makes it quite distinguishable to me.


This email-based "tennis" match could go on for quite a while as Guido 
pointed out and there are several good points for both sides. This is 
not a critic to the thread, which regarded PEP 7/8 and seems perfectly 
fine. This is also not a critic to Cannon's view on this.


Who is right in the end? ~One space defenders~ Nobody. There is no 
single right solution to this. As there is no single right decision 
regarding tabs or spaces~, except for spaces, always use spaces~. 
Consistency is what really matters (assuming we agree that one space is 
enough to make it visible).

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Why does PEP 7/8 explicitly suggest 2 spaces after a period?

[Bernardo Sulzbach]

On 05/20/2016 01:27 PM, Brett Cannon wrote:

Is there a specific reason for calling out two spaces in comments after a
period(I realize it's probably for consistency, but I sure don't ever think
about this when I write comment)? Otherwise who actually still writes using
two spaces after punctuation? :)



I've also asked myself this question. It may have made more sense back 
then, but nowadays I only get double spaces after a period if Ms. Vim 
decides to use them there for me, making me do substitution magic to 
"clean" it later on.


There may even be a way to disable this in Vim (without changing the 
sources and recompiling), but I never looked after it.


For modern monospaced typefaces and screen resolutions one space after a 
period is as readable (arguably even better looking) than two.

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com