Mailman 3 March 2015 - Python-ideas

OrderedDict.insert()
by Thomas Güttler 27 Mar '15

27 Mar '15

I am missing OrderedDict.insert() Other people, too: http://stackoverflow.com/questions/16664874/how-can-i-add-the-element-at-th… Why was it not implemented up to now? Why not implement it for the future? Regards, Thomas Güttler

6 8

list.pop() accepting a list of integers as argument
by pedro santos 26 Mar '15

26 Mar '15

Is this best way to remove multiple items from a list? Because if so I think passing a list of integers through pop would be cleaner. Code here: http://repl.it/f6E Cheers -- *------------------------------[image: http://i153.photobucket.com/albums/s202/animatics/probiner-sig.gif]Pedro Alpiarça dos Santos Animator 3DModeler Illustrator >> http://probiner.x10.mx/ <http://probiner.x10.mx/>*

3 3

Re: [Python-ideas] list.pop() accepting a list of integers as argument
by pedro santos 25 Mar '15

25 Mar '15

Hi David Thanks for the idea. Just some considerations: - Del is a list with indices and not the items themselves, so if you replace the code with that line it won't output the same result. - *del *deletes all items with an equal value so if I have L=[2,2,2,1,2] and have Del=[2], I end up with L=[1], which useful, but not my goal here and the reason I went to pop() instead, so I can address indices. Same remark for *in*. - I wouldn't mind if* in* and *del* approach would work if you instead of checking the value would be checking if a list had such indices and then deleting all at the same time if so. Again the same code with comments. http://repl.it/f6E/3 Thanks On Thu, Mar 26, 2015 at 2:04 AM, David Blaschke <dwblas(a)gmail.com> wrote: > ist comprehension is straight forward IMHO, and possibly faster than > pop depending on whether the items are removed one at a time or just > marked for deletion later > new_list=[item for item in L if item not in Del] > > On 3/25/15, pedro santos <probiner(a)gmail.com> wrote: > > Is this best way to remove multiple items from a list? > > Because if so I think passing a list of integers through pop would be > > cleaner. > > > > Code here: http://repl.it/f6E > > > > Cheers > > > > > > > > > > -- > > > > > > > > > > *------------------------------[image: > > http://i153.photobucket.com/albums/s202/animatics/probiner-sig.gif]Pedro > > Alpiarça dos Santos Animator 3DModeler Illustrator >> > > http://probiner.x10.mx/ <http://probiner.x10.mx/>* > > > > > -- > Only when you actually get to the state where there is neither > delusion nor enlightenment are you finally comfortable...Foyan > -- *------------------------------[image: http://i153.photobucket.com/albums/s202/animatics/probiner-sig.gif]Pedro Alpiarça dos Santos Animator 3DModeler Illustrator >> http://probiner.x10.mx/ <http://probiner.x10.mx/>*

1 0

gofmt for Python: standardized styling as a language feature
by Nicholas Chammas 25 Mar '15

25 Mar '15

The Zen of Python <https://www.python.org/dev/peps/pep-0020/> says: There should be one— and preferably only one —obvious way to do it. Python already has a style guide in PEP 8 <https://www.python.org/dev/peps/pep-0008/>. More importantly, from a practical standpoint, Python has automated third-party tools for checking and enforcing PEP 8 guidelines: - pep8 <https://pypi.python.org/pypi/pep8/>: Python style guide checker - autopep8 <https://pypi.python.org/pypi/autopep8/>: A tool that automatically formats Python code to conform to the PEP 8 style guide I say “more importantly” because these tools are what make the style guide alive. If a Python project of any non-trivial size is PEP 8-compliant, you can bet it’s because the project contributors automated the process of enforcing compliance using these or similar tools. (Certainly, some parts of PEP 8 are hard to automate. But those parts that *can* be automated have been, to the benefit of Python programmers everywhere.) Having a style guide provides benefits that I think are well-understood. Additionally having a standardized style that can be *applied automatically* makes whatever benefits of the style guide that much more prevalent in the greater community and actually effective. As many of you may already know, the Go-lang folks have such a feature for their language (though they call it formatting as opposed to styling). They note: go fmt your code <http://blog.golang.org/go-fmt-your-code>: Gofmt <http://golang.org/cmd/gofmt/> is a tool that automatically formats Go source code. Gofmt’d code is: - easier to *write*: never worry about minor formatting concerns while hacking away, - easier to *read*: when all code looks the same you need not mentally convert others’ formatting style into something you can understand. - easier to *maintain*: mechanical changes to the source don’t cause unrelated changes to the file’s formatting; diffs show only the real changes. - *uncontroversial*: never have a debate about spacing or brace position ever again! Of course, we don’t worry about brace positions, but these benefits of a standardized style carry over into any language. :) So, in the spirit of The Zen of Python, and taking a cue from Go-lang’s gofmt <http://blog.golang.org/go-fmt-your-code>, I propose we promote standardized auto-styling to a first-class language feature. UI-wise, I’m not sure how exactly we’d present this to the user. Perhaps something like: python -m style script.py Don’t read too much into this UI suggestion, as I’m really not sure how it would be implemented. The point is to expose some auto-styler as a standard language tool—i.e. something like autopep8, but as a built-in utility. On running a command like that, script.py would automatically be updated to conform to the standard style we want to promote. This is what gofmt does for Go code. Promoting an auto-styler to be a first-class language feature builds on the foundation laid in PEP 8 and in tools like pep8 and autopep8. It helps reduce code style to more of a non-issue for Python projects than it already is. ------------------------------ *Side Note 1:* There was a previous python-ideas discussion about introducing standardized formatting here <https://groups.google.com/d/msg/python-ideas/ic-aPSvamS4/2lj53Em0VrsJ>, but it was totally derailed by the OP’s suggestion that the formatter introduce block delimiters. I am proposing no such thing here. *Side Note 2:* I found these additional comments <http://blog.golang.org/go-fmt-your-code> about gofmt interesting: Gofmt also enables gofix <http://golang.org/cmd/fix/>, which can make arbitrarily complex source transformations. Gofix was an invaluable tool during the early days when we regularly made breaking changes to the language and libraries. Introducing Gofix <http://blog.golang.org/introducing-gofix>: Gofix gives us the ability to fix mistakes or completely rethink package APIs without worrying about the cost of converting existing code. Python has its own analog to gofix in 2to3 <https://docs.python.org/3/library/2to3.html>, though that was built for a specific migration rather than as a regular language feature. I wonder if having a gofmt analog in Python would similarly facilitate future migrations, though I doubt we’ll ever have a big as migration as the 2-to-3 one.

