Re: Is there a nice way to switch between 2 different packages providing the same APIs?

[Mark via Python-list]

On Thursday, July 5, 2018 at 6:24:09 PM UTC+1, Tim Williams wrote:
> On Thu, Jul 5, 2018 at 9:02 AM Mark Summerfield via Python-list <
> python-list@python.org> wrote:
> 
> > For GUI programming I often use Python bindings for Qt.
> >
> > There are two competing bindings, PySide and PyQt.
> >
> > Ideally I like to have applications that can use either. This way, if I
> > get a problem I can try with the other bindings: if I still get the
> > problem, then it is probably me; but if I don't it may be an issue with the
> > bindings.
> >
> > But working with both means that my imports are very messy. Here's a tiny
> > example:
> >
> > if PYSIDE: # bool True -> Use PySide; False -> Use PyQt5
> > from PySide2.QtCore import Qt
> > from PySide2.QtGui import QIcon
> > from PySide2.QtWidgets import (
> > QDialog, QFrame, QGridLayout, QLabel, QLineEdit, QPushButton,
> > QVBoxLayout)
> > else:
> > from PyQt5.QtCore import Qt
> > from PyQt5.QtGui import QIcon
> > from PyQt5.QtWidgets import (
> > QDialog, QFrame, QGridLayout, QLabel, QLineEdit, QPushButton,
> > QVBoxLayout)
> >
> > The PYSIDE constant is imported from another module and is used for all
> > .py files in a given project so that just by changing PYSIDE's value I can
> > run an entire application with PySide2 or with PyQt5.
> >
> > But I'd really rather just have one lot of imports per file.
> >
> > One obvious solution is to create a 'Qt.py' module that imports everything
> > depending on the PYSIDE switch and that I then use in all the other .py
> > files, something like this:
> >
> > from Qt.QtCore import Qt
> > from Qt.QtGui import QIcon
> > ... etc.
> >
> > But I'm just wondering if there's a nicer way to do all this?
> > --
> > https://mail.python.org/mailman/listinfo/python-list
> 
> 
> Check out pyqtgraph 
> 
> It tries to use  PyQt5/PyQt4/PySide depending on which if these packages
> were imported before importing pyqtgraph.

I looked at the source for this and it is v. similar to what I'm doing myself 
right down to having an isObjectAlive() function done exactly as I'm doing it.

The thing I'm not keen on is that the imports are like this:

from .Qt import QtCore

and then used as:

p = QtCore.QPoint(0, 0)

whereas I want to do something like this (incorrect & maybe not possible):

from .Qt.QtCore import QPoint, QRect

p = QPoint(0, 0)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Dealing with dicts in doctest

[Peter Otten]

Steven D'Aprano wrote:

> On Fri, 06 Jul 2018 09:31:50 +1000, Cameron Simpson wrote:
> 
>> On 05Jul2018 17:57, Steven D'Aprano
>>  wrote:
>>>I have a function which returns a dict, and I want to use doctest to
>>>ensure the documentation is correct. So I write a bunch of doctests:
>>>
>>>def func(arg):
>>>"""blah blah blah
>>>
>>>>>> func(1)
>>>{'a': 1, 'b': 2, 'c': 3}
>>>"""
>>>
>>>which is correct, *except* that dict keys have arbitrary order in the
>>>versions of Python I'm using.
>>>
>>>I have three ways of dealing with this. Which do you prefer?
>> 
>> Option 4:
>> 
>> >>> func(1) == {'a': 1, 'b': 2, 'c': 3}
>> True
> 
> Alas, in reality func takes anything up to six arguments, at least one of
> which will be a moderately long sequence requiring two lines:
> 
> >>> func([('a', 1), ('bb', 2), ('ccc', 4), ('', 8)],
> ...  ('eee', 16), ('ff', 32), ('g', 64)], ...
> 
> and the output is similarly long. So making it a one-liner isn't
> generally practical.

In that case: goodbye doctest, hello unittest ;)

With complex or just long setup, underdefined output, and exceptions I 
usually ditch doctest, convenient as it may be.


PS: the tinkerer in me wants to provide

import sys


class name(str):
def __repr__(self):
return str(self)


def dh(obj):
if type(obj) is dict:
try:
obj = name(
"{" +
", ".join("%r: %r" % kv for kv in sorted(obj.items()))
+ "}"
)
except TypeError:
pass  # might sort by (repr(key), repr(value))
_dh(obj)


_dh = sys.__displayhook__
sys.__displayhook__ = dh


def f(a):
"""
>>> f(dict(a=1, b=2))
{'a': 1, 'b': 2}
"""
return a


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PEP 526 - var annotations and the spirit of python

