🌐 Mailman 3 September 2016 - Python-list - python.org

Re: [python-committers] [RELEASE] Python 3.6.0b1 is now available
by Paul Moore Sept. 15, 2016

Sept. 15, 2016

On 14 September 2016 at 11:32, Serhiy Storchaka <storchaka(a)gmail.com> wrote: > On 13.09.16 02:35, Ned Deily wrote: >> >> On behalf of the Python development community and the Python 3.6 release >> team, I'm happy to announce the availability of Python 3.6.0b1. 3.6.0b1 >> is the first of four planned beta releases of Python 3.6, the next major >> release of Python, and marks the end of the feature development phase >> for 3.6. > > > There is no mention on https://www.python.org/news/. The last release mentioned there is 3.4.0rc1... Paul

3 2

Re: Oh gods can we get any more off-topic *wink* [was Re: [Python-ideas] Inconsistencies]
by Lawrence D’Oliveiro Sept. 15, 2016

Sept. 15, 2016

On Thursday, September 15, 2016 at 1:26:49 PM UTC+12, Chris Kaynor wrote: > If you find somebody determined to not trust evidence such as the blue > marble photos, it can be quite hard to prove that the world is not flat. A flat world doesn’t have a horizon.

3 2

Re: What is the correct form for saying "licensed under the same terms as Python itself"?
by Mark Summerfield Sept. 15, 2016

Sept. 15, 2016

Thanks v. much: I'll use the Apache 2.0 license.

1 0

Re: Oh gods can we get any more off-topic *wink* [was Re: [Python-ideas] Inconsistencies]
by Steve D'Aprano Sept. 15, 2016

Sept. 15, 2016

On Thu, 15 Sep 2016 03:43 am, Dale Marvin wrote: > On 9/14/16 12:20 AM, Steven D'Aprano wrote: >> On Wednesday 14 September 2016 16:54, Rustom Mody wrote: >> >>> everything we know will be negated in 5-50-500 years >> >> I'm pretty sure that in 5, 50, 500 or even 5000 years, the sun will still >> rise in the east, water will be wet, fire will burn, dogs will have >> mammary glands and frogs[1] won't, and the square root of 100 will still >> be 10. >> >> Isaac Asimov once wrote: >> >> When people thought the earth was flat, they were wrong. When people >> thought the earth was spherical, they were wrong. But if you think >> that thinking the earth is spherical is just as wrong as thinking the >> earth is flat, then your view is wronger than both of them put >> together. > >> http://chem.tufts.edu/AnswersInScience/RelativityofWrong.htm >> >> [1] Assuming that there are any frogs left by then. >> > > Funny, Asimov's professors must have taught him the same false history > that I was taught at college. There's much evidence that medieval > scholars did not believe the earth was flat. I don't see Asimov referring to medieval scholars. The medieval period is roughly around 1000 CE or thereabouts. Asimov talks about people believing in a flat earth "In the early days of civilization" and goes on to discuss how Greeks such as Aristotle (350 BCE) had evidence for a spherical earth. He doesn't mention the medieval period at all. If you're going to criticise Asimov, don't criticise him for wrongly thinking that people in the Middle Ages believed in a flat earth. There's no evidence of that in his essay. Rather, criticise him for over-simplifying how quickly and universally the idea of the spherical earth took over. Asimov jumps from Eratosthenes (about a century after Aristotle, so around 250 BCE) to Newton (17th century) with nary a mention of how long, slow and difficult it was for the flat earth cosmology to be discarded. Regardless of what a few ivory-tower Greek philosophers thought, in the early centuries CE many people still believed the world was flat. While it is true that by the Middle Ages educated scholars in Europe almost certainly believed in a spherical world, not all people were educated scholars. We have no idea what the average peasant tilling the fields would have believed, although given the influence of Christianity and the remnants of ancient Hebrew cosmology (flat earth) in the Bible, it is far more likely that the average uneducated person believed in a flat earth. But we don't really know for sure. And there is more to the world than just Europe. In China, belief in a flat earth cosmology was virtually unchallenged until the 17th century. https://en.wikipedia.org/wiki/Flat_Earth -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse.

2 1

unexpected rerun program itself when using cv2 and selenium
by meInvent bbird Sept. 15, 2016

Sept. 15, 2016

