Re: [Python-Dev] Subtle difference between f-strings and str.format()

2018-03-31 Thread Stefan Behnel
Serhiy Storchaka schrieb am 28.03.2018 um 17:27:
> There is a subtle semantic difference between str.format() and "equivalent"
> f-string.
> 
>     '{}{}'.format(a, b)
>     f'{a}{b}'
> 
> In the former case b is evaluated before formatting a. This is equivalent to
> 
>     t1 = a
>     t2 = b
>     t3 = format(t1)
>     t4 = format(t2)
>     r = t3 + t4
> 
> In the latter case a is formatted before evaluating b. This is equivalent to
> 
>     t1 = a
>     t2 = format(t1)
>     t3 = b
>     t4 = format(t3)
>     r = t2 + t4
> 
> In most cases this doesn't matter, but when implement the optimization that
> transforms the former expression to the the latter one ([1], [2]) we have
> to make a decision what to do with this difference.
> 
> [1] https://bugs.python.org/issue28307
> [2] https://bugs.python.org/issue28308

Just for the record, I implemented the translation-time transformation
described in [1] (i.e. '%' string formatting with a tuple) in Cython 0.28
(released mid of March, see [3]), and it has the same problem of changing
the behaviour. I was aware of this at the time I implemented it, but
decided to postpone the fix of evaluating the arguments before formatting
them, as I considered it low priority compared to the faster execution. I
expect failures during formatting to be rare in real-world code, where
string building tends to be at the end of a processing step that should
catch many value problems already. Rare, but not impossible.

I do consider this change in behaviour a bug that should be fixed, and I
would also consider it a bug in CPython if it was added there.

Stefan


[3]
https://github.com/cython/cython/blob/de618c0141ae818e7a4c35d46256d98e6b6dba53/Cython/Compiler/Optimize.py#L4261

___
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] Nuking wstr [Re: How can we use 48bit pointer safely?]

2018-03-31 Thread Antoine Pitrou
On Fri, 30 Mar 2018 21:40:21 +0300
Serhiy Storchaka  wrote:

> 30.03.18 16:54, Antoine Pitrou пише:
> > We could also simply nuke wstr.  I frankly don't think it's very
> > important.  It's only used when calling system functions taking a
> > wchar_t argument, as an « optimization ».  I'd be willing to
> > guess that modern workloads aren't bottlenecked by the cost overhead of
> > those system functions...  
> 
> This is possible only after removing all Py_UNICODE related C API. It is 
> deprecated since 3.3, but only in the documentation, and should stay to 
> the EOL of 2.7. Only in 3.7 most of these functions started emitting 
> deprecation warnings at compile time (GCC-only). [1] It would be good to 
> make them emitted in other compilers too.

It should be possible with MSVC:
https://stackoverflow.com/a/295229/10194

and clang as well:
http://releases.llvm.org/3.9.1/tools/clang/docs/AttributeReference.html#deprecated-gnu-deprecated

Regards

Antoine.


___
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