A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2009-April/088446.html below:

[Python-Dev] pyc files, constant folding and borderline portability issues

[Python-Dev] pyc files, constant folding and borderline portability issues [Python-Dev] pyc files, constant folding and borderline portability issuesJared Grubb jared.grubb at gmail.com
Tue Apr 7 21:55:10 CEST 2009
On 7 Apr 2009, at 11:59, Alexandru Moșoi wrote:
> Not necessarily. For example C/C++ doesn't define the order of the
> operations inside an expression (and AFAIK neither Python) and
> therefore folding 2 * 3 is OK whether b is an integer or an arbitrary
> object with mul operator overloaded. Moreover one would expect * to be
> associative and commutative (take a look at Python strings); if a * 2
> * 3 returns a different result from a * 6 I will find it very
> surprising and probably reject such code.

That's not true. All ops in C/C++ have associativity that is fixed and  
well-defined; the star op is left-associative:
2*3*x is (2*3)*x is 6*x
x*2*3 is (x*2)*3, and this is NOT x*6 (You can show this in C++ by  
creating a class that has a side-effect in its * operator).

The star operator is not commutative in Python or C/C++ (otherwise  
what would __rmul__ do?). It's easier to see that + is not  
commutative: "abc"+"def" and "def"+"abc" are definitely different!

You may be confusing the "order is undefined" for the evaluation of  
parameter lists in C/C++. Example: foo(f(),g()) calls f and g in an  
undefined order.

Jared
More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4