Mailman 3 October 2018 - Python-ideas

Dynamic getting of __doc__ of a function
by Marko Ristin-Kaufmann 08 Oct '18

08 Oct '18

Hi, I'm working on decorators that have a dynamic __doc__ property computed at runtime and not at decoration time. The decorator must return the wrapper as a function and can not return a callable object with __call__ since the "self" argument would not be properly passed through the decorator. (Making __call__ a static method drops implicitly the first argument). If __call__ could be a static method and get the arguments as-are, I could make __doc__ a property. But this is not possible, right? Assigning a class satisfying the property protocol to the function wrapper.__doc__ did not work either since the property object is returned as-is instead of invoking __get__ on it. Could someone explain a bit -- is this the desired behavior or a bug or an underspecification? Is there any way for a callable object to be used as a decorator? Thanks! Cheers Marko

4 11

Re: [Python-ideas] Simplicity of C (was why is design-by-contracts not widely)
by Hugh Fisher 07 Oct '18

07 Oct '18

> Date: Sat, 29 Sep 2018 02:45:06 +1000 > From: Steven D'Aprano <steve(a)pearwood.info> > To: python-ideas(a)python.org > Subject: Re: [Python-ideas] Why is design-by-contracts not widely > Message-ID: <20180928164506.GN19437(a)ando.pearwood.info> > Content-Type: text/plain; charset=us-ascii > > On Tue, Sep 25, 2018 at 09:59:53PM +1000, Hugh Fisher wrote: > > > C and Python (currently) are known as simple languages. > > o_O > > That's a usage of "simple" I haven't come across before. Especially in > the case of C, which is a minefield of *intentionally* underspecified > behaviour which makes it near to impossible for the developer to tell > what a piece of syntactically legal C code will actually do in practice. Oh FFS. You couldn't make the effort to read the very next sentence, let alone the next paragraph, before responding? -- cheers, Hugh Fisher

10 21

Re: [Python-ideas] PEPs: Theory of operation [was: Moving to another forum system ...]
by Jeroen Demeyer 03 Oct '18

03 Oct '18

On 2018-10-03 17:56, Wes Turner wrote: > The phrase "core developers and the BDFL" > is where some sort of alternate quorum/majority policy would need to be > specified if this is a contentious issue in practice? The whole point of the process described in PEP 8000 is to make this more precise. The only question for now (in particular for PEP 580) is whether the old BDFL-Delegate system can still work until the new governance model has been decided.

1 0

Re: [Python-ideas] Moving to another forum system where
by James Lu 03 Oct '18

03 Oct '18

> Is that really an issue here? I personally haven't seen threads where > Brett tried to stop an active discussion, but people ignored him and > kept fighting. Not personally with Brett, but I have seen multiple people try to stop the “reword or remove beautiful is better than ugly in Zen of Python.” The discussion was going in circles and evolved into attacking each other’s use of logical fallacies. Other than that, my biggest issues with the current mailing system are: * There’s no way to keep a updated proposal of your own- if you decide to change your proposal, you have to communicate the change. Then, if you want to find the authoritative current copy, since you might’ve forgotten or you want to join he current discussion, then you have to dig through the emails and recursively apply the proposed change. It’s just easier if people can have one proposal they can edit themselves. * I’ve seen experienced people get confused about what was the current proposal because they were replying to older emails or they didn’t see the email with the clear examples. * The mailing list is frankly obscure. Python community leaders and package maintainers often are not aware or do not participate in Python-ideas. Not many people know how to use or navigate a mailing list. * No one really promotes the mailing list, you have to go out of your way to find where new features are proposed. * Higher discoverability means more people can participate, providing their own use cases or voting (I mean using like or dislike measures, consensus should still be how things are approved) go out of their way to find so they can propose something. Instead, I envision a forum where people can read and give their 2 cents about what features they might like to see or might not want to see. * More people means instead of having to make decisions from sometimes subjective personal experience, we can make decisions with confidence in what other Python devs want. Since potential proposers will find it easier to navigate a GUI forum, they can read previous discussions to understand the reasoning, precedent behind rejected and successful features. People proposing things that have already been rejected before can be directed to open a subtopic on the older discussion. > On Sep 18, 2018, at 3:19 PM, python-ideas-request(a)python.org wrote: > > Is that really an issue here? I personally haven't seen threads where > Brett tried to stop an active discussion, but people ignored him and > kept fighting.

19 44

Transpiling contracts
by Marko Ristin-Kaufmann 02 Oct '18

02 Oct '18

Hi James, Regarding the “transpile into Python” syntax with with statements: Can I > see an example of this syntax when used in pathlib? I’m a bit worried this > syntax is too long and “in the way”, unlike decorators which are before the > function body. Or do you mean that both MockP and your syntax should be > supported? > > Would > > with requiring: assert arg1 < arg2, “message” > > Be the code you type or the code that’s actually run? > That's the code you would type. Let me make a full example (I'm omitting "with contracts" since we actually don't need it). You would read/write this: def some_func(arg1: List[int])->int: with requiring: assert len(arg1) > 3, "some description" with oldie as O, resultie as result, ensuring: if SLOW: O.var1 = sum(arg1) assert result > sum(arg1) > O.var1 assert len(result) > 5 This would run: @requires(lambda P: len(P.arg1) > 3, "some description") @snapshot(lambda P, var1: sum(P.arg1), enabled=SLOW) @ensures(lambda O, P, result: result > sum(arg1) > O.var1, enabled=SLOW) @ensures(lambda result: len(result) > 5) I omitted in the example how to specify a custom exception to avoid confusion. If we decide that transpiler is the way to go, I'd say it's easier to just stick with lambdas and allow no mock-based approach in transpilation. Cheers, Marko >

