Mailman 3 October 2018 - Python-ideas

Decide if `type.__subclasses__` is part of future Python or not
by Joy Diamond 29 Oct '18

29 Oct '18

Greetings, Currently `type.__subclasses__` is not documented at docs.python.org (and works in both python 2 & python 3). I would like to keep `.__subclasses__` and have it documented at docs.python.org. Is there a reason it is not documented? I realize the whole type system is going an overhaul, and the concept of what is "subclass" of another class is a complicated issue. See for example: https://github.com/python/typing/issues/135 which talks about the complexity of deciding subclassing. I think though, despite the overall, `types.__subclasses__` should be kept & documented. Thanks, Joy Diamond. 1. The google search: "site:docs.python.org __subclasses__" finds no instances of the word "__subclasses__" 2. As for what the function does, it returns the subclasses of a class: Consider the following program: class CryptographicActors(object): pass class Alice(CryptographicActors): pass class Bob(CryptographicActors): pass print("CryptographicActors subclases: %s" % CryptographicActors.__subclasses__()) help(CryptographicActors.__subclasses__) 3. It properly prints out: CryptographicActors subclases: [<class '__main__.Alice'>, <class '__main__.Bob'>] Showing the two subclasses (`Alice` and `Bob`) 4. The internal documentation explains "__subclasses__() -> list of immediate subclasses" To fully figure out what it did, I had to read the source code to Python -- which really is not the best way to figure out what a function does; hence the request to document it (and indicate it's future existence in python)

4 5

Pypi private repo's
by Nick Humrich 29 Oct '18

29 Oct '18

I am sure this has been discussed before, and this might not even be the best place for this discussion, but I just wanted to make sure this has been thought about. What if pypi.org supported private repos at a cost, similar to npm? This would be able to help support the cost of pypi, and hopefully make it better/more reliable, thus in turn improving the python community. If this discussion should happen somewhere else, let me know. Nick

5 5

Off-topic: can't access mail.python.org
by Mikhail V 29 Oct '18

29 Oct '18

Sorry for posting it here on the list, but I don't know the right contact for technical questions. The problem is, for 3 weeks or so the mail.python.org site is not accessible for me. What can be causing this? This means I can't manage the mail delivery, subscribe or unsubscribe or open any mail archive page. I have no idea what is it. I've sent this question to Ethan Furman few days ago because I thought he is the moderator, but there was no answer from him. Mikhail

3 3

async unittest.TestCase
by David Shawley 29 Oct '18

29 Oct '18

Hi everyone and good morning to some of you, Since asyncio and the async/await syntax are both part of Python, I think that we should extend TestCase to support it. The simplest solution that I can think of is to create unittest.AsyncTestCase sub-class with the following extensions: - create a new event loop and install it in AsyncTestCase.run - make it possible for setUp, tearDown, and test methods to be async by calling asyncio.iscoroutinefunction I wrote my own in a local test before noticing that Martin Richard had already written and published asynctest [1]. Since then I found the following projects as well: - https://github.com/kwarunek/aiounittest <https://github.com/kwarunek/aiounittest> - https://github.com/pytest-dev/pytest-asyncio <https://github.com/pytest-dev/pytest-asyncio> I think that the community as a whole would benefit from basic support in unittest for async/await test "user methods". I am personally fond of the approach of extending unittest.TestCase in asynctest [2] over some of the other approaches. Is this something that we want in our Standard Library? - dave -- [1]: https://github.com/Martiusweb/asynctest <https://github.com/Martiusweb/asynctest> [2]: https://github.com/Martiusweb/asynctest/blob/master/asynctest/case.py <https://github.com/Martiusweb/asynctest/blob/master/asynctest/case.py>

4 5

Multi Statement Lambdas
by Andreas Winschu 28 Oct '18

28 Oct '18

