Re: [Python-Dev] PEP 575: Unifying function/method classes

2018-04-15 Thread Jeroen Demeyer 

On 2018-04-14 23:14, Guido van Rossum wrote:

That actually sounds like a pretty big problem. I'm sure there is lots
of code that doesn't *just* duck-type nor calls inspect but uses
isinstance() to decide how to extract the desired information.


In the CPython standard library, the *only* fixes that are needed 
because of this are in:


- inspect (obviously)
- doctest (to figure out the __module__ of an arbitrary object)
- multiprocessing.reduction (something to do with pickling)
- xml.etree.ElementTree (to determine whether a certain method was 
overridden)

- GDB support

I've been told that there might also be a problem with 
Random._randbelow, even though it doesn't cause test failures.


The fact that there is so little breakage in the standard library makes 
me confident that the problem is not so bad. And in the cases where it 
does break, it's usually pretty easy to fix.


Finally: changing the classes of certain objects is exactly the point of 
this PEP, so it's impossible to achieve 100% backwards compatibility.



Jeroen.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 575: Unifying function/method classes

2018-04-15 Thread Nick Coghlan 
On 15 April 2018 at 22:50, Jeroen Demeyer  wrote:
> On 2018-04-14 23:14, Guido van Rossum wrote:
>>
>> That actually sounds like a pretty big problem. I'm sure there is lots
>> of code that doesn't *just* duck-type nor calls inspect but uses
>> isinstance() to decide how to extract the desired information.
>
> In the CPython standard library, the *only* fixes that are needed because of
> this are in:
>
> - inspect (obviously)
> - doctest (to figure out the __module__ of an arbitrary object)
> - multiprocessing.reduction (something to do with pickling)
> - xml.etree.ElementTree (to determine whether a certain method was
> overridden)
> - GDB support
>
> I've been told that there might also be a problem with Random._randbelow,
> even though it doesn't cause test failures.

>From Raymond's description (and from an initial reading of the code),
the _randbelow case seems like it may be a latent defect anyway, as it
wouldn't detect cases where the replacement implementation came from
an extension module (e.g. if someone used Cython to compile a module
that subclassed Random and overrode either Random.random or
Random.getrandbits). ("Builtin" is unfortunately a bit of a misnomer
in the existing type names, since extension modules also create
instances of those types)

In a post-PEP-575 world, I believe those checks could be replaced with
the more robust "if random.__func__ is __class__.random or
getrandbits.__func__ is not __class__.getrandbits:" (since unbound
methods go away even for builtin functions, it becomes easier to check
method identity against a baseline implementation).

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 575: Unifying function/method classes

2018-04-15 Thread Serhiy Storchaka 

15.04.18 16:09, Nick Coghlan пише:

On 15 April 2018 at 22:50, Jeroen Demeyer  wrote:

I've been told that there might also be a problem with Random._randbelow,
even though it doesn't cause test failures.


 From Raymond's description (and from an initial reading of the code),
the _randbelow case seems like it may be a latent defect anyway, as it
wouldn't detect cases where the replacement implementation came from
an extension module (e.g. if someone used Cython to compile a module
that subclassed Random and overrode either Random.random or
Random.getrandbits). ("Builtin" is unfortunately a bit of a misnomer
in the existing type names, since extension modules also create
instances of those types)

In a post-PEP-575 world, I believe those checks could be replaced with
the more robust "if random.__func__ is __class__.random or
getrandbits.__func__ is not __class__.getrandbits:" (since unbound
methods go away even for builtin functions, it becomes easier to check
method identity against a baseline implementation).


See https://bugs.python.org/issue33144.

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

[Python-Dev] Translating sample programs in documentation

2018-04-15 Thread Xuan Wu 
Excuse me if this was discussed before, but in French and Japanese 
translations, all the sample programs seem to have identifiers in 
English still. According to "PEP 545 -- Python Documentation 
Translations", as I understand .po files are used for translations. May 
I ask if there's technical restrictions causing translations being only 
applied to the text parts?


For example, here's the first sample program in 4.2:


# Measure some strings:

... words  =  ['cat',  'window',  'defenestrate']

for  w  in  words:

