socket module: plain stuples vs named tuples
AFAIK the socket module returns plain tuples in Python3: https://docs.python.org/3/library/socket.html Why not use named tuples? Regards, Thomas Güttler -- I am looking for feedback for my personal programming guidelines: https://github.com/guettli/programming-guidelines
+1 ;-) for example to get IP address of all interfaces we have to use the third (indexed as 2) member of "something" it is much more beatiful to get ip_address: *import *socket *for *ip *in *socket.gethostbyname_ex(socket.gethostname())[2]: print(ip) BR, George 2017-06-13 22:13 GMT+02:00 Thomas Güttler <guettliml@thomas-guettler.de>:
AFAIK the socket module returns plain tuples in Python3:
https://docs.python.org/3/library/socket.html
Why not use named tuples?
Regards, Thomas Güttler
-- I am looking for feedback for my personal programming guidelines: https://github.com/guettli/programming-guidelines _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Hi, 2017-06-13 22:13 GMT+02:00 Thomas Güttler <guettliml@thomas-guettler.de>:
AFAIK the socket module returns plain tuples in Python3:
https://docs.python.org/3/library/socket.html
Why not use named tuples?
For technical reasons: the socket module is mostly implemented in the C language, and define a "named tuple" in C requires to implement a "sequence" time which requires much more code than creating a tuple. In short, create a tuple is as simple as Py_BuildValue("OO", item1, item2). Creating a "sequence" type requires something like 50 lines of code, maybe more, I don't know exactly. Victor
There are examples in timemodule.c which went through a similar conversion from plain tuples to (sort-of) named tuples. I agree that upgrading the tuples returned by the socket module to named tuples would be nice, but it's a low priority project. Maybe someone interested can create a PR? (First open an issue stating that you're interested; point to this email from me to prevent that some other core dev just closes it again.) On Mon, Jun 19, 2017 at 2:24 PM, Victor Stinner <victor.stinner@gmail.com> wrote:
Hi,
2017-06-13 22:13 GMT+02:00 Thomas Güttler <guettliml@thomas-guettler.de>:
AFAIK the socket module returns plain tuples in Python3:
https://docs.python.org/3/library/socket.html
Why not use named tuples?
For technical reasons: the socket module is mostly implemented in the C language, and define a "named tuple" in C requires to implement a "sequence" time which requires much more code than creating a tuple.
In short, create a tuple is as simple as Py_BuildValue("OO", item1, item2).
Creating a "sequence" type requires something like 50 lines of code, maybe more, I don't know exactly.
Victor _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
-- --Guido van Rossum (python.org/~guido)
Oh, about the cost of writing C code, we started to enhance the socket module in socket.py but keep the C code unchanged. I am thinking to the support of enums. Some C functions are wrapped in Python. Victor Le 19 juin 2017 11:59 PM, "Guido van Rossum" <guido@python.org> a écrit :
There are examples in timemodule.c which went through a similar conversion from plain tuples to (sort-of) named tuples. I agree that upgrading the tuples returned by the socket module to named tuples would be nice, but it's a low priority project. Maybe someone interested can create a PR? (First open an issue stating that you're interested; point to this email from me to prevent that some other core dev just closes it again.)
On Mon, Jun 19, 2017 at 2:24 PM, Victor Stinner <victor.stinner@gmail.com> wrote:
Hi,
2017-06-13 22:13 GMT+02:00 Thomas Güttler <guettliml@thomas-guettler.de>:
AFAIK the socket module returns plain tuples in Python3:
https://docs.python.org/3/library/socket.html
Why not use named tuples?
For technical reasons: the socket module is mostly implemented in the C language, and define a "named tuple" in C requires to implement a "sequence" time which requires much more code than creating a tuple.
In short, create a tuple is as simple as Py_BuildValue("OO", item1, item2).
Creating a "sequence" type requires something like 50 lines of code, maybe more, I don't know exactly.
Victor _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
-- --Guido van Rossum (python.org/~guido)
Namedtuple in Python make startup time slow. So I'm very conservative to convert tuple to namedtuple in Python. INADA Naoki <songofacandy@gmail.com> On Tue, Jun 20, 2017 at 7:27 AM, Victor Stinner <victor.stinner@gmail.com> wrote:
Oh, about the cost of writing C code, we started to enhance the socket module in socket.py but keep the C code unchanged. I am thinking to the support of enums. Some C functions are wrapped in Python.
Victor
Le 19 juin 2017 11:59 PM, "Guido van Rossum" <guido@python.org> a écrit :
There are examples in timemodule.c which went through a similar conversion from plain tuples to (sort-of) named tuples. I agree that upgrading the tuples returned by the socket module to named tuples would be nice, but it's a low priority project. Maybe someone interested can create a PR? (First open an issue stating that you're interested; point to this email from me to prevent that some other core dev just closes it again.)
On Mon, Jun 19, 2017 at 2:24 PM, Victor Stinner <victor.stinner@gmail.com> wrote:
Hi,
2017-06-13 22:13 GMT+02:00 Thomas Güttler <guettliml@thomas-guettler.de>:
AFAIK the socket module returns plain tuples in Python3:
https://docs.python.org/3/library/socket.html
Why not use named tuples?
For technical reasons: the socket module is mostly implemented in the C language, and define a "named tuple" in C requires to implement a "sequence" time which requires much more code than creating a tuple.
In short, create a tuple is as simple as Py_BuildValue("OO", item1, item2).
Creating a "sequence" type requires something like 50 lines of code, maybe more, I don't know exactly.
Victor _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
-- --Guido van Rossum (python.org/~guido)
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
On 20 June 2017 at 12:05, INADA Naoki <songofacandy@gmail.com> wrote:
Namedtuple in Python make startup time slow. So I'm very conservative to convert tuple to namedtuple in Python.
Aye, I don't think a Python level wrapper would be the right way to go here - while namedtuple is designed to be as cheap as normal tuples in *use*, the same can't be said for the impact on startup time. As context for anyone not familiar with the time module precedent that Guido mentioned, we have a C level `PyStructSequence` that provides some of the most essential namedtuple features, but not all of them: https://github.com/python/cpython/blob/master/Objects/structseq.c So there's potentially a case to be made for: 1. Including the struct sequence header from "Python.h" and making it part of the stable ABI 2. Documenting it in the C API reference The main argument against doing so is that the initialisation API for it is pretty weird by the standards of the rest of the Python C API - it's mainly designed for use as a C level type *factory*, rather than intended to be used directly. That's also why there isn't a Python level API for it - it's designed around accepting C level structs as inputs, which doesn't translate well to pure Python code (whereas the collections.namedtuple API works well in pure Python code, but doesn't translate well to C code). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Mon, Jun 19, 2017 at 8:04 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
As context for anyone not familiar with the time module precedent that Guido mentioned, we have a C level `PyStructSequence` that provides some of the most essential namedtuple features, but not all of them: https://github.com/python/cpython/blob/master/Objects/structseq.c
So there's potentially a case to be made for:
1. Including the struct sequence header from "Python.h" and making it part of the stable ABI 2. Documenting it in the C API reference
+1 -- I was just thinking this morning that a C-level named tuple would be nice. And certainly better than re-implementing it in various places it is needed. Would there be any benefit in making a C implementation available from Python? -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
Would there be any benefit in making a C implementation available from Python?
-CHB
Yes, at startup time point of view. Current Python namedtuple implementation uses `eval`. It means we can't cache bytecode in pyc files. For example, importing functools is not so fast and its because `_CacheInfo` namedtuple for `lru_cache`. And structseq is faster than Python namedtuple too. ref: http://bugs.python.org/issue28638#msg282412 Regards,
2017-06-20 4:05 GMT+02:00 INADA Naoki <songofacandy@gmail.com>:
Namedtuple in Python make startup time slow. So I'm very conservative to convert tuple to namedtuple in Python. INADA Naoki <songofacandy@gmail.com>
While we are talking about startup time, I would be curious of seeing the overhead (python startup time, when importing socket) of the enums added to socket.py ;-) "import enum" added to Lib/re.py was a regression causing a slowdown in the "python_startup" benchmark, but it was related to the site module importing "re" in Python is running in a virtual environment. This very specific use case was fixed by not using the re module in the site module. Victor
thank you! I am happy that Guido is open for a pull request ... There were +1 votes, too (and some concern about python startup time). I stopped coding in spare time, since my children are more important at the moment .. if some wants to try it ... go ahead and implement named tuples for the socket standard library - would be great. Just for the records, I came here because of this feature request: https://github.com/giampaolo/psutil/issues/928 Regards, Thomas Güttler PS: For some strange reasons I received only some mails of this thread. But I could find the whole thread in the archive. Am 20.06.2017 um 04:05 schrieb INADA Naoki:
Namedtuple in Python make startup time slow. So I'm very conservative to convert tuple to namedtuple in Python. INADA Naoki <songofacandy@gmail.com>
On Tue, Jun 20, 2017 at 7:27 AM, Victor Stinner <victor.stinner@gmail.com> wrote:
Oh, about the cost of writing C code, we started to enhance the socket module in socket.py but keep the C code unchanged. I am thinking to the support of enums. Some C functions are wrapped in Python.
Victor
Le 19 juin 2017 11:59 PM, "Guido van Rossum" <guido@python.org> a écrit :
There are examples in timemodule.c which went through a similar conversion from plain tuples to (sort-of) named tuples. I agree that upgrading the tuples returned by the socket module to named tuples would be nice, but it's a low priority project. Maybe someone interested can create a PR? (First open an issue stating that you're interested; point to this email from me to prevent that some other core dev just closes it again.)
On Mon, Jun 19, 2017 at 2:24 PM, Victor Stinner <victor.stinner@gmail.com> wrote:
Hi,
2017-06-13 22:13 GMT+02:00 Thomas Güttler <guettliml@thomas-guettler.de>:
AFAIK the socket module returns plain tuples in Python3:
https://docs.python.org/3/library/socket.html
Why not use named tuples?
For technical reasons: the socket module is mostly implemented in the C language, and define a "named tuple" in C requires to implement a "sequence" time which requires much more code than creating a tuple.
In short, create a tuple is as simple as Py_BuildValue("OO", item1, item2).
Creating a "sequence" type requires something like 50 lines of code, maybe more, I don't know exactly.
Victor _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
-- --Guido van Rossum (python.org/~guido)
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
-- Thomas Guettler http://www.thomas-guettler.de/
Everyone, please be upfront when proposing any ideas if you refuse to implement your own idea yourself. It's implicit that if you have an idea to discuss here that you are serious enough about it to see it happen, so if that's not the case then do say so in your first email (obviously if your circumstances change during the discussion then that's understandable). Otherwise people will spend what little spare time they have helping you think through your idea, and then find out that the discussion will more than likely end up leading to no change because the most motivated person behind the discussion isn't motivated enough to actually enact the change. And if you lack knowledge in how to implement the idea or a certain area of expertise, please be upfront about that as well. We have had instances here where ideas have gone as far as PEPs to only find out the OP didn't know C which was a critical requirement to implementing the idea, and so the idea just fell to the wayside and hasn't gone anywhere. It's totally reasonable to ask for help, but once again, please be upfront that you will need it to have any chance of seeing your idea come to fruition. To be perfectly frank, I personally find it misleading to not be told upfront that you know you will need help (if you learn later because you didn't know e.g. C would be required, that's different, but once you do learn then once again be upfront about it). Otherwise I personally feel like I was tricked into a discussion under false pretenses that the OP was motivated enough to put the effort in to see their idea come to be. Had I known to begin with that no one was actually stepping forward to make this change happen I would have skipped the thread and spent the time I put in following the discussion into something more productive like reviewing a pull request. On Thu, 22 Jun 2017 at 08:26 Thomas Güttler <guettliml@thomas-guettler.de> wrote:
thank you! I am happy that Guido is open for a pull request ... There were +1 votes, too (and some concern about python startup time).
I stopped coding in spare time, since my children are more important at the moment .. if some wants to try it ... go ahead and implement named tuples for the socket standard library - would be great.
Just for the records, I came here because of this feature request:
https://github.com/giampaolo/psutil/issues/928
Regards, Thomas Güttler
PS: For some strange reasons I received only some mails of this thread. But I could find the whole thread in the archive.
Am 20.06.2017 um 04:05 schrieb INADA Naoki:
Namedtuple in Python make startup time slow. So I'm very conservative to convert tuple to namedtuple in Python. INADA Naoki <songofacandy@gmail.com>
On Tue, Jun 20, 2017 at 7:27 AM, Victor Stinner <victor.stinner@gmail.com> wrote:
Oh, about the cost of writing C code, we started to enhance the socket module in socket.py but keep the C code unchanged. I am thinking to the support of enums. Some C functions are wrapped in Python.
Victor
Le 19 juin 2017 11:59 PM, "Guido van Rossum" <guido@python.org> a écrit :
There are examples in timemodule.c which went through a similar
conversion
from plain tuples to (sort-of) named tuples. I agree that upgrading the tuples returned by the socket module to named tuples would be nice, but it's a low priority project. Maybe someone interested can create a PR? (First open an issue stating that you're interested; point to this email from me to prevent that some other core dev just closes it again.)
On Mon, Jun 19, 2017 at 2:24 PM, Victor Stinner < victor.stinner@gmail.com> wrote:
Hi,
2017-06-13 22:13 GMT+02:00 Thomas Güttler <
guettliml@thomas-guettler.de>:
AFAIK the socket module returns plain tuples in Python3:
https://docs.python.org/3/library/socket.html
Why not use named tuples?
For technical reasons: the socket module is mostly implemented in the C language, and define a "named tuple" in C requires to implement a "sequence" time which requires much more code than creating a tuple.
In short, create a tuple is as simple as Py_BuildValue("OO", item1, item2).
Creating a "sequence" type requires something like 50 lines of code, maybe more, I don't know exactly.
Victor _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
-- --Guido van Rossum (python.org/~guido)
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
-- Thomas Guettler http://www.thomas-guettler.de/ _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
On 2017-06-23 09:49, Brett Cannon wrote:
Everyone, please be upfront when proposing any ideas if you refuse to implement your own idea yourself. It's implicit that if you have an idea to discuss here that you are serious enough about it to see it happen, so if that's not the case then do say so in your first email (obviously if your circumstances change during the discussion then that's understandable). Otherwise people will spend what little spare time they have helping you think through your idea, and then find out that the discussion will more than likely end up leading to no change because the most motivated person behind the discussion isn't motivated enough to actually enact the change.
And if you lack knowledge in how to implement the idea or a certain area of expertise, please be upfront about that as well. We have had instances here where ideas have gone as far as PEPs to only find out the OP didn't know C which was a critical requirement to implementing the idea, and so the idea just fell to the wayside and hasn't gone anywhere. It's totally reasonable to ask for help, but once again, please be upfront that you will need it to have any chance of seeing your idea come to fruition.
To be perfectly frank, I personally find it misleading to not be told upfront that you know you will need help (if you learn later because you didn't know e.g. C would be required, that's different, but once you do learn then once again be upfront about it). Otherwise I personally feel like I was tricked into a discussion under false pretenses that the OP was motivated enough to put the effort in to see their idea come to be. Had I known to begin with that no one was actually stepping forward to make this change happen I would have skipped the thread and spent the time I put in following the discussion into something more productive like reviewing a pull request.
That is a reasonable position, but I think if that's really how this list is supposed to work then it'd be good to state those requirements more explicitly in the list description. Right now the description (https://mail.python.org/mailman/listinfo/python-ideas) just says the list is for "discussion of speculative language ideas for Python". There is no hint that any particular technical qualifications are required other than having used Python enough to have an idea about how to improve it. I also don't think such a requirement is obvious even from reading the list traffic (since I've rarely seen anyone explicitly state their inability to implement, as you suggest, although it does sometimes come up later, as in this case). No doubt this leads to the occasional cockamamie proposal but I think it also allows discussion of useful ideas that otherwise might never be raised. Also, the description does mention that at some point ideas might get moved on to python-dev; although it's not explicit about how this works, I think that creates a vague impression that thinking about how or whether you can implement an idea might be something for a later stage. That said, I don't personally agree with your position here. My impression of discussion on this list is that a good deal of it doesn't really have to do with implementation at all. It has to do with the proposal itself in terms of how it would feel to use it, hashing out what its semantics would be, what the benefits would be for code readability, what confusion it might create etc. --- in short, discussion from the perspective of people who USE Python, not people who implement Python. I think that's good discussion to have even if the proposal eventually stalls because no one with the right skills has the time or inclination to implement it. It would be a shame for all such discussion to get nipped in the bud just because the person with the original proposal doesn't know C or whatever. Also, because, as you say, some people don't know what would be needed to implement their ideas, requiring this kind of disclosure might perversely muffle discussion from people who know enough to know they don't know how to implement their idea, while still allowing all the ideas from people who don't even know whether they know how to implement their idea --- and the latter are probably more likely to fall into the cockamamie category. I realize you're not proposing that all such discussion be stopped entirely, just that it be tagged as I-can't-implement-this-myself at the outset. However, your last paragraph suggests to me that the effect might be similar. You seem to be saying that (some of) those who do know how to implement stuff would like to be able to ignore discussion from anyone who doesn't know how to implement stuff. That's certainly anyone's prerogative, but I think it would be a shame if this resulted in a bifurcation of the list in which ideas can't reach the attention of people who could implement them unless they're proposed by someone who could do so themselves. To me, that would somewhat blur the distinction between python-ideas and python-dev, and potentially chill discussion of "mid-level" ideas proposed by people who know enough to have a potentially useful idea, but not enough to bring it to fruition. We presumably don't want a situation where a person with some amount of knowledge thinks "This might be a good idea. . . but I don't know how to implement it, so if I bring it up on the list the more knowledgeable people will ignore it, oh well, I guess I won't" --- while a person with no knowledge blithely jumps in with "Golly everyone I have this great idea!" (I don't mean to say that is directly what you're proposing, but it is the evolution that came to my mind when I read your comment.) So to put it succinctly, as someone who's found discussion on this list interesting and valuable, I think there is value in having discussion about "what would Python be like if this idea were implemented" even if we never get very far with "how would we implement this idea in Python". And I would find it unfortunate if discussion of the former were prematurely restricted by worries about the latter. -- Brendan Barnwell "Do not follow where the path may lead. Go, instead, where there is no path, and leave a trail." --author unknown
"to put it succinctly" -- IMO we shouldn't discuss features without giving thought to their implementation. On Fri, Jun 23, 2017 at 11:28 AM, Brendan Barnwell <brenbarn@brenbarn.net> wrote:
On 2017-06-23 09:49, Brett Cannon wrote:
Everyone, please be upfront when proposing any ideas if you refuse to implement your own idea yourself. It's implicit that if you have an idea to discuss here that you are serious enough about it to see it happen, so if that's not the case then do say so in your first email (obviously if your circumstances change during the discussion then that's understandable). Otherwise people will spend what little spare time they have helping you think through your idea, and then find out that the discussion will more than likely end up leading to no change because the most motivated person behind the discussion isn't motivated enough to actually enact the change.
And if you lack knowledge in how to implement the idea or a certain area of expertise, please be upfront about that as well. We have had instances here where ideas have gone as far as PEPs to only find out the OP didn't know C which was a critical requirement to implementing the idea, and so the idea just fell to the wayside and hasn't gone anywhere. It's totally reasonable to ask for help, but once again, please be upfront that you will need it to have any chance of seeing your idea come to fruition.
To be perfectly frank, I personally find it misleading to not be told upfront that you know you will need help (if you learn later because you didn't know e.g. C would be required, that's different, but once you do learn then once again be upfront about it). Otherwise I personally feel like I was tricked into a discussion under false pretenses that the OP was motivated enough to put the effort in to see their idea come to be. Had I known to begin with that no one was actually stepping forward to make this change happen I would have skipped the thread and spent the time I put in following the discussion into something more productive like reviewing a pull request.
That is a reasonable position, but I think if that's really how this list is supposed to work then it'd be good to state those requirements more explicitly in the list description. Right now the description ( https://mail.python.org/mailman/listinfo/python-ideas) just says the list is for "discussion of speculative language ideas for Python". There is no hint that any particular technical qualifications are required other than having used Python enough to have an idea about how to improve it. I also don't think such a requirement is obvious even from reading the list traffic (since I've rarely seen anyone explicitly state their inability to implement, as you suggest, although it does sometimes come up later, as in this case). No doubt this leads to the occasional cockamamie proposal but I think it also allows discussion of useful ideas that otherwise might never be raised. Also, the description does mention that at some point ideas might get moved on to python-dev; although it's not explicit about how this works, I think that creates a vague impression that thinking about how or whether you can implement an idea might be something for a later stage.
That said, I don't personally agree with your position here. My impression of discussion on this list is that a good deal of it doesn't really have to do with implementation at all. It has to do with the proposal itself in terms of how it would feel to use it, hashing out what its semantics would be, what the benefits would be for code readability, what confusion it might create etc. --- in short, discussion from the perspective of people who USE Python, not people who implement Python. I think that's good discussion to have even if the proposal eventually stalls because no one with the right skills has the time or inclination to implement it. It would be a shame for all such discussion to get nipped in the bud just because the person with the original proposal doesn't know C or whatever. Also, because, as you say, some people don't know what would be needed to implement their ideas, requiring this kind of disclosure might perversely muffle discussion from people who know enough to know they don't know how to implement their idea, while still allowing all the ideas from people who don't even know whether they know how to implement their idea --- and the latter are probably more likely to fall into the cockamamie category.
I realize you're not proposing that all such discussion be stopped entirely, just that it be tagged as I-can't-implement-this-myself at the outset. However, your last paragraph suggests to me that the effect might be similar. You seem to be saying that (some of) those who do know how to implement stuff would like to be able to ignore discussion from anyone who doesn't know how to implement stuff. That's certainly anyone's prerogative, but I think it would be a shame if this resulted in a bifurcation of the list in which ideas can't reach the attention of people who could implement them unless they're proposed by someone who could do so themselves. To me, that would somewhat blur the distinction between python-ideas and python-dev, and potentially chill discussion of "mid-level" ideas proposed by people who know enough to have a potentially useful idea, but not enough to bring it to fruition. We presumably don't want a situation where a person with some amount of knowledge thinks "This might be a good idea. . . but I don't know how to implement it, so if I bring it up on the list the more knowledgeable people will ignore it, oh well, I guess I won't" --- while a person with no knowledge blithely jumps in with "Golly everyone I have this great idea!" (I don't mean to say that is directly what you're proposing, but it is the evolution that came to my mind when I read your comment.)
So to put it succinctly, as someone who's found discussion on this list interesting and valuable, I think there is value in having discussion about "what would Python be like if this idea were implemented" even if we never get very far with "how would we implement this idea in Python". And I would find it unfortunate if discussion of the former were prematurely restricted by worries about the latter.
-- Brendan Barnwell "Do not follow where the path may lead. Go, instead, where there is no path, and leave a trail." --author unknown _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
-- --Guido van Rossum (python.org/~guido)
On 23 June 2017 at 19:28, Brendan Barnwell <brenbarn@brenbarn.net> wrote:
So to put it succinctly, as someone who's found discussion on this list interesting and valuable, I think there is value in having discussion about "what would Python be like if this idea were implemented" even if we never get very far with "how would we implement this idea in Python". And I would find it unfortunate if discussion of the former were prematurely restricted by worries about the latter.
No-one is proposing otherwise, just that people are open when starting a discussion as to whether they anticipate being able to follow through with an implementation if the idea meets with approval, or if they are simply making a suggestion that they hope someone else will take up. That's not too much to ask, nor does it in any way stifle reasonable discussion (it may discourage people who want to *deliberately* give the impression that they will do the work, but actually have no intention of doing so - but I hope there's no-one like that here and if there were, I'm happy with discouraging them). So I'm +1 on Brett's request. Paul
+1 I'm quite active in the CoffeeScript community, but am also on a ton of medication that ultimately means I won't implement much of what I suggest doing, but the core devs understand the situation well enough to respond accordingly. It really does help when people know what they can reasonably expect from others, and it doesn't take much to let them know. None of this has ever prevented me from being involved. It just prevents me from wasting other people's time. -- Carl -- Carl Smith carl.input@gmail.com On 23 June 2017 at 21:09, Paul Moore <p.f.moore@gmail.com> wrote:
On 23 June 2017 at 19:28, Brendan Barnwell <brenbarn@brenbarn.net> wrote:
So to put it succinctly, as someone who's found discussion on this list interesting and valuable, I think there is value in having discussion about "what would Python be like if this idea were implemented" even if we never get very far with "how would we implement this idea in Python". And I would find it unfortunate if discussion of the former were prematurely restricted by worries about the latter.
No-one is proposing otherwise, just that people are open when starting a discussion as to whether they anticipate being able to follow through with an implementation if the idea meets with approval, or if they are simply making a suggestion that they hope someone else will take up. That's not too much to ask, nor does it in any way stifle reasonable discussion (it may discourage people who want to *deliberately* give the impression that they will do the work, but actually have no intention of doing so - but I hope there's no-one like that here and if there were, I'm happy with discouraging them).
So I'm +1 on Brett's request. Paul _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
On Fri, 23 Jun 2017 at 13:10 Paul Moore <p.f.moore@gmail.com> wrote:
On 23 June 2017 at 19:28, Brendan Barnwell <brenbarn@brenbarn.net> wrote:
So to put it succinctly, as someone who's found discussion on this list interesting and valuable, I think there is value in having discussion about "what would Python be like if this idea were implemented" even if we never get very far with "how would we implement this idea in Python". And I would find it unfortunate if discussion of the former were prematurely restricted by worries about the latter.
No-one is proposing otherwise, just that people are open when starting a discussion as to whether they anticipate being able to follow through with an implementation if the idea meets with approval, or if they are simply making a suggestion that they hope someone else will take up. That's not too much to ask, nor does it in any way stifle reasonable discussion (it may discourage people who want to *deliberately* give the impression that they will do the work, but actually have no intention of doing so - but I hope there's no-one like that here and if there were, I'm happy with discouraging them).
So I'm +1 on Brett's request.
+1 to what Paul and Guido said: people are welcome to have hypothetical discussions here as long as they are upfront that it is hypothetical, but I personally choose to ignore all discussions that don't involve discussing the implementation of said idea (hence why learning that at the end is frustrating for those of us who are trying to be pragmatic with our time). Sorry if that wasn't clear enough in my original email where the distinction between "Brett as list admin" and "Brett as list participant" started and ended.
It has been brought to my attention that some people found this email as sounding rather angry. I was frustrated (and there is more to this specific issue than what everyone is seeing publicly), but I didn't meant for it to come off as angry, and for that I apologize. On Fri, 23 Jun 2017 at 09:49 Brett Cannon <brett@python.org> wrote:
Everyone, please be upfront when proposing any ideas if you refuse to implement your own idea yourself. It's implicit that if you have an idea to discuss here that you are serious enough about it to see it happen, so if that's not the case then do say so in your first email (obviously if your circumstances change during the discussion then that's understandable). Otherwise people will spend what little spare time they have helping you think through your idea, and then find out that the discussion will more than likely end up leading to no change because the most motivated person behind the discussion isn't motivated enough to actually enact the change.
And if you lack knowledge in how to implement the idea or a certain area of expertise, please be upfront about that as well. We have had instances here where ideas have gone as far as PEPs to only find out the OP didn't know C which was a critical requirement to implementing the idea, and so the idea just fell to the wayside and hasn't gone anywhere. It's totally reasonable to ask for help, but once again, please be upfront that you will need it to have any chance of seeing your idea come to fruition.
To be perfectly frank, I personally find it misleading to not be told upfront that you know you will need help (if you learn later because you didn't know e.g. C would be required, that's different, but once you do learn then once again be upfront about it). Otherwise I personally feel like I was tricked into a discussion under false pretenses that the OP was motivated enough to put the effort in to see their idea come to be. Had I known to begin with that no one was actually stepping forward to make this change happen I would have skipped the thread and spent the time I put in following the discussion into something more productive like reviewing a pull request.
On Thu, 22 Jun 2017 at 08:26 Thomas Güttler <guettliml@thomas-guettler.de> wrote:
thank you! I am happy that Guido is open for a pull request ... There were +1 votes, too (and some concern about python startup time).
I stopped coding in spare time, since my children are more important at the moment .. if some wants to try it ... go ahead and implement named tuples for the socket standard library - would be great.
Just for the records, I came here because of this feature request:
https://github.com/giampaolo/psutil/issues/928
Regards, Thomas Güttler
PS: For some strange reasons I received only some mails of this thread. But I could find the whole thread in the archive.
Namedtuple in Python make startup time slow. So I'm very conservative to convert tuple to namedtuple in Python. INADA Naoki <songofacandy@gmail.com>
On Tue, Jun 20, 2017 at 7:27 AM, Victor Stinner <victor.stinner@gmail.com> wrote:
Oh, about the cost of writing C code, we started to enhance the socket module in socket.py but keep the C code unchanged. I am thinking to the support of enums. Some C functions are wrapped in Python.
Victor
Le 19 juin 2017 11:59 PM, "Guido van Rossum" <guido@python.org> a écrit :
There are examples in timemodule.c which went through a similar
conversion
from plain tuples to (sort-of) named tuples. I agree that upgrading
Am 20.06.2017 um 04:05 schrieb INADA Naoki: the
tuples returned by the socket module to named tuples would be nice, but it's a low priority project. Maybe someone interested can create a PR? (First open an issue stating that you're interested; point to this email from me to prevent that some other core dev just closes it again.)
On Mon, Jun 19, 2017 at 2:24 PM, Victor Stinner < victor.stinner@gmail.com> wrote:
Hi,
2017-06-13 22:13 GMT+02:00 Thomas Güttler <
guettliml@thomas-guettler.de>:
> AFAIK the socket module returns plain tuples in Python3: > > https://docs.python.org/3/library/socket.html > > Why not use named tuples?
For technical reasons: the socket module is mostly implemented in the C language, and define a "named tuple" in C requires to implement a "sequence" time which requires much more code than creating a tuple.
In short, create a tuple is as simple as Py_BuildValue("OO", item1, item2).
Creating a "sequence" type requires something like 50 lines of code, maybe more, I don't know exactly.
Victor _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
-- --Guido van Rossum (python.org/~guido)
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
-- Thomas Guettler http://www.thomas-guettler.de/ _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
participants (11)
-
Brendan Barnwell -
Brett Cannon -
Carl Smith -
Chris Barker -
George Fischhof -
Guido van Rossum -
INADA Naoki -
Nick Coghlan -
Paul Moore -
Thomas Güttler -
Victor Stinner