unexpected rerun program itself when using cv2 and selenium when a script, it is expected to run once and stop but it start a new browser again when using selenium and cv2 d, bbox, filename) File "C:\Python27\lib\site-packages\pyscreenshot\procutil.py", line 28, in run _in_childprocess p.start() File "C:\Python27\lib\multiprocessing\process.py", line 130, in start self._popen = Popen(self) File "C:\Python27\lib\multiprocessing\forking.py", line 258, in __init__ cmd = get_command_line() + [rhandle] File "C:\Python27\lib\multiprocessing\forking.py", line 358, in get_command_li ne is not going to be frozen to produce a Windows executable.''') RuntimeError: Attempt to start a new process before the current process has finished its bootstrapping phase. This probably means that you are on Windows and you have forgotten to use the proper idiom in the main module: if __name__ == '__main__': freeze_support() ... The "freeze_support()" line can be omitted if the program is not going to be frozen to produce a Windows executable.

1 0

Why don't we call the for loop what it really is, a foreach loop?
by rgrigonis＠gmail.com Sept. 15, 2016

Sept. 15, 2016

It would help newbies and prevent confusion.

7 6

Re: Expression can be simplified on list
by Jussi Piitulainen Sept. 15, 2016

Sept. 15, 2016

Serhiy Storchaka writes: > On 14.09.16 11:28, Steven D'Aprano wrote: >> I'm not sure if it makes sense to talk about an "empty regular >> expression", or if that is the same as re.compile(''). Presumably if >> such a thing makes sense, it would match nothing, from any input at >> all. > > Actually, it matches anything. re.compile('').match(x) returns > non-false value for any valid x. It matches the empty string. The .match method returns a match object if the regex matches at the start of the input. See span: re.compile('').match('foo') ===> <_sre.SRE_Match object; span=(0, 0), match=''> There's an empty string at every position, same content, different span: re.compile('').findall('foo') ===> ['', '', '', ''] More mathematical treatments of regular expressions usually include a special expression that stands for the empty string, typically ε or λ, I've also seen Λ, sometimes e -- my impression is that those sources tend to use small alphabets, often just two or three letters, so they can afford to give up e. Some ruminations follow, following Rustom's mathematical ruminations, related to extended regex software that has taken a rather different direction from the usual matching engines. Mathematical discussions tend to acknowledge only alternation (union), concatenation and iteration (Kleene star) as operations, unless they specifically focus on some other operations that can, in principle, be expressed in terms of those three. There are many such. Without further regex operations it makes sense to include a special regular expression that matches nothing. Otherwise a very simple NFA (DFA) has no corresponding regex, which can be considered awkward. There are powerful regex operations for which it may not be computationally trivial, regarding time and space, to tell whether the regex matches anything at all. Does one expect bool(o) to happen quickly? in near-constant time? I think there tends to be some such expectation. Then it might make practical sense to not interpret a regex as a container of the strings that it matches, even if such an interpretation makes some theoretical sense. It may make sense to keep the regex and its interpretation as a set (or relation) separate in theory, too, just for the clarity of thought. My colleagues down the corridor deal with large finite-state automata and transducers, applying a rich regex formalism to analyze the various forms that words can take. Some of them used to be a challenge to compile at all - a Greenlandish lexicon was an example. - It looks like the move of the software to GitHub has happened: http://hfst.github.io/.

3 3

Re: Expression can be simplified on list
by Lawrence D’Oliveiro Sept. 15, 2016

Sept. 15, 2016

On Thursday, September 15, 2016 at 8:13:05 AM UTC+12, Terry Reedy wrote: > Because True is the default, object need not and at least in CPython > does not have a __bool__ (or __len__) method. If they had to (in the absence of which a bool() cast would not work), then that would help prevent problems like the one I previously linked to, don’t you think?

4 4

Creating A Pythonic ctypes Binding
by Lawrence D’Oliveiro Sept. 15, 2016

Sept. 15, 2016

ctypes <https://docs.python.org/3/library/ctypes.html> is a wonderful library. If you need to create a Python binding for some library that doesn’t already have one, you should look at ctypes, rather than writing an extension module in C or C++. The odds are, a pure Python implementation using ctypes can be done with much less effort than writing C/C++ code. But it is not enough to wrap an API designed for C or C++. A Python API should take advantage of the power and convenience of Python. The question I like to ask is: “How would the API have been designed if it was native to Python, rather than being intended for C or C++?”. Another question to consider is: “Does the Python API binding give you a reason to use Python to write your code in the first place, rather than choosing C or C++ instead?”. In short, does your Python code that makes calls to the API look like a straight transliteration of C code, or does it work at a higher level? What do I mean by this? An obvious, very basic, example is not having the user have to bother with explicitly creating and destroying objects. Wrap an underlying API object in a Python object, such that the Python object’s “__del__” method will take care of disposing of the API object. Then Python’s usual object-management mechanisms will automatically manage the API objects as well. This is how Qahirah <https://github.com/ldo/qahirah>, my wrapper for the Cairo graphics library <https://www.cairographics.org/>, works. But there is more you can do. Another obvious one is, where the underlying API provides “get_xxx” and “set_xxx” methods, to wrap them in a read/write Python property. For example, Cairo defines a “fill rule” that governs how paths are filled, with getter and setter calls <https://www.cairographics.org/manual/cairo-cairo-t.html#cairo-set-fill-rule>. In Qahirah this is translated to a property that you can obtain with a simple expression like “«ctx».fill_rule” (where «ctx» is a Context object), and change by a simple assignment like “«ctx».fill_rule = «new_value»”. Sometimes the values that are returned by the getter or set with the setter have a more complex, variable-length structure. So the C API may need two parts to the getter routines, one to determine how big a structure the caller needs to allocate, and the other to fill in a preallocated structure with the actual data. For example, the dash setting for stroking lines <https://www.cairographics.org/manual/cairo-cairo-t.html#cairo-set-dash> is of this type. In Python, it makes sense to store the dash information in a high-level Python object, which is directly returned from the Python-level getter and directly passed to the Python-level setter. In Qahirah, I use a 2-tuple, the first element of which specifies the alternating on/off dash lengths (itself a tuple), and the second of which is the starting offset. All conversion between this format and the actual format that Cairo expects happens within the Python wrapper routines, without the caller having to worry about it. Sometimes the opportunities to add value come from other available Python libraries. Cairo only deals with colours as RGB components, with an optional alpha. But Python provides this handy colorsys module <https://docs.python.org/3/library/colorsys.html> as standard, which provides conversions to/from a number of non-RGB colour spaces; why not take advantage of it? So I defined a “Colour” type, and all wrappers to Cairo calls that set or get colours take or return this object instead of separate RGB or RGBA components. A Colour can be constructed from components in any of the supported colour spaces, and you can query its components in any of these colour spaces. But more than that, you can also perform useful manipulations on Colours, like adjusting the values of components to produce new, but related, colours. This all goes way beyond the functionality of Cairo itself, but I felt it was useful, even essential, to have in a worthwhile graphics API. Python has a remarkably simple and elegant technique for implementing custom overloading of its standard operators. C, of course, has no such thing. So APIs designed for C have to provide function calls instead, such as for Cairo’s matrix operations <https://www.cairographics.org/manual/cairo-cairo-matrix-t.html>. It was easy enough for me to define a “Matrix” class, with the “*” operator (“@” as well in Python 3.5 or later) to do Matrix multiplication. Instead of updating a Matrix object in place (procedural programming), I prefer a more functional approach, where each operation creates a new Matrix object as its result, leaving its operands unchanged. This lets you write expressions which are closer to the underlying mathematics. I also defined a “Vector” class, representing both X and Y coordinates in a single value. Cairo itself requires you to pass (or get back) separate X and Y coordinate values; but again, I wrap all these calls so that you pass and return Vectors. It is extremely common to do calculations on corresponding X- and Y-coordinates that are absolutely identical, except for the coordinate-specific components; Qahirah lets you write these calculations just once instead of twice, operating directly on Vectors. In short: ctypes is cool. Python is cool. Python + ctypes = OMG wow cool. Yeah. :)

1 0

How could I implement a virtual method and override it in python?
by wesley.keeling＠iugome.com Sept. 15, 2016

Sept. 15, 2016

Hey guys, I will show the code first: Helper.py: def Foo( *args ): print ("This is a callback") def Run: Foo() MyModule.py: import Helper def Foo( *args ): print ("I want to be the new callback") I want to be able to call the Foo method in MyModule.py when it's there first and when it's not I want to call the Foo in helper.py. I am coming from .net so I am not fully understanding how the Foo method would override the other one. Thanks!

3 3