...  print(w,  len(w))
...
cat 3
window 6
defenestrate 12

Here's a possible translation in Chinese:


# 丈量一些字符串

... 词表 = ['猫', '窗户', '丢出窗户']

for 词 in 词表:

... print(词, len(词))
...
猫 1
窗户 2
丢出窗户 4

As you may notice the strings differ in size if they are translated 
directly. Obviously that does add extra burden to review the new sample 
programs to assure effectiveness and readability.

Any suggestion or comments are welcome.


Thanks,
Xuan.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 575: Unifying function/method classes

2018-04-15 Thread Raymond Hettinger 


> On Apr 15, 2018, at 5:50 AM, Jeroen Demeyer  wrote:
> 
> On 2018-04-14 23:14, Guido van Rossum wrote:
>> That actually sounds like a pretty big problem. I'm sure there is lots
>> of code that doesn't *just* duck-type nor calls inspect but uses
>> isinstance() to decide how to extract the desired information.
> 
> In the CPython standard library, the *only* fixes that are needed because of 
> this are in:
> 
> - inspect (obviously)
> - doctest (to figure out the __module__ of an arbitrary object)
> - multiprocessing.reduction (something to do with pickling)
> - xml.etree.ElementTree (to determine whether a certain method was overridden)
> - GDB support
> 
> I've been told that there might also be a problem with Random._randbelow, 
> even though it doesn't cause test failures.

Don't worry about Random._randbelow, we're already working on it and it is an 
easy fix.  Instead, focus on Guido's comment. 

> The fact that there is so little breakage in the standard library makes 
> me confident that the problem is not so bad. And in the cases where it 
> does break, it's usually pretty easy to fix.

I don't think that confidence is warranted.  The world of Python is very large. 
 When public APIs (such as that in the venerable types module) get changed, is 
virtually assured that some code will break.


Raymond
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Translating sample programs in documentation

2018-04-15 Thread Shell Xu 
Well, I'm not sure weather or not this is what you're looking for, but
pep-8 (https://www.python.org/dev/peps/pep-0008/) suggest like this:

For Python 3.0 and beyond, the following policy is prescribed for the
standard library (see PEP 3131): All identifiers in the Python standard
library MUST use ASCII-only identifiers, and SHOULD use English words
wherever feasible (in many cases, abbreviations and technical terms are
used which aren't English). In addition, string literals and comments must
also be in ASCII. The only exceptions are (a) test cases testing the
non-ASCII features, and (b) names of authors. Authors whose names are not
based on the Latin alphabet (latin-1, ISO/IEC 8859-1 character set) MUST
provide a transliteration of their names in this character set.

So, I guess translate symbols to Chinese are not gonna help reader to
figure out what kind of code should they writing...

On Mon, Apr 16, 2018 at 12:41 AM, Xuan Wu <
[email protected]> wrote:

> Excuse me if this was discussed before, but in French and Japanese
> translations, all the sample programs seem to have identifiers in English
> still. According to "PEP 545 -- Python Documentation Translations", as I
> understand .po files are used for translations. May I ask if there's
> technical restrictions causing translations being only applied to the text
> parts?
>
> For example, here's the first sample program in 4.2:
>
> >>> # Measure some strings:... words = ['cat', 'window', 'defenestrate']>>> 
> >>> for w in words:... print(w, len(w))...cat 3window 6defenestrate 12
>
> Here's a possible translation in Chinese:
>
> >>> # 丈量一些字符串
> ... 词表 = ['猫', '窗户', '丢出窗户']
> >>> for 词 in 词表:
> ... print(词, len(词))
> ...
> 猫 1
> 窗户 2
> 丢出窗户 4
>
> As you may notice the strings differ in size if they are translated
> directly. Obviously that does add extra burden to review the new sample
> programs to assure effectiveness and readability.
> Any suggestion or comments are welcome.
>
>
> Thanks,
> Xuan.
>
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> shell909090%40gmail.com
>
>


-- 
彼節者有間，而刀刃者無厚；以無厚入有間，恢恢乎其於游刃必有餘地矣。
blog: http://shell909090.org/
twitter: @shell909090 
about.me: http://about.me/shell909090
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com