Re: [Python-Dev] fixing broken link in pep 3
Hi, Yes, the link is dead. It looks like the following link contains the same info: https://docs.python.org/devguide/triaging.html Dead page: https://web.archive.org/web/20090704040931/http://www.python.org/dev/workflow/ "Core Development > Issue Workflow" Victor 2014-12-18 6:57 GMT+01:00 Raymond Sanchez : > Hello my name is Raymond and I would like to fix a broken link on pep 3. If > you go to > https://www.python.org/dev/peps/pep-0003/ and click on link > http://www.python.org/dev/workflow/, it returns a 404. > > What is the correct url? Should we also update the description "It has been > replaced by the Issue Workflow"? > > After I'll get the correct answers, I will submit a patch. > > > Thanks for your help. > > > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/victor.stinner%40gmail.com > ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Redirection of ar.pycon.org
Hi! Don't remember where to ask for changing the redirection of that domain name. Somebody knows? I need for the redirection to be to pycon.python.org.ar (and we'll take care of proper year-by-year redirection from there). Thanks! -- .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ Twitter: @facundobatista ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] libffi embedded in CPython
After reading this http://bugs.python.org/issue23085 and remembering struggling having our own patches into cpython's libffi (but not into libffi itself), I wonder, is there any reason any more for libffi being included in CPython? Cheers, fijal ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] libffi embedded in CPython
Maciej Fijalkowski wrote: > After reading this http://bugs.python.org/issue23085 and remembering > struggling > having our own patches into cpython's libffi (but not into libffi itself), I > wonder, is there any reason any more for libffi being included in CPython? We use it for ctypes, so there's certainly still a need. Are you asking whether we need a fork of it as opposed to treating it like an external (like OpenSSL)? > Cheers, > fijal ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] libffi embedded in CPython
On Thu, Dec 18, 2014 at 9:17 PM, Steve Dower wrote: > Maciej Fijalkowski wrote: >> After reading this http://bugs.python.org/issue23085 and remembering >> struggling >> having our own patches into cpython's libffi (but not into libffi itself), I >> wonder, is there any reason any more for libffi being included in CPython? > > We use it for ctypes, so there's certainly still a need. Are you asking > whether we need a fork of it as opposed to treating it like an external (like > OpenSSL)? yes (why is there a copy of libffi in the cpython source). And I'm asking not why it landed there, but why it is still there ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] libffi embedded in CPython
On Thu, Dec 18, 2014, at 14:13, Maciej Fijalkowski wrote: > After reading this http://bugs.python.org/issue23085 and remembering > struggling having our own patches into cpython's libffi (but not into > libffi itself), I wonder, is there any reason any more for libffi > being included in CPython? It has some sort of Windows related patches. No one seems to know whether they're still needed for newer libffi. Unfortunately, ctypes doesn't currently have a maintainer. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] libffi embedded in CPython
well, the problem is essentially that libffi gets patched (e.g. for ARM) and it does not make it's way to CPython quickly. This is unlikely to be a security issue (for a variety of reasons, including ctypes), but it's still an issue I think. Segfaults related to e.g. stack alignment are hard to debug On Thu, Dec 18, 2014 at 9:30 PM, Benjamin Peterson wrote: > > > On Thu, Dec 18, 2014, at 14:13, Maciej Fijalkowski wrote: >> After reading this http://bugs.python.org/issue23085 and remembering >> struggling having our own patches into cpython's libffi (but not into >> libffi itself), I wonder, is there any reason any more for libffi >> being included in CPython? > > It has some sort of Windows related patches. No one seems to know > whether they're still needed for newer libffi. Unfortunately, ctypes > doesn't currently have a maintainer. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] libffi embedded in CPython
On Thu, Dec 18, 2014, at 14:50, Maciej Fijalkowski wrote: > well, the problem is essentially that libffi gets patched (e.g. for > ARM) and it does not make it's way to CPython quickly. This is > unlikely to be a security issue (for a variety of reasons, including > ctypes), but it's still an issue I think. Segfaults related to e.g. > stack alignment are hard to debug Certainly it's a suboptimal situation, but resolving it requires someone to figure out whether we still need/want whatever patches are in there. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] libffi embedded in CPython
On Thu, Dec 18, 2014, at 14:50, Maciej Fijalkowski wrote: > well, the problem is essentially that libffi gets patched (e.g. for > ARM) and it does not make it's way to CPython quickly. This is > unlikely to be a security issue (for a variety of reasons, including > ctypes), but it's still an issue I think. Segfaults related to e.g. > stack alignment are hard to debug Certainly it's a suboptimal situation, but resolving it requires someone to figure out whether we still need/want whatever patches are in there. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Redirection of ar.pycon.org
On Thu, Dec 18, 2014, at 10:59, Facundo Batista wrote: > Hi! > > Don't remember where to ask for changing the redirection of that > domain name. Somebody knows? Seems DNS for that is controlled by eGenix, so ccing mal. (We should move pycon.org DNS to use the PSF's normal DNS infrastructure.) > > I need for the redirection to be to pycon.python.org.ar (and we'll > take care of proper year-by-year redirection from there). ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] libffi embedded in CPython
On Thu, Dec 18, 2014, at 14:13, Maciej Fijalkowski wrote: > ... http://bugs.python.org/issue23085 ... > is there any reason any more for libffi being included in CPython? [And why a fork, instead of just treating it as an external dependency] Benjamin Peterson responded: > It has some sort of Windows related patches. No one seems to know > whether they're still needed for newer libffi. Unfortunately, ctypes > doesn't currently have a maintainer. Are any of the following false? (1) Ideally, we would treat it as an external dependency. (2) At one point, it was intentionally forked to get in needed patches, including at least some for 64 bit windows with MSVC. (3) Upstream libffi maintenance has picked back up. (4) Alas, that means the switch merge would not be trivial. (5) In theory, we could now switch to the external version. [In particular, does libffi have a release policy such that we could assume the newest released version is "safe", so long as our integration doesn't break?] (6) By its very nature, libffi changes are risky and undertested. At the moment, that is also true of its primary user, ctypes. (7) So a switch is OK in theory, but someone has to do the non-trivial testing and merging, and agree to support both libffi and and ctypes in the future. Otherwise, stable wins. (8) The need for future support makes this a bad candidate for "patches wanted"/"bug bounty"/GSoC. -jJ -- If there are still threading problems with my replies, please email me with details, so that I can try to resolve them. -jJ ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] datetime nanosecond support (ctd?)
done - http://bugs.python.org/issue23084 On 12/17/14 8:20 PM, Eric Snow wrote: On Wed, Dec 17, 2014 at 7:52 PM, Matthieu Bec wrote: Attached patch defines a new type struct_timespec for the time module. A new capsule exports the type along with to/from converters - opening a bridge for C, and for example the datetime module. I'd recommend opening a new issue in the bug tracker (bugs.python.org) and attach the patch there. Attaching it to an email is a good way for it to get lost and forgotten. :) -eric ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [PEPs] Fwd: fixing broken link in pep 3
On Fri, Dec 19, 2014 at 5:39 AM, Guido van Rossum wrote: >-- Forwarded message -- > From: Victor Stinner > > Hi, > > Yes, the link is dead. It looks like the following link contains the same > info: > https://docs.python.org/devguide/triaging.html > > Dead page: > https://web.archive.org/web/20090704040931/http://www.python.org/dev/workflow/ > "Core Development > Issue Workflow" > > Victor Edits made to PEP 3, link now updated. Noticed along the way that the next link down (for people _submitting_ bugs) is pointing to the /2/ section of the docs; should that be updated to send people to /3/, or are the two kept in sync? ChrisA ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Redirection of ar.pycon.org
Hi Facunda, you should either write to [email protected], the conference ML or me directly, since I'm managing these the pycon.org subdomains. > On Thu, Dec 18, 2014, at 10:59, Facundo Batista wrote: >> Hi! >> >> Don't remember where to ask for changing the redirection of that >> domain name. Somebody knows? >> >> I need for the redirection to be to pycon.python.org.ar (and we'll >> take care of proper year-by-year redirection from there). -- Marc-Andre Lemburg Director Python Software Foundation http://www.python.org/psf/ ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [PEPs] Fwd: fixing broken link in pep 3
On 12/18/2014 4:19 PM, Chris Angelico wrote: On Fri, Dec 19, 2014 at 5:39 AM, Guido van Rossum wrote: -- Forwarded message -- From: Victor Stinner Hi, Yes, the link is dead. It looks like the following link contains the same info: https://docs.python.org/devguide/triaging.html Dead page: https://web.archive.org/web/20090704040931/http://www.python.org/dev/workflow/ "Core Development > Issue Workflow" Victor Edits made to PEP 3, link now updated. PEP 3 is listed in PEP 0 under Abandoned, Withdrawn, and Rejected PEPs If this is proper, it does not make sense to update it. If this is not, the header should be updated. Noticed along the way that the next link down (for people _submitting_ bugs) is pointing to the /2/ section of the docs; should that be updated to send people to /3/, or are the two kept in sync? The actual link in the doc is http://docs.python.org/bugs.html. The site redirects that to http://docs.python.org/2/bugs.html. To me, the redirection should be to http://docs.python.org/3/bugs.html, regardless of the PEP 3 status. -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [PEPs] Fwd: fixing broken link in pep 3
On Fri, Dec 19, 2014 at 12:24 PM, Terry Reedy wrote: > PEP 3 is listed in PEP 0 under Abandoned, Withdrawn, and Rejected PEPs > If this is proper, it does not make sense to update it. > If this is not, the header should be updated. Guido passed the request on to the pep-editors list, which I took to mean that this should be updated. PEP 3 has been replaced with info in the dev guide, and the link in question is to the exact page of that dev guide which replaces it. ChrisA ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] libffi embedded in CPython
On Thu, Dec 18, 2014, at 15:36, Jim J. Jewett wrote: > > > On Thu, Dec 18, 2014, at 14:13, Maciej Fijalkowski wrote: > > ... http://bugs.python.org/issue23085 ... > > is there any reason any more for libffi being included in CPython? > > [And why a fork, instead of just treating it as an external dependency] > > Benjamin Peterson responded: > > > It has some sort of Windows related patches. No one seems to know > > whether they're still needed for newer libffi. Unfortunately, ctypes > > doesn't currently have a maintainer. > > Are any of the following false? > > (1) Ideally, we would treat it as an external dependency. > > (2) At one point, it was intentionally forked to get in needed > patches, including at least some for 64 bit windows with MSVC. > > (3) Upstream libffi maintenance has picked back up. > > (4) Alas, that means the switch merge would not be trivial. > > (5) In theory, we could now switch to the external version. > [In particular, does libffi have a release policy such that we > could assume the newest released version is "safe", so long as > our integration doesn't break?] > > (6) By its very nature, libffi changes are risky and undertested. > At the moment, that is also true of its primary user, ctypes. > > (7) So a switch is OK in theory, but someone has to do the > non-trivial testing and merging, and agree to support both libffi > and and ctypes in the future. Otherwise, stable wins. > > (8) The need for future support makes this a bad candidate for > "patches wanted"/"bug bounty"/GSoC. Sounds about right. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
