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

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 --

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

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:

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

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 >> >

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

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

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

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. > >

[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

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

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

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

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

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__``

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

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__

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

[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

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

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__

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