Re: [Python-Dev] cpython (3.6): replace usage of Py_VA_COPY with the (C99) standard va_copy
On Fri, Sep 23, 2016 at 4:47 PM, Benjamin Peterson wrote: > On Thu, Sep 22, 2016, at 04:44, Victor Stinner wrote: >> 2016-09-22 8:02 GMT+02:00 Benjamin Peterson : >> > Just dump the compat macros in Python 4.0 I think. >> >> Please don't. Python 3 was so painful because we decided to make >> millions of tiny backward incompatible changes. To have a smooth >> Python 4.0 release, we should only remove things which were already >> deprecated since at least 2 cycles, and well documented as deprecated. > > I'm being flippant here because of the triviality of the change. Anyone > using Py_VA_COPY or Py_MEMCPY can fix their code in a backwards and > forwards compatible manner in 7 seconds with a sed command. In fact, this kind of thing would be perfect for Python 4.0 - it's technically backward incompatible (thus justifying the 4.0 number), but removes only things that have been deprecated for some time, and have simple and direct translations. ChrisA ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython (3.6): replace usage of Py_VA_COPY with the (C99) standard va_copy
2016-09-23 8:47 GMT+02:00 Benjamin Peterson : > I'm being flippant here because of the triviality of the change. Anyone > using Py_VA_COPY or Py_MEMCPY can fix their code in a backwards and > forwards compatible manner in 7 seconds with a sed command. Python 3 had the same argument with 2to3: run 2to3 once, and you are done. C99 is a new thing for Python >= 3.6, but when you want to support Python 2.7 and 3.5, you are stuck at Visual Studio 2010 which is less happy with C99 than VS 2015... Hum, I don't recall if Python 2.7 requires VS 2010 or 2008? Python 2.7 doesn't seem to be mentioned in the dev guide :-/ https://docs.python.org/devguide/setup.html#windows-compiling Victor ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython (3.6): replace usage of Py_VA_COPY with the (C99) standard va_copy
Hi, Python 2.7 requires VS 2008 as Microsoft provides a specific bundle https://www.microsoft.com/en-us/download/details.aspx?id=44266 Kind regards Thierry On Fri, Sep 23, 2016 at 9:05 AM +0200, "Victor Stinner" wrote: 2016-09-23 8:47 GMT+02:00 Benjamin Peterson : > I'm being flippant here because of the triviality of the change. Anyone > using Py_VA_COPY or Py_MEMCPY can fix their code in a backwards and > forwards compatible manner in 7 seconds with a sed command. Python 3 had the same argument with 2to3: run 2to3 once, and you are done. C99 is a new thing for Python >= 3.6, but when you want to support Python 2.7 and 3.5, you are stuck at Visual Studio 2010 which is less happy with C99 than VS 2015... Hum, I don't recall if Python 2.7 requires VS 2010 or 2008? Python 2.7 doesn't seem to be mentioned in the dev guide :-/ https://docs.python.org/devguide/setup.html#windows-compiling Victor ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/tchappui%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython (3.6): replace usage of Py_VA_COPY with the (C99) standard va_copy
2016-09-23 9:03 GMT+02:00 Chris Angelico : > In fact, this kind of thing would be perfect for Python 4.0 - it's > technically backward incompatible (thus justifying the 4.0 number), > but removes only things that have been deprecated for some time, and > have simple and direct translations. Sorry, you missed my point. No, I'm strongly opposed to yet another "break the world" major release. Python 4 must not introduce deliberate backward compatible changes for the purity of the code. The main lesson learnt from Python 3.0 is that practicality beats purity. For me, it's fine to remove deprecated things, but only if we respect the smooth common deprecation planning: * pending deprecation * deprecation * remove The strict minimum is a deprecation in one cycle, but it's better to use 3 cycles (Python 3.x releases) for a smooth transition. For Py_MEMCPY and Py_VA_COPY, the maintenance burden is gone: these macros are now dumb aliases. I would prefer to wait until Python 2.7 is death 7 times before removing it. But I'm proposing to keep tracks of such macros kept for backward compatibility to remind that some day, we should think how to remove them. By the way, GCC has a neat "deprecated" attribute. Maybe we should start to use it? https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes Currently, we don't warn technically developers of C extensions. The best that we can do is to document deprecations C API in What's New in Python 3.x and in the documentation of the C API... but who still read these documentations when their C extension is stable and "just works"? A warning during the compilation would be a nice hint that something is wrong and should be fixed. Oh... I already proposed to use __attribute__((deprecated)) in november 2013 :-) http://bugs.python.org/issue19569 Victor ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] OpenIndiana and Solaris support
Hi, My question is simple: do we officially support Solaris and/or OpenIndiana? Jesus Cea runs an OpenIndiana buildbot slave: http://buildbot.python.org/all/buildslaves/cea-indiana-x86 "Open Indiana 32 bits" The platform module of Python says "Solaris-2.11", I don't know the exact OpenIndiana version. A lot of unit tests fail on this buildbot with MemoryError. I guess that it's related to Solaris which doesn't allow overcommit (allocating more memory than available memory on the system), or more simply because the slave has not enough memory. There is now an issue which seems specific to OpenIndiana: http://bugs.python.org/issue27847 It might impact Solaris as well, but the Solaris buildbot is offline since "684 builds". Five years ago, I reported a bug because the curses module of Python 3 doesn't build on Solaris nor OpenIndiana anymore. It seems like the bug was not fixed, and the issue is still open: http://bugs.python.org/issue13552 So my question is if we officially support Solaris and/or OpenIndiana. If yes, how can we fix issues when we only have buildbot slave which has memory errors, and no SSH access to this server? Solaris doesn't seem to be officially supported in Python, so I suggest to drop the OpenIndiana buildbot (which is failing since at least 2 years) and close all Solaris issues as "WONTFIX". Victor ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2016-09-16 - 2016-09-23) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open5530 (+23) closed 34485 (+53) total 40015 (+76) Open issues with patches: 2381 Issues opened (63) == #16700: Document that bytes OS API can returns unusable results on Win http://bugs.python.org/issue16700 reopened by serhiy.storchaka #27922: Make IDLE tests less flashy http://bugs.python.org/issue27922 reopened by terry.reedy #28162: WindowsConsoleIO readall() fails if first line starts with Ctr http://bugs.python.org/issue28162 reopened by eryksun #28164: _PyIO_get_console_type fails for various paths http://bugs.python.org/issue28164 reopened by eryksun #28165: The 'subprocess' module leaks memory when called in certain wa http://bugs.python.org/issue28165 reopened by Xavion #28176: Fix callbacks race in asyncio.SelectorLoop.sock_connect http://bugs.python.org/issue28176 reopened by haypo #28183: Clean up and speed up dict iteration http://bugs.python.org/issue28183 opened by serhiy.storchaka #28185: Tabs in C source code http://bugs.python.org/issue28185 opened by franciscouzo #28186: Autogenerated tabs / trailing whitespace http://bugs.python.org/issue28186 opened by franciscouzo #28188: os.putenv should support bytes arguments on Windows http://bugs.python.org/issue28188 opened by eryksun #28190: Cross-build _curses failed if host ncurses headers and target http://bugs.python.org/issue28190 opened by Chi Hsuan Yen #28191: Support RFC4985 SRVName in SAN name http://bugs.python.org/issue28191 opened by christian.heimes #28194: Clean up some checks in dict implementation http://bugs.python.org/issue28194 opened by xiang.zhang #28196: ssl.match_hostname() should check for SRV-ID and URI-ID http://bugs.python.org/issue28196 opened by christian.heimes #28197: range.index mismatch with documentation http://bugs.python.org/issue28197 opened by veky #28199: Compact dict resizing is doing too much work http://bugs.python.org/issue28199 opened by rhettinger #28201: dict: perturb shift should be done when first conflict http://bugs.python.org/issue28201 opened by inada.naoki #28202: Python 3.5.1 C API, the global variable is not destroyed when http://bugs.python.org/issue28202 opened by Jack Liu #28203: complex() gives wrong error when the second argument has an in http://bugs.python.org/issue28203 opened by manishearth #28206: signal.Signals not documented http://bugs.python.org/issue28206 opened by Samuel Colvin #28207: SQLite headers are not searched in custom locations http://bugs.python.org/issue28207 opened by Santiago Castro #28208: update sqlite to 3.14.2 http://bugs.python.org/issue28208 opened by Big Stone #28209: Exe or MSI unable to find Py3.5 http://bugs.python.org/issue28209 opened by jcrmatos #28210: argparse with subcommands difference in python 2.7 / 3.5 http://bugs.python.org/issue28210 opened by stephan #28211: Wrong return value type in the doc of PyMapping_Keys/Values/It http://bugs.python.org/issue28211 opened by xiang.zhang #28212: Closing server in asyncio is not efficient http://bugs.python.org/issue28212 opened by ÐонÑÑанÑин Ðолков #28213: asyncio SSLProtocol _app_transport is private http://bugs.python.org/issue28213 opened by ÐонÑÑанÑин Ðолков #28214: Improve exception reporting for problematic __set_name__ attri http://bugs.python.org/issue28214 opened by Tim.Graham #28215: PyModule_AddIntConstant() wraps >=2^31 values when long is 4 b http://bugs.python.org/issue28215 opened by altendky #28217: Add interactive console tests http://bugs.python.org/issue28217 opened by steve.dower #28218: Windows docs have wrong versionadded description http://bugs.python.org/issue28218 opened by steve.dower #28219: Is order of argparse --help output officially defined? http://bugs.python.org/issue28219 opened by barry #28221: Unused indata in test_ssl.ThreadedTests.test_asyncore_server http://bugs.python.org/issue28221 opened by martin.panter #28222: test_distutils fails http://bugs.python.org/issue28222 opened by xiang.zhang #28223: test_tools fails with timeout on AMD64 Snow Leop 3.x buildbot http://bugs.python.org/issue28223 opened by haypo #28224: Compilation warnings on Windows: export 'PyInit_xx' specified http://bugs.python.org/issue28224 opened by haypo #28225: bz2 does not support pathlib http://bugs.python.org/issue28225 opened by ethan.furman #28226: compileall does not support pathlib http://bugs.python.org/issue28226 opened by ethan.furman #28227: gzip does not support pathlib http://bugs.python.org/issue28227 opened by ethan.furman #28228: imghdr does not support pathlib http://bugs.python.org/issue28228 opened by ethan.furman #28229: lzma does not support pathlib http://bugs.python.org/issue28229 opened by ethan.furman
Re: [Python-Dev] cpython (3.6): replace usage of Py_VA_COPY with the (C99) standard va_copy
On Thu, Sep 22, 2016 at 11:47:20PM -0700, Benjamin Peterson wrote: > > On Thu, Sep 22, 2016, at 04:44, Victor Stinner wrote: > > 2016-09-22 8:02 GMT+02:00 Benjamin Peterson : > > > Just dump the compat macros in Python 4.0 I think. > > > > Please don't. Python 3 was so painful because we decided to make > > millions of tiny backward incompatible changes. To have a smooth > > Python 4.0 release, we should only remove things which were already > > deprecated since at least 2 cycles, and well documented as deprecated. > > I'm being flippant here because of the triviality of the change. Anyone > using Py_VA_COPY or Py_MEMCPY can fix their code in a backwards and > forwards compatible manner in 7 seconds with a sed command. Sorry, I haven't been following this thread in detail, so perhaps I've misunderstood. Are you assuming that anyone who is building Python from source is automatically able to diagnose C level build failures and known how to fix them using sed? -- Steve ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] OpenIndiana and Solaris support
What on earth is OpenIndiana? Its website is a mystery of buzzwords and PR vagueness: "openindiana Community-driven Illumos Distribution" "What is illumos ? From the illumos developer’s guide: “illumos is a consolidation of software that forms the core of an Operating System. It includes the kernel, device drivers, core system libraries, and utilities. It is the home of many technologies include ZFS, DTrace, Zones, ctf, [...]" "The “Hipster” branch Hipster is a codename for rapidly moving development branch of OpenIndiana and users might experience occasional breakages or problems. Hipster is using rolling-release model and only publishes installation ISOs once in a while. Every ISO release will be announced via mailing list and ..." That didn't exactly answer my questions. Clearly they don't care about anyone who isn't already a user of openindiana or illumos. So I propose that we shouldn't care about them either. On Fri, Sep 23, 2016 at 1:33 AM, Victor Stinner wrote: > Hi, > > My question is simple: do we officially support Solaris and/or OpenIndiana? > > Jesus Cea runs an OpenIndiana buildbot slave: > http://buildbot.python.org/all/buildslaves/cea-indiana-x86 > "Open Indiana 32 bits" > > The platform module of Python says "Solaris-2.11", I don't know the > exact OpenIndiana version. > > A lot of unit tests fail on this buildbot with MemoryError. I guess > that it's related to Solaris which doesn't allow overcommit > (allocating more memory than available memory on the system), or more > simply because the slave has not enough memory. > > There is now an issue which seems specific to OpenIndiana: > http://bugs.python.org/issue27847 > > It might impact Solaris as well, but the Solaris buildbot is offline > since "684 builds". > > Five years ago, I reported a bug because the curses module of Python 3 > doesn't build on Solaris nor OpenIndiana anymore. It seems like the > bug was not fixed, and the issue is still open: > http://bugs.python.org/issue13552 > > So my question is if we officially support Solaris and/or OpenIndiana. > If yes, how can we fix issues when we only have buildbot slave which > has memory errors, and no SSH access to this server? > > Solaris doesn't seem to be officially supported in Python, so I > suggest to drop the OpenIndiana buildbot (which is failing since at > least 2 years) and close all Solaris issues as "WONTFIX". > > Victor > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/guido%40python.org -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] OpenIndiana and Solaris support
Illumos, OpenIndiana et al are open source forks of Solaris. Back before the acquisition by Oracle, Sun open sourced the Solaris OS, called it OpenSolaris and encouraged projects to use it as an OS for x86 and other architectures. But after the acquisition, the OpenSolaris project seemed to end (I don’t know specifics) but several organizations carried on with distributions / forks of OpenSolaris. On 9/23/16, 10:49 AM, "Python-Dev on behalf of Guido van Rossum" wrote: What on earth is OpenIndiana? Its website is a mystery of buzzwords and PR vagueness: "openindiana Community-driven Illumos Distribution" "What is illumos ? From the illumos developer’s guide: “illumos is a consolidation of software that forms the core of an Operating System. It includes the kernel, device drivers, core system libraries, and utilities. It is the home of many technologies include ZFS, DTrace, Zones, ctf, [...]" "The “Hipster” branch Hipster is a codename for rapidly moving development branch of OpenIndiana and users might experience occasional breakages or problems. Hipster is using rolling-release model and only publishes installation ISOs once in a while. Every ISO release will be announced via mailing list and ..." That didn't exactly answer my questions. Clearly they don't care about anyone who isn't already a user of openindiana or illumos. So I propose that we shouldn't care about them either. On Fri, Sep 23, 2016 at 1:33 AM, Victor Stinner wrote: > Hi, > > My question is simple: do we officially support Solaris and/or OpenIndiana? > > Jesus Cea runs an OpenIndiana buildbot slave: > http://buildbot.python.org/all/buildslaves/cea-indiana-x86 > "Open Indiana 32 bits" > > The platform module of Python says "Solaris-2.11", I don't know the > exact OpenIndiana version. > > A lot of unit tests fail on this buildbot with MemoryError. I guess > that it's related to Solaris which doesn't allow overcommit > (allocating more memory than available memory on the system), or more > simply because the slave has not enough memory. > > There is now an issue which seems specific to OpenIndiana: > http://bugs.python.org/issue27847 > > It might impact Solaris as well, but the Solaris buildbot is offline > since "684 builds". > > Five years ago, I reported a bug because the curses module of Python 3 > doesn't build on Solaris nor OpenIndiana anymore. It seems like the > bug was not fixed, and the issue is still open: > http://bugs.python.org/issue13552 > > So my question is if we officially support Solaris and/or OpenIndiana. > If yes, how can we fix issues when we only have buildbot slave which > has memory errors, and no SSH access to this server? > > Solaris doesn't seem to be officially supported in Python, so I > suggest to drop the OpenIndiana buildbot (which is failing since at > least 2 years) and close all Solaris issues as "WONTFIX". > > Victor > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%40python.org -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/david.c.stewart%40intel.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] OpenIndiana and Solaris support
My guess is that Oracle owns the brand "Solaris" and its awful lawyers have done this. I don't think it's worth our time to support either Solaris or its descendants unless Oracle pays for it. It's too bad for the open source participants in OpenIndiana but realistically we just can't afford the distraction. On Fri, Sep 23, 2016 at 10:55 AM, Stewart, David C wrote: > Illumos, OpenIndiana et al are open source forks of Solaris. > Back before the acquisition by Oracle, Sun open sourced the Solaris OS, > called it OpenSolaris and encouraged projects to use it as an OS for x86 and > other architectures. But after the acquisition, the OpenSolaris project > seemed to end (I don’t know specifics) but several organizations carried on > with distributions / forks of OpenSolaris. > > On 9/23/16, 10:49 AM, "Python-Dev on behalf of Guido van Rossum" > gu...@python.org> wrote: > > What on earth is OpenIndiana? Its website is a mystery of buzzwords > and PR vagueness: > > "openindiana > Community-driven Illumos Distribution" > > "What is illumos ? > > From the illumos developer’s guide: “illumos is a consolidation of > software that forms the core of an Operating System. It includes the > kernel, device drivers, core system libraries, and utilities. It is > the home of many technologies include ZFS, DTrace, Zones, ctf, [...]" > > "The “Hipster” branch > > Hipster is a codename for rapidly moving development branch of > OpenIndiana and users might experience occasional breakages or > problems. Hipster is using rolling-release model and only publishes > installation ISOs once in a while. Every ISO release will be announced > via mailing list and ..." > > > That didn't exactly answer my questions. Clearly they don't care about > anyone who isn't already a user of openindiana or illumos. So I > propose that we shouldn't care about them either. > > On Fri, Sep 23, 2016 at 1:33 AM, Victor Stinner > wrote: > > Hi, > > > > My question is simple: do we officially support Solaris and/or > OpenIndiana? > > > > Jesus Cea runs an OpenIndiana buildbot slave: > > http://buildbot.python.org/all/buildslaves/cea-indiana-x86 > > "Open Indiana 32 bits" > > > > The platform module of Python says "Solaris-2.11", I don't know the > > exact OpenIndiana version. > > > > A lot of unit tests fail on this buildbot with MemoryError. I guess > > that it's related to Solaris which doesn't allow overcommit > > (allocating more memory than available memory on the system), or more > > simply because the slave has not enough memory. > > > > There is now an issue which seems specific to OpenIndiana: > > http://bugs.python.org/issue27847 > > > > It might impact Solaris as well, but the Solaris buildbot is offline > > since "684 builds". > > > > Five years ago, I reported a bug because the curses module of Python 3 > > doesn't build on Solaris nor OpenIndiana anymore. It seems like the > > bug was not fixed, and the issue is still open: > > http://bugs.python.org/issue13552 > > > > So my question is if we officially support Solaris and/or OpenIndiana. > > If yes, how can we fix issues when we only have buildbot slave which > > has memory errors, and no SSH access to this server? > > > > Solaris doesn't seem to be officially supported in Python, so I > > suggest to drop the OpenIndiana buildbot (which is failing since at > > least 2 years) and close all Solaris issues as "WONTFIX". > > > > Victor > > ___ > > Python-Dev mailing list > > Python-Dev@python.org > > https://mail.python.org/mailman/listinfo/python-dev > > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/guido%40python.org > > > > -- > --Guido van Rossum (python.org/~guido) > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/david.c.stewart%40intel.com > > -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
