Re: [Python-Dev] [python-committers] Should I delay 3.5.3 and 3.4.6 by two weeks?
On 19.12.2016 06:26, Larry Hastings wrote: > > > Python 3.6.0 final just slipped by two weeks. I scheduled 3.5.3 and 3.4.6 to > ship about a month after 3.6.0 did, to "let the dust settle" around the > release. I expect a flood of adoption of 3.6, and people switching will find > bugs, and maybe those bugs are in 3.5 or 3.4. So it just seemed sensible. > > 3.6 just slipped by two weeks. So now there's less than two weeks between > 3.6.0 > final shipping and tagging the release canddiates for 3.5.3 and 3.4.6. This > isn't as much time as I'd like. > > If I had total freedom to do as I liked, I'd slip my releases by two weeks to > match 3.6. But there might be people planning around 3.5.3 and 3.4.6--like > Guido was waiting for 3.5.3 for something iirc. > > So, if you have an opinion, please vote for one of these three options: > > * Don't slip 3.5.3. and 3.4.6. > * Slip 3.5.3 and 3.4.6 by two weeks to match 3.6.0. > * Slip 3.5.3 and 3.4.6 by a whole month, to give 3.6.0 the ability to >slip again without us having to change the release. I would appreciate a 3.5.3 release which doesn't slip, or which only slips by a week, to be available before the Debian freeze. Neither Debian nor Ubuntu ship the 3.4 branch anymore, so for 3.4 I'm fine with any solution. Matthias ___ 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] Deprecate `from __future__ import unicode_literals`?
On Mon, Dec 19, 2016 at 11:50 PM, Chris Barker wrote: > Please don't get rid of unicode+literals -- I don't even think we should > depreciate it as a recommendation or discourage it. > > Maybe a note or two added as to where issues may arise would be good. > > I've found importing unicode_literals to be an excellent way to write > py2/3 code. And I have never found a problem. > > I'm also hoping that my py2/3 compatible code will someday be py3 only -- > and then I'll be really glad that I don't have all those u" all over the > place. > > Also it does "automagically" do the right thing with, for instance passing > a literal to the file handling functions in the os module -- so that's > pretty nice. > > The number of times you need to add a b"" is FAR fewer than "text" string > literals. Let's keep it. > > -CHB > > Same thing here... also, it helps coding with the same mindset of Python 3, where everything is unicode by default -- and yes, there are problems if you use a unicode in an API that accepts bytes on Python 2, but then, you can also have the same issues on Python 3 -- you need to know and keep track on the bytes vs unicode everywhere (although they're syntactically similar to declare, they're not the same thing) and I find that there are less places where you need to put b'' than u'' (if you code with unicode in mind in Python 2)... On the ideal world, Python 2 would actually be improved to accept unicode on the places where Python 3 accepts unicode (such as subprocess.Popen, etc) to make it easier in porting applications that actually do the "right" thing on Python 2 to go to Python 3. Best Regards, Fabio ___ 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] Issue #23903 - stable API is incomplete
For those who aren't aware, the stable API (PEP 384) is broken on Windows because the exports from python3.dll have not been kept up to date. Over at http://bugs.python.org/issue23903 we're trying to address this by automatically generating the DLL based on the headers. This has shown that many more functions and data items are in the stable ABI than expected. If it's left entirely to me, I'm planning to add all the public APIs into python3.dll, which will commit them to the stable API for good, and remove the _private APIs that have been added since we last updated the DLL. However, if you've added an API recently that you didn't mean to be in the stable API, here is your chance to remove it. The full list of APIs that have never been available on Windows in the stable ABI but are in the headers are below. If it should not be considered long-term stable, then it needs "#ifndef Py_LIMITED_API" around it. Note that anything NOT on this list has already been released, and so it cannot be removed from the stable API at this time. I want to resolve this for 3.5.3 (that is, release all of these as stable and then it cannot be undone), which is coming up very soon, so if any of the public APIs should NOT be stable, please fix them, and if any of the private APIs SHOULD be stable, they'll probably need version-specific guards (see moduleobject.h). Cheers, Steve Full list of APIs to be added to python3.dll: PyAST_FromNode PyAST_FromNodeObject PyAST_Validate PyCmpWrapper_Type PyCodec_NameReplaceErrors PyErr_GetExcInfo PyErr_ResourceWarning PyErr_SetExcFromWindowsErr PyErr_SetExcFromWindowsErrWithFilename PyErr_SetExcFromWindowsErrWithFilenameObject PyErr_SetExcFromWindowsErrWithFilenameObjects PyErr_SetExcInfo PyErr_SetExcWithArgsKwargs PyErr_SetFromErrnoWithFilenameObjects PyErr_SetFromWindowsErr PyErr_SetFromWindowsErrWithFilename PyErr_SetImportError PyErr_SetImportErrorSubclass PyErr_SyntaxLocationEx PyExc_BlockingIOError PyExc_BrokenPipeError PyExc_ChildProcessError PyExc_ConnectionAbortedError PyExc_ConnectionError PyExc_ConnectionRefusedError PyExc_ConnectionResetError PyExc_FileExistsError PyExc_FileNotFoundError PyExc_InterruptedError PyExc_IsADirectoryError PyExc_ModuleNotFoundError PyExc_NotADirectoryError PyExc_PermissionError PyExc_ProcessLookupError PyExc_RecursionError PyExc_ResourceWarning PyExc_StopAsyncIteration PyExc_TimeoutError PyExc_WindowsError PyImport_AddModuleObject PyImport_ExecCodeModuleObject PyImport_ImportFrozenModuleObject PyImport_ImportModuleLevelObject PyMarshal_ReadObjectFromString PyMarshal_WriteLongToFile PyMarshal_WriteObjectToFile PyMarshal_WriteObjectToString PyMem_Calloc PyMember_GetOne PyMember_SetOne PyMemoryView_FromMemory PyModuleDef_Init PyModuleDef_Type PyModule_AddFunctions PyModule_ExecDef PyModule_FromDefAndSpec2 PyModule_GetNameObject PyModule_NewObject PyModule_SetDocString PyNode_AddChild PyNode_Free PyNode_ListTree PyNode_New PyNumber_InPlaceMatrixMultiply PyNumber_MatrixMultiply PyOS_CheckStack PyOS_FSPath PyObject_Calloc PyObject_GenericSetDict PyParser_SimpleParseStringFlagsFilename PySys_AddXOption PySys_GetXOptions PyThread_GetInfo PyThread_ReInitTLS PyThread_acquire_lock PyThread_acquire_lock_timed PyThread_allocate_lock PyThread_create_key PyThread_delete_key PyThread_delete_key_value PyThread_exit_thread PyThread_free_lock PyThread_get_key_value PyThread_get_stacksize PyThread_get_thread_ident PyThread_init_thread PyThread_release_lock PyThread_set_key_value PyThread_set_stacksize PyThread_start_new_thread PyUnicode_AsMBCSString PyUnicode_AsUCS4 PyUnicode_AsUCS4Copy PyUnicode_AsWideCharString PyUnicode_DecodeCodePageStateful PyUnicode_DecodeLocale PyUnicode_DecodeLocaleAndSize PyUnicode_DecodeMBCS PyUnicode_DecodeMBCSStateful PyUnicode_EncodeCodePage PyUnicode_EncodeLocale PyUnicode_FindChar PyUnicode_GetLength PyUnicode_ReadChar PyUnicode_Substring PyUnicode_WriteChar Py_DecodeLocale Py_EncodeLocale Py_FileSystemDefaultEncodeErrors Py_SetPath Py_hexdigits _PyBytes_DecodeEscape _PyDebug_PrintTotalRefs _PyThreadState_Current _PyTrash_thread_deposit_object _PyTrash_thread_destroy_chain _PyUnicode_DecodeUnicodeEscape _Py_AddToAllObjects _Py_ForgetReference _Py_GetRefTotal _Py_HashSecret_Initialized _Py_NegativeRefcount _Py_NewReference _Py_PrintReferenceAddresses _Py_PrintReferences _Py_RefTotal ___ 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] Issue #23903 - stable API is incomplete
I should also point out that when 3.6.0 releases, all of these will already be in the stable API for other platforms. I'm not going to take a stance on whether we can break it there between 3.6.0 and 3.6.1, but it may already be too late to remove any. Top-posted from my Windows Phone -Original Message- From: "Steve Dower" Sent: 12/20/2016 17:56 To: "Python Dev" Subject: [Python-Dev] Issue #23903 - stable API is incomplete For those who aren't aware, the stable API (PEP 384) is broken on Windows because the exports from python3.dll have not been kept up to date. Over at http://bugs.python.org/issue23903 we're trying to address this by automatically generating the DLL based on the headers. This has shown that many more functions and data items are in the stable ABI than expected. If it's left entirely to me, I'm planning to add all the public APIs into python3.dll, which will commit them to the stable API for good, and remove the _private APIs that have been added since we last updated the DLL. However, if you've added an API recently that you didn't mean to be in the stable API, here is your chance to remove it. The full list of APIs that have never been available on Windows in the stable ABI but are in the headers are below. If it should not be considered long-term stable, then it needs "#ifndef Py_LIMITED_API" around it. Note that anything NOT on this list has already been released, and so it cannot be removed from the stable API at this time. I want to resolve this for 3.5.3 (that is, release all of these as stable and then it cannot be undone), which is coming up very soon, so if any of the public APIs should NOT be stable, please fix them, and if any of the private APIs SHOULD be stable, they'll probably need version-specific guards (see moduleobject.h). Cheers, Steve Full list of APIs to be added to python3.dll: PyAST_FromNode PyAST_FromNodeObject PyAST_Validate PyCmpWrapper_Type PyCodec_NameReplaceErrors PyErr_GetExcInfo PyErr_ResourceWarning PyErr_SetExcFromWindowsErr PyErr_SetExcFromWindowsErrWithFilename PyErr_SetExcFromWindowsErrWithFilenameObject PyErr_SetExcFromWindowsErrWithFilenameObjects PyErr_SetExcInfo PyErr_SetExcWithArgsKwargs PyErr_SetFromErrnoWithFilenameObjects PyErr_SetFromWindowsErr PyErr_SetFromWindowsErrWithFilename PyErr_SetImportError PyErr_SetImportErrorSubclass PyErr_SyntaxLocationEx PyExc_BlockingIOError PyExc_BrokenPipeError PyExc_ChildProcessError PyExc_ConnectionAbortedError PyExc_ConnectionError PyExc_ConnectionRefusedError PyExc_ConnectionResetError PyExc_FileExistsError PyExc_FileNotFoundError PyExc_InterruptedError PyExc_IsADirectoryError PyExc_ModuleNotFoundError PyExc_NotADirectoryError PyExc_PermissionError PyExc_ProcessLookupError PyExc_RecursionError PyExc_ResourceWarning PyExc_StopAsyncIteration PyExc_TimeoutError PyExc_WindowsError PyImport_AddModuleObject PyImport_ExecCodeModuleObject PyImport_ImportFrozenModuleObject PyImport_ImportModuleLevelObject PyMarshal_ReadObjectFromString PyMarshal_WriteLongToFile PyMarshal_WriteObjectToFile PyMarshal_WriteObjectToString PyMem_Calloc PyMember_GetOne PyMember_SetOne PyMemoryView_FromMemory PyModuleDef_Init PyModuleDef_Type PyModule_AddFunctions PyModule_ExecDef PyModule_FromDefAndSpec2 PyModule_GetNameObject PyModule_NewObject PyModule_SetDocString PyNode_AddChild PyNode_Free PyNode_ListTree PyNode_New PyNumber_InPlaceMatrixMultiply PyNumber_MatrixMultiply PyOS_CheckStack PyOS_FSPath PyObject_Calloc PyObject_GenericSetDict PyParser_SimpleParseStringFlagsFilename PySys_AddXOption PySys_GetXOptions PyThread_GetInfo PyThread_ReInitTLS PyThread_acquire_lock PyThread_acquire_lock_timed PyThread_allocate_lock PyThread_create_key PyThread_delete_key PyThread_delete_key_value PyThread_exit_thread PyThread_free_lock PyThread_get_key_value PyThread_get_stacksize PyThread_get_thread_ident PyThread_init_thread PyThread_release_lock PyThread_set_key_value PyThread_set_stacksize PyThread_start_new_thread PyUnicode_AsMBCSString PyUnicode_AsUCS4 PyUnicode_AsUCS4Copy PyUnicode_AsWideCharString PyUnicode_DecodeCodePageStateful PyUnicode_DecodeLocale PyUnicode_DecodeLocaleAndSize PyUnicode_DecodeMBCS PyUnicode_DecodeMBCSStateful PyUnicode_EncodeCodePage PyUnicode_EncodeLocale PyUnicode_FindChar PyUnicode_GetLength PyUnicode_ReadChar PyUnicode_Substring PyUnicode_WriteChar Py_DecodeLocale Py_EncodeLocale Py_FileSystemDefaultEncodeErrors Py_SetPath Py_hexdigits _PyBytes_DecodeEscape _PyDebug_PrintTotalRefs _PyThreadState_Current _PyTrash_thread_deposit_object _PyTrash_thread_destroy_chain _PyUnicode_DecodeUnicodeEscape _Py_AddToAllObjects _Py_ForgetReference _Py_GetRefTotal _Py_HashSecret_Initialized _Py_NegativeRefcount _Py_NewReference _Py_PrintReferenceAddresses _Py_PrintReferences _Py_RefTotal ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/pytho