There was an extensive discussion about this in the past. https://www.artima.com/weblogs/viewpost.jsp?thread=147358 In the end Guido felt that his effort seems to him like building a Rube Goldberg machine. By looking at the amount of people still stumbling on this issue we definitely feel, that it is not the. Such a machine is a useful one. "Naming things" was from the beginning one the two hardest things in programming. Good naming is important for understandable code. The balance of extracted, named functions, as most of things in programming, is subjective though. The python style guide itself encourages people to use simple data transformations like `map`, `filter`, `reduce` for expressiveness. Those transformations can still be simple with 2 or 3 statements and will not require naming. Naming the transformation becomes harder, than reading the actual code. Coffeescript, which is another indent based language, handles multi statement lambdas without curly braces. *arr = []* *arr.map((x)-> * * y = x+1* * y * 2* *)* There is also an argument in this discussion, that just using curly braces for lambdas (which is easier to implement) would be pretty unpythonic. I really agree that python curly braces free block style is really helpful for readability in contrast to javascript for example. However using curly braces for lambdas in ruby is not hurting the eyes that much. Normally blocks in ruby use `do .. end` notation. Thus lambdas are clearly visible and also people try not to nest multiple levels of lamda transfromations. We strive to keep such a chain flat. *def transform arr* * .map { ... }* * .filter { ... } .reduce { ... }* In the end curly branes for lambdas is also a mathematical notation. Guido had a hard opinion on this, but i hope the python community does not. A powerful general purpose language should not limit itself to one statement in a closure. Lets add mutli-statement lambdas to python either with just curly braces or with an indent based machine.

10 23

Standardising ASGI as a PEP
by Andrew Godwin 28 Oct '18

28 Oct '18

Hi everyone, I'd like to breach the topic of standardising an asynchronous successor to WSGI - specifically, the ASGI specification I and a group of other Python web developers have been refining over the past couple of years (you can read more at https://asgi.readthedocs.io/en/latest/). I'm unsure of the best approach to take for this, given a couple of factors: - Web SIG has been basically dead for at least two years and several maintainers I know unsubscribed from it last time as things got toxic. It appears to not be a good place to start this discussion, but maybe it can be revived? - The specification as I would propose it is two or three parts - an overall interface for asynchronous servers to talk to applications and then a separate specification(s) of how to transport HTTP and WebSockets over that. Would this be multiple PEPs? I'd appreciate advice from you all on these questions as well as what you think the best way to even approach something like "let's add a WSGI successor" is. My initial approach was to go away and prove something in real-world use and across a variety of frameworks, and we seem to have got to that point, and so now I would like to start making it more official. I'm more than ready to take the specification we have and start prepping it to land into the PEP repo for further discussion, but I wanted to check in here first before jumping the gun (and besides, there's already plenty of specs, write ups, and reference code to discuss the merits of this). Andrew

3 4

Re: [Python-ideas] [Distutils] Pypi private repo's
by Nick Coghlan 28 Oct '18

28 Oct '18

On 5 April 2018 at 07:58, Jannis Gebauer <ja.geb(a)me.com> wrote: > What if there was some kind of “blessed” entity that runs these services and puts the majority of the revenue into a fund that funds development on PyPi (maybe trough the PSF)? Having a wholly owned for-profit subsidiary that provides commercial services as a revenue raising mechanism is certainly one way to approach something like this without alienating sponsors or tax authorities (although it may still alienate the vendors of now competing services). It would require a big time commitment on the PSF side to get everything set up though, as well as interest from key folks in joining what would essentially be a single-language-focused start up in an already crowded cross-language developer tools marketplace. When the PSF as a whole is still operating with only a handful of full or part time employees, it's far from clear that setting something like that up would be the most effective possible use of their time and energy. At a more basic level, that kind of arrangement technically doesn't require anyone's blessing, it could be as straightforward as downstream tooling vendors signing up as PSF sponsors and saying "please allocate our sponsorship contribution to the Packaging WG's budget so that PyPI keeps operating well and the PyPA tooling keeps improving, increasing the level of demand for our commercial Python repository management services". Historically that wouldn't have helped much, since the PSF itself has struggled with effective project management (for a variety of reasons), but one of the things I think the success of the MOSS grant has shown is the significant strides that the PSF has made in budget management in recent years, such that if funding is made available, it can and will be spent effectively. Cheers, Nick. P.S. PyPA contributors are also free agents in their own right, so folks offering Python-centric developer workflow management tools or features may decide that it's worth their while to invest more directly in smoothing out some of the rough edges that currently still exist. It's a mercenary way of looking at things, but in many cases, it is *absolutely* possible to pay for the time and attention of existing contributors, and if you can persuade them that your proposals are reasonable, they'll often have an easier time than most convincing other community contributors that it's a good way to go :) -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

