Mailman 3 March 2015 - Python-ideas

math.tau
by anatoly techtonik March 18, 2015

March 18, 2015

>>> import math >>> math.tau Traceback (most recent call last): File "<stdin>", line 1, in <module> AttributeError: 'module' object has no attribute 'tau' >>> math.pi * 2 6.283185307179586 https://www.youtube.com/watch?v=2hhjsSN-AiU =)

3 3

Re: [Python-ideas] gofmt for Python: standardized styling as a language feature
by Nicholas Chammas March 17, 2015

March 17, 2015

Please disregard this thread in favor of the one that went successfully through via Mailman here: https://groups.google.com/forum/#!topic/python-ideas/xute5NmXRps Apologies again about the duplicate posting.

1 0

Re: [Python-ideas] gofmt for Python: standardized styling as a language feature
by Nicholas Chammas March 17, 2015

March 17, 2015

I posted this via Google Groups and got a response back by email saying my post was rejected because I wasn't a list member. So I signed up via Mailman and resubmitted this post by mail. Not sure if I should expect a duplicate post to show up here on not... Apologies. On Tuesday, March 17, 2015 at 2:13:31 PM UTC-4, Nicholas Chammas wrote: > > 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. > >

1 0

Add str.bmp() to only expand non-BMP chars, for tkinter use
by Terry Reedy March 16, 2015

March 16, 2015

3.x comes with builtin ascii(obj) to return a string representation of obj that only has ascii characters. >>> s = 'a\xaa\ua000\U0001a000' >>> len(s) 4 >>> sa = ascii(s) >>> sa, len(sa) ("'a\\xaa\\ua000\\U0001a000'", 23) This allows any string to be printed on even a minimal ascii terminal. Python also comes with the tkinter interface to tk. Tk widgets are not limited to ascii but support the full BMP subset of unicode. (This is better than Windows consoles limited by codepages.) Thus, for use with tkinter, ascii() has two faults: it adds a quote at beginning and end of the string (like repr); it expands too much. I looked at repr, which expands less, but it seems to be buggy in that it is not consistent in its handling of non-BMP chars. >>> s1 = 'a\xaa\ua000\U00011000' >>> sa = 'a\xaa\ua000\U0001a000' >>> s1r = repr(s1); len(s1r) 6 >>> sar = repr(sa); len(sar) 15 '\U0001a000' gets expanded, and can be printed. '\U00011000' does not, and cannot be consistently printed. >>> s1r # only works at >>> prompt "'a\xaa\ua000\U00011000'" >>> print(s1r) # required in programs Traceback (most recent call last): File "<pyshell#43>", line 1, in <module> print(s1r) File "C:\Programs\Python34\lib\idlelib\PyShell.py", line 1347, in write return self.shell.write(s, self.tags) UnicodeEncodeError: 'UCS-2' codec can't encode characters in position 4-4: Non-BMP character not supported in Tk Printing s1 or sa directly, by either means, gives the same error. (Since '>>> expr' is supposed to be the same as 'print(expr)' the above difference puzzles me.) Even if repr always worked as it does for '\U0001a000', there would still be the problem of the added quotes. I therefore proposed the addition of a new str method, such as 's.bmp()', that returns s with all non-BMP chars, and only such chars, expanded. Since strings (in CPython) are internally marked by 'kind', the method would just return s when no expansion is needed. I presume it could otherwise re-use the expansion code already in repr. Aside from tkinter programmers in general, this issue bites Idle in at least two ways. Internally, filenames can contain non-BMP chars and Idle displays them in 3 places. See http://bugs.python.org/issue23672. Externally, Idle users sometimes want to print strings with non-BMP chars. I believe the automatic use of .bmp() with console prints could be user selectable. There have been issues about this on both our tracker and StackOverflow. I believe that the use of non-BMP chars is becoming more common and can no longer be simply dismissed as too rare to worry about. Telling Windows users that they are better off than if they use python directly, with the windows console, does not solve the inability to print any Python string. This proposal would. -- Terry Jan Reedy

5 4

CPython needs to revamp/replace it's build system && Cross-compiling Python sucks
by Ryan Gonzalez March 16, 2015

March 16, 2015

I've been trying to work on Issue 23496. And want to tear my hair out. I've noticed a few problems with Python's current build system: - There is no separation of the host C compiler and the target C compiler. When you give configure a C compiler for cross-compiling, make will happily try to build Parser/pgen with the cross-compiler. And try to run the generated executable. And fail. I know you can use `make touch` to get around this, but it still sucks. - For some reason, autoconf decided to re-configure everything about 2 minutes into make. But it didn't pass any of the flags I needed, resulting in everything failing. - I do not like having to use this for configuring: PYTHON_FOR_BUILD=`realpath ../cpython/python` CC=arm-linux-androideabi-clang CXX=arm-linux-androideabi-clang++ ./configure --host=arm-linux-androideabi --build=x86_64 --disable-ipv6 ac_cv_file__dev_ptmx=no ac_cv_file__dev_ptc=no ac_cv_have_long_long_format=yes At the same time, I'm not quite sure how many people would want to sift through the 5000 lines in configure.ac or the 1650 lines in Makefile.pre.in. I just get the feeling that, whenever I build Python, there are too many holes/hacks to get around make/autoconf things. -- Ryan If I were in a 10-story building glass-sided building and forced to write either Go or autconf scripts, I’d jump out a window. http://kirbyfan64.github.io/

