Mailman 3 March 2021 - Python-ideas

Fwd: [Python-Dev] Suggestion About Python Syntax
by George Harding 03 Mar '21

03 Mar '21

---------- 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 you want. 2. You don’t need to worry about indentation, and you can indent whenever you want. I hope that you consider these issues and fix them in Python 4 (if you ever make it). Sincerely, Anthony, age 10. -- mm m # ## m mm mm#mm # mm mmm m mm m m # # #" # # #" # #" "# #" # "m m" #mm# # # # # # # # # # #m# # # # # "mm # # "#m#" # # "# m" "" _______________________________________________ Python-Dev mailing list -- python-dev(a)python.org To unsubscribe send an email to python-dev-leave(a)python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/RZR2O3Y… Code of Conduct: http://python.org/psf/codeofconduct/

1 0

Integer concatenation to byte string
by mmax42852＠gmail.com 02 Mar '21

02 Mar '21

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 # Works the same as bytesvariable+=b"123" foo+= a"\x255\x00" # Concatenation with itself foo+= b"\x255\x00" # Cross compatibility with bytes objects. This would be processed the same as, or would be the bytearray, >>> type(a"\x00\x01\x02abcÿ") <class 'bytearray'>

7 6

SimpleNamespace vs object
by Sven R. Kunze 02 Mar '21

02 Mar '21

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 SimpleNamespace is the best way to do this, and maybe there's a > good argument for making it a builtin (or at least giving it a shorter > name), but changing object would be problematic. I would be skeptical that either those ideas would help a lot. My reasoning is the following: Given the usual terminology in computer science and programming courses, we think in "objects". "Namespaces" on the other side are quite static, usual representing surroundings or environments which in turn can contain "objects". Sadly, the terminology-wise ideal solution is blocked by technical reasons. The thinking in the concepting use-case goes like "I need a blank object which I can do random things with" (yes, including attaching new attributes to it, maybe other stuff as well). The thinking "hey I need a (simple) namespace which I can attach attributes to" requires quite some thoughts especially when being in a more "concepting"/"trying out ideas" mood. In this phase, one does not simply know what one needs ("could be sentinel only", "could be data carrying", "could be signalling", "could something else") and things move quickly. So, just as an example when renaming/aliasing "types.SimpleNamespace" to "builtins.thing", my expectation would be that people could be horribly confused seeing "object" and "thing" being a builtin when used in a project simultaneously. This always leads to questions like "what to use now?" As a conclusion I would say let's leave it like it is since it's a minor issue. Best Sven

19 44

Have virtual environments led to neglect of the actual environment?
by Random832 01 Mar '21

01 Mar '21

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 problem should be solved rather than merely advising users against using it. And why is it, anyway, that distributions whose package managers can't coexist with pip-installed packages don't ever seem to get the same amount of flak for "damaging python's brand" as Debian is getting from some of the people in the discussion thread? Why is it that this community is resigned to recommending a workaround when distributions decide the site-packages directory belongs to their package manager rather than pip, instead of bringing the same amount of fiery condemnation of that practice as we apparently have for *checks notes* splitting parts of the stdlib into optional packages? Why demand that pip be present if we're not going to demand that it works properly? I think that installing packages into the actual python installation, both via distribution packaging tools and pip [and using both simultaneously - the Debian model of separated dist-packages and site-packages folders seems like a reasonable solution to this problem] can and should be a supported paradigm, and that virtual environments [or more extreme measures such as shipping an entire python installation as part of an application's deployment] should ideally be reserved for the rare corner cases where that doesn't work for some reason. How is it that virtual environments have become so indispensable, that no-one considers installing libraries centrally to be a viable model anymore? Are library maintainers making breaking changes too frequently, reasoning that if someone needs the old version they can just venv it? Is there some other cause?

13 20

Cross-platform extended attribute APIs
by David Gilman 28 Feb '21

28 Feb '21

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 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<

1 0