4 5

Maintaining civility - the core of the Python community
by VanL 02 Oct '18

02 Oct '18

Hello everyone, You all have probably noted that there have been some contentious threads recently, ultimately ending in a few people being given a time-out from posting on these lists. I don't normally get into things on this list, but it has been generally discouraging to see a bunch of generally nice and reasonable people get sidetracked into unproductive, sarcastic, and unhelpful remarks. There are some efforts underway to formalize what is in and out of bounds - but I would suggest that we are losing our way when we need to get to explicit lists of things not to do. Unfortunately, we are getting there. I would like to reemphasize that we are bound together by the things that we share. We love working on Python. We love being in the community and seeing it grow. We can make our community stronger and more pleasant by choosing to emphasize the things that we have in common and by ignoring or avoiding topics that are more likely to generate unproductive discussion. We can and should also try to remember that not everyone is coming from the same place, and so we should actively assume the best of others and interpret what they say in the most charitable way possible. Think of it as Postel's law [1] as applied to people. I'd also suggest that generally, 1) use of profanity, 2) use of sexual terms and imagery, and 3) use of specifically denigrating terms to refer to a person [2][3][4] are completely out of bounds for the professional environment we want to maintain. It is ok to attack arguments, and ideas, but ad hominem arguments - those attack a person, rather than the person's argument - are also inappropriate. Use of sarcasm should be strongly moderated, as it is not correctly interpreted by many people. No reply is needed to this email. Instead, I'd prefer to see a continuation of solid technical discussion, rather than meta-discussion. Thanks, Van [1] https://en.wikipedia.org/wiki/Robustness_principle [2] https://en.wikipedia.org/wiki/List_of_ethnic_slurs [3] https://en.wikipedia.org/wiki/List_of_religious_slurs [4] https://en.wikipedia.org/wiki/List_of_disability-related_terms_with_negativ…

1 0

"while:" for the loop
by Mikhail V 02 Oct '18

02 Oct '18

I suggest allowing "while:" syntax for the infinite loop. I.e. instead of "while 1:" and "while True:" notations. IIRC, in the past this was mentioned in python-list discussions as alternative for the "while True:"/"while 1:" syntax. I even had impression that there was nothing rational against this (apart from the traditional "don't change anything" principle) My opinion: 1. I think it'd definitely improve clarity. Although it's not extremely frequent statement, it still appears in algorithms, where additional noise interfers the reader's concentration. 2. This should become the answer to the "how should I denote an infinte loop?" question. 3. In schools/unis they teach algorithms with Python syntax so it will be easier to remember and to write. Adoption of this spelling is natural and straightforward. 4. It does seem to be a rare case of a very easy to implement syntax change (an expert note needed) Also I have personal sympathy for this because I like to use explicit "break" in the loop body, even though I could use "while expression:" syntax, but I prefer this: while 1: ... if i == N : break instead of this: while i < N: ... It helps me to concentrate by reading, especially in nested loops and those situations with multiple break points. So by me this syntax would definitely achieve an extra +. There were alternative suggestions, e.g. introducing a new keyword "loop", but obviously a new keyword is much harder to do now. I don't know what to add to this actually, I think the idea is understood. I see, it is not the most important problem, but if there is nothing serious against this, I think it's worth it and would be quite a positive (small) improvement and a nice gift to those involved in algorithms. As for statistics - IIRC someone gave statistics once, but the only thing I can remember - "while 1/True" is used quite a lot in the std lib, so the numbers exceeded my expectation (because I expected that it's used mostly in algorithms). Mikhail

9 12

Renaming icontract to pcontract
by Marko Ristin-Kaufmann 02 Oct '18

02 Oct '18

Hi, I'd like to rename icontract into pcontract to avoid name conflict with java's icontract library. Do you have any better suggestion? Thanks! Marko

3 4

Suggestion: Extend integers to include iNaN
by Steve Barnes 01 Oct '18

01 Oct '18

One of the strengths of the IEEE float, (to set against its many weaknesses), is the presence of the magic value NaN. Not a Number, or NaA, is especially useful in that it is a valid value in any mathematical operation, (always returning NaN), or comparison, (always returning False). In functional programming this is especially useful as it allows the chain to complete after an error while retaining the fact that an error occurred, (as we got NaN). In languages such as C integers can only be used to represent a limited range of values in integers and a less limited range of values, (but still limited), with a limited accuracy. However, one of Pythons strengths is that its integers can represent any whole number value, (up to the maximum available memory and in exchange for slow performance when numbers get huge). This is accomplished by Python Integers being objects rather than a fixed number of bytes. I think that it should be relatively simple to extend the Python integer class to have a NaN flag, possibly by having a bit length of 0, and have it follow the same rules for the handling of floating point NaN, i.e. any mathematical operation on an iNaN returns an iNaN and any comparison with one returns False. One specific use case that springs to mind would be for Libraries such as Pandas to return iNaN for entries that are not numbers in a column that it has been told to treat as integers. We would possibly need a flag to set this behaviour, rather than raising an Exception, or at the very least automatically (or provide a method to) set LHS integers to iNaN on such an exception. I thought that I would throw this out to Python Ideas for some discussion of whether such a feature is: a) Desirable? b) Possible, (I am sure that it could be done)? c) Likely to get me kicked off of the list? -- Steve (Gadget) Barnes Any opinions in this message are my personal opinions and do not reflect those of my employer. --- This email has been checked for viruses by AVG. https://www.avg.com

14 55

Upgrade to Mailman 3
by James Lu 01 Oct '18

01 Oct '18

It has a nice GUI for people who spectate a discussion to read emails without having to subscribe to the list. http://docs.mailman3.org/en/latest/migration.html

2 1

Python-ideas October 2018