16 37

os.path.commonprefix: Yes that old chestnut.
by Paddy3118 24 Mar '15

24 Mar '15

I had to add a comment to an RC entry <http://rosettacode.org/wiki/Longest_common_prefix#Python>that was using os.path.commonprefix to compute the longest common prefix which it does regardless of path separators, (which is what it should do). It has been discussed before <http://bugs.python.org/issue10395>- it goes back to the nineties it seems, but we are still left with a misplaced function, (it should be str.commonprefix), with an awful hack of saying "yes we know its ballsed up" in the documentation <https://docs.python.org/3.5/library/os.path.html?highlight=commonprefix#os.…> . I guess we missed a great opportunity to fix this when we moved to Python 3 too!? The fix seems clear: deprecate os.path.commonprefix whilst creating a true os.path.commonpath and str.commonprefix. The deprecated function should hang around and the standard libs modified to switch to the new function(s) I've heard that some religious people put obvious faults in their work as only their god should get so close to perfection - maybe that's why we still have this wart :-)

8 26

Re: [Python-ideas] pathlib.Path.parts - tuple of path objects rather than strings?
by Markus Unterwaditzer 24 Mar '15

24 Mar '15

Forgot to reply to list! -------- Original Message -------- From: Markus Unterwaditzer <markus(a)unterwaditzer.net> Sent: 24 March 2015 13:25:27 CET To: Paul Moore <p.f.moore(a)gmail.com> Subject: Re: [Python-ideas] pathlib.Path.parts - tuple of path objects rather than strings? I'd say treating each part as full-blown Path doesn't make sense from a semantical POV. Simply mapping Path over the results is also a potential source of bugs, since each part is now a relative path to the CWD, instead of the previous segment. I'd suggest that an additional property is added where: Path("/usr/bin/true").newproperty == (Path("/"), Path("/usr"), Path("/usr/bin"), Path("/usr/bin/true")) I.e. each part is a prefix of the next one. But I'm not sure where you'd use that. -- Markus On 24 March 2015 13:08:25 CET, Paul Moore <p.f.moore(a)gmail.com> wrote: >One occasional problem I have with pathlib.Path.parts is that it >returns a tuple of strings. For WindowsPath objects, paths are case >insensitive but strings aren't. So we get the situation that > >>>> p1 = pathlib.PureWindowsPath('foo') >>>> p2 = pathlib.PureWindowsPath('FOO') >>>> p1 == p2 >True >>>> p1.parts == p2.parts >False > >Making p1.parts return a tuple of objects of type p1.__class__ would >address this: > >>>> [p1.__class__(p) for p in p1.parts] == [p2.__class__(p) for p in >p2.parts] >True > >Is this something that's worth changing (pathlib is still provisional, >so the backward compatibility break would technically be allowed, even >if it's not ideal)? Or would an extra property, say p.path_parts that >returned a tuple of path objects be worth considering? > >As it is, use of path.parts is a potential source of portability bugs, >where Unix users don't consider the case sensitivity issue. (Heck, as >a Windows user, I almost missed the problem in my implementation of >common_prefix, so it's not just Unix users...) > >Paul >_______________________________________________ >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/

