date:20180705

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???

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


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

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

[issue34059] multiprocessing deadlock

2018-07-05 Thread Guillaume Perrault-Archambault



New submission from Guillaume Perrault-Archambault :

The simple code attached causes a deadlock in Linux.

Problem is I have to slightly muck around with it depending on the distro and 
python version to get it to deadlock.

On the cluster I use the most (python 3.6.3, CentOS Linux release 7.4.1708, 
pytorch 0.4.0 with no CUDA), the code attached causes a deadlock.

--
components: Library (Lib)
files: multiprocess_torch.py
messages: 321146
nosy: gobbedy
priority: normal
severity: normal
status: open
title: multiprocessing deadlock
type: crash
versions: Python 3.6
Added file: https://bugs.python.org/file47673/multiprocess_torch.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

testing code

2018-07-05 Thread 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

[issue34051] Update multiprocessing example

2018-07-05 Thread Windson Yang



Change by Windson Yang :


--
nosy: +zach.ware

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Dealing with dicts in doctest

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???

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()

2018-07-05 Thread 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

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

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???

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()




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()




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()

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()

2018-07-05 Thread 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()

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

[issue34058] Default Python 3.7 install broken on openSUSE Leap 42.3: $PYTHONHOME/lib64/python3.7/lib-dynload/ not linked to $PYTHONHOME/lib/python3.7/lib-dynload/

2018-07-05 Thread Ted Kandell



New submission from Ted Kandell :

The default Python 3.7 install (./configure with no parameters) does not work 
(at least) on openSUSE Leap 42.3. 

Python3 gives a ModuleNotFoundError: No module named 'readline'
 error, and pip3 has a ModuleNotFoundError: No module named '_socket' error, 
because the site libraries cannot be found.

The fix is to manually:
sudo ln -s /usr/local/lib64/python3.7/lib-dynload/ 
/usr/local/lib/python3.7/lib-dynload

The same problem should also be present with a PYTHONHOME other than the 
default /usr/local .

I suspect this is a more widespread problem than just openSUSE Leap 42.3, and 
may exist in other distros as well.

The fix should be for make install to automatically create the symbolic link 
for the  $PYTHONHOME/lib64/python3.7/lib-dynload directory in 
$PYTHONHOME/lib/python3.7/ .

--
components: Installation
messages: 321145
nosy: tkandell
priority: normal
severity: normal
status: open
title: Default Python 3.7 install broken on openSUSE Leap 42.3: 
$PYTHONHOME/lib64/python3.7/lib-dynload/ not linked to 
$PYTHONHOME/lib/python3.7/lib-dynload/
type: crash
versions: Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34047] IDLE: on macOS, scroll slider 'sticks' at bottom of file

2018-07-05 Thread Bruce Elgort


Bruce Elgort  added the comment:

Terry,

Here is a video I made showing the problem I’m having. I have no clue about the 
other things you are asking about.

https://www.youtube.com/watch?v=BpyMhdjTNvQ 


Bruce

> On Jul 5, 2018, at 3:21 PM, Terry J. Reedy  wrote:
> 
> 
> Change by Terry J. Reedy :
> 
> 
> --
> stage:  -> test needed
> title: Scrolling in IDLE for OS X is not working correctly when reaching end 
> of file -> IDLE: on macOS, scroll slider 'sticks' at bottom of file
> 
> ___
> Python tracker 
> 
> ___

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34019] webbrowser: wrong arguments for Opera browser.



Change by Pablo Galindo Salgado :


--
pull_requests: +7707

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28657] cmd.Cmd.get_help() implementation can't see do_*() methods added dynamically by setattr()



Change by Raymond Hettinger :


--
resolution: later -> 

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34019] webbrowser: wrong arguments for Opera browser.

2018-07-05 Thread Bumsik Kim



Bumsik Kim  added the comment:

I also believe this can be backported to 2.7 as well.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Dealing with dicts in doctest

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

[issue28657] cmd.Cmd.get_help() implementation can't see do_*() methods added dynamically by setattr()



