Re: [Python-Dev] Deprecating "instance method" class
05.04.19 09:07, Jeroen Demeyer пише: On 2019-04-05 00:57, Greg Ewing wrote: If it's designed for use by things outside of CPython, how can you be sure nothing is using it? Of course I'm not sure. However: 1. So far, nobody in this thread knows of any code using it. 2. So far, nobody in this thread knows any use case for it. And if we end up deprecating and it was a mistake, we can easily revert the deprecation. I have a use case. I did not know this before, but it can be used to implement accelerated versions of separate methods instead of the whole class. I'm going to use it to further optimize total_ordering. Thanks Josh Rosenberg for the tip. ___ 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] Deprecating "instance method" class
On 2019-04-05 14:10, Serhiy Storchaka wrote: it can be used to implement accelerated versions of separate methods instead of the whole class. Could you elaborate? I'm curious what you mean. I'm going to use it to further optimize total_ordering. There are so many ways in which total_ordering is inefficient. If you really want it to be efficient, you should just implement it in C. ___ 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] Deprecating "instance method" class
05.04.19 14:27, Jeroen Demeyer пише: On 2019-04-05 14:10, Serhiy Storchaka wrote: it can be used to implement accelerated versions of separate methods instead of the whole class. Could you elaborate? I'm curious what you mean. It is easy to implement a function in C. But there is a difference between functions implemented in Python and C -- the latter are not descriptors. They behave like static methods when assigned to a class attribute, i.e. there is no implicit passing of the "self" argument. I'm going to use it to further optimize total_ordering. There are so many ways in which total_ordering is inefficient. If you really want it to be efficient, you should just implement it in C. Yes, this is what I want to do. I did not do this only because implementing method-like functions which which do not belong to concrete class implemented in C is not convention. But PyInstanceMethod_New() should help. ___ 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] Deprecating "instance method" class
On 2019-04-05 15:13, Serhiy Storchaka wrote: It is easy to implement a function in C. Why does it need to be a PyCFunction? You could put an actual method descriptor in the class. In other words, use PyDescr_NewMethod() instead of PyCFunction_New() + PyInstanceMethod_New(). It's probably going to be faster too since the instancemethod adds an unoptimized extra level of indirection. Yes, this is what I want to do. I did not do this only because implementing method-like functions which which do not belong to concrete class implemented in C is not convention. Sure, you could implement separate methods like __gt__ in C, but that's still less efficient than just implementing a specific tp_richcompare for total_ordering and then having the usual wrapper descriptors for __gt__. ___ 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] Deprecating "instance method" class
Let's stop here. This API is doing no harm, it's not a maintenance burden, clearly *some* folks have a use for it. Let's just keep it, okay? There are bigger fish to fry. On Fri, Apr 5, 2019 at 5:36 AM Jeroen Demeyer wrote: > On 2019-04-05 15:13, Serhiy Storchaka wrote: > > It is easy to implement a function in C. > > Why does it need to be a PyCFunction? You could put an actual method > descriptor in the class. In other words, use PyDescr_NewMethod() instead > of PyCFunction_New() + PyInstanceMethod_New(). It's probably going to be > faster too since the instancemethod adds an unoptimized extra level of > indirection. > > > Yes, this is what I want to do. I did not do this only because > > implementing method-like functions which which do not belong to concrete > > class implemented in C is not convention. > > Sure, you could implement separate methods like __gt__ in C, but that's > still less efficient than just implementing a specific tp_richcompare > for total_ordering and then having the usual wrapper descriptors for > __gt__. > ___ > 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] New Python Initialization API
Le dim. 31 mars 2019 à 01:49, Steve Dower a écrit : > Here is my first review of https://www.python.org/dev/peps/pep-0587/ and > in general I think it's very good. Ah nice, that's a good start :-) Thanks for reviewing it. Your email is long, and answer makes it even longer, so I will reply in multiple emails. > > ``PyWideCharList`` is a list of ``wchar_t*`` strings. > > I always forget whether "const" is valid in C99, but if it is, can we > make this a list of const strings? Short answer: no :-( This structure mostly exists to simplify the implementation. Sadly, "const PyWideCharList" doesn't automatically make PyWideCharList.items an array of "const wchar_t*". I tried some hacks to have an array of const strings... but it would be very complicated and not natural at all in C. Sadly, it's way more simple to have "wchar_t*" in practice. > I also prefer a name like ``PyWideStringList``, since that's what it is > (the other places we use WideChar in the C API refer only to a single > string, as far as I'm aware). I'm fine with this name. > > ``PyInitError`` is a structure to store an error message or an exit code > > for the Python Initialization. > > I love this struct! Currently it's private, but I wonder whether it's > worth making it public as PyError (or PyErrorInfo)? The PEP 587 makes the structure public, but I'm not sure about calling it PyError because PyInitError also allows to exit Python with an exit status which is something specific to the initialization. If you want to use a structure to reporting errors, I would prefer to add a new simpler PyError structure to only report an error message, but never exit Python. PyInitError use case is really specific to Python initialization. Moreover, the API is inefficient since it is returned by copy, not by reference. That's fine for Python initialization which only happens once and is not part of "hot code". I'm not sure if PyError would need to store the C function name where the error is triggered. Usually, we try hard to hide Python internals to the user. > > * ``exitcode`` (``int``): if greater or equal to zero, argument passed to > > ``exit()`` > > Windows is likely to need/want negative exit codes, as many system > errors are represented as 0x8000|(source of error)|(specific code). Hum, int was used in Python 3.6 code base. We change change PyInitError.exitcode type to DWORD on Windows, but use int on Unix. We can add a private field to check if the error is an error message or an exit code. Or maybe check if the error message is NULL or not. Py_INIT_ERR(MSG) must never be called with Py_INIT_ERR(NULL) and it should be called with a static string, not with a dynamically allocated string (since the API doesn't allow to release memory). > > * ``user_err`` (int): if non-zero, the error is caused by the user > > configuration, otherwise it's an internal Python error. > > Maybe we could just encode this as "positive exitcode is user error, > negative is internal error"? I'm pretty sure struct return values are > passed by reference in most C calling conventions, so the size of the > struct isn't a big deal, but without a proper bool type it may look like > this is a second error code (like errno/winerror in a few places). Honestly, I'm not sure that we really have to distinguish "user error" and "internal error". It's an old debate about calling abort()/DebugBreak() or not. It seems like most users are annoyed by getting a coredump on Unix when abort() is called. Maybe we should just remove Py_INIT_USER_ERR(), always use Py_INIT_ERR(), and never call abort()/DebugBreak() in Py_ExitInitError(). Or does anyone see a good reason to trigger a debugger on an initialization error? See https://bugs.python.org/issue19983 discussion: "When interrupted during startup, Python should not call abort() but exit()" Note: I'm not talking about Py_FatalError() here, this one will not change. 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] New Python Initialization API
About PyPreConfig and encodings. > The appendix is excellent, by the way. Very useful detail to have > written down. Thanks. The appendix is based on Include/cpython/coreconfig.h comments which is now my reference documentation. By the way, this header file contains more information about PyConfig fields than the PEP 587. For example, the comment on filesystem_encoding and filesystem_errors lists every single cases and exceptions (it describes the implementation). > > ``PyPreConfig`` structure is used to pre-initialize Python: > > > > * Set the memory allocator > > * Configure the LC_CTYPE locale > > * Set the UTF-8 mode > > I think we should have the isolated flag in here - oh wait, we do - I > think we should have the isolated/use_environment options listed in this > list :) My introduction paragraph only explains the changes made by Py_PreInitialize(): calling Py_PreInitialize() doesn't "isolate" Python. PyPreConfig.isolated is used to decide if Python reads environment variables or not. Examples: PYTHONMALLOC, PYTHONUTF8, PYTHONDEVMODE (which has an impact on PyPreConfig.allocator), PYTHONCOERCECLOCALE, etc. That's why isolated and use_environment are present in PyPreConfig and PyConfig. In practice, values should be equal in both structures. Moreover, if PyConfig.isolated is equal to 1, Py_InitializeFromConfig() updates _PyRuntime.preconfig.isolated to 1 ;-) > > * ``PyInitError Py_PreInitialize(const PyPreConfig *config)`` > > * ``PyInitError Py_PreInitializeFromArgs( const PyPreConfig *config, > int argc, char **argv)`` > > * ``PyInitError Py_PreInitializeFromWideArgs( const PyPreConfig > *config, int argc, wchar_t **argv)`` > > I hope to one day be able to support multiple runtimes per process - can > we have an opaque PyRuntime object exposed publicly now and passed into > these functions? I hesitated to include a "_PyRuntimeState*" parameter somewhere, but I chose to not do so. Currently, there is a single global variable _PyRuntime which has the type _PyRuntimeState. The _PyRuntime_Initialize() API is designed around this global variable. For example, _PyRuntimeState contains the registry of interpreters: you don't want to have multiple registries :-) I understood that we should only have a single instance of _PyRuntimeState. So IMHO it's fine to keep it private at this point. There is no need to expose it in the API. > (FWIW, I think we're a long way from being able to support multiple > runtimes *simultaneously*, so the initial implementation here would be > to have a PyRuntime_Create() that returns our global one once and then > errors until it's finalised. The migration path is probably to enable > switching of the current runtime via a dedicated function (i.e. one > active at a time, probably with thread local storage), since we have no > "context" parameter for C API functions, and obviously there are still > complexities such as poorly written extension modules that nonetheless > can be dealt with in embedding scenarios by simply not using them. This > doesn't seem like an unrealistic future, *unless* we add a whole lot of > new APIs now that can't allow it :) ) FYI I tried to design an internal API with a "context" to pass _PyRuntimeState, PyPreConfig, _PyConfig, the current interpreter, etc. => https://bugs.python.org/issue35265 My first need was to pass a memory allocator to Py_DecodeLocale(). There are 2 possible implementations: * Modify *all* functions to add a new "context" parameter and modify *all* functions to pass this parameter to sub-functions. * Store the current "context" as a thread local variable or something like that. I wrote a proof-of-concept of the first option: the implementation was very painful to write: a lot of changes which looks useless and a lot of new private functions which to pass the argument. I had to modify way too much code. I gave up. For the second option: well, there is no API change needed! It can be done later. Moreover, we already have such API! PyThreadState_Get() gets the Python thread state of the current thread: the current interpreter can be accessed from there. > > ``PyPreConfig`` fields: > > > > * ``coerce_c_locale_warn``: if non-zero, emit a warning if the C locale > > is coerced. > > * ``coerce_c_locale``: if equals to 2, coerce the C locale; if equals to > > 1, read the LC_CTYPE to decide if it should be coerced. > > Can we use another value for coerce_c_locale to determine whether to > warn or not? Save a field. coerce_c_locale is already complex, it can have 4 values: -1, 0, 1 and 2. I prefer keep a separated field. Moreover, I understood that you might want to coerce the C locale *and* get the warning, or get the warning but *not* coerce the locale. > > * ``legacy_windows_fs_encoding`` (Windows only): if non-zero, set the > > Python filesystem encoding to ``"mbcs"``. > > * ``utf8_mode``: if non-zero, enable the UTF-8 mode > > Why not just set the encodings here? For different technical reasons, yo
Re: [Python-Dev] New Python Initialization API
> > Example of Python initialization enabling the isolated mode:: > > > > PyConfig config = PyConfig_INIT; > > config.isolated = 1; > > Haven't we already used extenal values by this point that should have > been isolated? On this specific example, "config.isolated = 1;" ensures that Py_PreInitialize() is also called internally with "PyPreConfig.isolated = 1". > I'd rather have the isolation up front. Or better yet, > make isolation the default unless you call one of the "FromArgs" > functions, and then we don't actually need the config setting at all. While there are supporters of an "isolated Python" (sometimes called "system python"), the fact that it doesn't exist in any Linux distribution nor on any other operating system (Windows, macOS, FreeBSD), whereas it's already doable in Python 3.6 with Py_IsolatedFlag=1 makes me think that users like the ability to control Python with environment variables and configuration files. I would prefer to leave Python as not isolated by default. It's just a matter of comment line arguments. > > * The PEP 432 stores ``PYTHONCASEOK`` into the config. Do we need > > to add something for that into ``PyConfig``? How would it be exposed > > at the Python level for ``importlib``? Passed as an argument to > > ``importlib._bootstrap._setup()`` maybe? It can be added later if > > needed. > > Could we convert it into an xoption? It's very rarely used, to my knowledge. The first question is if there is any need for an embedder to change this option. Currently, importlib._bootstrap_external._install() reads the environment variable and it's the only way to control the option. ... By the way, importlib reads PYTHONCASEOK environment varaible even if isolated mode is enabled (sys.flags.isolated is equal to 1). Is it a bug? :-) 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] New Python Initialization API
> I think my biggest point (about halfway down) is that I'd rather use > argv/environ/etc. to *initialize* PyConfig and then only use the config > for initializing the runtime. That way it's more transparent for users > and more difficult for us to add options that embedders can't access. I chose to exclude PyConfig_Read() function from the PEP to try to start with the bare minimum public API and see how far we can go with that. The core of the PEP 587 implementation are PyPreConfig_Read() and PyConfig_Read() functions (currently called _PyPreConfig_Read() and _PyCoreConfig_Read()): they populate all fields so the read config becomes the reference config which will be applied. For example, PyConfig_Read() fills module_search_paths, from other PyConfig fields: it will become sys.path. I spent a lot of time to rework deeply the implementation of PyConfig_Read() to make sure that it has no side effect. Reading and writing the configuration are now strictly separated. So it is safe to call PyConfig_Read(), modify PyConfig afterwards, and pass the modified config to Py_InitializeFromConfig(). Do you think that exposing PyConfig_Read() would solve some of your problems? > Currently you have three functions, that take a PyConfig and optionally > also use the environment/argv to figure out the settings: > > > * ``PyInitError Py_InitializeFromConfig(const PyConfig *config)`` > > * ``PyInitError Py_InitializeFromArgs(const PyConfig *config, int > argc, char **argv)`` > > * ``PyInitError Py_InitializeFromWideArgs(const PyConfig *config, int > argc, wchar_t **argv)`` > > I would much prefer to see this flipped around, so that there is one > initialize function taking PyConfig, and two functions that will fill > out the PyConfig based on the environment: > > (note two of the "const"s are gone) > > * ``PyInitError Py_SetConfigFromArgs(PyConfig *config, int argc, char > **argv)`` > * ``PyInitError Py_SetConfigFromWideArgs(PyConfig *config, int argc, > wchar_t **argv)`` > * ``PyInitError Py_InitializeFromConfig(const PyConfig *config)`` This implementation evolved *A LOT* last months. I was *very confused* until the pre-initialization phase was introduced which solved a lot of bootstrap issues. After I wrote down the PEP and read it again, I also came to the same conclusion: Py_InitializeFromConfig(config) should be enough, and we can add helper functions to set arguments on PyConfig (as you showed). 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] New Python Initialization API
For the PyMainConfig structure idea, I cannot comment at this point. I need more time to think about it. About the "path configuration" fields, maybe a first step to enhance the API would be to add the the following function: PyInitError PyConfig_ComputePath(PyConfig *config, const wchar *home); where home can be NULL (and PyConfig.module_search_paths_env field goes away: the function reads PYTHONPATH env var internally). This function would "compute the path configuration", what's currently listed in _PyCoreConfig under: /* Path configuration outputs */ int use_module_search_paths; /* If non-zero, use module_search_paths */ _PyWstrList module_search_paths; /* sys.path paths. Computed if use_module_search_paths is equal to zero. */ wchar_t *executable;/* sys.executable */ wchar_t *prefix;/* sys.prefix */ wchar_t *base_prefix; /* sys.base_prefix */ wchar_t *exec_prefix; /* sys.exec_prefix */ wchar_t *base_exec_prefix; /* sys.base_exec_prefix */ #ifdef MS_WINDOWS wchar_t *dll_path; /* Windows DLL path */ #endif 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] Deprecating "instance method" class
05.04.19 15:33, Jeroen Demeyer пише: On 2019-04-05 15:13, Serhiy Storchaka wrote: It is easy to implement a function in C. Why does it need to be a PyCFunction? You could put an actual method descriptor in the class. In other words, use PyDescr_NewMethod() instead of PyCFunction_New() + PyInstanceMethod_New(). It's probably going to be faster too since the instancemethod adds an unoptimized extra level of indirection. PyDescr_NewMethod() takes PyTypeObject* which is not known at that moment. But maybe passing &PyBaseObject_Type will make a trick. I need to try. Yes, this is what I want to do. I did not do this only because implementing method-like functions which which do not belong to concrete class implemented in C is not convention. Sure, you could implement separate methods like __gt__ in C, but that's still less efficient than just implementing a specific tp_richcompare for total_ordering and then having the usual wrapper descriptors for __gt__. At Python level we can monkeypatch __gt__, but not tp_richcompare. In any case, removing a C API is a large breakage, and it is better to avoid it unless that API is inherently broken. ___ 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] Deprecating "instance method" class
On 05/04/2019 17.46, Guido van Rossum wrote: > Let's stop here. This API is doing no harm, it's not a maintenance > burden, clearly *some* folks have a use for it. Let's just keep it, > okay? There are bigger fish to fry. Sounds good to me. My code is 12 years ago and I can't remember any complain. I have closed the BPO issue and PR. ___ 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] Deprecating "instance method" class
On 2019-04-05 19:53, Serhiy Storchaka wrote: At Python level we can monkeypatch __gt__, but not tp_richcompare. Sure, but you're planning to use C anyway so that's not really an argument. ___ 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 (2019-03-29 - 2019-04-05)
Python tracker at https://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:
open7056 ( +8)
closed 41231 (+55)
total 48287 (+63)
Open issues with patches: 2816
Issues opened (44)
==
#36260: Cpython/Lib vulnerability found and request a patch submission
https://bugs.python.org/issue36260 reopened by krnick
#36474: RecursionError resets trace function set via sys.settrace
https://bugs.python.org/issue36474 opened by blueyed
#36475: PyEval_AcquireLock() and PyEval_AcquireThread() do not handle
https://bugs.python.org/issue36475 opened by eric.snow
#36476: Runtime finalization assumes all other threads have exited.
https://bugs.python.org/issue36476 opened by eric.snow
#36478: backport of pickle fixes to Python 3.5.7 uses C99 for loops
https://bugs.python.org/issue36478 opened by Anthony Sottile
#36479: Exit threads when interpreter is finalizing rather than runtim
https://bugs.python.org/issue36479 opened by eric.snow
#36481: telnetlib process_rawq() callback
https://bugs.python.org/issue36481 opened by Quanthir
#36484: Can't reorder TLS 1.3 ciphersuites
https://bugs.python.org/issue36484 opened by Eman Alashwali
#36485: Establish a uniform way to clear all caches in a given module
https://bugs.python.org/issue36485 opened by serhiy.storchaka
#36486: Bugs and inconsistencies in unicodedata
https://bugs.python.org/issue36486 opened by dscorbett
#36487: Make C-API docs clear about what the "main" interpreter is
https://bugs.python.org/issue36487 opened by nanjekyejoannah
#36488: os.sendfile() on BSD and macOS does not return bytes sent on E
https://bugs.python.org/issue36488 opened by giampaolo.rodola
#36489: add filename_extension_map and/or content-types_map dict(s) to
https://bugs.python.org/issue36489 opened by Daniel Black
#36490: Modernize function signature format in Archiving section of sh
https://bugs.python.org/issue36490 opened by CAM-Gerlach
#36494: bdb.Bdb.set_trace: should set f_trace_lines = True
https://bugs.python.org/issue36494 opened by blueyed
#36495: Out-of-bounds array reads in Python/ast.c
https://bugs.python.org/issue36495 opened by blarsen
#36497: Undocumented behavior in csv.Sniffer (preferred delimiters)
https://bugs.python.org/issue36497 opened by thomas
#36500: Add "regen-*" equivalent projects for Windows builds
https://bugs.python.org/issue36500 opened by anthony shaw
#36501: Remove POSIX.1e ACLs in tests that rely on default permissions
https://bugs.python.org/issue36501 opened by Ivan.Pozdeev
#36502: The behavior of str.isspace() for U+00A0 and U+202F is differe
https://bugs.python.org/issue36502 opened by Jun
#36503: remove references to aix3 and aix4 in \*.py
https://bugs.python.org/issue36503 opened by Michael.Felt
#36504: Signed integer overflow in _ctypes.c's PyCArrayType_new()
https://bugs.python.org/issue36504 opened by ZackerySpytz
#36506: [security] CVE-2019-10268: An arbitrary execution vulnerabilit
https://bugs.python.org/issue36506 opened by bigbigliang
#36508: python-config --ldflags must not contain LINKFORSHARED ("-Xlin
https://bugs.python.org/issue36508 opened by vstinner
#36509: Add iot layout for windows iot containers
https://bugs.python.org/issue36509 opened by Paul Monson
#36511: Add Windows ARM32 buildbot
https://bugs.python.org/issue36511 opened by Paul Monson
#36512: future_factory argument for Thread/ProcessPoolExecutor
https://bugs.python.org/issue36512 opened by stefanhoelzl
#36513: Add support for building arm32 nuget package
https://bugs.python.org/issue36513 opened by Paul Monson
#36515: unaligned memory access in the _sha3 extension
https://bugs.python.org/issue36515 opened by doko
#36516: Python Launcher can not recognize pyw file as Python GUI Scrip
https://bugs.python.org/issue36516 opened by gjj2828
#36517: typing.NamedTuple does not support mixins
https://bugs.python.org/issue36517 opened by rectalogic
#36518: Avoid conflicts when pass arbitrary keyword arguments to Pytho
https://bugs.python.org/issue36518 opened by serhiy.storchaka
#36519: Blake2b/s implementations have minor GIL issues
https://bugs.python.org/issue36519 opened by gwk
#36520: Email header folded incorrectly
https://bugs.python.org/issue36520 opened by Jonathan Horn
#36521: Consider removing docstrings from co_consts in code objects
https://bugs.python.org/issue36521 opened by rhettinger
#36523: missing docs for IOBase writelines
https://bugs.python.org/issue36523 opened by Marcin Niemira
#36527: unused parameter warnings in Include/object.h (affecting build
https://bugs.python.org/issue36527 opened by AMDmi3
#36528: Remove duplicate tests in Lib/tests/re_tests.py
https://bugs.python.org/issue36528 opened by xtreak
#36529: Python from WindowsStore: can't install package using "-m pip"
https://bugs.python.org/issue36529 opened
Re: [Python-Dev] Deprecating "instance method" class
On 2019-04-05 17:46, Guido van Rossum wrote: This API is doing no harm, it's not a maintenance burden What if the following happens? 1. For some reason (possibly because of this thread), people discover instancemethod and start using it. 2. People realize that it's slow. 3. It needs to be made more efficient, causing new code bloat and maintenance burden. clearly *some* folks have a use for it. I'm not convinced. I don't think that instancemethod is the right solution for functools.total_ordering for example. Jeroen. ___ 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] Deprecating "instance method" class
On Fri, Apr 5, 2019 at 11:30 AM Jeroen Demeyer wrote: > On 2019-04-05 17:46, Guido van Rossum wrote: > > This API is doing no harm, it's not a maintenance > > burden > > What if the following happens? > > 1. For some reason (possibly because of this thread), people discover > instancemethod and start using it. > > 2. People realize that it's slow. > > 3. It needs to be made more efficient, causing new code bloat and > maintenance burden. > Then we can consider improving the documentation if there are performance implications. But the point is if there's code out there already using it without issue then ripping it out of the C API is painful since we don't have nearly as good of a deprecation setup as we do in Python code. Not everything about the C APi is about performance. -Brett > > > clearly *some* folks have a use for it. > > I'm not convinced. OK, but as of right now others like me are convinced and we typically err on the side of backwards-compatibility in these kinds of situations. -Brett > I don't think that instancemethod is the right > solution for functools.total_ordering for example. > > > Jeroen. > ___ > 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/brett%40python.org > ___ 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] Deprecating "instance method" class
On 2019-04-05 21:58, Brett Cannon wrote: Then we can consider improving the documentation if there are performance implications. Sure, we could write in the docs something like "Don't use this, this is not what you want. It's slow and there are better alternatives like method descriptors". Should I do that (with better wording of course)? since we don't have nearly as good of a deprecation setup as we do in Python code. I don't get this. One can easily raise a DeprecationWarning from C code, there is plenty of code already doing that. Jeroen. ___ 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] Deprecating "instance method" class
On Fri, Apr 5, 2019 at 1:11 PM Jeroen Demeyer wrote: > On 2019-04-05 21:58, Brett Cannon wrote: > > Then we can consider improving the documentation if there are > > performance implications. > > Sure, we could write in the docs something like "Don't use this, this is > not what you want. It's slow and there are better alternatives like > method descriptors". Should I do that (with better wording of course)? > Up to you. Obviously help is always appreciated, just a question of who feels qualified to review the PR. > > > since we don't have nearly as good of a deprecation setup as we > > do in Python code. > > I don't get this. One can easily raise a DeprecationWarning from C code, > there is plenty of code already doing that. > True. I personally prefer compile-time warnings for that sort of thing, but you're right we can do it at the Python "level" with a raise of a DeprecationWarning on those instances. ___ 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] PEP-582 and multiple Python installations
On 02.04.19 18:10, Steve Dower wrote:
> On 02Apr2019 0817, Calvin Spealman wrote:
>> (I originally posted this to python-ideas, where I was told none of this
>> PEP's
>> authors subscribe so probably no one will see it there, so I'm posting it
>> here
>> to raise the issue where it can get seen and hopefully discussed)
>
> Correct, thanks for posting. (I thought we had a "discussions-to" tag with
> distutils-sig on it, but apparently not.)
>
>> While the PEP does show the version number as part of the path to the actual
>> packages, implying support for multiple versions, this doesn't seem to be
>> spelled out in the actual text. Presumably __pypackages__/3.8/ might sit
>> beside __pypackages__/3.9/, etc. to keep future versions capable of
>> installing
>> packages for each version, the way virtualenv today is bound to one version
>> of
>> Python.
>>
>> I'd like to raise a potential edge case that might be a problem, and likely
>> an
>> increasingly common one: users with multiple installations of the *same*
>> version of Python. This is actually a common setup for Windows users who use
>> WSL, Microsoft's Linux-on-Windows solution, as you could have both the
>> Windows
>> and Linux builds of a given Python version installed on the same machine. The
>> currently implied support for multiple versions would not be able to separate
>> these and could create problems if users pip install a Windows binary package
>> through Powershell and then try to run a script in Bash from the same
>> directory, causing the Linux version of Python to try to use Windows python
>> packages.
>>
>> I'm not actually sure what the solution here is. Mostly I wanted to raise the
>> concern, because I'm very keen on WSL being a great entry path for new
>> developers and I want to make that a better experience, not a more confusing
>> one. Maybe that version number could include some other unique identify,
>> maybe
>> based on Python's own executable. A hash maybe? I don't know if anything like
>> that already exists to uniquely identify a Python build or installation.
>
> Yes, this is a situation we're aware of, and it's caught in the conflict of
> "who
> is this feature meant to support".
This smells the same like mixing system installed python packages (deb/rpm) with
one managed by pip, and pip touching system installed packages.
> Since all platforms have a unique extension module suffix (e.g.
> "module.cp38-win32.pyd"), it would be possible to support this with "fat"
> packages that include all binaries (or some clever way of merging wheels for
> multiple platforms).
unfortunately not. The Android developers opted out of that, reverting that
change. Also how would you differentiate win32 builds for different
architectures? But maybe this is already done.
> And since this is already in CPython itself, it leads to about the only
> reasonable solution - instead of "3.8", use the extension module suffix
> "cp38-win32". (Wheel tags are not in core CPython, so we can't use those.)
>
> But while this seems obvious, it also reintroduces problems that this has the
> potential to fix - suddenly, just like installing into your global
> environment,
> your packages are not project-specific anymore but are Python-specific. Which
> is
> one of the major confusions people run into ("I pip installed X but now can't
> import it in python").
>
> So the main points of discussion right now are "whose problem does this solve"
> and "when do we tell people they need a full venv". And that discussion is
> mostly happening at
> https://discuss.python.org/t/pep-582-python-local-packages-directory/963/
>
> Cheers,
> 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/doko%40ubuntu.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] New Python Initialization API
On Sat, Apr 6, 2019 at 1:13 AM Victor Stinner wrote: > > > > ``PyPreConfig`` fields: > > > > > > * ``coerce_c_locale_warn``: if non-zero, emit a warning if the C locale > > > is coerced. > > > * ``coerce_c_locale``: if equals to 2, coerce the C locale; if equals to > > > 1, read the LC_CTYPE to decide if it should be coerced. > > > > Can we use another value for coerce_c_locale to determine whether to > > warn or not? Save a field. > > coerce_c_locale is already complex, it can have 4 values: -1, 0, 1 and 2. > I prefer keep a separated field. > > Moreover, I understood that you might want to coerce the C locale *and* > get the warning, or get the warning but *not* coerce the locale. > Are these configurations are really needed? Applications embedding Python may not initialize Python interpreter at first. For example, vim initializes Python when Python is used first time. On the other hand, C locale coercion should be done ASAP application starts. I think dedicated API for coercing C locale is better than preconfig. // When application starts: Py_CoerceCLocale(warn=0); // later... Py_Initialize(); -- Inada Naoki ___ 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