3 3

Re: [Python-ideas] PEP 484 (Type Hints) -- second draft
by David Foster 24 Mar '15

24 Mar '15

* It's a bit vague how local variables should be typed in the presence of multiple assignments. Consider: ``` if x > 0: root = sqrt(x) # type: int else: root = None ``` It seems that the type of `root` should be inferred as `Union[int, None]` (AKA `Optional[int]`), but there's no discussion about this type of inference in the PEP. Cases like this are the only way that the proposed blank `Undefined` value makes sense to me, using an example like: ``` root = Undefined # type: Optional[int] if x > 0: root = sqrt(x) # type: int else: root = None ``` * +1 for only allowing .pyi as the extension for stub files (and not also .py). Makes it very clear that they should only be interpreted as stubs. * -1 that `Optional[T1]` is unnecessary. It's conceptually more clean and directly corresponds conceptually to types like `int?` and `?int` from other languages. * +1 for the argument order cast(x, T). This is consistent with (x: T) elsewhere. -- David Foster http://dafoster.net/ P.S. Apologies if this doesn't add to the message chain correctly. There's no clearly correct way to reply to a digest email from Mailman.

13 18

Fwd: pathlib.Path.parts - tuple of path objects rather than strings?
by Paul Moore 24 Mar '15

24 Mar '15

For completeness, here's my reply that got sent off-list... On 24 March 2015 at 12:25, Markus Unterwaditzer <markus(a)unterwaditzer.net> wrote: > I'd say treating each part as full-blown Path doesn't make sense from a semantical POV. > > Simply mapping Path over the results is also a potential source of bugs, since each part is now a relative path to the CWD, instead of the previous segment. Fair point. Although I tend to view them as just "relative" - to what depends on context (in this case, "to the preceding bits in the list" is implied). But I agree, people may not be expecting that and so could make mistakes. I still think using strings is equally a bug magnet, though. There's actually no clean way of getting the correct case sensitivity behaviour *apart* from making the parts into path objects. I don't think your suggestion of each part being a prefix of the next would actually help in any of the places I've ever used .parts. Paul PS BTW, did you mean to send to just me rather than the list? I'd like to know what other people think of your point.

1 0

Re: [Python-ideas] pathlib.Path.parts - tuple of path objects rather than strings?
by Markus Unterwaditzer 24 Mar '15

24 Mar '15

No, I always forget. I've forwarded the message. I understand that the current behavior creates bugs too, however, I'd say the drawbacks I described are much bigger. The next option would be to create a separate type for path segments which has the appropriate comparison behavior: PathSegment, or more generically, PathString. On 24 March 2015 13:37:34 CET, Paul Moore <p.f.moore(a)gmail.com> wrote: >On 24 March 2015 at 12:25, Markus Unterwaditzer ><markus(a)unterwaditzer.net> wrote: >> I'd say treating each part as full-blown Path doesn't make sense from >a semantical POV. >> >> Simply mapping Path over the results is also a potential source of >bugs, since each part is now a relative path to the CWD, instead of the >previous segment. > >Fair point. Although I tend to view them as just "relative" - to what >depends on context (in this case, "to the preceding bits in the list" >is implied). But I agree, people may not be expecting that and so >could make mistakes. > >I still think using strings is equally a bug magnet, though. There's >actually no clean way of getting the correct case sensitivity >behaviour *apart* from making the parts into path objects. > >I don't think your suggestion of each part being a prefix of the next >would actually help in any of the places I've ever used .parts. > >Paul > >PS BTW, did you mean to send to just me rather than the list? I'd like >to know what other people think of your point.

1 0

pathlib.Path.parts - tuple of path objects rather than strings?
by Paul Moore 24 Mar '15

24 Mar '15

One occasional problem I have with pathlib.Path.parts is that it returns a tuple of strings. For WindowsPath objects, paths are case insensitive but strings aren't. So we get the situation that >>> p1 = pathlib.PureWindowsPath('foo') >>> p2 = pathlib.PureWindowsPath('FOO') >>> p1 == p2 True >>> p1.parts == p2.parts False Making p1.parts return a tuple of objects of type p1.__class__ would address this: >>> [p1.__class__(p) for p in p1.parts] == [p2.__class__(p) for p in p2.parts] True Is this something that's worth changing (pathlib is still provisional, so the backward compatibility break would technically be allowed, even if it's not ideal)? Or would an extra property, say p.path_parts that returned a tuple of path objects be worth considering? As it is, use of path.parts is a potential source of portability bugs, where Unix users don't consider the case sensitivity issue. (Heck, as a Windows user, I almost missed the problem in my implementation of common_prefix, so it's not just Unix users...) Paul

1 0