9 14

About people's accounts being deactivated due to bounces
by Brett Cannon March 16, 2015

March 16, 2015

We're trying to figure out what's going on. Just re-enable your account if you got a notice that it was temporarily disabled.

5 4

Modify inspect.getmembers() to return object members in source code order
by Cem Karan March 16, 2015

March 16, 2015

I'd like to suggest that inspect.getmembers() be modified to return elements in the order they are defined in the source code rather than in alphabetical order. For people that want the output in sorted order, the call would become 'sorted(inspect.getmembers())', which is relatively easy to do. For me, and anyone else that is generating code from source code, the advantage is that the generated code is 'in the right order'. As an example, consider generating unit tests for code that really should have had unit tests as the code was written, but didn't[1]. If inspect.getmembers() returned the elements in the same order as they appear in the source code, then we can generate code similar to the following[2]: """ members = inspect.getmembers(SomeoneNeedsToCleanThisUp) names = [x[0] for x in members] def test_gen(name): return (" def test_{0!s}(self):\n".format(name) + " raise NotImplementedError('He Who Shall Not Be Named, But Is On My Special List had better fill this in NOW!')\n" + " # End of test_{0!s}()\n".format(name)) tests = "\n".join([test_gen(x) for x in names]) # Writing out names to the right location, etc. """ Thoughts? Thanks, Cem Karan [1] This may possibly be the reason why I want to propose this change... [2] Banged out in Mail.app very quickly, may have bugs, and definitely is not production code.

4 6

datetime: Support infinity
by Thomas Güttler March 12, 2015

March 12, 2015

Hi, at the end of january there was a mail thread about "datetime: Support infinity". Some people liked it :-) What can I do to get this done? Regards, Thomas

1 0

Implementation of adding dicts
by julien tayon March 11, 2015

March 11, 2015

Hello, Just in case I have to implementation of dict/sub/mult/div for dict. I have chosen only one rule: + - / * should behave with the least surprise principle which is so far linear algebrae when dealing with stuff that looks like mathematics Implementation 2 (trying trait and mixin) http://archery.readthedocs.org/en/latest/bow.html Implementation 1 (experimenting weired stuff with dict (like addition and transforming dict with dict in a «matrix like» fashion) http://vectordict.readthedocs.org/en/latest/algebrae.html And the linear algebrae test: http://vectordict.readthedocs.org/en/latest/consistent.html And the results https://github.com/jul/ADictAdd_iction/blob/master/docs/source/result.txt I just noticed the dicussion, I have been using the + - / * for aggregations for 2 years now and it is really helpful. I can give any feedback. I also had to overload + - for Sets ^^ and I have the cosine similarities that works nicely out of the box with my definition

1 0

"Regular" namespace packages
by Dmitry Malinovsky March 10, 2015

March 10, 2015

Hello, I'm implementing an extensible library. Along with the library itself I want to implement various extensions (and some of these extensions will be also pluggable). I found that creating a namespace package will be user-friendly (to distinguish default implementations from third-party ones). However, current namespace packages implementation does not allow me to have a dedicated regular package with the same name as the namespace. E.g. if I have to namespaced packages: top.packageA and top.packageB, I can't have dedicated top package. (Actually, I can do that: py module is the example, but this way is not easy to implement for the library developers and to understand by external contributors). So my idea is to have a standard (and easy) way to declare a package which can act both as a namespace package and a regular package, like pep-420 (implicit namespace packages) standardized way to create namespace packages. Here is an example: first/first/__init__.py: X = 1 second/first/second/__init__.py: Y = 2 import sys sys.path += ['first', 'second'] import first first.X # 1 import first.second # I expect to get 2, first.second.Y # but currently ImportError is raised If I understand this correctly, this change will require to modify the default submodule lookup algorithm, so when the import machinery finds the cached first module, and there is no second submodule defined, the machinery launches the standard namespace packages finder algorithm (as described in [1]), excluding first package directory from the search path. >From a user perspective, assuming we have a mature library with lots of extensions (for example, flask), and a pluggable extension (like flask-flatpages), the following imports from flask import Flask from flask_flatpages import FlatPages from flask_flatpages_knitr import FlatPagesKnitr can be rewritten as follows: from flask import Flask from flask.flatpages import FlatPages from flask.flatpages.knitr import FlatPagesKnitr which I find more readable than the first snippet. What do you think about it? Is flat better than nested, or namespaces are really great? Thank you for any feedback! [1] https://www.python.org/dev/peps/pep-0420/#dynamic-path-computation -- Dmitry Malinovsky Senior DevOps Thumbtack Technology Email: dmalinovsky(a)thumbtack.net <pnegoduyko(a)thumbtack.net> Skype: d_malinoff

3 3