[Steven D'Aprano]

On Thu, 05 Jul 2018 16:09:52 +0200, Antoon Pardon wrote:

>> This is not an innovation of Mypy. It's how type inference is supposed
>> to work. If a particular type checker doesn't do that, it is doing it
>> wrong.
> 
> That is how type interference works in languages that have some kind of
> static typing like Haskell.

No, that's how type inference works in dynamically typed languages like 
Python as well. See Mypy for an example.

Do you have a counter-example? I'm happy to be corrected by facts, but 
not by suppositions about hypothetical type-checkers which might someday 
exist but don't yet.


> Sure if mypy want to impose something like
> that it can, but you can't interfere something like that for python
> programs in general.

Naturally -- that's why type-checking remains opt-in. Nobody, especially 
not me, says that if you see 

x = 3

in a random Python program, that means that x must be an int everywhere 
in that program. That would be a foolish thing to say.

But if you opt-in to using a type-checker, the assumption is that you are 
writing in a less-dynamic, more-static style that will actually get some 
advantage from static type checking. If you're not doing so, then you're 
just annoying yourself and wasting time and you won't enjoy the 
experience one bit.

As many people -- including you, if I remember correctly -- have often 
pointed out, the amount of dynamism allowed in Python is a lot more than 
the amount typically used by most programs. Most of us, most of the time, 
treat variables as mostly statically typed. Reusing a variable for 
something completely unrelated is mildly frowned on, and in practice, 
most variables are only used for *one* thing during their lifetime.

Python remains a fundamentally dynamically typed language, so a static 
type checker (whether it has type inference or not) cannot cope. It 
requires gradual typing: a type system capable of dealing with mixed code 
with parts written in a static-like style and parts that remain fully 
dynamic.

Mypy makes pretty conservative decisions about which parts of your code 
to check. (E.g. it treats functions as duck-typed unless you explicitly 
annotate them.) But when it does infer types, it cannot always infer the 
type you, the programmer, intended. Often because there is insufficient 
information available:

x = []  # we can infer that x is a list, but a list of what?
x.append("hello world")  # allowed, or a type error?

And if the type checker turns out to make an overly-strict inference, and 
you want to overrule it, you can always annotate it as Any.

Type checking algorithms, whether static or gradual, are predicated on 
the assumption that the type of variable is consistent over the lifetime 
of that variable. (By type, I include unions, optional types, etc. "A 
float or a string" is considered a type for these purposes. So is 
"anything at all".) That's the only reasonable assumption to make for 
static analysis.

I'll grant you that a sufficiently clever type checking algorithm could 
track changes through time. Proof of concept is that we humans can do so, 
albeit imperfectly and often poorly, so it's certainly possible. But how 
we do it is by more-or-less running a simulated Python interpreter in our 
brain, tracking the types of variables as they change.

So *in principle* there could be a type-checker which does that, but as 
far as I know, there isn't such a beast. As far as I know, nobody has a 
clue how to do so with any sort of reliability, and I doubt that it is 
possible since you would surely need runtime information not available to 
a source-code static analyser.

We humans do it by focusing only on a small part of the program at once, 
and using heuristics to guess what the likely runtime information could 
be. The fact that we're not very good at it is provable by the number of 
bugs we let slip in.

So the bottom line is, any *practical* static type checker has to assume 
that a single variable is always the same type during its lifetime, and 
treat any assignment to another type as an error unless told differently.

(If you have counter-examples, I'm happy to learn better.)



By the way, you keep writing "interfere", the word is "infer":

infer
v 1: reason by deduction; establish by deduction [syn: deduce,
 infer, deduct, derive]
2: draw from specific cases for more general cases [syn:
   generalize, generalise, extrapolate, infer]
3: conclude by reasoning; in logic [syn: deduce, infer]



> Unless you mean "A probable guess" by interfere.

No.


-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: about main()

[Gregory Ewing]

Steven D'Aprano wrote:
Even the Eskimos and Inuit, living in some of the harshest 
environments on earth, managed to have a relatively wide variety of foods 
in their diet.


They might be living on a very wide variety of berries.

Or perhaps, in their language, "berry" simply means "food".

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: about main()

[Steven D'Aprano]

On Thu, 05 Jul 2018 18:40:11 -0700, Jim Lee wrote:

> On 07/05/18 18:25, Steven D'Aprano wrote:
>> On Thu, 05 Jul 2018 11:27:09 -0700, Jim Lee wrote:
>>
>>> Take a village of people.  They live mostly on wild berries.
>> Because of course a community of people living on one food is so
>> realistic. Even the Eskimos and Inuit, living in some of the harshest
>> environments on earth, managed to have a relatively wide variety of
>> foods in their diet.
>>
>> https://en.wikipedia.org/wiki/Inuit_cuisine
>>
>>
> Pedantics again.  Didn't even get the point before tearing apart the
> *analogy* rather than the *point itself*.  

I got the point. The point was "old man yells at clouds".

Your point is simply *wrong* -- specialisation is what has created 
civilization, not generalisation, and your Golden Age when all 
programmers were "Real Programmers" who could not only optimize code at 
an expert level in a dozen different language but could probably make 
their own CPUs using nothing but a handful of sand and a cigarette 
lighter never actually existed.

We are in no danger of losing the ability to optimize code that needs to 
be optimized, and we're in no danger of being stuck with compiler 
technology that nobody understands. As cautionary tales go, yours is as 
sensible as "Stop jumping around, you'll break gravity and we'll all 
float into space!"

There's no shortage of people demanding of their programmers "can't you 
make it go faster?" and no shortage of people good enough to make it 
happen. Even if the absolute number of clueless code monkeys has gone up, 
and although certain areas of the software ecosystem are under assault by 
cascades of attention-deficit disorder teenagers, the proportion of 
decent coders has not changed in any meaningful way.

There are still enough competent programmers and the average quality of 
code hasn't gone down, and if the industry as a whole has shifted towards 
more specialisation and less generalisation, that's a GOOD thing.


> Childish.

If an analogy is to be treated seriously, it ought to be at least 
plausible. Yours wasn't. I could have just mocked it mercilessly, but I 
gave it the benefit of the doubt and treated it seriously and saw where 
it fell down and failed even the simplest smoke test.

Your analogy simply doesn't come close to describing either a realistic 
scenario or the state of computing in 2018.



> The rest was TL;DR.

I give you the benefit of the doubt, reading your posts and thinking 
about them before deciding whether to dismiss them as rubbish or not. You 
ought to give others the same courtesy.

Who knows, you might learn something.



-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: RANT why the *%#&%^ does installing pip not install setuptools???

[Steven D'Aprano]

On Fri, 06 Jul 2018 11:58:08 +1000, Chris Angelico wrote:

> On Fri, Jul 6, 2018 at 11:35 AM, Steven D'Aprano
>  wrote:
>> On Fri, 06 Jul 2018 03:47:55 +1000, Chris Angelico wrote:
>>
>>> What's the output of:
>>>
>>> $ apt-cache show python3-pip
>>
>> Mysteriously, the output is repeated twice, in every-so-slightly
>> different formats. It's the little details like that give us confidence
>> in the quality of the software...
> 
> The solution to the mystery is here:
> 
>> Package: python3-pip
>> Version: 8.1.1-2ubuntu0.4
>>
>> Package: python3-pip
>> Version: 8.1.1-2
> 
> You can see where the two packages come from with:
> 
> $ apt-cache policy python3-pip
> 
> It probably means you have multiple package sources configured; 

I am using the default configuration.

> or
> perhaps you have one installed currently, and you could upgrade to a
> slightly updated version.

Given that I had just run apt install python3-pip yesterday, that would 
be surprising but not impossible... let's find out:

steve@orac /home $ apt install python3-pip
Reading package lists... Done
Building dependency tree
Reading state information... Done
python3-pip is already the newest version (8.1.1-2ubuntu0.4).


> In any case, setuptools is listed in the recommends.

If setuptools isn't included, pip can fail.

I don't know if it will fail *always*, but it will surely fail *most* of 
the time. setuptools should not be treated as an optional extra for pip.



-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: testing code

[Cameron Simpson]

On 05Jul2018 19:56, Sharan Basappa  wrote:
I have implemented my first program in python that uses ML to do some 
classification task. The whole code is in a single file currently.

It contains executable code as well as functions.


I presume when you write "executable code" you mean some kind of "main program" 
that just runs when you run the .py file?



At the end of the program, I have series of calls that is used to test my code.
Now, I would like to re-structure this to separate test code from the program.
As I have not done this in Python, I am a bit lost.

Please let me know if the following understanding of mine is correct.
I need to put the program code in a separate file and organize every executable 
code in some form of function. If any code exists outside of function then it 
is not executable by importing.


This is not quite right. Because Python is a dynamic language, importing a file 
actually runs it. That is how the functions etc get defined.


So what you need to do is arrange that your "series of calls that is used to 
test my code" live in their own function, and that that function only gets run 
if the file is directly run.


Fortunately, this is a very common, almost universal, requirement and there is 
a standard idom for arranging it.


Support you have your code in the file "foo.py" (because I need a concrete 
filename for the example). It might look like this at present:


 def func1(...):

 def func2(...):

 x = func1(...)
 y = func2(...)
 print(x + y)

i.e. some function definitions and then you testing code.

Now, you can write another file "foo_tests.py" which starts like this:

 import foo
 ... run some tests of foo.func1, foo.func2 etc ...

The issue is that as written, foo.py will run your test calls during the 
import.  Restructure foo.py like this:


 def main():
 x = func1(...)
 y = func2(...)
 print(x + y)

 def func1(...):

 def func2(...):

 if __name__ == '__main__':
 main()

This is very standard. When you run a python file directly the built in  
__name__ variable contains the string "__main__". This tells you that you're 
running it as a "main program" i.e. directly.


If you import the file instead, as from your planned testing file, the __name__ 
variable will contain the string "foo" because that is the name of the module.


So that "main" function and the "if" at the bottom is standard Python 
boilerplate code for what you're trying to do.


Import this in my test program (file/module) and then initiate  calls present 
in the program.

If there is some simple example, it would help a lot.


Now you can do this part.

Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

Re: testing code

[Chris Angelico]

On Fri, Jul 6, 2018 at 12:56 PM, Sharan Basappa
 wrote:
> Please let me know if the following understanding of mine is correct.
> I need to put the program code in a separate file and organize every 
> executable code in some form of function. If any code exists outside of 
> function then it is not executable by importing.
>

Kinda. It's actually the other way around: if any code exists outside
of functions, it will be executed immediately when you import. So
you're correct in that it would be hard (maybe impossible) to
unit-test that; and yes, the normal way to do it is to put all your
important code into functions.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

testing code

[Sharan Basappa]

Hi All,

I am new to Python though not new to programming.

I have implemented my first program in python that uses ML to do some 
classification task. The whole code is in a single file currently.
It contains executable code as well as functions.

At the end of the program, I have series of calls that is used to test my code.
Now, I would like to re-structure this to separate test code from the program.
As I have not done this in Python, I am a bit lost.

Please let me know if the following understanding of mine is correct.
I need to put the program code in a separate file and organize every executable 
code in some form of function. If any code exists outside of function then it 
is not executable by importing.

Import this in my test program (file/module) and then initiate  calls present 
in the program.

If there is some simple example, it would help a lot.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Dealing with dicts in doctest

[Cameron Simpson]

On 06Jul2018 01:43, Steven D'Aprano  
wrote:

On Fri, 06 Jul 2018 09:31:50 +1000, Cameron Simpson wrote:
On 05Jul2018 17:57, Steven D'Aprano  
wrote:

I have three ways of dealing with this. Which do you prefer?


Option 4:

>>> func(1) == {'a': 1, 'b': 2, 'c': 3}
True


Alas, in reality func takes anything up to six arguments, at least one of
which will be a moderately long sequence requiring two lines:

   >>> func([('a', 1), ('bb', 2), ('ccc', 4), ('', 8)],
   ...  ('eee', 16), ('ff', 32), ('g', 64)], ...

and the output is similarly long. So making it a one-liner isn't
generally practical.


If you're in Python 3 there's a DocTest.OutputChecker class. Maybe it's 
possible to subclass this in some doctest utility and use that to catch 
unsorted dicts?


I speak freely here, as one who hasn't tried this.

But I'm just starting with doctest myself, so I'm interested.

Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

Re: RANT why the *%#&%^ does installing pip not install setuptools???

[Chris Angelico]

On Fri, Jul 6, 2018 at 11:35 AM, Steven D'Aprano
 wrote:
> On Fri, 06 Jul 2018 03:47:55 +1000, Chris Angelico wrote:
>
>> What's the output of:
>>
>> $ apt-cache show python3-pip
>
> Mysteriously, the output is repeated twice, in every-so-slightly
> different formats. It's the little details like that give us confidence
> in the quality of the software...

The solution to the mystery is here:

> Package: python3-pip
> Version: 8.1.1-2ubuntu0.4
>
> Package: python3-pip
> Version: 8.1.1-2

You can see where the two packages come from with:

$ apt-cache policy python3-pip

It probably means you have multiple package sources configured; or
perhaps you have one installed currently, and you could upgrade to a
slightly updated version.

In any case, setuptools is listed in the recommends.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: about main()

[Gene Heskett]

On Thursday 05 July 2018 21:25:31 Steven D'Aprano wrote:

> On Thu, 05 Jul 2018 11:27:09 -0700, Jim Lee wrote:
> > Take a village of people.  They live mostly on wild berries.
>
> Because of course a community of people living on one food is so
> realistic. Even the Eskimos and Inuit, living in some of the harshest
> environments on earth, managed to have a relatively wide variety of
> foods in their diet.
>
> https://en.wikipedia.org/wiki/Inuit_cuisine
>
> But okay, let's run with this scenario...
>
> > One day, a man invents an automated way to sort good berries from
> > poisonous berries.
>
> Right, because it is totally realistic that a pre-agricultural society
> living on nothing but berries has mastered the technology to automate
> sorting berries.
>
> > Soon, all the villagers take their berries to him to be
> > sorted.
>
> Of course they do, because why pick only edible berries when it is so
> much more fun to pick both edible and poisonous berries, mix them
> together, and then play a game of "let's see if we missed any of the
> deadly berries and will die horribly after eating them accidentally".
>
> In this scenario of yours, is everyone in this a village a workaholic
> with a death-wish? Why exactly are they doing twice as much work as
> necessary picking poisonous berries and mixing them in together with
> the edible berries?
>
> > The man dies, but passes the secret on to his son before doing
> > so.  This continues for a few generations.  Eventually, the final
> > descendant dies with no children, and the secret vanishes.  Now, the
> > entire village is clueless when it comes to identifying the
> > poisonous berries.
>
> Even this city boy knows enough to tell the difference between edible
> blackberries, raspberries and strawberries and the many
> maybe-its-edible- maybe-its-not berries which grown on random trees
> and bushes.
>
> Are there a bunch of dead birds around the tree? Then its poisonous.
>
> Do birds happily eat the berries and keep coming back? Then its worth
> trying one or two and see if they give you a stomach ache, if not,
> they're probably safe.
>
> A more sensible example would have been mushrooms. And its true, I'm
> entirely clueless how to identify poisonous mushrooms from edible
> ones. However will I survive?
>
The mushroom question is easy Steven. Since there is NO food value to a 
mushroom, simply avoid them all. The only reason we use them in our food 
is the flavoring.  There are no calories, no or only trace amounts of 
vitamins or minerals. Skipping them is the sensible thing to do

> Nor do I know how to smelt copper, or tan leather using nothing but
> dung, or perform brain surgery. I guess civilization is about to
> collapse.
>
In that case, I hate to say it, but your education is sorely lacking in 
the fundamentals. Smelting for instance was discussed at length in the 
high school physics books I was reading by the time I was in the 3rd 
grade. Don't they teach anything in school anymore? Tanning leather for 
instance involves a long soaking in strong tea, and doesn't name the 
brand or genus of the tea, the important part was the tannic acid 
content.>
>
>
> --
> Steven D'Aprano
> "Ever since I learned about confirmation bias, I've been seeing
> it everywhere." -- Jon Ronson



-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Dealing with dicts in doctest

[Steven D'Aprano]

On Thu, 05 Jul 2018 19:56:59 +0100, MRAB wrote:

> What about sorting the items?
> 
> def func(arg):
>   """blah blah blah
> 
>   >>> sorted(func(1).items())
>   [('a', 1), ('b', 2), ('c', 3)]
>   """


Hmmm it still has the disadvantage of putting the emphasis on the 
sorted() function instead of the function being doctested, and obscuring 
the fact that it returns a dict. But I actually like that.



-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Dealing with dicts in doctest

[Steven D'Aprano]

On Fri, 06 Jul 2018 09:31:50 +1000, Cameron Simpson wrote:

> On 05Jul2018 17:57, Steven D'Aprano
>  wrote:
>>I have a function which returns a dict, and I want to use doctest to
>>ensure the documentation is correct. So I write a bunch of doctests:
>>
>>def func(arg):
>>"""blah blah blah
>>
>>>>> func(1)
>>{'a': 1, 'b': 2, 'c': 3}
>>"""
>>
>>which is correct, *except* that dict keys have arbitrary order in the
>>versions of Python I'm using.
>>
>>I have three ways of dealing with this. Which do you prefer?
> 
> Option 4:
> 
> >>> func(1) == {'a': 1, 'b': 2, 'c': 3}
> True

Alas, in reality func takes anything up to six arguments, at least one of 
which will be a moderately long sequence requiring two lines:

>>> func([('a', 1), ('bb', 2), ('ccc', 4), ('', 8)],
...  ('eee', 16), ('ff', 32), ('g', 64)], ...

and the output is similarly long. So making it a one-liner isn't 
generally practical.




-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: RANT why the *%#&%^ does installing pip not install setuptools???

[Steven D'Aprano]

On Fri, 06 Jul 2018 03:47:55 +1000, Chris Angelico wrote:

> What's the output of:
> 
> $ apt-cache show python3-pip

Mysteriously, the output is repeated twice, in every-so-slightly 
different formats. It's the little details like that give us confidence 
in the quality of the software...



Package: python3-pip
Architecture: all
Version: 8.1.1-2ubuntu0.4
Priority: optional
Section: universe/python
Source: python-pip
Origin: Ubuntu
Maintainer: Ubuntu Developers 
Original-Maintainer: Debian Python Modules Team 
Bugs: https://bugs.launchpad.net/ubuntu/+filebug
Installed-Size: 556
Depends: ca-certificates, python-pip-whl (= 8.1.1-2ubuntu0.4), 
python3:any (>= 3.4~)
Recommends: build-essential, python3-dev (>= 3.2), python3-setuptools, 
python3-wheel
Filename: pool/universe/p/python-pip/python3-pip_8.1.1-2ubuntu0.4_all.deb
Size: 108962
MD5sum: e3dc92b0b965b3bea3ff4bf8526e24db
SHA1: bcfb2aff46c05cc6b6a14d4faaa1cf2d0c90d1f3
SHA256: e55a2450e6dd6db15df0d9119e746af4f398e33a303a707cd660f159c9f78c5e
Homepage: https://pip.pypa.io/en/stable/
Description-en_AU: alternative Python package installer - Python 3 
version of the package
 pip is a replacement for easy_install, and is intended to be an improved
 Python package installer.  It integrates with virtualenv, doesn't do
 partial installs, can save package state for replaying, can install from
 non-egg sources, and can install from version control repositories.
 .
 This is the Python 3 version of the package.
Description-md5: 518fd76c787f6bd48e413ec4bcd3eb84

Package: python3-pip
Priority: optional
Section: universe/python
Installed-Size: 554
Maintainer: Ubuntu Developers 
Original-Maintainer: Debian Python Modules Team 
Architecture: all
Source: python-pip
Version: 8.1.1-2
Depends: ca-certificates, python-pip-whl (= 8.1.1-2), python3:any (>= 
3.4~)
Recommends: build-essential, python3-dev (>= 3.2), python3-setuptools, 
python3-wheel
Filename: pool/universe/p/python-pip/python3-pip_8.1.1-2_all.deb
Size: 108740
MD5sum: 2df4cd61c524a0e7721e612e89f710e8
SHA1: 7eca35aaadf0e2a5246a256063fdfc4631630fbd
SHA256: cf6a2d9befe0a6fb0002cd259bed40669588101a825006f4f07e2343a89e5f49
Description-en_AU: alternative Python package installer - Python 3 
version of the package
 pip is a replacement for easy_install, and is intended to be an improved
 Python package installer.  It integrates with virtualenv, doesn't do
 partial installs, can save package state for replaying, can install from
 non-egg sources, and can install from version control repositories.
 .
 This is the Python 3 version of the package.
Description-md5: 518fd76c787f6bd48e413ec4bcd3eb84
Homepage: https://pip.pypa.io/en/stable/
Bugs: https://bugs.launchpad.net/ubuntu/+filebug
Origin: Ubuntu





-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: about main()

[Jim Lee]

On 07/05/18 18:25, Steven D'Aprano wrote:

On Thu, 05 Jul 2018 11:27:09 -0700, Jim Lee wrote:


Take a village of people.  They live mostly on wild berries.

Because of course a community of people living on one food is so
realistic. Even the Eskimos and Inuit, living in some of the harshest
environments on earth, managed to have a relatively wide variety of foods
in their diet.

https://en.wikipedia.org/wiki/Inuit_cuisine


Pedantics again.  Didn't even get the point before tearing apart the 
*analogy* rather than the *point itself*.  Childish. The rest was TL;DR.


-Jim

--
https://mail.python.org/mailman/listinfo/python-list

Re: about main()

[Jim Lee]

On 07/05/18 18:14, Michael Torrie wrote:

On 07/05/2018 11:47 AM, Calvin Spealman wrote:

That wasn't me, but I do agree with the sentiment in that its often silly
to focus on them at the wrong time and without constraints that warrant
that focus.

Premature optimization is the root of all evil, the saying goes.  I see
this kind of thing all the time on hobby programming forums for
non-mainstream languages (as an example, FreeBASIC).  People are delving
into assembler all the time for "speed" rather than thinking about their
data structures and algorithms.  I'm not sure they even know where their
programs are spending the majority of their execution time.


Yup.  Like any other skill, part of mastery is knowing *when* to use it 
as well as *how*.


-Jim

--
https://mail.python.org/mailman/listinfo/python-list

Re: about main()

[Steven D'Aprano]

On Thu, 05 Jul 2018 11:27:09 -0700, Jim Lee wrote:

> Take a village of people.  They live mostly on wild berries.

Because of course a community of people living on one food is so 
realistic. Even the Eskimos and Inuit, living in some of the harshest 
environments on earth, managed to have a relatively wide variety of foods 
in their diet.

https://en.wikipedia.org/wiki/Inuit_cuisine

But okay, let's run with this scenario...


> One day, a man invents an automated way to sort good berries from
> poisonous berries.

Right, because it is totally realistic that a pre-agricultural society 
living on nothing but berries has mastered the technology to automate
sorting berries.


> Soon, all the villagers take their berries to him to be
> sorted.

Of course they do, because why pick only edible berries when it is so 
much more fun to pick both edible and poisonous berries, mix them 
together, and then play a game of "let's see if we missed any of the 
deadly berries and will die horribly after eating them accidentally".

In this scenario of yours, is everyone in this a village a workaholic 
with a death-wish? Why exactly are they doing twice as much work as 
necessary picking poisonous berries and mixing them in together with the 
edible berries?


> The man dies, but passes the secret on to his son before doing
> so.  This continues for a few generations.  Eventually, the final
> descendant dies with no children, and the secret vanishes.  Now, the
> entire village is clueless when it comes to identifying the poisonous
> berries.

Even this city boy knows enough to tell the difference between edible 
blackberries, raspberries and strawberries and the many maybe-its-edible-
maybe-its-not berries which grown on random trees and bushes.

Are there a bunch of dead birds around the tree? Then its poisonous.

Do birds happily eat the berries and keep coming back? Then its worth 
trying one or two and see if they give you a stomach ache, if not, 
they're probably safe.

A more sensible example would have been mushrooms. And its true, I'm 
entirely clueless how to identify poisonous mushrooms from edible ones. 
However will I survive?

Nor do I know how to smelt copper, or tan leather using nothing but dung, 
or perform brain surgery. I guess civilization is about to collapse.




-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: about main()

[Michael Torrie]

On 07/05/2018 11:47 AM, Calvin Spealman wrote:
> That wasn't me, but I do agree with the sentiment in that its often silly
> to focus on them at the wrong time and without constraints that warrant
> that focus.

Premature optimization is the root of all evil, the saying goes.  I see
this kind of thing all the time on hobby programming forums for
non-mainstream languages (as an example, FreeBASIC).  People are delving
into assembler all the time for "speed" rather than thinking about their
data structures and algorithms.  I'm not sure they even know where their
programs are spending the majority of their execution time.

I did some Python programming a while back that was pretty math heavy,
but with a few simple optimizations like memoization I was able to make
it run very acceptably fast.  Still an order of magnitude slower than a
C program might run, but I didn't care if it took half a second or a
millisecond for my program to run. It was fast enough.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: about main()

[Steven D'Aprano]

On Thu, 05 Jul 2018 10:41:36 -0700, Jim Lee wrote:

> The horde of
> programmers a generation or two from now may have no clue how to do
> these things.

That's okay, the horde of programmers have never known how to do these 
things (optimization).

They either don't do it at all, or they run riot prematurely "optimizing" 
everything in sight, either obfuscating their code and introducing bugs 
without actually speeding it up, or in many cases actually slowing it 
down. Actually *testing* whether the code is faster is not as much fun as 
writing the cleverest code you possibly can ("I sweated blood and tears 
to write this genius code, of course it will be faster") so the horde 
doesn't do it. And since they don't write tests either (boring and 
repetitive) they don't know when they've broken their own code by 
"optimizing" it.


Debugging is twice as hard as writing the code in the 
first place. Therefore, if you write the code as cleverly
as possible, you are, by definition, not smart enough to
debug it.  -- Brian W. Kernighan


More computing sins are committed in the name of efficiency
(without necessarily achieving it) than for any other single
reason — including blind stupidity.  -- W.A. Wulf


The Rules of Optimization are simple. Rule 1: Don’t do it.
Rule 2 (for experts only): Don’t do it yet.
-- Michael A. Jackson, "Principles of Program Design"



-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Dealing with dicts in doctest

[Cameron Simpson]

On 05Jul2018 17:57, Steven D'Aprano  
wrote:

I have a function which returns a dict, and I want to use doctest to
ensure the documentation is correct. So I write a bunch of doctests:

def func(arg):
   """blah blah blah

   >>> func(1)
   {'a': 1, 'b': 2, 'c': 3}
   """

which is correct, *except* that dict keys have arbitrary order in the
versions of Python I'm using.

I have three ways of dealing with this. Which do you prefer?


Option 4:

   >>> func(1) == {'a': 1, 'b': 2, 'c': 3}
   True

Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

Re: Is there a nice way to switch between 2 different packages providing the same APIs?

[Cameron Simpson]

On 05Jul2018 05:57, Mark Summerfield  wrote:

For GUI programming I often use Python bindings for Qt.

There are two competing bindings, PySide and PyQt.

Ideally I like to have applications that can use either. This way, if I get a 
problem I can try with the other bindings: if I still get the problem, then it 
is probably me; but if I don't it may be an issue with the bindings.

But working with both means that my imports are very messy. Here's a tiny 
example:

if PYSIDE: # bool True -> Use PySide; False -> Use PyQt5
   from PySide2.QtCore import Qt
   from PySide2.QtGui import QIcon
   from PySide2.QtWidgets import (
   QDialog, QFrame, QGridLayout, QLabel, QLineEdit, QPushButton,
   QVBoxLayout)
else:
   from PyQt5.QtCore import Qt
   from PyQt5.QtGui import QIcon
   from PyQt5.QtWidgets import (
   QDialog, QFrame, QGridLayout, QLabel, QLineEdit, QPushButton,
   QVBoxLayout)

The PYSIDE constant is imported from another module and is used for all .py 
files in a given project so that just by changing PYSIDE's value I can run an 
entire application with PySide2 or with PyQt5.

But I'd really rather just have one lot of imports per file.

One obvious solution is to create a 'Qt.py' module that imports everything 
depending on the PYSIDE switch and that I then use in all the other .py files, 
something like this:

from Qt.QtCore import Qt
from Qt.QtGui import QIcon
... etc.

But I'm just wondering if there's a nicer way to do all this?


My recollection is that the Qt names are pretty unique; they're grouped into 
QtCore and QtGui and so forth for organisational, conceptual and maintenance 
reasons, but generally don't conflct.  I tend to make a module like your 
"Qt.py" which doesn't have any hierarchy in its own namespace, so you get code 
like this:


 from Qt import Qt, QIcon, ...

I would call it something other than "Qt" though, to avoid conflict with 
PyQt5.QtCore.Qt etc. Maybe "myqt" or the like.


Your existing sample "if PYSIDE:" code should work directly, as all those names 
you import become simple flat names inside Qt (Qt.Qt, Qt.QIcon, Qt.QDialog, 
etc).


Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

Re: about main()

[Cameron Simpson]

On 05Jul2018 11:22, Rhodri James  wrote:

On 05/07/18 09:43, Abdur-Rahmaan Janhangeer wrote:

just when to use main() in

if __name__ == '__main__' :
main()

is far is it good in py?

or should file intended to be run just not include it?


It's a matter of taste.  If your "file intended to be run" also 
contains things that might be useful as a module, use the "if __name__ 
== '__main__'" trick.  Otherwise it can be more of a distraction than 
a help.  I'm not a big fan of "main()" functions myself; creating a function 
which will be called exactly once seems rather wasteful.


I almost always make a main. For several of my modules there's a meaningful 
command line mode, and for most of the rest I make main run the self tests.


The main function has some advantages:

- I put it at the top of the module, before anything other functions: that way 
 the "main" operation of the module, if there is one, is in your face them you 
 open the file, easy to find. Also, it is _immediately_ apparent that this 
 module has a "main programme" mode.


- You don't need to call it just once. Making a main() function, should it make 
 sense, lets you call it _from other code_. Consider a wrapper which relies on 
 the main function of this module for the core command line operation, or 
 which runs this module's main as some kind of "subcommand" in a larger tool, 
 such as most VCS commands, GraphicsMagick, etc - all have subcommandswhich 
 are effectively standalone things in their own right.


I also advocate making the boilerplate like this:

 if __name__ == '__main__':
   sys.exit(main(sys.argv))

and make main() like this:

 def main(argv=None):
   if argv is None:
 argv = sys.argv
   ... code here ...
   return meaningful_exit_code

The "argv is None" shuffle is for PyPI packaging, where the standard script 
wrapper _doesn't_ pass in sys.argv, (no idea why, I should submit an 
enhancement proposal). Otherwise, there's argv, ready for reuse of the main() 
function from arbitrary code.


Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

[ANN] PyYAML-3.13: YAML parser and emitter for Python

[Ingy dot Net]

 Announcing PyYAML-3.13


A new bug fix release of PyYAML is now available:

http://pyyaml.org/wiki/PyYAML

*** Important Note From Maintainers ***

This is the first PyYAML release by the new maintainers. It was made
critical
because PyYAML-3.12 did not work with the recent Python 3.7 release.

A more ambitious 4.1 release was attempted last week and needed to be
retracted
for many reasons. We apologize any pain caused by the 4.1 removal, but we
remain confident that it was the best decision.

There are over 60 pull requests in PyYAML and LibYAML that will be
represented
in the upcoming 4.2 release and we are working hard to get those to you as
soon
as the release is ready (but no sooner :).

We are are excited that the PyYAML project is moving forward again.

-- The PyYAML Maintenance Team



Changes
===

* Rebuilt with the latest Cython to support the new Python 3.7 release.
* No functionality is different from PyYAML 3.12 in this release.


Resources
=

PyYAML IRC Channel: #pyyaml on irc.freenode.net
YAML IRC Channel: #yaml-dev on irc.freenode.net
LibYAML IRC Channel: #libyaml on irc.freenode.net

PyYAML homepage: http://pyyaml.org/wiki/PyYAML
PyYAML documentation: http://pyyaml.org/wiki/PyYAMLDocumentation
Source and binary installers: https://pypi.python.org/pypi/PyYAML/3.13

GitHub repository: https://github.com/yaml/pyyaml/
Bug tracking: https://github.com/yaml/pyyaml/issues

YAML homepage: http://yaml.org/
YAML-core mailing list:
http://lists.sourceforge.net/lists/listinfo/yaml-core


About PyYAML


YAML is a data serialization format designed for human readability and
interaction with scripting languages. PyYAML is a YAML parser and emitter
for
Python.

PyYAML features a complete YAML 1.1 parser, Unicode support, pickle support,
capable extension API, and sensible error messages. PyYAML supports standard
YAML tags and provides Python-specific tags that allow to represent an
arbitrary Python object.

PyYAML is applicable for a broad range of tasks from complex configuration
files to object serialization and persistance.


Example
===

>>> import yaml

>>> yaml.load("""
... name: PyYAML
... description: YAML parser and emitter for Python
... homepage: http://pyyaml.org/wiki/PyYAML
... keywords: [YAML, serialization, configuration, persistance, pickle]
... """)
{'keywords': ['YAML', 'serialization', 'configuration', 'persistance',
'pickle'], 'homepage': 'http://pyyaml.org/wiki/PyYAML', 'description':
'YAML parser and emitter for Python', 'name': 'PyYAML'}

>>> print yaml.dump(_)
name: PyYAML
homepage: http://pyyaml.org/wiki/PyYAML
description: YAML parser and emitter for Python
keywords: [YAML, serialization, configuration, persistance, pickle]


Maintainers
===

The following people are currently responsible for maintaining PyYAML:

* Ingy döt Net
* Tina Mueller
* Matt Davis

and many thanks to all who have contribributed!
See: https://github.com/yaml/pyyaml/pulls


Copyright
=

Copyright (c) 2017-2018 Ingy döt Net 
Copyright (c) 2006-2016 Kirill Simonov 

The PyYAML module was written by Kirill Simonov .
It is currently maintained by the YAML and Python communities.

PyYAML is released under the MIT license.
See the file LICENSE for more details.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: RANT why the *%#&%^ does installing pip not install setuptools???

[eryk sun]

On Thu, Jul 5, 2018 at 5:37 PM, Steven D'Aprano
 wrote:
> I'm trying to install pip on a Linux Mint box. The maintainers of Mint
> (or possibly their upstream distro, Ubuntu) decided in their infinite
> wisdom to remove the ensurepip package, so
>
> python3 -m ensurepip

In Debian distros, a customized version of ensurepip is part of
python3-venv [1]. But it's only for use in virtual environments; it
doesn't install the upstream version of pip as the system pip. Even
with the customized python3-pip package, it's still recommended to use
the system package manager (apt or dpkg) for the system Python. I only
use pip in local builds and virtual environments, as suggested, so I
can't provide concrete cases in which using it for the system
site-packages actually breaks something due to a version mismatch. Of
course you can remove a package and repair the system if it causes a
conflict, but it's worth a warning at least.

[1]: https://packages.debian.org/stretch/python3-venv
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: about main()

[Jim Lee]

On 07/05/18 14:15, MRAB wrote:

On 2018-07-05 21:43, Jim Lee wrote:



On 07/05/18 12:58, Chris Angelico wrote:

On Fri, Jul 6, 2018 at 4:27 AM, Jim Lee  wrote:


On 07/05/18 10:47, Calvin Spealman wrote:



You say "pitfall", but I say "allow developers to focus on 
higher-level
problems and enable developers to specialize among tasks so every 
single one
of us doesn't have to be a jack of all trades just to build a todo 
list

app".


Sure, that's the *benefit*, but the benefit doesn't erase the 
*pitfall*.


It's the same as with any other convenience.  When a convenience 
becomes a

necessity, skill is lost.

Take a village of people.  They live mostly on wild berries.  One 
day, a man
invents an automated way to sort good berries from poisonous 
berries.  Soon,
all the villagers take their berries to him to be sorted. The man 
dies, but
passes the secret on to his son before doing so.  This continues 
for a few
generations.  Eventually, the final descendant dies with no 
children, and
the secret vanishes.  Now, the entire village is clueless when it 
comes to

identifying the poisonous berries.


I would respect your analogy more if every compiler used today were
forty years old and not being developed by anyone other than its
original creator(s).

ChrisA


It's not about compilers - it's about skills.  As programming becomes
more and more specialized, it becomes harder and harder to find
programmers with a skill set broad enough to be adaptable to a different
task.


Fortunately the berry-sorter is open-source!


Yes, that helps, as long as the reader is able to understand all the 
concepts and algorithms used...


-Jim

--
https://mail.python.org/mailman/listinfo/python-list

Re: about main()

[MRAB]

On 2018-07-05 21:43, Jim Lee wrote:



On 07/05/18 12:58, Chris Angelico wrote:

On Fri, Jul 6, 2018 at 4:27 AM, Jim Lee  wrote:


On 07/05/18 10:47, Calvin Spealman wrote:



You say "pitfall", but I say "allow developers to focus on higher-level
problems and enable developers to specialize among tasks so every single one
of us doesn't have to be a jack of all trades just to build a todo list
app".



Sure, that's the *benefit*, but the benefit doesn't erase the *pitfall*.

It's the same as with any other convenience.  When a convenience becomes a
necessity, skill is lost.

Take a village of people.  They live mostly on wild berries.  One day, a man
invents an automated way to sort good berries from poisonous berries.  Soon,
all the villagers take their berries to him to be sorted.  The man dies, but
passes the secret on to his son before doing so.  This continues for a few
generations.  Eventually, the final descendant dies with no children, and
the secret vanishes.  Now, the entire village is clueless when it comes to
identifying the poisonous berries.


I would respect your analogy more if every compiler used today were
forty years old and not being developed by anyone other than its
original creator(s).

ChrisA


It's not about compilers - it's about skills.  As programming becomes
more and more specialized, it becomes harder and harder to find
programmers with a skill set broad enough to be adaptable to a different
task.


Fortunately the berry-sorter is open-source!
--
https://mail.python.org/mailman/listinfo/python-list

Re: about main()

[Jim Lee]

On 07/05/18 12:58, Chris Angelico wrote:

On Fri, Jul 6, 2018 at 4:27 AM, Jim Lee  wrote:


On 07/05/18 10:47, Calvin Spealman wrote:



You say "pitfall", but I say "allow developers to focus on higher-level
problems and enable developers to specialize among tasks so every single one
of us doesn't have to be a jack of all trades just to build a todo list
app".



Sure, that's the *benefit*, but the benefit doesn't erase the *pitfall*.

It's the same as with any other convenience.  When a convenience becomes a
necessity, skill is lost.

Take a village of people.  They live mostly on wild berries.  One day, a man
invents an automated way to sort good berries from poisonous berries.  Soon,
all the villagers take their berries to him to be sorted.  The man dies, but
passes the secret on to his son before doing so.  This continues for a few
generations.  Eventually, the final descendant dies with no children, and
the secret vanishes.  Now, the entire village is clueless when it comes to
identifying the poisonous berries.


I would respect your analogy more if every compiler used today were
forty years old and not being developed by anyone other than its
original creator(s).

ChrisA


It's not about compilers - it's about skills.  As programming becomes 
more and more specialized, it becomes harder and harder to find 
programmers with a skill set broad enough to be adaptable to a different 
task.


-Jim

--
https://mail.python.org/mailman/listinfo/python-list

Re: about main()

[Chris Angelico]

On Fri, Jul 6, 2018 at 4:27 AM, Jim Lee  wrote:
>
>
> On 07/05/18 10:47, Calvin Spealman wrote:
>>
>>
>>
>> You say "pitfall", but I say "allow developers to focus on higher-level
>> problems and enable developers to specialize among tasks so every single one
>> of us doesn't have to be a jack of all trades just to build a todo list
>> app".
>>
>>
>
> Sure, that's the *benefit*, but the benefit doesn't erase the *pitfall*.
>
> It's the same as with any other convenience.  When a convenience becomes a
> necessity, skill is lost.
>
> Take a village of people.  They live mostly on wild berries.  One day, a man
> invents an automated way to sort good berries from poisonous berries.  Soon,
> all the villagers take their berries to him to be sorted.  The man dies, but
> passes the secret on to his son before doing so.  This continues for a few
> generations.  Eventually, the final descendant dies with no children, and
> the secret vanishes.  Now, the entire village is clueless when it comes to
> identifying the poisonous berries.
>

I would respect your analogy more if every compiler used today were
forty years old and not being developed by anyone other than its
original creator(s).

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: is there a problem with IDLE, python3.7.0, or my computer?

[Chris Angelico]

On Fri, Jul 6, 2018 at 4:20 AM, Bonn Mowae lazaga <2ndmo...@gmail.com> wrote:
> hello, I would like to notify you that there may be a problem with IDLE or 
> Python3.7.0
> I installed python 3.7.0 for my 64 bit windows 10, and it was working fine, I 
> could also use turtle graphics using the command:
>
> from turtle import *
>
>  and:
>
> forward(200)
>
>  and other control commands for turtle, and it was drawing in screen like 
> normal. A while later, I opened up IDLE again. I typed the command:
>
>  from turtle import *
>
> then:
>
>
>  forward(200)
>
>  and it gave me an error message saying that the name forward could not be 
> identified/it didn’t recognise it.

Did you create a file called turtle.py? If so, pick a different name
for your own program - you've shadowed the standard library module.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: about main()

[Jim Lee]

On 07/05/18 10:47, Calvin Spealman wrote:



You say "pitfall", but I say "allow developers to focus on 
higher-level problems and enable developers to specialize among tasks 
so every single one of us doesn't have to be a jack of all trades just 
to build a todo list app".





Sure, that's the *benefit*, but the benefit doesn't erase the *pitfall*.

It's the same as with any other convenience.  When a convenience becomes 
a necessity, skill is lost.


Take a village of people.  They live mostly on wild berries.  One day, a 
man invents an automated way to sort good berries from poisonous 
berries.  Soon, all the villagers take their berries to him to be 
sorted.  The man dies, but passes the secret on to his son before doing 
so.  This continues for a few generations.  Eventually, the final 
descendant dies with no children, and the secret vanishes.  Now, the 
entire village is clueless when it comes to identifying the poisonous 
berries.



-Jim


-Jim
--
https://mail.python.org/mailman/listinfo/python-list

is there a problem with IDLE, python3.7.0, or my computer?

[Bonn Mowae lazaga]

hello, I would like to notify you that there may be a problem with IDLE or 
Python3.7.0
I installed python 3.7.0 for my 64 bit windows 10, and it was working fine, I 
could also use turtle graphics using the command:  
 
from turtle import *   

 and:    

forward(200)   

 and other control commands for turtle, and it was drawing in screen like 
normal. A while later, I opened up IDLE again. I typed the command: 
 
 from turtle import *

then:


 forward(200)

 and it gave me an error message saying that the name forward could not be 
identified/it didn’t recognise it. I did the same with 

left(90) 

and a similar error message popped up, saying that the name left could not be 
identified/it didn’t recognise it. Also, it says the the else keyword is 
invalid syntax, even though it highlighted it in orange, (as shown in the 
email) meaning it recognised it as a keyword. Please notify me if there is a 
problem with python3.7.0, IDLE, or my windows 10 (64 bit.)

Thank you for taking my email into consideration.

P.S. I highlighted certain words in certain colors so you know how it was 
highlighted in IDLE

From: Ancus



Sent from Mail for Windows 10

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: RANT why the *%#&%^ does installing pip not install setuptools???

[Brian J. Oney via Python-list]

On Stretch:

~ $ aptitude show python-pip
Package: python-pip  
Version: 9.0.1-2
...
Maintainer: Debian Python Modules Team 
...
Depends: ca-certificates, python-pip-whl (= 9.0.1-2), python:any (<
2.8), python:any (>= 2.7.5-5~)
Recommends: build-essential, python-all-dev (>= 2.6), python-
setuptools,
python-wheel
...
Tags: admin::package-management, devel::lang:python, devel::packaging,
  implemented-in::python, role::program

And:
~ $ aptitude show python3-pip
Package: python3-pip 
Version: 9.0.1-2
...
Maintainer: Debian Python Modules Team 
...
Depends: ca-certificates, python-pip-whl (= 9.0.1-2), python3:any (>=
3.4~)
Recommends: build-essential, python3-dev (>= 3.2), python3-setuptools,
python3-wheel
...
 

It seems deliberate, but I am not the person to ask why.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Dealing with dicts in doctest

[MRAB]

On 2018-07-05 18:57, Steven D'Aprano wrote:

I have a function which returns a dict, and I want to use doctest to
ensure the documentation is correct. So I write a bunch of doctests:

def func(arg):
 """blah blah blah

 >>> func(1)
 {'a': 1, 'b': 2, 'c': 3}
 """

which is correct, *except* that dict keys have arbitrary order in the
versions of Python I'm using.

I have three ways of dealing with this. Which do you prefer?


1. Re-write the doctest to compare with another dict:

 >>> actual = func(1)
 >>> expected = {'a': 1, 'b': 2, 'c': 3}
 >>> actual == expected
 True

I don't like that because it obscures the clear relationship between
"call the function" -> "here's the output you get".



2. Use a pretty-printer function that cleverly sorts the keys before
printing:

 >>> _ppr(func(1))
 {'a': 1, 'b': 2, 'c': 3}

I don't like that, because the call to the pretty printer obscures the
call to the function.



3. I thought, "what a pity I can't move the pretty printer to the end od
the line, instead of the beginning, to reduce the emphasis on it". And
then I thought, yes I can!" and re-wrote the pretty printer to use the
__ror__ method instead:

 >>> func(1) | _ppr
 {'a': 1, 'b': 2, 'c': 3}


I think that's really clever. Is it too clever? How do you deal with
dicts in doctests?


(Ensuring that the dicts only have a single item is not feasible.)


What about sorting the items?

def func(arg):
 """blah blah blah

 >>> sorted(func(1).items())
 [('a', 1), ('b', 2), ('c', 3)]
 """
--
https://mail.python.org/mailman/listinfo/python-list

Dealing with dicts in doctest

[Steven D'Aprano]

I have a function which returns a dict, and I want to use doctest to 
ensure the documentation is correct. So I write a bunch of doctests:

def func(arg):
"""blah blah blah

>>> func(1)
{'a': 1, 'b': 2, 'c': 3}
"""

which is correct, *except* that dict keys have arbitrary order in the 
versions of Python I'm using.

I have three ways of dealing with this. Which do you prefer?


1. Re-write the doctest to compare with another dict:

>>> actual = func(1)
>>> expected = {'a': 1, 'b': 2, 'c': 3}
>>> actual == expected
True

I don't like that because it obscures the clear relationship between 
"call the function" -> "here's the output you get".



2. Use a pretty-printer function that cleverly sorts the keys before 
printing:

>>> _ppr(func(1))
{'a': 1, 'b': 2, 'c': 3}

I don't like that, because the call to the pretty printer obscures the 
call to the function.



3. I thought, "what a pity I can't move the pretty printer to the end od 
the line, instead of the beginning, to reduce the emphasis on it". And 
then I thought, yes I can!" and re-wrote the pretty printer to use the 
__ror__ method instead:

>>> func(1) | _ppr
{'a': 1, 'b': 2, 'c': 3}


I think that's really clever. Is it too clever? How do you deal with 
dicts in doctests?


(Ensuring that the dicts only have a single item is not feasible.)




-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: about main()

[Calvin Spealman]

On Thu, Jul 5, 2018 at 1:41 PM, Jim Lee  wrote:

>
>
> On 07/05/18 10:15, Calvin Spealman wrote:
>
> On Thu, Jul 5, 2018 at 12:59 PM, Jim Lee  wrote:
>
>>
>>
>> On 07/05/18 05:14, Marko Rauhamaa wrote:
>>
>>> Abdur-Rahmaan Janhangeer :
>>>
 * Create as many functions as you can
>
 performance?

>>> Python?
>>>
>>> Seriously, though. The principle of expressive encapsulation is one of
>>> the basic cornerstones of writing computer programs. Performance barely
>>> ever becomes a question, and even more rarely has anything to do with
>>> the number of function calls (low-level programming language compilers
>>> optimize efficiently).
>>>
>>> The most important objective of software development is the management
>>> of complexity. Silly performance optimizations are way down the priority
>>> list.
>>>
>>>
>>> Marko
>>>
>>
>> Sadly, this *is* the current mindset.
>>
>> "Don't bother optimizing, the compiler does it better than you can."
>>
>
> I think that is a pretty clear mis-characterization of what was said.
>
>
> Well, you did say "silly performance optimizations".
>

That wasn't me, but I do agree with the sentiment in that its often silly
to focus on them at the wrong time and without constraints that warrant
that focus.

> The mindset isn't that optimization will be done for you, but that it
> isn't high on a priority list.
>
>
> Things at the bottom of a priority list tend to never get done -
> especially in the current era of software development.  And if you rarely
> or never do something, you lose the skill.  The horde of programmers a
> generation or two from now may have no clue how to do these things.  That's
> the pitfall behind "smart tools".
>

You say "pitfall", but I say "allow developers to focus on higher-level
problems and enable developers to specialize among tasks so every single
one of us doesn't have to be a jack of all trades just to build a todo list
app".

¯\_(ツ)_/¯

> Tell me, who writes the compilers?  When we die off, nobody will have a
>> clue how to do it...
>>
>> -Jim
>>
>>
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: RANT why the *%#&%^ does installing pip not install setuptools???

[Chris Angelico]

On Fri, Jul 6, 2018 at 3:37 AM, Steven D'Aprano
 wrote:
> I'm trying to install pip on a Linux Mint box. The maintainers of Mint
> (or possibly their upstream distro, Ubuntu) decided in their infinite
> wisdom to remove the ensurepip package, so
>
> python3 -m ensurepip
>
> fails ("No module named ensurepip"). Okay, let's do this the hard way:
>
> sudo apt install python3-pip
>
> Yay, that worked! So then I try using it:
>
> python3 -m pip install blahblahblah
>
> and after downloading the entire package, it crashes:
>
> ImportError: No module named 'setuptools'
>
> because *of course* why would you treat setuptools as a dependency of
> pip, just because it happens to be a dependency of pip? That would be too
> sensible.
>
> sudo apt install python3-setuptools
>
> fixed the issue. But now I want to go out and kick puppies.

What's the output of:

$ apt-cache show python3-pip

? On my system (Debian Stretch), the dependencies are:

Depends: ca-certificates, python3-distutils, python-pip-whl (=
9.0.1-2.3), python3:any (>= 3.4~)
Recommends: build-essential, python3-dev (>= 3.2), python3-setuptools,
python3-wheel

It looks like this needs to be promoted out of recommends into
depends, but if (as is commonly the default) your apt is configured to
automatically install recommended packages, you should be fine.

If kicking puppies isn't your thing, you may want to raise this with
the package maintainer. Again, using the info from my system, which
may not be quite the same as yours:

Maintainer: Debian Python Modules Team


ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: about main()

[Jim Lee]

On 07/05/18 10:15, Calvin Spealman wrote:
On Thu, Jul 5, 2018 at 12:59 PM, Jim Lee > wrote:




On 07/05/18 05:14, Marko Rauhamaa wrote:

Abdur-Rahmaan Janhangeer mailto:arj.pyt...@gmail.com>>:

* Create as many functions as you can

performance?

Python?

Seriously, though. The principle of expressive encapsulation
is one of
the basic cornerstones of writing computer programs.
Performance barely
ever becomes a question, and even more rarely has anything to
do with
the number of function calls (low-level programming language
compilers
optimize efficiently).

The most important objective of software development is the
management
of complexity. Silly performance optimizations are way down
the priority
list.


Marko


Sadly, this *is* the current mindset.

"Don't bother optimizing, the compiler does it better than you can."


I think that is a pretty clear mis-characterization of what was said.



Well, you did say "silly performance optimizations".

The mindset isn't that optimization will be done for you, but that it 
isn't high on a priority list.


Things at the bottom of a priority list tend to never get done - 
especially in the current era of software development.  And if you 
rarely or never do something, you lose the skill.  The horde of 
programmers a generation or two from now may have no clue how to do 
these things.  That's the pitfall behind "smart tools".



Tell me, who writes the compilers?  When we die off, nobody will
have a clue how to do it...

-Jim



--
https://mail.python.org/mailman/listinfo/python-list

RANT why the *%#&%^ does installing pip not install setuptools???

[Steven D'Aprano]

I'm trying to install pip on a Linux Mint box. The maintainers of Mint 
(or possibly their upstream distro, Ubuntu) decided in their infinite 
wisdom to remove the ensurepip package, so

python3 -m ensurepip 

fails ("No module named ensurepip"). Okay, let's do this the hard way:

sudo apt install python3-pip

Yay, that worked! So then I try using it:

python3 -m pip install blahblahblah

and after downloading the entire package, it crashes:

ImportError: No module named 'setuptools'

because *of course* why would you treat setuptools as a dependency of 
pip, just because it happens to be a dependency of pip? That would be too 
sensible.

sudo apt install python3-setuptools

fixed the issue. But now I want to go out and kick puppies.

/rant




-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Is there a nice way to switch between 2 different packages providing the same APIs?

[Tim Williams]

On Thu, Jul 5, 2018 at 9:02 AM Mark Summerfield via Python-list <
python-list@python.org> wrote:

> For GUI programming I often use Python bindings for Qt.
>
> There are two competing bindings, PySide and PyQt.
>
> Ideally I like to have applications that can use either. This way, if I
> get a problem I can try with the other bindings: if I still get the
> problem, then it is probably me; but if I don't it may be an issue with the
> bindings.
>
> But working with both means that my imports are very messy. Here's a tiny
> example:
>
> if PYSIDE: # bool True -> Use PySide; False -> Use PyQt5
> from PySide2.QtCore import Qt
> from PySide2.QtGui import QIcon
> from PySide2.QtWidgets import (
> QDialog, QFrame, QGridLayout, QLabel, QLineEdit, QPushButton,
> QVBoxLayout)
> else:
> from PyQt5.QtCore import Qt
> from PyQt5.QtGui import QIcon
> from PyQt5.QtWidgets import (
> QDialog, QFrame, QGridLayout, QLabel, QLineEdit, QPushButton,
> QVBoxLayout)
>
> The PYSIDE constant is imported from another module and is used for all
> .py files in a given project so that just by changing PYSIDE's value I can
> run an entire application with PySide2 or with PyQt5.
>
> But I'd really rather just have one lot of imports per file.
>
> One obvious solution is to create a 'Qt.py' module that imports everything
> depending on the PYSIDE switch and that I then use in all the other .py
> files, something like this:
>
> from Qt.QtCore import Qt
> from Qt.QtGui import QIcon
> ... etc.
>
> But I'm just wondering if there's a nicer way to do all this?
> --
> https://mail.python.org/mailman/listinfo/python-list


Check out pyqtgraph 

It tries to use  PyQt5/PyQt4/PySide depending on which if these packages
were imported before importing pyqtgraph.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: about main()

[Calvin Spealman]

On Thu, Jul 5, 2018 at 12:59 PM, Jim Lee  wrote:

>
>
> On 07/05/18 05:14, Marko Rauhamaa wrote:
>
>> Abdur-Rahmaan Janhangeer :
>>
>>> * Create as many functions as you can

>>> performance?
>>>
>> Python?
>>
>> Seriously, though. The principle of expressive encapsulation is one of
>> the basic cornerstones of writing computer programs. Performance barely
>> ever becomes a question, and even more rarely has anything to do with
>> the number of function calls (low-level programming language compilers
>> optimize efficiently).
>>
>> The most important objective of software development is the management
>> of complexity. Silly performance optimizations are way down the priority
>> list.
>>
>>
>> Marko
>>
>
> Sadly, this *is* the current mindset.
>
> "Don't bother optimizing, the compiler does it better than you can."
>

I think that is a pretty clear mis-characterization of what was said.

The mindset isn't that optimization will be done for you, but that it isn't
high on a priority list. This is doubly true when looked at from a planning
perspective. Make something work first, make it organized and
understandable, and *then* and only if measurements warrant it do you need
to put resources explicitly towards performance.

Not because performance isn't important or that someone else will do it for
you, but because most problems and contexts do not have constraints that
warrant it as a high and immediate priority.

Tell me, who writes the compilers?  When we die off, nobody will have a
> clue how to do it...
>
> -Jim
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: about main()

[Jim Lee]

On 07/05/18 05:14, Marko Rauhamaa wrote:

Abdur-Rahmaan Janhangeer :

* Create as many functions as you can

performance?

Python?

Seriously, though. The principle of expressive encapsulation is one of
the basic cornerstones of writing computer programs. Performance barely
ever becomes a question, and even more rarely has anything to do with
the number of function calls (low-level programming language compilers
optimize efficiently).

The most important objective of software development is the management
of complexity. Silly performance optimizations are way down the priority
list.


Marko


Sadly, this *is* the current mindset.

"Don't bother optimizing, the compiler does it better than you can."

Tell me, who writes the compilers?  When we die off, nobody will have a 
clue how to do it...


-Jim

--
https://mail.python.org/mailman/listinfo/python-list

Re: File names with slashes [was Re: error in os.chdir]

[Gene Heskett]

On Thursday 05 July 2018 11:57:18 Mikhail V wrote:

> Steven D'Aprano wrote:
> > In Explorer and the open-file dialog of most applications, they will
> > see paths like this:
> >
> > directory\file name with spaces
> >
> > with the extension (.jpg, .pdf, .docx etc) suppressed. So by your
> > argument, Python needs to accept strings without quotes:
> >
> > open(directory\file name with spaces, 'r')
> >
> > and guess which extension you mean.
> >
> > That would be fun to watch in action.
>
> I think it's what is called 'English humor'?
> Funny (just a little bit).
>
> Wait a moment - you are well aware of Windows features,
> that's suspicious...
>
>
> BTW Explorer with hidden extension that's a sign of
> "double-click, drag-and-drop" category of users.
> Definitely more advanced users turn on extensions,
> or don't even use explorer as a file manager.
>
> > Linux programmers will
> > see paths with spaces and other metacharacters escaped:
> >
> > directory/file\ name\ with\ spaces.txt
>
> ick. what I see is escaping of the most frequent Latin character.

ick  is a very weak adjective.

For a change, why can't windows do it right?  Oh wait, its windows so the 
question is moot.  Sigh, and just one of the reasons there are zero 
windows machines on my premises.


-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 
-- 
https://mail.python.org/mailman/listinfo/python-list

File names with slashes [was Re: error in os.chdir]

[Mikhail V]

Steven D'Aprano wrote:

> In Explorer and the open-file dialog of most applications, they will see
> paths like this:
>
> directory\file name with spaces
>
> with the extension (.jpg, .pdf, .docx etc) suppressed. So by your
> argument, Python needs to accept strings without quotes:
>
> open(directory\file name with spaces, 'r')
>
> and guess which extension you mean.
>
> That would be fun to watch in action.


I think it's what is called 'English humor'?
Funny (just a little bit).

Wait a moment - you are well aware of Windows features,
that's suspicious...


BTW Explorer with hidden extension that's a sign of
"double-click, drag-and-drop" category of users.
Definitely more advanced users turn on extensions,
or don't even use explorer as a file manager.

> Linux programmers will
> see paths with spaces and other metacharacters escaped:
>
> directory/file\ name\ with\ spaces.txt


ick. what I see is escaping of the most frequent Latin character.
-- 
https://mail.python.org/mailman/listinfo/python-list

RE: PEP 526 - var annotations and the spirit of python

[Schachner, Joseph]

It is interesting to contemplate how this could transform Python into nearly a 
statically typed language:
x = 3
x = f(x)

If you say the type checker should infer that x is an int, and then therefore 
complain about x=f(x) if f() does not return an int, then we have what in new 
C++ is auto type declaration by default, and after that it's statically typed.

So this would still work
valStr = QueryMeasuringInstrument("app.Meas.P1.Result.Mean")
val = float(valStr)

but this would not:
val = QueryMeasuringInstrument("app.Meas.P1.Result.Mean")
val = float(val)
even though it works today in both Python 2 and Python 3.   I don't think the 
intent of var annotations is to automatically extract the type for variables 
that are not annotated, and then insist that they retain the same type at all 
times.   It would break this example.

I think if I do annotate a variable, THEN the type checker can insist that I do 
not change its type.  So this could cause an error:

string val = QueryMeasuringInstrument("app.Meas.P1.Result.Mean")
val = float(val)

--- Joe S. 

-Original Message-
From: Steven D'Aprano  
Sent: Wednesday, July 4, 2018 11:31 AM
To: python-list@python.org
Subject: Re: PEP 526 - var annotations and the spirit of python

On Wed, 04 Jul 2018 13:48:26 +0100, Bart wrote:

> Presumably one type hint applies for the whole scope of the variable, 
> not just the one assignment.

You know how in C you can write 

int x = 1;  # the type applies for just this one assignment
x = 2.5;# perfectly legal, right?


Wait, no, of course you can't do that. Why would you suggest that as even a 
possibility?

Of course the type (whether inferred or annotated) applies for the entire scope 
of that variable.


> Which means that here:
> 
> x: int = 3
> x = f(x)
> 
> you know x should still an int after these two statements, because the
> type hint says so. Without it:
> 
> x = 3
> x = f(x)
> 
> x could be anything.

That's not how type checking works. It makes *no difference* whether the 
type is inferred or hinted. Type hints only exist to cover the cases the 
type inference engine can't determine, or determine too strictly. See 
below.

In the Dark Ages of type-checking, the compiler was too dumb to work out 
for itself what the type of variables is, so you have to explicitly 
declare them all, even the most obvious ones. Given such a declaration:

int x = 3;  # using C syntax

the type checker is smart enough to look at the next line:

x = f(x);

and complain with a type-error if f() returns (say) a string, or a list. 
Checking that the types are compatible is the whole point of type 
checking.

Now fast forward to the Enlightenment of type-inference, first used in a 
programming language in 1973 (so older than half the programmers alive 
today). That purpose doesn't go away because we're using type inference.

With type-inference, the type-checker is smart enough to recognise what 
type a variable is supposed to be (at least sometimes):

x = 3;  # of course it's an int, what else could it be?
x = f(x);

and likewise complain if f(x) returns something other than an int. 
There's no point in type checking if you don't, you know, actually 
*check* the types.

With type inference, the only reason to declare a variable's type is if 
the type checker can't infer it from the code, or if it infers the wrong 
type. (More on this later.)

To do otherwise is as pointless and annoying as those comments which 
merely repeat what the code does:

import math   # import the math module
mylist.append(v)  # append v to mylist
counter += 1  # add 1 to counter
s = s.upper() # convert s to uppercase
x: int = 3# assign the int 3 to x

Don't be That Guy who writes comments stating the bleeding obvious.

There's not always enough information for the type checker to infer the 
right type. Sometimes the information simply isn't there:

x = []  # a list of what?

and sometimes you actually did intend what looks like a type-error to the 
checker:

x = 3   # okay, x is intended to be an int
x = "spam"  # wait, this can't be right


In the later case, you can annotate the variable with the most general 
"any type at all" type:

from typing import Any
x: Any = 3  # x can be anything, but happens to be an int now
x = "spam"  # oh that's fine then


or you can simply not check that module. (Type checking is optional, not 
mandatory.)



>> A better example would be:
>> 
>>  x: int = None
>> 
>> which ought to be read as "x is an int, or None, and it's currently
>> None".
> 
> In that case the type hint is lying.

"Practicality beats purity."

"This type, or None" is such a common pattern that any half-way decent 
type checker ought to be able to recognise it. You can, of course, 
explicitly annotate it:

x: Optional[int] = None

but the type checker should infer that if you assign None to a variable 
which is declared int, you

Re: PEP 526 - var annotations and the spirit of python

[Antoon Pardon]

On 05-07-18 15:07, Steven D'Aprano wrote:
> On Thu, 05 Jul 2018 13:54:28 +0200, Antoon Pardon wrote:
>
>> On 05-07-18 11:59, Steven D'Aprano wrote:
>>> On Thu, 05 Jul 2018 17:34:55 +1200, Gregory Ewing wrote:
>>>
>>>
> Indeed, that's often the best way, except for the redundant type
> hint, which makes you That Guy:
>
> x: int = 0  # set x to the int 0
 But you've shown in an earlier example that such a hint is *not*
 always redundant
>>> But it is redundant in *that* example. Your hint is not giving any more
>>> information that what the reader, or type checker, can already infer.
>> Yes it gives more information. Without the hint you can only interfere
>> that it is an int at that point.
> That would be utterly pointless:
>
>  x = 3  # infer x must be an int, but only at this point
>  y = x + "Hello world"  # who knows what x is now? maybe it's okay
>
>
> A type checker that did that would be a waste of time.
>
>
>> IIUC, with the hint you can interfere
>> it is supposed to be an int during its life time, not just at that
>> point.
> No.
>
> Mypy considers the initial assignment as the definition
> of a variable. If you do not explicitly specify the type
> of the variable, mypy infers the type based on the
> static type of the value expression
>
> http://mypy.readthedocs.io/en/latest/type_inference_and_annotations.html
>
> This is not an innovation of Mypy. It's how type inference is supposed to 
> work. If a particular type checker doesn't do that, it is doing it wrong.

That is how type interference works in languages that have some kind of static
typing like Haskell. Sure if mypy want to impose something like that it can,
but you can't interfere something like that for python programs in general.

Unless you mean "A probable guess" by interfere.

-- 
Antoon.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: about main()

[Chris Angelico]

On Thu, Jul 5, 2018 at 10:47 PM, Abdur-Rahmaan Janhangeer
 wrote:
> that's what happens when you type from mobile
>
> btw i have top posted since some days only in this thread
>
> as for my english well i got distinction in cambridge ucles in gp for high
> school but practicality beats purity

Ahh, yes. The elegant purity of reading every email that goes through
this mailing list, or the practicality of killfiling people who can't
be bothered to use correct grammar in English, and probably are
comparably sloppy in their code. It's a very important decision to
make.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: about main()

[Chris Angelico]

On Thu, Jul 5, 2018 at 9:20 PM, Marko Rauhamaa  wrote:
> Rhodri James :
>> I'm not a big fan of "main()" functions myself; creating a function
>> which will be called exactly once seems rather wasteful.
>
> A function is the encapsulation of a distinct ... well ... function.
> Functions that are called just once are desirable.
>
> So I'm saying the opposite:
>
>  * Have no code outside functions.

So, no import statements outside functions, no "if name is main"
incantation, and especially, no function definitions outside
functions, because they are themselves code.

What code is permitted outside functions and what isn't?

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PEP 526 - var annotations and the spirit of python

[Steven D'Aprano]

On Thu, 05 Jul 2018 13:54:28 +0200, Antoon Pardon wrote:

> On 05-07-18 11:59, Steven D'Aprano wrote:
>> On Thu, 05 Jul 2018 17:34:55 +1200, Gregory Ewing wrote:
>>
>>
 Indeed, that's often the best way, except for the redundant type
 hint, which makes you That Guy:

 x: int = 0  # set x to the int 0
>>> But you've shown in an earlier example that such a hint is *not*
>>> always redundant
>> But it is redundant in *that* example. Your hint is not giving any more
>> information that what the reader, or type checker, can already infer.
> 
> Yes it gives more information. Without the hint you can only interfere
> that it is an int at that point.

That would be utterly pointless:

 x = 3  # infer x must be an int, but only at this point
 y = x + "Hello world"  # who knows what x is now? maybe it's okay


A type checker that did that would be a waste of time.


> IIUC, with the hint you can interfere
> it is supposed to be an int during its life time, not just at that
> point.

No.

Mypy considers the initial assignment as the definition
of a variable. If you do not explicitly specify the type
of the variable, mypy infers the type based on the
static type of the value expression

http://mypy.readthedocs.io/en/latest/type_inference_and_annotations.html

This is not an innovation of Mypy. It's how type inference is supposed to 
work. If a particular type checker doesn't do that, it is doing it wrong.



-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson

-- 
https://mail.python.org/mailman/listinfo/python-list

Is there a nice way to switch between 2 different packages providing the same APIs?

[Mark Summerfield via Python-list]

For GUI programming I often use Python bindings for Qt.

There are two competing bindings, PySide and PyQt.

Ideally I like to have applications that can use either. This way, if I get a 
problem I can try with the other bindings: if I still get the problem, then it 
is probably me; but if I don't it may be an issue with the bindings.

But working with both means that my imports are very messy. Here's a tiny 
example:

if PYSIDE: # bool True -> Use PySide; False -> Use PyQt5
from PySide2.QtCore import Qt
from PySide2.QtGui import QIcon
from PySide2.QtWidgets import (
QDialog, QFrame, QGridLayout, QLabel, QLineEdit, QPushButton,
QVBoxLayout)
else:
from PyQt5.QtCore import Qt
from PyQt5.QtGui import QIcon
from PyQt5.QtWidgets import (
QDialog, QFrame, QGridLayout, QLabel, QLineEdit, QPushButton,
QVBoxLayout)

The PYSIDE constant is imported from another module and is used for all .py 
files in a given project so that just by changing PYSIDE's value I can run an 
entire application with PySide2 or with PyQt5.

But I'd really rather just have one lot of imports per file.

One obvious solution is to create a 'Qt.py' module that imports everything 
depending on the PYSIDE switch and that I then use in all the other .py files, 
something like this:

from Qt.QtCore import Qt
from Qt.QtGui import QIcon
... etc.

But I'm just wondering if there's a nicer way to do all this?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PEP 526 - var annotations and the spirit of python

[Bart]

On 05/07/2018 11:04, Steven D'Aprano wrote:

On Thu, 05 Jul 2018 09:17:20 +0200, Christian Gollwitzer wrote:



Not sure what point you are trying to make, but your example compiles in
C, if you replace the '#' comment sign with '//'.



Sometimes I wonder how C programmers manage to write a bug-free "Hello
World" program. No wonder it is described as a type-unsafe language or a
weakly-typed language.

I understand upcasting ints to floats, that's cool (even if a few
languages take a hard line on that too, I don't). I understand Python's
dynamic typing approach.


Do you? Python seems to have its own problems when mixing ints and 
floats: the calculation is done as float, that means converting int to 
float which can result in loss of precision when the int is bigger than 
about 2**52.



I don't understand C requiring type
declarations, then down-casting floats to integers.

At least it shows a warning.


You would need a warning both ways, since not all ints are representable 
as floats. And warnings when converting between signed and unsigned. Or 
from a wider int to a narrower one.


Programs would be so full of explicit conversions that real problems 
will be hidden, and they would be difficult to read.


Anyway lower level languages need more skill to write and you need to be 
very aware of what is going on.


--
bart
--
https://mail.python.org/mailman/listinfo/python-list

Re: about main()

[Abdur-Rahmaan Janhangeer]

that's what happens when you type from mobile

btw i have top posted since some days only in this thread

as for my english well i got distinction in cambridge ucles in gp for high
school but practicality beats purity

Abdur-Rahmaan Janhangeer
https://github.com/Abdur-rahmaanJ

>
>
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PEP 526 - var annotations and the spirit of python

[Mark Lawrence]

On 05/07/18 11:26, Bart wrote:



And at numerous other languages that are properly statically typed (Ada 
being one of the most rigorous, while C++ is a nightmare).




I had to chuckle at that as friends of mine have had great fun rewriting 
Ada in C++ as it was just too damn slow.  This was after they'd 
converted the code from CORAL 66 as Ada was the new kid on the block in 
the defence industry world.


Then there was Ada and poor old ariane, didn't help too much there did 
it?  Still I'm fairly certain that the insurers wouldn't have batted an 
eyelid at the mere $356,000,000 payout.


--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: about main()

[Mark Lawrence]

On 05/07/18 11:39, Abdur-Rahmaan Janhangeer wrote:

i once saw a python course (by academics) advertising main() in it's
promotional flier

that's put me in doubt as whether it's that recommended or not

Abdur-Rahmaan Janhangeer
https://github.com/Abdur-rahmaanJ



I can remember back to the good old days when people on this list could 
write in English and didn't top post.  So much for progress :(



--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: about main()

[Marko Rauhamaa]

Abdur-Rahmaan Janhangeer :
>> * Create as many functions as you can
> performance?

Python?

Seriously, though. The principle of expressive encapsulation is one of
the basic cornerstones of writing computer programs. Performance barely
ever becomes a question, and even more rarely has anything to do with
the number of function calls (low-level programming language compilers
optimize efficiently).

The most important objective of software development is the management
of complexity. Silly performance optimizations are way down the priority
list.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: about main()

[Abdur-Rahmaan Janhangeer]

no about wrapping everything in functions

Abdur-Rahmaan Janhangeer
https://github.com/Abdur-rahmaanJ

On Thu, 5 Jul 2018, 15:55 Joel Goldstick,  wrote:

> On Thu, Jul 5, 2018 at 7:45 AM, Abdur-Rahmaan Janhangeer
>  wrote:
> > performance?
>
> You are asking basic file layout questions in the learning process of
> understand how to code in python.  Performance should be very low on
> your list of concerns.  The only thing that happens when the file is
> loaded is that it gets compiled, and run.  If it is imported, and you
> have the 'if __name__ ... block, it will run the code within the if
> block.  If that has a main() function it makes it simpler later to
> change what main does instead of cluttering up the if block.  But
> there is no 'performance' issue that I can see.
> >
> > Abdur-Rahmaan Janhangeer
> > https://github.com/Abdur-rahmaanJ
> >
> > * Create as many functions as you can
> > --
> > https://mail.python.org/mailman/listinfo/python-list
>
>
>
> --
> Joel Goldstick
> http://joelgoldstick.com/blog
> http://cc-baseballstats.info/stats/birthdays
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: about main()

[Joel Goldstick]

On Thu, Jul 5, 2018 at 7:45 AM, Abdur-Rahmaan Janhangeer
 wrote:
> performance?

You are asking basic file layout questions in the learning process of
understand how to code in python.  Performance should be very low on
your list of concerns.  The only thing that happens when the file is
loaded is that it gets compiled, and run.  If it is imported, and you
have the 'if __name__ ... block, it will run the code within the if
block.  If that has a main() function it makes it simpler later to
change what main does instead of cluttering up the if block.  But
there is no 'performance' issue that I can see.
>
> Abdur-Rahmaan Janhangeer
> https://github.com/Abdur-rahmaanJ
>
> * Create as many functions as you can
> --
> https://mail.python.org/mailman/listinfo/python-list



-- 
Joel Goldstick
http://joelgoldstick.com/blog
http://cc-baseballstats.info/stats/birthdays
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PEP 526 - var annotations and the spirit of python

[Antoon Pardon]

On 05-07-18 11:59, Steven D'Aprano wrote:
> On Thu, 05 Jul 2018 17:34:55 +1200, Gregory Ewing wrote:
>
>
>>> Indeed, that's often the best way, except for the redundant type hint,
>>> which makes you That Guy:
>>>
>>> x: int = 0  # set x to the int 0
>> But you've shown in an earlier example that such a hint is *not* always
>> redundant
> But it is redundant in *that* example. Your hint is not giving any more 
> information that what the reader, or type checker, can already infer.

Yes it gives more information. Without the hint you can only interfere that
it is an int at that point. IIUC, with the hint you can interfere it is
supposed to be an int during its life time, not just at that point.

-- 
Antoon.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: about main()

[Abdur-Rahmaan Janhangeer]

performance?

Abdur-Rahmaan Janhangeer
https://github.com/Abdur-rahmaanJ

* Create as many functions as you can
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: about main()

[Bart]

On 05/07/2018 11:22, Rhodri James wrote:

On 05/07/18 09:43, Abdur-Rahmaan Janhangeer wrote:

just when to use main() in

if __name__ == '__main__' :
 main()

is far is it good in py?

or should file intended to be run just not include it?


It's a matter of taste.  If your "file intended to be run" also contains 
things that might be useful as a module, use the "if __name__ == 
'__main__'" trick.  Otherwise it can be more of a distraction than a 
help.  I'm not a big fan of "main()" functions myself; creating a 
function which will be called exactly once seems rather wasteful.


Wasteful of what? Since it will only be called once, that is not exactly 
an overhead.


But packaging the main function like that has some advantages:

1. It /is/ tidily packaged

2. You can place it anywhere in the program

3. It can be more easily copied

4. If you had a need to, it could call itself

5. If sometimes you had to wrap extra code around it, that becomes easier:

prologue()
main()
epilogue()

6. If you had to run it more than once /within the same execution 
environment/, that is easier too.


7. If you had a choice of main1() and main2(), that becomes easier as well.

Actually, I can't think of any downsides.

Not packaging main() into its own function reminds of sprawling, 
unstructured Fortran code from the 1970s, when people even frowned upon 
putting long stretches of code into a subroutine.


--
bart


--
https://mail.python.org/mailman/listinfo/python-list

Re: about main()

[Marko Rauhamaa]

Rhodri James :
> I'm not a big fan of "main()" functions myself; creating a function
> which will be called exactly once seems rather wasteful.

A function is the encapsulation of a distinct ... well ... function.
Functions that are called just once are desirable.

So I'm saying the opposite:

 * Have no code outside functions.

 * Make the functions as small as (meaningfully) possible. Most should
   be smaller than 20 lines.

 * Create as many functions as you can.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: about main()

[Marko Rauhamaa]

Abdur-Rahmaan Janhangeer :

> just when to use main() in
>
> if __name__ == '__main__' :
> main()
>
> is far is it good in py?
>
> or should file intended to be run just not include it?

I think all Python programs should have it.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Using Python with a website

[Alister via Python-list]

On Wed, 04 Jul 2018 23:25:14 +, Adrian Taylor wrote:

> G'day All,
> 
> I have just discovered Python and thanks to a script by Ethan I can read
> a foxpro database and change the required values.
> However my next big step is to be able to use this python feature within
> a website.
> 
> Basically I want to be able to click on a button and call the script.
> This would in turn display some information on the webpage but do what
> it needs to do on the server.
> I have setup Apache and it all works on the server, my stumbling block
> is calling it from a website.
> 
> I am using Server 2012 R2 Python 3.7 Apache 2.4 I can run the Python
> scripts from the command line prompt.
> 
> Can anyone help?
> 
> Regards,
> Adrian Taylor InfoHub - ICT - Helpdesk
> 
> 
> 
> A : 5 Faith Avenue, Plainland , QLD 4341 T : 07 5466 9900 E :
> atay...@faithlc.qld.edu.au
> W : www.faithlc.qld.edu.au
> 
> [cid:image005.png@01D2CD7E.0F6F4710]
> 
> 
> 
> The information contained in this e-mail message and any attached files
> may be confidential information, and may also be the subject of legal
> professional privilege. If you are not the intended recipient any use,
> disclosure or copying of this e-mail is unauthorised. If you have
> received this e-mail in error, please notify the sender immediately by
> reply e-mail and delete all copies of this transmission together with
> any attachments.

start by looking up uwsgi




-- 
Sun in the night, everyone is together,
Ascending into the heavens, life is forever.
-- Brand X, "Moroccan Roll/Sun in the Night"
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Vectorizing operation involving multiple DataFrames

[Viswanath Potluri]

On Wednesday, July 4, 2018 at 7:51:19 PM UTC-7, Viswanath Potluri wrote:
> I've a dataframe all_paths with say 9000 rows, and i've another dataframe 
> Legs with 4000 rows. I need to filter all_paths dataframe based on a column 
> called 'itineraries' which contains a list of strings, for each row in Legs. 
> So, basically its like getting a dataframe that is subset of all_paths for 
> each row in Legs. Then I need to perform a math operation on the columns of 
> each subset and assign the values back to another column in all_paths. 
> Following is my implementation
> 
> def step1_vec(iti_list, idx):
>   mask= all_paths.loc[all_paths['Path'].isin(iti_list)]
>   Legs.loc[idx,'r']=np.dot(mask['demand'].values, mask['u'].values.T)
>   Legs.loc[idx, 't']= Legs.loc[idx, 'k']/Legs.loc[idx, 'r']
> 
> def step2():
>   not_full_legs=Legs.loc[(~Legs['Leg ID'].isin(full_legs))&(Legs['t']<1)]
>   np.vectorize(step1_vec 
> (not_full_legs['itineraries'].values,not_full_legs.index.values)

does someone has a solution for my question??
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: about main()

[Abdur-Rahmaan Janhangeer]

i once saw a python course (by academics) advertising main() in it's
promotional flier

that's put me in doubt as whether it's that recommended or not

Abdur-Rahmaan Janhangeer
https://github.com/Abdur-rahmaanJ

>  main()
> >
> > is far is it good in py?
> >
> > or should file intended to be run just not include it?
>
> It's a matter of taste.  If your "file intended to be run" also contains
> things that might be useful as a module, use the "if __name__ ==
> '__main__'" trick.  Otherwise it can be more of a distraction than a
> help.  I'm not a big fan of "main()" functions myself; creating a
> function which will be called exactly once seems rather wasteful.
>
> --
> Rhodri James *-* Kynesim Ltd
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: about main()

[Rhodri James]

On 05/07/18 09:43, Abdur-Rahmaan Janhangeer wrote:

just when to use main() in

if __name__ == '__main__' :
 main()

is far is it good in py?

or should file intended to be run just not include it?


It's a matter of taste.  If your "file intended to be run" also contains 
things that might be useful as a module, use the "if __name__ == 
'__main__'" trick.  Otherwise it can be more of a distraction than a 
help.  I'm not a big fan of "main()" functions myself; creating a 
function which will be called exactly once seems rather wasteful.


--
Rhodri James *-* Kynesim Ltd
--
https://mail.python.org/mailman/listinfo/python-list

Re: PEP 526 - var annotations and the spirit of python

[Bart]

On 05/07/2018 10:59, Steven D'Aprano wrote:


But it is redundant in *that* example. Your hint is not giving any more
information that what the reader, or type checker, can already infer.

These are useful:

 x: Any = 3  # x can be anything, but is currently an int

 x: int = None # x can be an int, or None

 x: Union[int, str] = 'abc'  # x can be either an int, or a
 # string, not just the string you see here


This is one reason I dropped type hinting from my own developments.

It's a poor, half-baked version of both true static typing, and of true 
type inference.


Look at Haskell for how type inference can be done well (I have to 
admire it even if I don't understand it).


And at numerous other languages that are properly statically typed (Ada 
being one of the most rigorous, while C++ is a nightmare).


--
bart
--
https://mail.python.org/mailman/listinfo/python-list

Re: Congrats to Chris for breaking his PEP curse

[Steven D'Aprano]

On Thu, 05 Jul 2018 17:59:05 +1200, Gregory Ewing wrote:

> Steven D'Aprano wrote:
>> Not everything in Python uses a strict left-to-right reading order.
>> Just like English really.
> 
> Well, English is read left to right, but it doesn't always mean things
> in the order it says them. :-)

"First things first, but not necessarily in that order."
- Doctor Who


-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PEP 526 - var annotations and the spirit of python

[Steven D'Aprano]

On Thu, 05 Jul 2018 09:17:20 +0200, Christian Gollwitzer wrote:

> Am 04.07.18 um 17:31 schrieb Steven D'Aprano:
>> On Wed, 04 Jul 2018 13:48:26 +0100, Bart wrote:
>> 
>>> Presumably one type hint applies for the whole scope of the variable,
>>> not just the one assignment.
>> 
>> You know how in C you can write
>> 
>>  int x = 1;  # the type applies for just this one assignment x =
>>  2.5;# perfectly legal, right?
>> 
>> 
> Not sure what point you are trying to make, but your example compiles in
> C, if you replace the '#' comment sign with '//'.


Oops.


But... it compiles? Seriously? 

> Only it doesn't do
> what you might think: the 2.5 is down-converted to an integer, therefore
> x will be 2 in the end. There will be a compiler warning but no error.

Sometimes I wonder how C programmers manage to write a bug-free "Hello 
World" program. No wonder it is described as a type-unsafe language or a 
weakly-typed language.

I understand upcasting ints to floats, that's cool (even if a few 
languages take a hard line on that too, I don't). I understand Python's 
dynamic typing approach. I don't understand C requiring type 
declarations, then down-casting floats to integers.

At least it shows a warning. But hell, who pays attention to C compiler 
warnings? There's *so many of them*.

(And I bet that by default the warning is disabled, amirite?)



-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PEP 526 - var annotations and the spirit of python

[Steven D'Aprano]

On Thu, 05 Jul 2018 17:34:55 +1200, Gregory Ewing wrote:

> Steven D'Aprano wrote:
> 
>> but the type checker should infer that if you assign None to a variable
>> which is declared int, you must have meant Optional[int] rather than
>> just int.
> 
> This seems to be equivalent to saying that *all* types are Optional, in
> which case what point is there in having Optional at all?

How do you reason that?

x = 3

infers that x is an int, and only an int, not an optional int. An 
explicit hint, like:

def func(x:int) -> something

requires func(x) to only accept int arguments, not int-or-None. But:

def func(x:int = None) -> something

says to the type checker, in effect, "Yeah, I know I said an int, but I 
obviously also want to allow None because that's the default, so just 
deal with it, okay?"

You may or may not like the "Do What I Mean" aspect of this, you might 
question whether Optional[int] is really more common than Union[int, str] 
(for example). But I don't see how you go from this narrowly defined 
exceptional situation ("use a hint for one type and assign None on the 
same line") and conclude that "all types are optional".


>> Indeed, that's often the best way, except for the redundant type hint,
>> which makes you That Guy:
>> 
>> x: int = 0  # set x to the int 0
> 
> But you've shown in an earlier example that such a hint is *not* always
> redundant

But it is redundant in *that* example. Your hint is not giving any more 
information that what the reader, or type checker, can already infer.

These are useful:

x: Any = 3  # x can be anything, but is currently an int

x: int = None # x can be an int, or None

x: Union[int, str] = 'abc'  # x can be either an int, or a
# string, not just the string you see here


but this is redundant (unless you're forced to use a type-checker with no 
type inference at all):

x: int = 3

Well duh of course its an int. That's what 3 is. An int. If it were a 
comment, you'd slap the writer around the head with a clue-stick:

x = 3  # x is an int


> e.g.
> 
> x = 0
> x = 2.5
> 
> is legal and useful, 

Of course it is useful -- well, not *literally* that pair of lines, but I 
know what you mean -- but its probably an error.

Mypy allows ints wherever a float is expected:

x = 0.0  # infer x is a float
x = 1# ints are compatible with floats

https://github.com/python/typing/issues/48

which probably isn't *strictly* valid (ints can exceed the range of 
floats), so I assume there's a switch to disable it. But the other way is 
an error:

x = 0# infer x is an int
x = 2.5  # that's not an int!


Some type checkers may even enforce a strict separation of ints and 
floats. In any case, if you want to overrule the type checker, you can:

x: Union[int, float] = 0
x = 2.5


A better example would be:

x = 0  # infers type int, or maybe type Number
x = "foo"  # certainly not a number, so a type error



> whereas
> 
> x: int = 0
> x = 2.5
> 
> ought to be a type error.

It ought to be a type error even without the hint.




-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson

-- 
https://mail.python.org/mailman/listinfo/python-list

about main()

[Abdur-Rahmaan Janhangeer]

just when to use main() in

if __name__ == '__main__' :
main()

is far is it good in py?

or should file intended to be run just not include it?



Abdur-Rahmaan Janhangeer
https://github.com/Abdur-rahmaanJ
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PEP 526 - var annotations and the spirit of python

[Abdur-Rahmaan Janhangeer]

he means too much of it

Abdur-Rahmaan Janhangeer
https://github.com/Abdur-rahmaanJ

Well you always mention how like english the if-expression in python is and
> thus by implication readable.
>
> --
> Antoon.
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PEP 526 - var annotations and the spirit of python

[Antoon Pardon]

On 05-07-18 08:58, Steven D'Aprano wrote:
>
>> Optimize for readability, not writability.
> And that is why we all hold COBOL up as the paragon of excellence for a 
> programming language! *wink*
>
> Or if you don't like COBOL, how about Hypertalk?

Well you always mention how like english the if-expression in python is and
thus by implication readable.

-- 
Antoon.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PEP 526 - var annotations and the spirit of python

[Christian Gollwitzer]

Am 04.07.18 um 17:31 schrieb Steven D'Aprano:

On Wed, 04 Jul 2018 13:48:26 +0100, Bart wrote:


Presumably one type hint applies for the whole scope of the variable,
not just the one assignment.


You know how in C you can write

 int x = 1;  # the type applies for just this one assignment
 x = 2.5;# perfectly legal, right?



Not sure what point you are trying to make, but your example compiles in 
C, if you replace the '#' comment sign with '//'. Only it doesn't do 
what you might think: the 2.5 is down-converted to an integer, therefore 
x will be 2 in the end. There will be a compiler warning but no error.



=
Apfelkiste:Tests chris$ cat intx.c
#include 
int main() {
int x=1;
x=2.5;
printf("%d\n", x);
return 0;
}

Apfelkiste:Tests chris$ gcc intx.c -o intx && ./intx
intx.c:4:4: warning: implicit conversion from 'double' to 'int' changes 
value

  from 2.5 to 2 [-Wliteral-conversion]
x=2.5;
 ~^~~
1 warning generated.
2



Christian
--
https://mail.python.org/mailman/listinfo/python-list

Re: PEP 526 - var annotations and the spirit of python

[Chris Angelico]

On Thu, Jul 5, 2018 at 4:58 PM, Steven D'Aprano
 wrote:
>> Optimize for readability, not writability.
>
> And that is why we all hold COBOL up as the paragon of excellence for a
> programming language! *wink*
>
> Or if you don't like COBOL, how about Hypertalk?
>
> put 42 into x
> ask file "Which file would you like to open?" with "default.txt"
> if it is empty exit to Hypercard
> put it into thefile
> open file thefile
> repeat with num = 1 to x
>   write "spam" to file thefile
> end repeat
> close file thefile
>

Using Chai and Mocha to test a Node.js web app ends up looking a bit
like that, actually. You perform a request, then make assertions:

expect(res).to.be.json;
expect(res.body).to.be.an(object);
expect(res.body.stuff).to.be.an(array);
expect(res.body.stuff).to.have.length(5);

etc etc etc.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PEP 526 - var annotations and the spirit of python

[Steven D'Aprano]

On Wed, 04 Jul 2018 13:26:03 -0600, Ian Kelly wrote:

[...]
>> Note that None is a special case (because sometimes special cases *are*
>> special enough to break the rules).
> 
> 
> I don't think this case is special enough. As a person coming along
> later and trying to read the code, I should be able to trust that the
> type hint means what it says. I should not have to go look up the rules
> of the linter to infer that in this case, type A actually means type B.

I hear what you're saying, and I neither agree nor disagree. But 
describing it as "Type A" versus "Type B" exaggerates the difference. Its 
more like "Type A" versus "Optional Type A" -- and, so the argument goes, 
it ought to be blindingly obvious from context.


> Optimize for readability, not writability.

And that is why we all hold COBOL up as the paragon of excellence for a 
programming language! *wink*

Or if you don't like COBOL, how about Hypertalk?

put 42 into x
ask file "Which file would you like to open?" with "default.txt"
if it is empty exit to Hypercard
put it into thefile
open file thefile
repeat with num = 1 to x
  write "spam" to file thefile
end repeat
close file thefile



-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson

-- 
https://mail.python.org/mailman/listinfo/python-list