Mailman 3 March 2018 - Python-ideas

In-place assignment for "boolean or"?
by Cammil Taank March 26, 2018

March 26, 2018

Hi, I find a common idiom in Python is: x = x or 'some other value' This is highly reminiscent of the problem inplace operators solve. Would it be a good idea to consider an inplace operator for this, perhaps: x or= 'some other value' ? Thanks, Cammil

6 6

New PEP proposal -- Pathlib Module Should Contain All File Operations -- version 2
by George Fischhof March 25, 2018

March 25, 2018

Hi folks, I added the list of functions to the proposal, here is the new version. George PEP: 9999 Title: Pathlib Module Should Contain All File Operations Author: George Fischhof <george at fischhof.hu> Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 15-Mar-2018 Python-Version: 3.8 Post-History: 12-Mar-2018, 17-Mar-2018 Abstract ======== This PEP proposes pathlib module to be a centralized place for all file-system related operations. Rationale ========= … [View More]

7 9

Re: [Python-ideas] New PEP proposal -- Pathlib Module ShouldContain All File Operations -- version 2
by Chris Barker - NOAA Federal March 25, 2018

March 25, 2018

On Mar 23, 2018, at 7:26 AM, Steve Dower <steve.dower(a)python.org> wrote: I had a colleague complaining to me the other day about having to search multiple packages for the right function to move a file (implying: with the same semantics as drag-drop). Thanks Steve — I know there isn’t any kind of consensus about exactly what should be part of a “most file operations” package/class, but I’ve found it odd that there doesn’t even seem to be acknowledgment among longtime python users … [View More]that the current hodgepodge is pretty dysfunctional for new users. One thing that’s been hammered home for me teaching newbies is that people get very far with computing these days without ever having touched a command line — certainly not a *nix one. Even the concept of a working directory is foreign to many. So telling them that they can create and manipulate paths in nifty ways with the Path object, but then telling them to go to the os module to do simple things like rename or delete a file, and then looking at the docs for the os module, which starts with a bunch of references to other modules you need for not quite as simple things (shutil) or more complex things (tempfile). Then you look through the module and see a LOT of low level cryptic and semi-platform dependent functions — not newbie friendly. Heck, I’ve been using Python for almost 20 years and I still have go look up whether it’s “delete” or “remove” or “unlink”. And there is so much in os that ipython or IDE completion doesn’t help much. So as not to only write a critical rant — here is a proposal of sorts: The python standard library should have one-stop shopping for the basic file system manipulations. “Basic” could be guided by “what users typically do with a GUI file manager” This could be yet another module, but given that navigating the file system ( I.e. path manipulation) is one of the things people typically do with a file manager, it makes sense to add it all to pathlib, maybe even all to the Path object. ( though maybe more advanced classes/functions could be added to pathlib as way to put it all in one place, while not expanding the Path namespace too much) Of course, this will require a substantial amount of work to work out the details in a PEP. I don’t have the time to do that, but if the OP or someone else does, I’ll help. -CHB If there isn’t a pathtools library on PyPI yet, this would certainly be valuable for newer developers. My view on Path is to either have everything on it or nothing on it (without removing what’s already there, of course), and since everything is so popular we should at least put everything in the one place. Top-posted from my Windows phone *From: *Mike Miller <python-ideas(a)mgmiller.net> *Sent: *Monday, March 19, 2018 10:51 *To: *python-ideas(a)python.org *Subject: *Re: [Python-ideas] New PEP proposal -- Pathlib Module ShouldContain All File Operations -- version 2 On 2018-03-18 10:55, Paul Moore wrote: >> Should Path() have methods to access all file operations? > > No, (Counterexample, having a Path operation to set Windows ACLs for a path). Agreed, not a big fan of everything filesystem-related in pathlib, simply because it doesn't read well. Having them scattered isn't a great experience either. Perhaps it would be better to have a filesystem package instead, maybe named "fs" that included all this stuff in one easy to use location. File stuff from os, path stuff from os.path, pathlib, utils like stat, and shutil etc? _______________________________________________ Python-ideas mailing list Python-ideas(a)python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/ _______________________________________________ Python-ideas mailing list Python-ideas(a)python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/ [View Less]

7 7

Re: [Python-ideas] PEP proposal: unifying function/method classes
by Jeroen Demeyer March 25, 2018

March 25, 2018

Dear Nick Coghlan, First of all, thanks for your insightful comments! On 2018-03-24 09:09, Nick Coghlan wrote: > As Antoine notes, unifying user-defined functions and builtin functions > would be fraught with backwards compatibility problems, so you probably > don't want to go down that path when your goal is "Let third parties > define types that are recognised by the core interpreter as being > user-defined functions". First of all, my post was mainly meant to get an answer … [View More]to "is this idea PEP-able?". I have never written a PEP and PEP 1 recommends this step. So it's not clear whether you want to say "that potential PEP is a bad idea" or just "go ahead with your PEP but be aware of backwards compatibility issues". It would be good to know what your backwards compatibility worries are. If I have a clearer idea of what could break, it would be easier to see if it's possible to not break that. Anyway, many (not all though!) backwards compatibility issues could be fixed by keeping the current built-in functions as a distinct type (say, old_style_builtin although I wouldn't use that name). My vague plan in the PEP is to introduce a base class "basefunction" and have old_style_builtin and Python functions be subclasses of that. Cython functions would then be another subclass. That way, we could implement "basefunction" properly and then implement old_style_builtin to support things like __get__ not binding as a method. > If it was just about introspection, then we could define a new protocol > method or attribute, update the inspect module to respect it, and call > it done. True. In fact, I got a long way by just defining inspect.isfunction as def isfunction(obj): return hasattr(type(obj), "__code__") > However, it seems to me that the most plausible path towards granting > Cython access to the optimised fast paths for native functions would be > setting Py_TPFLAGS_BASETYPE on types.FunctionType Why FunctionType and not BuiltinFunctionType? That's really the problem here: I want a function which is as fast as a built-in function but which behaves from a user's point of view as a Python function. > We can't introduce a new protocol > into those paths without slowing them down I don't really follow you here. Are you saying that it's impossible to allow custom function classes that are as fast as the current builtin functions? Instead of adding a flag for a subclass, we could add a flag for "can be called as if it is a built-in function". Jeroen. [View Less]

