Mailman 3 March 2021 - Python-ideas

Fwd: [Python-Dev] Suggestion About Python Syntax
by George Harding March 3, 2021

March 3, 2021

---------- Forwarded message --------- From: Anthony Farino <anthonyf(a)pacemschool.org> Date: Wed, Mar 3, 2021 at 5:52 PM Subject: [Python-Dev] Suggestion About Python Syntax To: <python-dev(a)python.org> I love the Python scripting language, but there’s something that would make it much better. Almost every other programming language uses curly braces to enclose blocks of code and semicolons after the lines of code. That means that: 1. You can have as much white space as … [View More]

1 0

Integer concatenation to byte string
by mmax42852＠gmail.com March 2, 2021

March 2, 2021

Currently, the only way to concatenate an integer to a bytes object is by converting the integer to bytes with a function call before concatenating. And there is no way to make a mutable bytes object without a function call. I propose an array-type string like the, or for the bytearray. It would work as a mutable b-string, as foo = a"\x00\x01\x02abcÿ" # a-string, a mutable bytes object. foo[0] = 123 # Item assignment foo+= 255 … [View More]

7 6

SimpleNamespace vs object
by Sven R. Kunze March 2, 2021

March 2, 2021

Starting this as a new thread for the interested reader: On 17.02.21 11:18, Chris Angelico wrote: > On Wed, Feb 17, 2021 at 9:11 PM Sven R. Kunze <srkunze(a)mail.de> wrote: >> Still think that "object()" should be writable since this seems like an >> arbitrary restriction (+SimpleNamespace is no builtin and at least I >> would use object() for fast PoCs or dirty hackery). But I guess there's >> been discussion around this already. >> [...] > Using … [View More]

19 44

Have virtual environments led to neglect of the actual environment?
by Random832 March 1, 2021

March 1, 2021

I was reading a discussion thread <https://gist.github.com/tiran/2dec9e03c6f901814f6d1e8dad09528e> about various issues with the Debian packaged version of Python, and the following statement stood out for me as shocking: Christian Heimes wrote: > Core dev and PyPA has spent a lot of effort in promoting venv because we don't want users to break their operating system with sudo pip install. I don't think sudo pip install should break the operating system. And I think if it does, that … [View More]

13 20

Cross-platform extended attribute APIs
by David Gilman March 1, 2021

March 1, 2021

The standard library implements support for Linux's extended attribute API with os.getxattr/setxattr/listxattr/removexattr. I'd like to implement support for more platforms under the same API in the standard library. Proof of concept ================ I've implemented a native-Python library (using ctypes) that runs CI tests against Linux, Mac OS X and FreeBSD. If accepted, this library could also be used to backport support to Python 3.6+. https://github.com/dgilman/xattr-compat API … [View More]discussion ============== It is at least possible to do this on all three platforms as demonstrated by my library. Mutable mapping --------------- I've also implemented a mutable mapping (inspired by os.environ) that can be used for access to a file's extended attributes. Unlike os.environ you have to instantiate the class with your path, but once you have it, it's a straightforward API. # class Xattrs(path: os.PathLike, follow_symlinks: bool = True) import xattr_compat xattrs = xattr_compat.Xattrs("./my_file") xattrs["user.humanfund.xattr"] = b"hello\0world" print("Extended attributes:", xattrs.items()) MacOS X ------- Not listed in the manpage but defined in the xattr.h header file are a few more bitflags: XATTR_NOSECURITY, XATTR_NODEFAULT and XATTR_SHOWCOMPRESSION. Linux's setxattr takes a flags argument so os.setxattr() has a flags argument, but on MacOS X all four functions take a flags argument. It may be worth adding a flags= kwarg to all four Python functions to support the MacOS X case. MacOS X also has no restrictions on the name of the format key which is nice. The manpages demand that you use UTF-8 for the encoding as well. Linux ----- Linux requires the attribute name to start with "user.", "system.", "trusted." or "security.". Luckily the current Python implementation doesn't attempt to validate this, leaving it up to the kernel to set errno when you don't do this. Because Linux was the most restrictive of these platforms existing code will work correctly on the new platforms. FreeBSD/NetBSD -------------- These systems added an argument attrnamespace to all of their xattr system calls. There are only two namespaces: EXTATTR_NAMESPACE_SYSTEM and EXTATTR_NAMESPACE_USER. There are no further restrictions on the attribute name. Unfortunately, directly supporting attrnamespace in the Python API is going to require breaking away a bit from the Linux interface. You can't rely on checking the attribute string to determine which namespace a key should go into because there will be keys without those prefixes on live systems. You also can't trim the string in Python before handing it off to the kernel because it is valid to have a key that starts with "user." and so on in the BSDs and I imagine there are probably a lot of users who want compatibility with Linux and are doing exactly that. I have my library using the USER namespace by default which seems to be the correct thing to do. However, it is still possible that someone might want to read or write from a SYSTEM namespace xattr. I've extended the function signature to optionally take a tuple in place of the os.PathLike argument. The first member of the tuple is the namespace constant, the second is the actual path or file descriptor that you want to work on. I'm pretty happy with this API - it doesn't break compatibility for the tiny user base of FreeBSD users who are interested in reading SYSTEM-namespaced xattrs from Python but also doesn't clutter things up too much. But maybe this is too tacky for the standard library. Windows ------- If the Windows Subsystem for Linux implements xattr this code can likely mimic what it does. I don't have a Windows machine so I can't comment on if that is already there. Bikeshedding ============ Should the mapping class be named os.xattrs or os.xattr or os.Xattrs or os.Xattr? Implementation ============== If accepted, what sort of tests would be expected as part of the PR? I already have a handful of unit tests in the xattr_compat repo. -- David Gilman :DG< [View Less]

1 0