Re: [Python-Dev] PEP 560: bases classes / confusion

On 16 November 2017 at 04:39, Ivan Levkivskyi wrote: > Nick is exactly right here. Jim, if you want to propose alternative > wording, then we could consider it. > Jim also raised an important point that needs clarification at the spec level: given multiple entries in "orig_bases" with __mro_entr

Re: [Python-Dev] module customization

On Wed, Nov 15, 2017 at 10:14 PM, Nathaniel Smith wrote: > On Wed, Nov 15, 2017 at 4:27 PM, Ethan Furman wrote: >> The second way is fairly similar, but instead of replacing the entire >> sys.modules entry, its class is updated to be the class just created -- >> something like sys.modules['mymod'

Re: [Python-Dev] module customization

On Wed, Nov 15, 2017 at 5:49 PM, Guido van Rossum wrote: >> If not, why not, and if so, shouldn't PEP 562's __getattr__ also take a >> 'self'? > > Not really, since there's only one module (the one containing the > __getattr__ function). Plus we already have a 1-argument module-level > __getattr__

Re: [Python-Dev] module customization

On Wed, Nov 15, 2017 at 4:27 PM, Ethan Furman wrote: > The second way is fairly similar, but instead of replacing the entire > sys.modules entry, its class is updated to be the class just created -- > something like sys.modules['mymod'].__class__ = MyNewClass . > > My request: Can someone write a

Re: [Python-Dev] module customization

Ethan Furman wrote: The second way is fairly similar, but instead of replacing the entire sys.modules entry, its class is updated to be the class just created -- something like sys.modules['mymod'].__class__ = MyNewClass . If the recent suggestion to replace the global namespace dict with the

Re: [Python-Dev] Python possible vulnerabilities in concurrency

CWE (Common Weakness Enumeration) has numbers (and URLs) and a graph model, and code examples, and mitigations for bugs, vulnerabilities, faults, design flaws, weaknesses. https://cwe.mitre.org/ Research Concepts https://cwe.mitre.org/data/definitions/1000.html Development Concepts https://cwe.mi

Re: [Python-Dev] Python possible vulnerabilities in concurrency

On Wed, Nov 15, 2017 at 6:50 PM, Guido van Rossum wrote: > On Wed, Nov 15, 2017 at 6:37 PM, Armin Rigo wrote: > >> Hi, >> >> On 14 November 2017 at 14:55, Jan Claeys wrote: >> > Sounds like https://www.iso.org/standard/71094.html >> > which is updating https://www.iso.org/standard/61457.html >>

Re: [Python-Dev] Add a developer mode to Python: -X dev command line option

Hi, Since Brett and Nick like the idea and nobody complained against it, I implemented the -X dev option: https://bugs.python.org/issue32043 (Right now, it's a pull request.) I removed the -b option. Victor 2017-11-14 3:57 GMT+01:00 Nick Coghlan : > On 14 November 2017 at 02:08, Victor Stinner

Re: [Python-Dev] Python possible vulnerabilities in concurrency

On Wed, Nov 15, 2017 at 6:37 PM, Armin Rigo wrote: > Hi, > > On 14 November 2017 at 14:55, Jan Claeys wrote: > > Sounds like https://www.iso.org/standard/71094.html > > which is updating https://www.iso.org/standard/61457.html > > (which you can download from there if you search a bit; clearly e

Re: [Python-Dev] Python possible vulnerabilities in concurrency

Hi, On 14 November 2017 at 14:55, Jan Claeys wrote: > Sounds like https://www.iso.org/standard/71094.html > which is updating https://www.iso.org/standard/61457.html > (which you can download from there if you search a bit; clearly either > ISO doesn't have a UI/UX "standard" or they aren't follo

Re: [Python-Dev] module customization

On Wed, Nov 15, 2017 at 4:27 PM, Ethan Furman wrote: > So there are currently two ways to customize a module, with PEP 562 > proposing a third. > > The first method involves creating a standard class object, instantiating > it, and replacing the sys.modules entry with it. > > The second way is fa

[Python-Dev] module customization

So there are currently two ways to customize a module, with PEP 562 proposing a third. The first method involves creating a standard class object, instantiating it, and replacing the sys.modules entry with it. The second way is fairly similar, but instead of replacing the entire sys.modules en

Re: [Python-Dev] PEP 560

On 11/14/2017 3:26 PM, Ivan Levkivskyi wrote: After some discussion on python-ideas, see https://mail.python.org/pipermail/python-ideas/2017-September/047220.html, this PEP received positive comments. The updated version that takes into account the comments that appeared in the discussion so fa

Re: [Python-Dev] PEP 562

On Wed, Nov 15, 2017 at 8:02 PM, Ethan Furman wrote: > On 11/15/2017 04:55 AM, Koos Zevenhoven wrote: > >> On Tue, Nov 14, 2017 at 10:34 PM, Ivan Levkivskyi wrote: >> > > >> Rationale >>> = >>> >>> [...] It would be convenient to simplify this >>> procedure by recognizing ``__getattr__``

Re: [Python-Dev] PEP 560: bases classes / confusion

On Wed, Nov 15, 2017 at 5:37 PM, Nick Coghlan wrote: > On 16 November 2017 at 00:20, Jim J. Jewett wrote: > >> I *think* the following will happen: >> >> "NewList[int]" will be evaluated, and __class_getitem__ called, so >> that the bases tuple will be (A, GenericAlias(NewList, int), B) >> >

Re: [Python-Dev] PEP 560: bases classes / confusion

Nick is exactly right here. Jim, if you want to propose alternative wording, then we could consider it. -- Ivan On 15 November 2017 at 16:37, Nick Coghlan wrote: > On 16 November 2017 at 00:20, Jim J. Jewett wrote: > >> I *think* the following will happen: >> >> "NewList[int]" will be eva

Re: [Python-Dev] PEP 562

On 11/15/2017 04:55 AM, Koos Zevenhoven wrote: On Tue, Nov 14, 2017 at 10:34 PM, Ivan Levkivskyi wrote: Rationale = [...] It would be convenient to simplify this procedure by recognizing ``__getattr__`` defined directly in a module that would act like a normal ``__getattr__`` method

Re: [Python-Dev] PEP 562

I think it's reasonable for the PEP to include some examples, consequences and best practices. I don't think it's reasonable for the PEP to also define the API and implementation of helper functions that might be added once the mechanisms are in place. Those are better developed as 3rd party packag

Re: [Python-Dev] PEP 560: bases classes / confusion

On 16 November 2017 at 00:20, Jim J. Jewett wrote: > I *think* the following will happen: > > "NewList[int]" will be evaluated, and __class_getitem__ called, so > that the bases tuple will be (A, GenericAlias(NewList, int), B) > > # (A) I *think* __mro_entries__ gets called with the full

Re: [Python-Dev] PEP 560: bases classes / confusion

For anyone confused about similar things, I expect you to be interested in my post on python-ideas from today: https://mail.python.org/pipermail/python-ideas/2017-November/047896.html ––Koos On Wed, Nov 15, 2017 at 4:20 PM, Jim J. Jewett wrote: > (1) I found the following (particularly "base

[Python-Dev] PEP 560: bases classes / confusion

(1) I found the following (particularly "bases classes") very confusing: """ If an object that is not a class object appears in the bases of a class definition, then ``__mro_entries__`` is searched on it. If found, it is called with the original tuple of bases as an argument. The result of the c

Re: [Python-Dev] PEP 562

On Tue, Nov 14, 2017 at 10:34 PM, Ivan Levkivskyi wrote: ​[..]​ > Rationale > = > > It is sometimes convenient to customize or otherwise have control over > access to module attributes. A typical example is managing deprecation > warnings. Typical workarounds are assigning ``__class__``

Re: [Python-Dev] PEP 562

15.11.17 12:53, Ivan Levkivskyi пише: On 15 November 2017 at 08:43, Serhiy Storchaka > wrote: It is worth to mention that using name as a module global will bypass __getattr__. And this is intentional, otherwise calling __getattr__ for builtins will harm a

Re: [Python-Dev] PEP 562

On 15 November 2017 at 08:43, Serhiy Storchaka wrote: > 14.11.17 22:34, Ivan Levkivskyi пише: > >> This function will be called only if ``name`` is not found in the module >> through the normal attribute lookup. >> > > It is worth to mention that using name as a module global will bypass > __geta