3 5

Fix documentation for __instancecheck__
by Joy Diamond 27 Oct '18

27 Oct '18

Greetings, This is a request to fix the documentation for __instancecheck__. Please add the following (please rewrite better than I can -- I am not good at explaining concepts in short sentences): NOTE: As an optimization, isinstance(*object*, *classinfo*) does NOT call classinfo.__instancecheck__(instance) when type(object) == classinfo. Consider the following program: class M(type): def __instancecheck__(m, t): print('instancecheck(%s, %s)' % (m, t)) return False # LIE! Test = M('Test', ((object,)), {}) something = Test() print('Does *NOT* call __instancecheck__:') print('isinstance(something, Test): %s' % isinstance(something, Test)) print() print('Does call __instancecheck__:') print('isinstance(0, Test): %s' % isinstance(0, Test)) Under python 2, python 3, and pypy, in all cases, the first examples does *NOT* call __instancecheck__. You can see the optimization here: https://github.com/python/cpython/blob/master/Objects/abstract.c#L2397-L2405 Which reads: int PyObject_IsInstance(PyObject *inst, PyObject *cls) { _Py_IDENTIFIER(__instancecheck__); PyObject *checker; /* Quick test for an exact match */ if (Py_TYPE(inst) == (PyTypeObject *)cls) return 1; I'm fine with the optimization -- I am not suggesting to get rid of it. I just want the documentation to match the actual implementation. The following documentation needs to be fixed: https://docs.python.org/2/reference/datamodel.html https://docs.python.org/3/reference/datamodel.html https://www.python.org/dev/peps/pep-3119/ It took me half an hour to figure out why my version of __instancecheck__ was not working, as I tried to test it using the super simple code above ... One of the best things about python is how accurate and consistent the documentation is. This request is to keep these high standards. Thanks, Joy Diamond. NOTE: I'm not sure where to post this, so posting to python-ideas, in case people want to discuss getting rid of the optimization in PyObject_IsInstance ... which I am not suggesting.

4 9

PEP 543-conform TLS library
by Mathias Laurin 26 Oct '18

26 Oct '18

Hello Python ideas, I have implemented an (I believe) PEP 543-conform TLS library and released TLS support in the latest version yesterday: https://github.com/Synss/python-mbedtls/tree/0.13.0 https://pypi.org/project/python-mbedtls/0.13.0/ As far as I know, I am the first one to follow PEP 543. So one point is that the API works. However, I have a couple of questions regarding the PEP: - I do not know what to do in `TLSWrappedBuffer.do_handshake()`. The full TLS handshake requires writing to the server, reading back, etc., (ClientHello, ServerHello, KeyExchange, etc.), which cannot be accomplished in a single buffer. For now, I am doing the handshake in `TLSWrappedSocket.do_handshake()`: I set the BIO to using the socket directly, then perform the handshake on the socket thus entirely bypassing the TLSWrappedBuffer. Once this is done, I swap the BIO to using the buffer and go on encrypting and decrypting from the buffer. That is, the encrypted communication is buffered. - The PEP sometimes mentions an "input buffer" and an "output buffer", and some other times just "the buffer". I believe that both implementations are possible. That is, with two different buffers for input and output, or a single one. I have implemented it with a single circular buffer (that is a stream after all). What the PEP is expecting is nonetheless not clear to me. So, can anybody clarify these two points from the PEP? Or should I just address Cory Benfield (who does not seem very active anymore lately) and Christian Heimes directly? Cheers, Mathias

2 1

name2type mapping
by Thomas Güttler Lists 26 Oct '18

26 Oct '18

I created a first draft of the name2type mapping which was discussed here some days ago: https://github.com/guettli/python-name2type-mapping/blob/master/README.rst Feedback is welcome. Regards, Thomas Güttler -- Thomas Guettler http://www.thomas-guettler.de/ I am looking for feedback: https://github.com/guettli/programming-guidelines

4 3

Python-ideas October 2018