Raymond Hettinger  added the comment:

> That method would then perform an assignment with setattr() calls: 
> setattr(self, "do_" + command, func).

Could this have been done with:  setattr(self.__class__, "do_" + command, func)?

I'm concerned that attaching functions to the instance is fighting the Python 
norms and the design of the module.  It seems like a can of worms.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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


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()


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

[issue34049] abs() method accept argument that implement abs()



Raymond Hettinger  added the comment:

Thanks

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34051] Update multiprocessing example



Change by Raymond Hettinger :


--
assignee: docs@python -> davin
nosy: +davin

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34057] Py_Initialize aborts when using static Python version. Windows



Change by STINNER Victor :


--
nosy: +vstinner

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34057] Py_Initialize aborts when using static Python version. Windows

2018-07-05 Thread Alberto



New submission from Alberto :

Hi,

I've followed the build instructions to get a statically linked Python library 
in windows. The compilation works great and I get a big fat statically linked 
.lib file. 

When I use it and in my code I call Py_Initialize() the program aborts and I 
get this error:

Fatal Python error: initfsencoding: unable to load the file system codec
ModuleNotFoundError: No module named 'encodings'

It seems that python is looking for encodings on the file system instead of 
looking for the built-in one since if I do 
Py_SetPythonHome(L"C:\\Python37.0-x64"); before calling Py_Initialize it works 
fine. 

Why is Python looking for external modules when it is a statically linked 
library and encodings should be built-in?

How can I indicate Python to look for the modules in itself and not externally?

Regards

--
components: Interpreter Core
messages: 321140
nosy: illera88
priority: normal
severity: normal
status: open
title: Py_Initialize aborts when using static Python version. Windows
type: crash
versions: Python 3.8

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34056] checked hash-based pyc files not working with imp module

2018-07-05 Thread Patrick McCarty



Change by Patrick McCarty :


Added file: https://bugs.python.org/file47672/imp-test-mod.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34044] subprocess: reusing STARTUPINFO breaks under 3.7 (Windows)

2018-07-05 Thread Sebastian Bank



Sebastian Bank  added the comment:

Perfect, thanks for the quick fix.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34056] checked hash-based pyc files not working with imp module

2018-07-05 Thread Patrick McCarty



New submission from Patrick McCarty :

OS: Clear Linux build 23460
Python version: 3.7.0

Description:
I am seeing an uncaught exception in Python 3.7.0 when using the "imp" module 
to import a module that has a checked hash-based pyc file. See the attached 
source files.

Steps to reproduce:
1) Copy attached source files to a directory
2) In that directory, run
$ python3.7 -m compileall --invalidation-mode checked-hash imp-test-mod.py
$ python3.7 imp-test.py
3) See the resulting output (omitting the imp deprecation notice):

Traceback (most recent call last):
  File "imp-test.py", line 6, in 
mod = imp.load_module(modname, f, p, d)
  File "/usr/lib/python3.7/imp.py", line 235, in load_module
return load_source(name, filename, file)
  File "/usr/lib/python3.7/imp.py", line 172, in load_source
module = _load(spec)
  File "", line 696, in _load
  File "", line 677, in _load_unlocked
  File "", line 724, in exec_module
  File "", line 838, in get_code
TypeError: a bytes-like object is required, not 'str'

--
components: Interpreter Core
files: imp-test.py
messages: 321139
nosy: phmccarty
priority: normal
severity: normal
status: open
title: checked hash-based pyc files not working with imp module
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file47671/imp-test.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

2018-07-05 Thread 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

[issue34047] IDLE: on macOS, scroll slider 'sticks' at bottom of file



Change by Terry J. Reedy :


--
stage:  -> test needed
title: Scrolling in IDLE for OS X is not working correctly when reaching end of 
file -> IDLE: on macOS, scroll slider 'sticks' at bottom of file

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

2018-07-05 Thread 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

[issue34047] Scrolling in IDLE for OS X is not working correctly when reaching end of file



Terry J. Reedy  added the comment:

1 down, but how about my other questions?
Is there only a problem if the slider is the first thing touched?
Is there still a problem if the line "return 'break'" in 
idlelib.editor.EditorWindow.handle_yview is deleted or disabled by prefixig it 
with '#'?  (Are you allowed to edit stdlib files?)
Do you see any messages if you start IDLE in a terminal?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34055] IDLE: erroneous 'smart' indents in shell



Terry J. Reedy  added the comment:

def funcname(param = 'somestring)
 # Indent for next param.

is another situation where \n is treating as closing '.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34055] IDLE: erroneous 'smart' indents in shell



Terry J. Reedy  added the comment:

The SyntaxError is not relevant.  Interactive CPython:

>>> d=[]
>>> d=()
>>> d={}
>>>

Erroneous extra lines in IDLE 3.6+ Shell but not editor:

>>> d = []
 
>>> d=()
 
>>> d={}
 
>>> d=[i for i in [1]]
 
>>> 

The 'blank' lines are indents produced by IDLE's smart indent mechanism, which 
is trigger by keying '\n', *before* the code is tentatively compiled.

While the extra lines are an error for the examples above, they are arguably 
correct for your example, where there is no closing '}'.  The indenter treats 
it the same as if there were a closing quote, as in the following, which *is* 
the same in shell and editor, and correct.

d = {1: 'one}'
 # Indent lines up next dict item with the one above.

Even though your example is no a bug, it lead me to discover a regression in 
current 3.6+.  In the past year, there have been a couple of patches that 
touched the autoindent code.

--
stage:  -> test needed
title: IDLE inserts extra blank line in prompt after SyntaxError -> IDLE: 
erroneous 'smart' indents in shell
versions: +Python 3.7, Python 3.8

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: about main()




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

[issue33944] Deprecate and remove pth files

2018-07-05 Thread Ivan Pozdeev



Ivan Pozdeev  added the comment:

> They are very difficult to debug because they're processed too early.  

.pth's are processed by site.py, so no more difficult than site/sitecustomize.
You can e.g. run `site.addpackage(,,None)' to debug the logic.

> They usually contain globs of inscrutable code.

An ability to contain code is there for a reason: to allow a module do 
something more intelligent than adding hardcoded paths if needed (e.g. pywin32 
adds a subdir with .dll dependencies to PATH).

A chunk of code is limited to a single line -- a conscious limitation to deter 
misuse 'cuz search path setup code is presumed to be small.

If someone needs something other than path setup, they should do it upon the 
module's import instead.
If they insist on misusing the feature, Python's design does what it's supposed 
to do in such cases: "make right things easy, make wrong things hard".

If there's a valid reason to allow larger code chunks, we can introduce a 
different syntax -- e.g. something like bash here-documents.

> Exceptions in pth files can get swallowed in some cases.

If this happens, it's a bug. A line from .pth is executed with "exec line", any 
exceptions should propagate up the stack as usual.

> They are loaded in indeterminate order.

Present a use case justifying a specific order.
I can see a probable use case: a package needs to do something using its 
dependencies, so any .pth for the dependencies should run before the one for 
the package.
But I can't see why that package can't do this upon its import instead (saves 
unnecessary work if the user won't be using that package in that session, too).
The only valid case I can see is if the package is using some 3rd-party import 
system (e.g. a .7z archive or some module repository) that needs to be loaded 
first for its search path to make sense.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34044] subprocess: reusing STARTUPINFO breaks under 3.7 (Windows)



STINNER Victor  added the comment:

Sebastian Bank: Thank you for your bug report and your example! I used your 
example to write an unit test. I fixed the bug in 3.7 and master branches. The 
fix will be part of the future 3.7.1 release.

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34044] subprocess: reusing STARTUPINFO breaks under 3.7 (Windows)



STINNER Victor  added the comment:


New changeset 29be3bd3c9aed0190e60096a603120cacda82375 by Victor Stinner in 
branch '3.7':
bpo-34044: subprocess.Popen copies startupinfo (GH-8090) (GH-8121)
https://github.com/python/cpython/commit/29be3bd3c9aed0190e60096a603120cacda82375


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: about main()

2018-07-05 Thread 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

[issue34044] subprocess: reusing STARTUPINFO breaks under 3.7 (Windows)



Change by STINNER Victor :


--
pull_requests: +7706

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34044] subprocess: reusing STARTUPINFO breaks under 3.7 (Windows)



STINNER Victor  added the comment:


New changeset 483422f57e5d8c8bf8820fec29fc9b96bb15d4ef by Victor Stinner in 
branch 'master':
bpo-34044: subprocess.Popen copies startupinfo (GH-8090)
https://github.com/python/cpython/commit/483422f57e5d8c8bf8820fec29fc9b96bb15d4ef


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34044] subprocess: reusing STARTUPINFO breaks under 3.7 (Windows)

2018-07-05 Thread miss-islington



Change by miss-islington :


--
pull_requests: +7705

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: about main()




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()

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?

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()




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?

2018-07-05 Thread 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

[issue34042] Reference loss for local classes

2018-07-05 Thread Yury Selivanov



Yury Selivanov  added the comment:

> Agreed, if it was a real reference bug, the interpreter should crash before 
> the total reference count gets negative ;-)

First thing I checked with Serhiy's script :)

A PR with a fix: https://github.com/python/cpython/pull/8119

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34042] Reference loss for local classes

2018-07-05 Thread Yury Selivanov



Change by Yury Selivanov :


--
keywords: +patch
pull_requests: +7704
stage:  -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15443] datetime module has no support for nanoseconds

2018-07-05 Thread Steve Holden



Change by Steve Holden :


--
nosy:  -holdenweb

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34042] Reference loss for local classes

2018-07-05 Thread Antoine Pitrou



Antoine Pitrou  added the comment:

Agreed, if it was a real reference bug, the interpreter should crash before the 
total reference count gets negative ;-)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34042] Reference loss for local classes

2018-07-05 Thread Yury Selivanov



Yury Selivanov  added the comment:

This isn't a real reference bug, but rather a bug in total refs accountability. 
 It seems that I missed the fact that we track refs to the keys table with a 
DK_INCREF macro.

The new `clone_combined_dict` uses `memcpy` to clone the keys table (along with 
its `dk_refcnt` field, but it doesn't register the fact that we have a new keys 
table after copying.  The bug can be solved with the following diff:

diff --git a/Objects/dictobject.c b/Objects/dictobject.c
index 7a1bcebec6..3ac6a54415 100644
--- a/Objects/dictobject.c
+++ b/Objects/dictobject.c
@@ -656,6 +656,7 @@ clone_combined_dict(PyDictObject *orig)
 /* Maintain tracking. */
 _PyObject_GC_TRACK(new);
 }
+_Py_INC_REFTOTAL;
 return (PyObject *)new;
 }


I don't think this is a critical-level bug that needs an emergency 3.7.1 
release, but I'll submit a PR right now. Would appreciate if you guys can 
review it.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

2018-07-05 Thread 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

[issue24954] No way to generate or parse timezone as produced by datetime.isoformat()

2018-07-05 Thread Guido van Rossum



Change by Guido van Rossum :


--
nosy:  -gvanrossum

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34047] Scrolling in IDLE for OS X is not working correctly when reaching end of file

2018-07-05 Thread Bruce Elgort



Bruce Elgort  added the comment:

2.7.15 scrolling is working just fine.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34055] IDLE inserts extra blank line in prompt after SyntaxError

2018-07-05 Thread Grant Jenks



New submission from Grant Jenks :

IDLE inserts an extra blank line after the prompt after encountering a 
SyntaxError:

```
>>> 1 + 2
3
>>> print('Hello')
Hello
 v-- Missing single quote!
>>> d = {1: 'uno', 2: 'dos', 3: 'tres}
 
SyntaxError: EOL while scanning string literal
>>> print('Hello')
 <-- Extra blank line and whitespace (tab and space).
Hello
>>> 1 + 2
 <-- Extra blank line and whitespace (tab and space).
3
>>> 
```

Notice the line starting with ">>> d =" above contains a missing single quote 
which causes a "SyntaxError: EOL while scanning string literal". This causes 
IDLE to insert extra blank lines with one tab and one space after every input.

The old behavior looked like:

```
>>> 1 + 2
3
>>> print('Hello')
Hello
>>> d = {1: 'uno', 2: 'dos', 3: 'tres}
 
SyntaxError: EOL while scanning string literal
>>> print('Hello')
Hello
>>> 1 + 2
3
```

--
assignee: terry.reedy
components: IDLE
messages: 321126
nosy: grantjenks, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE inserts extra blank line in prompt after SyntaxError
type: behavior
versions: Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Dealing with dicts in doctest

2018-07-05 Thread 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

[issue33944] Deprecate and remove pth files



Terry J. Reedy  added the comment:

This issue, as stated, looks like a severe regression to me.

In each of my python installs, Lib/site-packages has a file called 'python.pth' 
containing 'F:/Python'.  This is not a glob of inscrutable code.  It is not 
even Python code.  Just a path.  Is this issue about something else also called 
a 'pth file'?

F:/Python latter is a package development directory on my supplementary hard 
drive.  When I first install a new version of Python (early alpha), I copy this 
tiny file.  Voila!  The packages within /Python are 'installed' for the new 
version without making copies.  Editing a file edits it for all 'installs'.  
Deleting the directory for an old and no longer needed version does not delete 
any of my files.

Import in files within F:/Python/pack act as if pack were installed in the site 
package for the version of python running the file.  I can easily run anything 
in Command Prompt with 'py -x.y -m pack.file'.  I can easily rerun with a 
different version by hitting up arrow and changing x.y.  Command Prompt's 
current working directory does not matter.

I think this is one of Python's most under-appreciated features.  I am rather 
sure there is no way to so easily get the same effect.  Abuse of a great 
feature is not a good reason to delete it completely.

--
nosy: +terry.reedy

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34042] Reference loss for local classes



Pablo Galindo Salgado  added the comment:

@Antoine Wow, it seems that we both  
foundb0a7a037b8fde56b62f886d5188bced7776777b4 with one minute of difference :D

I added Yuri to the noise list as is the author of that PR.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34042] Reference loss for local classes

2018-07-05 Thread Antoine Pitrou



Antoine Pitrou  added the comment:

I've bisected myself and the culprit seems to be 
b0a7a037b8fde56b62f886d5188bced7776777b4 ("""bpo-31179: Make dict.copy() up to 
5.5 times faster.""").

--
nosy: +yselivanov

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34042] Reference loss for local classes



Pablo Galindo Salgado  added the comment:

I think I found it. After doing the bisect manually (as redirecting 
stdout/stderr) seems to affect somehow the test) I found commit 
b0a7a037b8fde56b62f886d5188bced7776777b4 as the culprit. Reverting this commit 
on the current master seem to solve the problem. This is the diff of the revert:

diff --git a/Objects/dictobject.c b/Objects/dictobject.c
index 40d7d8af6e..f7d792232e 100644
--- a/Objects/dictobject.c
+++ b/Objects/dictobject.c
@@ -613,52 +613,6 @@ new_dict_with_shared_keys(PyDictKeysObject *keys)
 return new_dict(keys, values);
 }

-
-static PyObject *
-clone_combined_dict(PyDictObject *orig)
-{
-assert(PyDict_CheckExact(orig));
-assert(orig->ma_values == NULL);
-assert(orig->ma_keys->dk_refcnt == 1);
-
-Py_ssize_t keys_size = _PyDict_KeysSize(orig->ma_keys);
-PyDictKeysObject *keys = PyObject_Malloc(keys_size);
-if (keys == NULL) {
-PyErr_NoMemory();
-return NULL;
-}
-
-memcpy(keys, orig->ma_keys, keys_size);
-
-/* After copying key/value pairs, we need to incref all
-   keys and values and they are about to be co-owned by a
-   new dict object. */
-PyDictKeyEntry *ep0 = DK_ENTRIES(keys);
-Py_ssize_t n = keys->dk_nentries;
-for (Py_ssize_t i = 0; i < n; i++) {
-PyDictKeyEntry *entry = [i];
-PyObject *value = entry->me_value;
-if (value != NULL) {
-Py_INCREF(value);
-Py_INCREF(entry->me_key);
-}
-}
-
-PyDictObject *new = (PyDictObject *)new_dict(keys, NULL);
-if (new == NULL) {
-/* In case of an error, `new_dict()` takes care of
-   cleaning up `keys`. */
-return NULL;
-}
-new->ma_used = orig->ma_used;
-assert(_PyDict_CheckConsistency(new));
-if (_PyObject_GC_IS_TRACKED(orig)) {
-/* Maintain tracking. */
-_PyObject_GC_TRACK(new);
-}
-return (PyObject *)new;
-}
-
 PyObject *
 PyDict_New(void)
 {
@@ -2527,13 +2481,7 @@ PyDict_Copy(PyObject *o)
 PyErr_BadInternalCall();
 return NULL;
 }
-
 mp = (PyDictObject *)o;
-if (mp->ma_used == 0) {
-/* The dict is empty; just return a new dict. */
-return PyDict_New();
-}
-
 if (_PyDict_HasSplitTable(mp)) {
 PyDictObject *split_copy;
 Py_ssize_t size = USABLE_FRACTION(DK_SIZE(mp->ma_keys));
@@ -2560,27 +2508,6 @@ PyDict_Copy(PyObject *o)
 _PyObject_GC_TRACK(split_copy);
 return (PyObject *)split_copy;
 }
-
-if (PyDict_CheckExact(mp) && mp->ma_values == NULL &&
-(mp->ma_used >= (mp->ma_keys->dk_nentries * 2) / 3))
-{
-/* Use fast-copy if:
-
-   (1) 'mp' is an instance of a subclassed dict; and
-
-   (2) 'mp' is not a split-dict; and
-
-   (3) if 'mp' is non-compact ('del' operation does not resize dicts),
-   do fast-copy only if it has at most 1/3 non-used keys.
-
-   The last condition (3) is important to guard against a pathological
-   case when a large dict is almost emptied with multiple del/pop
-   operations and copied after that.  In cases like this, we defer to
-   PyDict_Merge, which produces a compacted copy.
-*/
-return clone_combined_dict(mp);
-}
-
 copy = PyDict_New();
 if (copy == NULL)
 return NULL;

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Dealing with dicts in doctest

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

[issue32521] NIS module fails to build due to the removal of interfaces related to Sun RPC from glibc.

2018-07-05 Thread Matej Cepl

Matej Cepl added the comment:

> Matej is this about Python 2?

I am currently ONLY on building python 3.7.0, nothing else bothers me at the
moment.

Let me summarize my findings, or what I think is the situation (of course, I
could be completely wrong):

* See
https://build.opensuse.org/package/show/devel:languages:python:Factory/python3
... Tumbleweed and Leap 15 (which all have libnsl) fail to be build with
libnsl-devel installed. It seems to me that it somehow tries to build
nismodule.c, but fails in configure (see above), so it doesn't end up well.

I think the problem is that the Python build system expects libnsl to be the
one which is found in Solaris and so it looks for its API. Except, the Linux
one is different and doesn't provide the same API. And from there, it goes all
down to hell.

With Leap 42.3 (which has glibc-2.27-4.1, but no libnsl, so I guess NIS API is
still inside of glibc; is it possible?), nis builds correctly and so it is
included.

* Concerning Python 2. I don't see any problems with it.
https://build.opensuse.org/package/show/devel:languages:python:Factory/python
shows https://is.gd/sbwIf6 that glibc is the same glibc-2.27-4.1,
libnsl-devel-1.2.0-2.1, ./configure still fails, but
http://download.opensuse.org/repositories/devel:/languages:/python:/Factory/openSUSE_Tumbleweed/x86_64/python-base-2.7.15-112.1.x86_64.rpm
still contains /usr/lib64/python2.7/lib-dynload/nis.so module.

OK, so I have no clue and it is all complete mess.

___
Python tracker

___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: about main()

2018-07-05 Thread 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???

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()




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???

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?

2018-07-05 Thread 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()

2018-07-05 Thread 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

[issue34042] Reference loss for local classes



Pablo Galindo Salgado  added the comment:

I investigated that commit but I cannot find anything :(.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27400] Datetime NoneType after calling Py_Finalize and Py_Initialize



Change by Pablo Galindo Salgado :


--
Removed message: https://bugs.python.org/msg321110

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27400] Datetime NoneType after calling Py_Finalize and Py_Initialize



Change by Pablo Galindo Salgado :


--
Removed message: https://bugs.python.org/msg32

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33988] [EASY] [3.7] test_platform fails when run with -Werror



STINNER Victor  added the comment:


New changeset f5770f354cb982303237d581ad2b296486475965 by Victor Stinner 
(Xtreak) in branch '3.7':
bpo-33988: Fix test_warnings using -W error (GH-7985)
https://github.com/python/cpython/commit/f5770f354cb982303237d581ad2b296486475965


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: about main()




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

[issue33988] [EASY] [3.7] test_platform fails when run with -Werror



STINNER Victor  added the comment:

Thank you Karthikeyan Singaravelan for your fix!

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10381] Add timezone support to datetime C API



STINNER Victor  added the comment:

I tested manually "./python -m test test_datetime test_datetime" in 3.6, 3.7 
and master branches: I confirm that the test no longer crash. It has been fixed 
by the commit 58dc03c737a71de93edef7723c9f6186116288ef.

Moreover, I don't recall a recent crash on Windows Refleak or Gentoo Refleak 
buildbots.

Thanks again Paul Ganssle for this nice enhancement!

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34054] multiprocessing should use time.monotonic() for timeout



STINNER Victor  added the comment:

Monotonic clock: https://docs.python.org/dev/library/time.html#time.monotonic

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34054] multiprocessing should use time.monotonic() for timeout



Change by STINNER Victor :


--
keywords: +patch
pull_requests: +7703
stage:  -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34054] multiprocessing should use time.monotonic() for timeout



New submission from STINNER Victor :

In different functions, the multiprocessing module uses the system clock: 
time.time(). The system clock can be updated manually by the system 
administrator or automatically by NTP (for example).

Attached PR modifies multiprocessing to use time.monotonic() instead to not be 
affected by system clock changes.

time.monotonic() is always available since Python 3.5. See also the PEP 418.

--
components: Library (Lib)
messages: 321115
nosy: vstinner
priority: normal
severity: normal
status: open
title: multiprocessing should use time.monotonic() for timeout
versions: Python 3.6, Python 3.7, Python 3.8

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33701] test_datetime crashed (SIGSEGV) on Travis CI



STINNER Victor  added the comment:

I didn't see the bug since at least one month. I close the issue.

--
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33627] test-complex of test_numeric_tower.test_complex() crashes intermittently on Ubuntu buildbots



STINNER Victor  added the comment:

I didn't see the bug since at least one month. I close the issue.

--
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

2018-07-05 Thread 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

[issue27741] datetime.datetime.strptime functionality description incorrect



Change by Paul Ganssle :


--
nosy: +p-ganssle

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15390] PEP 3121, 384 refactoring applied to datetime module



Change by Paul Ganssle :


--
nosy: +p-ganssle

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22426] strptime accepts the wrong '2010-06-01 MSK' string but rejects the right '2010-06-01 MSD'



Change by Paul Ganssle :


--
nosy: +p-ganssle

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5516] equality not symmetric for subclasses of datetime.date and datetime.datetime



Change by Paul Ganssle :


--
nosy: +p-ganssle

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

2018-07-05 Thread 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

[issue22377] %Z in strptime doesn't match EST and others



Change by Paul Ganssle :


--
nosy: +p-ganssle

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28730] reduce not being called in dervied extension class from datetime.datetime