5 5

Inplace assignment for "boolean or"?
by Cammil Taank March 25, 2018

March 25, 2018

Hi, I find a common idiom in Python is: x = x or 'some other value' This is highly reminiscent of the problem inplace operators solve. Would it be a good idea to consider an inplace operator for this, perhaps: x or= 'some other value' ? Thanks, Cammil

1 0

PEP proposal: unifying function/method classes
by Jeroen Demeyer March 24, 2018

March 24, 2018

Dear python-ideas, I would like to draft a PEP to change the implementation of functions and methods in CPython. The idea for this PEP come from a discussion on https://bugs.python.org/issue30071 The core idea of the PEP is to reorganize classes for functions and methods with the goal of removing the difference between functions/methods implemented in C and functions/methods implemented in Python. Currently, CPython has two different function classes: the first is Python functions, … [View More]

3 2

Disallow importing the same module under multiple names
by Chris Billington March 21, 2018

March 21, 2018

The Python "double import" problem (discussed here <http://python-notes.curiousefficiency.org/en/latest/python_concepts/import_…>) leads to subtle bugs in code that change depending on what directory the code was run from. It's hard to think of reasons why importing the same filepath multiple times resulting in two copies of a module should be allowed, it almost always indicates a mistake in code. One possible solution I though of is to return the existing module upon import under a … [View More]

9 18

New PEP proposal -- Pathlib Module Should Contain All File Operations
by George Fischhof March 21, 2018

March 21, 2018

Good day all, as it seemed to be a good idea, I wrote a PEP proposal for pathlib to contain file operations. Here is the draft. What do you think about this? BR, George --------------------------- PEP: 9999 Title: Pathlib Module Should Contain All File Operations Author: George Fischhof <george at fischhof.hu> Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 15-Mar-2018 Python-Version: 3.8 Post-History: Abstract ======== This PEP proposes pathlib module to be … [View More]

22 47

Adding quantile to the statistics module
by PLIQUE Guillaume March 19, 2018

March 19, 2018

Hello everyone, Sorry if this subject has already been covered in the mailing list but I could not find it. My question is very simple: should the `quantile` function be added to python `statistics` module. I was very happy to learn the existence of this module in python3 only to later be forced to install numpy to compute a .7 quantile which is even more frustrating since the module actually provides an implementation of the median. I would therefore be willing to submit a PR to add the `… [View More]

7 11

Syntax idea for 2D lists\arrays
by Mikhail V March 17, 2018

March 17, 2018

Once there was a discussion about alternative list and arrays creation and assignment syntaxes. I think this is one of things with room for ideas and has frequent usage. I've had some ideas for syntax long ago, and now I remembered it because of the recent topic "Descouraging the implicit string concatenation". Idea is a concept for 2D arrays/lists syntax, which should simplify some editing boilerplate while working with arrays and improve readability for bigger arrays. Lets start with a … [View More]simple list example : L === 1 5 9 155 53 44 44 34 returns a 2d list: [[1, 5, 9, 155], [53, 44, 44, 34]] Syntax rules here: - "===" indicates parsing start (may be some other decorator) - data block *always* starts on the new line and parsing always like in a "def:" block (by indentation, till next negative indent) - new line is a next element - white space separated inner elements (tabs, spaces) Line continuation as usual: L === 2 1 5 \ 3 4 6 returns: [[2, 1, 5, 3, 4, 5]] SPECIAL CASE: 1d list could be explicitly marked with e.g. *: L ===* 2 1 5 3 4 6 returns : [2, 1, 5, 3, 4, 5] Also in 1d case one might omit the line continuation \: L ===* "msg1" "msg2" "error" returns: ["msg1", "msg2", "error"] IMO the latter looks nice and very useful for pretty-formatting of string lists. ---- *Examples for working with 3D arrays:* import numpy as np A = np.zeros((2,3,2)) A[0,0] === 8 8 A[1] === 0 0 155 1 1 1 returns: [[[ 8. 8.] [ 0. 0.] [ 0. 0.]] [[ 0. 0.] [ 155. 1.] [ 1. 1.]]] Compared to same operation in current syntax: A[0, 0] = [8, 8] A[1] = [ [0, 0], [155, 1], [1, 1] ] (which is ugly, though can be a bit more compact in simplest case) I think these examples show the general idea already. Pros: - clean readable look - copy-pasting tables from e.g. excel with little to no re-typing - no more editing annoyance with trailing commas/brackets Cons: - less compact for trivail cases (newline always added) ----- Problems that I see with this syntax: *Comma-separated vs space separated*. Space separated IMO better readable in general, though single space can be too dense with some proportional fonts. In this case two or more spaces could be better. Also consider expressions inside arrays, e.g.: SS ===* 11 + 3 5 6 SS ===* 11 + 3, 5, 6 I would not say comma really improves things here, but opinions may vary. Still, all in all, I am on the side of space-separated. Also numpy uses space-separated with print() method by default. ------ How do you like such syntax? Maybe someone can come up with counter-examples where such syntax will lead to ugly look? Mikhail [View Less]

4 7