Re: [Python-Dev] PEP 575: Unifying function/method classes
On 13 April 2018 at 02:12, Jeroen Demeyer wrote: > Dear Python developers, > > I would like to request a review of PEP 575, which is about changing the > classes used for built-in functions and Python functions and methods. The > text of the PEP can be found at > > https://www.python.org/dev/peps/pep-0575/ > > No substantial changes to the contents of the PEP were made compared to the > first posting. However, many details have been changed, clarified or added, > based on comments from the initial discussion thread and the work on an > implementation. I'm personally +1 on this version of the PEP (thank you for putting it together!), but have one request for clarification related to `__doc__`: at first glance, it isn't obvious why there are two different ways of storing the docstring (either m_ml->ml_doc or a dedicated func_code field). Those technically *could* be consolidated by always using m_ml->ml_doc, and changing the definition of base_function such that m_ml always pointed to a PyMethodDef instance. However, that's less than ideal when the doc string is already a Python object, since you need to convert between "const char *" and "PyObject *" when accessing the field from Python (and vice versa when setting it). There's also a section in the rationale which refers to METH_USRx flags, which I'm guessing from context are an idea you were considering proposing, but eventually dropped from the rest of the PEP. These remaining references to the concept just need to be cleaned up. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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] Timing for removing legacy Unicode APIs deprecated by PEP 393
Hi,
PEP 393 [1] deprecates some Unicode APIs relating to Py_UNICODE.
The PEP doesn't provide schedule for removing them. But the APIs are
marked "will be removed in 4.0" in the document.
When removing them, we can reduce `wchar_t *` member of unicode object.
It takes 8 bytes on 64bit platform.
[1]: "Flexible String Representation" https://www.python.org/dev/peps/pep-0393/
I thought Python 4.0 is the next version of 3.9. But Guido has different idea.
He said following at Zulip chat (we're trying it for now).
> No, 4.0 is not just what comes after 3.9 -- the major number change would
> indicate some kind of major change somewhere (like possibly the Gilectomy,
> which changes a lot of the C APIs). If we have more than 10 3.x versions,
> we'll just live with 3.10, 3.11 etc.
And he said about these APIs:
>> Unicode objects has some "Deprecated since version 3.3, will be removed in
>> version 4.0" APIs (pep-393).
>> When removing them, we can reduce PyUnicode size about 8~12byte.
>
> We should be able to deprecate these sooner by updating the docs.
Then, I want to reschedule the removal of these APIs.
Can we remove them in 3.8? 3.9? or 3.10?
I prefer sooner as possible.
---
Slightly off topic, there are 4bytes alignment gap in the unicode object,
on 64bit platform.
typedef struct {
struct {
unsigned int interned:2;
unsigned int kind:3;
unsigned int compact:1;
unsigned int ascii:1;
unsigned int ready:1;
unsigned int :24;
} state; // 4 bytes
// implicit 4 bytes gap here.
wchar_t *wstr; // 8 bytes
} PyASCIIObject;
So, I think we can reduce 12 bytes instead of 8 bytes when removing wstr.
Or we can reduce 4 bytes soon by moving `wstr` before `state`.
Off course, it needs siphash support 4byte aligned data instead of 8byte.
Regards,
--
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
Re: [Python-Dev] PEP 575: Unifying function/method classes
To make it easier to test and try out PEP 575, I created a binder repo: https://mybinder.org/v2/gh/jdemeyer/pep575binder.git /master?filepath=index.ipynb ___ 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 (2018-04-06 - 2018-04-13) 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: open6572 ( +4) closed 38452 (+32) total 45024 (+36) Open issues with patches: 2560 Issues opened (24) == #33238: AssertionError on await of Future returned by asyncio.wrap_fut https://bugs.python.org/issue33238 opened by Jason Haydaman #33239: tempfile module: functions with the 'buffering' option are inc https://bugs.python.org/issue33239 opened by MartyMacGyver #33240: shutil.rmtree fails when the inner floder is opened in Explore https://bugs.python.org/issue33240 opened by yuliu #33245: Unable to send CTRL_BREAK_EVENT https://bugs.python.org/issue33245 opened by Ofekmeister #33249: Unpickling objects with recursive references and partials fail https://bugs.python.org/issue33249 opened by aleneum #33250: Move VERSION attribute output up in pydoc (via help() builtin) https://bugs.python.org/issue33250 opened by handle #33251: ConfigParser.items returns items present in vars https://bugs.python.org/issue33251 opened by timster #33252: Clarify ResourceWarning documentation https://bugs.python.org/issue33252 opened by edmorley #33254: importlib.resources.contents() incorrectly yields an empty lis https://bugs.python.org/issue33254 opened by brett.cannon #33255: json.dumps has different behaviour if encoding='utf-8' or enco https://bugs.python.org/issue33255 opened by nhatcher #33256: module is not displayed by cgitb.html https://bugs.python.org/issue33256 opened by sblondon #33257: Race conditions in Tkinter with non-threaded Tcl https://bugs.python.org/issue33257 opened by Ivan.Pozdeev #33258: Unable to install 3.6.5 on Windows Server 2008 https://bugs.python.org/issue33258 opened by hpo0016 #33259: Encoding issue in the name of the local DST timezone https://bugs.python.org/issue33259 opened by maggyero #33261: inspect.isgeneratorfunction fails on hand-created methods https://bugs.python.org/issue33261 opened by jdemeyer #33262: Deprecate shlex.split(None) to read from stdin. https://bugs.python.org/issue33262 opened by christian.heimes #33263: Asyncio server enters an invalid state after a request with SO https://bugs.python.org/issue33263 opened by drtyrsa #33264: Remove to-be-deprecated urllib.request.urlretrieve function re https://bugs.python.org/issue33264 opened by adelfino #33266: 2to3 doesn't parse all valid string literals https://bugs.python.org/issue33266 opened by Zsolt Dollenstein #33267: ctypes array types create reference cycles https://bugs.python.org/issue33267 opened by Eric.Wieser #33269: InteractiveConsole behaves differently when used on terminal a https://bugs.python.org/issue33269 opened by Kadir Haldenbilen #33270: tags for anonymous code objects should be interned https://bugs.python.org/issue33270 opened by Daniel Moisset #33271: Exception handling matches subtypes, not subclasses https://bugs.python.org/issue33271 opened by Michael McCoy #33272: Which are reasonable reason for recursion limit in function _v https://bugs.python.org/issue33272 opened by mv.gavrilov Most recent 15 issues with no replies (15) == #33272: Which are reasonable reason for recursion limit in function _v https://bugs.python.org/issue33272 #33271: Exception handling matches subtypes, not subclasses https://bugs.python.org/issue33271 #33270: tags for anonymous code objects should be interned https://bugs.python.org/issue33270 #33263: Asyncio server enters an invalid state after a request with SO https://bugs.python.org/issue33263 #33261: inspect.isgeneratorfunction fails on hand-created methods https://bugs.python.org/issue33261 #33259: Encoding issue in the name of the local DST timezone https://bugs.python.org/issue33259 #33257: Race conditions in Tkinter with non-threaded Tcl https://bugs.python.org/issue33257 #33256: module is not displayed by cgitb.html https://bugs.python.org/issue33256 #33255: json.dumps has different behaviour if encoding='utf-8' or enco https://bugs.python.org/issue33255 #33251: ConfigParser.items returns items present in vars https://bugs.python.org/issue33251 #33250: Move VERSION attribute output up in pydoc (via help() builtin) https://bugs.python.org/issue33250 #33236: MagicMock().__iter__.return_value is different from MagicMock( https://bugs.python.org/issue33236 #33234: Improve list() pre-sizing for inputs with known lengths https://bugs.python.org/issue33234 #33225: imaplib module IMAP4.append() unexpected response BAD Command https://bugs.python.org/issue33225 #33220: Antivirus hits on python-2.7.14.amd64.msi file https://bugs.python.org/issue33220 Most recent 15 issues waiting for review (15) = #33271: Exception handling matches subtypes, not subclasses https://bugs.pytho
Re: [Python-Dev] PEP 575: Unifying function/method classes
> On Apr 12, 2018, at 9:12 AM, Jeroen Demeyer wrote: > > I would like to request a review of PEP 575, which is about changing the > classes used for built-in functions and Python functions and methods. The > text of the PEP can be found at > > https://www.python.org/dev/peps/pep-0575/ Thanks for doing this work. The PEP is well written and I'm +1 on the general idea of what it's trying to do (I'm still taking in all the details). It would be nice to have a section that specifically discusses the implications with respect to other existing function-like tooling: classmethod, staticmethod, partial, itemgetter, attrgetter, methodgetter, etc. Also, please mention the backward compatibility issue that will arise for code that currently relies on types.MethodType, types.BuiltinFunctionType, types.BuiltinMethodType, etc. For example, I would need to update the code in random._randbelow(). That code uses the existing builtin-vs-pure-python type distinctions to determine whether either the random() or getrandbits() methods have been overridden. This is likely an easy change for me to make, but there may be code like it the wild, code that would be broken if the distinction is lost. Raymond ___ 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
