Re: mutiprocessing gui

[dieter]

Antoon Pardon  writes:
> When one wants to combine multithreading and gui programming
> all sorts of issues arise. So I wonder how one might combine
> multiprocessing with gui programming.
>
> gui libraries typically have some registration mechanisme,
> where you can register a call back for when data is available
> on a network connection. Could one write a wrapper so that
> the multiprocessing.Queue or multiprocessing.Pipe could be
> usable like that?

The Zope application server has a similar problem.
Though not a GUI application framework, it is using a similar
architecture: a main thread with an event loop and a set of "worker"s.
when a worker has finished its work, it usually must wake up
the event loop (in this case to distribute the result).
It does this by using short messages on a socket (the event loop
in this case is an IO based event loop; thus, has means to recognize
if IO is available).

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

Re: windows 8 versus urllib2 certificate verify

[dieter]

Robin Becker  writes:

> I have an application built on 32 bit windows 7 with python 2.7.10.
> The application runs fine on windows 7 and older windows machines, but
> it is failing to connect properly using urllib2 when run on windows 8.
>
> The error CERTIFICATE_VERIFY_FAILED indcates this is some issue with
> urllib2 not being able to verify the remote certificate.
>
> This is pyinstaller so the python and python library seem to be
> constant. I thought I understood that python uses its own cert path,
> but obviously I am wrong.
>
> Googling sort of implies I might need certifi to be installed, but is that 
> true?
>
> Why does this fail only on windows 8?

Certificate verification generally depends on local configuration:
specifically, the set of installed trusted root certificates.

I do not know about Windows, but often the root certificates installed
for other packages, e.g. the browser, are used. And different
versions of the same package may install different sets of trusted
certificates. It might also be that your new environment lacks
one of the packages from your old environment - and it has provided
the required root certificate.


Of course, the problem might also be caused by a general problem.
Try to access a "common" https site via urllib2, one you do not have
any problems to connect with a browser (or another "http" utility
like "wget" or "curl") from the same machines.
If this works, the problem is assiciated with the specific certificate.

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

Re: Simple board game GUI framework

[Wolfgang Maier]

On 11.09.2017 12:58, Paul Moore wrote:

I'm doing some training for a colleague on Python, and I want to look
at a bit of object orientation. For that, I'm thinking of a small
project to write a series of classes simulating objects moving round
on a chess-style board of squares.

I want to concentrate on writing the classes and their behaviour, and
not on display issues, but I would like it if the resulting program
was reasonably interesting. To that end, I was thinking of putting
together a frontend that displayed the objects moving round on a board
(rather than, for example, just printing out lists of co-ordinates).
I'd build the frontend, then my student could write the object classes
and drop them into the framework.



Maybe not exactly what you are asking for, but something I thought about 
for a Python class earlier this year: There are several Minecraft mods 
that let you interact with the game from Python. Of course, Minecraft 
itself is Java code, but it's a prime example of OOP and you are getting 
a very sophisticated and fully tested display engine for free. It's a 
bit complicated to get started with (which eventually made me postpone 
this experiment to next year's class), but I think it may be a lot of 
fun, especially if you've played Minecraft before. Here's a link to get 
you started: http://www.instructables.com/id/Python-coding-for-Minecraft/


Best,
Wolfgang

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

Fw: Problems Installing Python36

[rdb...@juno.com]

I have subscribed to the Python List as directed.Below is my information 
request re-submitted. Thank you. 
-- Forwarded Message --
From: "rdb...@juno.com" 
To: python-list@python.org
Subject: Problems Installing Python36
Date: Tue, 12 Sep 2017 01:35:11 GMT


I am having difficulty executing Python-3.6.2-amd64.exe.

I am able to install it successfully, but each time Python36 fails to execute. 
The error message returned is:

“The program can’t start because api-ms-win-crt-runtime-|1-1-0.dll 
is missing from your computer. Try reinstalling the program to fix this 
problem."
 
I have tried repeatedly to install various Python versions (32-bit or 64-bit), 
but the same error occurs. Is it possibly related to either Windows Paths or to 
conflicts with other Python compilers/interpreters embedded in programs such as 
OpenOffice 3 and GNU Gimp 2?

I am using an ASUS laptop with an Intel Pentium CPU B970 @ 2.30 Hz, dual 64-bit 
cores, running Windows 7 Home Premium, Service Pack 1.

Each time I ran the Installer as the System Administrator and I checked the 
boxes labeled:  “Install launcher for all users,” and “Add 
Python 3.6 to PATH,” which appear to have been incorporated properly.

With the material from Python.org about “get-pip.py” and the 
“Virtual Environment,” I succeeded in activating/deactivating 
“venv,” but not “get-pip.py” because Python36 will not 
execute.

Can you please tell me what I am doing wrong.  I would appreciate any help that 
you can give me in getting Python installed. 

Thank you for your assistance in this matter.


Respectively yours,

Randolph Bracey
Myrtle Beach, SC



Doctor Reveals 3 "Death Foods" You Need To Avoid This Summer
Nucific
http://thirdpartyoffers.juno.com/TGL3131/59b7912c5c17d112c4c04st03vuc
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: array.array()'s memory shared with multiprocessing.Process()

[gerlando . falauto]

Il giorno lunedì 11 settembre 2017 12:19:27 UTC+2, Thomas Jollans ha scritto:
> On 2017-09-10 23:05, iurly wrote:
> > As far as I'm concerned, I'm probably better off using double buffers to 
> > avoid this kind of issues.
> > Thanks a lot for your help!
> > 
> 
> 
> That should work. Some other things to consider, if both processes are
> on the same machine, are a series of memory-mapped files to pass the
> data without pickling, or, if your code is only going to run on Unix,
> something involving shared memory through multiprocessing.Array.

Oh, I see, multiprocessing.Array() sounds like a pretty good idea, thanks!
It's simple enough and actually already compatible with what I'm doing.
That would involve double buffers which I would have to use as the first 
optimization step anyway.

Notice however how I'd have to create those Arrays dynamically in the producer 
thread. Would I then be able to pass them to the consumer by putting a 
reference in a queue? I wouldn't want them to be pickled at all in that case, 
of course.

Also, why do you say it only works on Unix? I couldn't find any reference to 
such limitation in the documentation.

Thank you so much again!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: array.array()'s memory shared with multiprocessing.Process()

[Stephan Houben]

Op 2017-09-12, gerlando.fala...@gmail.com schreef :

> Notice however how I'd have to create those Arrays dynamically in the
> producer thread. Would I then be able to pass them to the consumer by
> putting a reference in a queue? 

Yes.

> I wouldn't want them to be pickled at all in that case, of course.

Essentially only an address pointing into a piece of shared memory is
pickled and transmitted then.

> Also, why do you say it only works on Unix? I couldn't find any
> reference to such limitation in the documentation.

There is no such limitation.
It's supposed to work on all platforms (including Windows).

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

Re: array.array()'s memory shared with multiprocessing.Process()

[Thomas Jollans]

On 12/09/17 10:21, gerlando.fala...@gmail.com wrote:
> Il giorno lunedì 11 settembre 2017 12:19:27 UTC+2, Thomas Jollans ha scritto:
>> On 2017-09-10 23:05, iurly wrote:
>>> As far as I'm concerned, I'm probably better off using double buffers to 
>>> avoid this kind of issues.
>>> Thanks a lot for your help!
>>>
>>
>> That should work. Some other things to consider, if both processes are
>> on the same machine, are a series of memory-mapped files to pass the
>> data without pickling, or, if your code is only going to run on Unix,
>> something involving shared memory through multiprocessing.Array.
> Oh, I see, multiprocessing.Array() sounds like a pretty good idea, thanks!
> It's simple enough and actually already compatible with what I'm doing.
> That would involve double buffers which I would have to use as the first 
> optimization step anyway.
>
> Notice however how I'd have to create those Arrays dynamically in the 
> producer thread. Would I then be able to pass them to the consumer by putting 
> a reference in a queue? I wouldn't want them to be pickled at all in that 
> case, of course.
>
> Also, why do you say it only works on Unix? I couldn't find any reference to 
> such limitation in the documentation.

I'm not sure actually. Maybe someone else here can help. I have a hunch
that on Windows the memory might not be shared in the same way that it
would on Linux/Unix, since Windows simply doesn't have the same process
forking capabilities as Unix. This stack overflow question appears to be
in agree with that hunch, but I can't judge whether something else isn't
going wrong there:
https://stackoverflow.com/questions/35239168/multiprocessing-shared-array-variable-windows-is-not-updated-in-the-process

If the consumer process is always working from the same shared buffer,
then you don't have to pass any data through the queue at all! (Or, if
you have a small number of shared buffers, just tell the consumer which
one to look at) You do have to somehow guarantee that the producer
thread doesn't overwrite the buffer while it is being processed, of
course. I'll let you be the judge of how well this kind of scheme would
work for your data processing and acquisition rates.

>
> Thank you so much again!


-- 
Thomas Jollans


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

Re: Fw: Problems Installing Python36

[Louis Krupp]

On Tue, 12 Sep 2017 07:46:47 GMT, "rdb...@juno.com" 
wrote:

>I have subscribed to the Python List as directed.Below is my information 
>request re-submitted. Thank you. 
>-- Forwarded Message --
>From: "rdb...@juno.com" 
>To: python-list@python.org
>Subject: Problems Installing Python36
>Date: Tue, 12 Sep 2017 01:35:11 GMT
>
>
>I am having difficulty executing Python-3.6.2-amd64.exe.
>
>I am able to install it successfully, but each time Python36 fails to execute. 
>The error message returned is:
>
>“The program can’t start because api-ms-win-crt-runtime-|1-1-0.dll 
>is missing from your computer. Try reinstalling the program to fix this 
>problem."
> 
>I have tried repeatedly to install various Python versions (32-bit or 64-bit), 
>but the same error occurs. Is it possibly related to either Windows Paths or 
>to conflicts with other Python compilers/interpreters embedded in programs 
>such as OpenOffice 3 and GNU Gimp 2?
>
>I am using an ASUS laptop with an Intel Pentium CPU B970 @ 2.30 Hz, dual 
>64-bit cores, running Windows 7 Home Premium, Service Pack 1.
>
>Each time I ran the Installer as the System Administrator and I checked the 
>boxes labeled:  “Install launcher for all users,” and “Add 
>Python 3.6 to PATH,” which appear to have been incorporated properly.
>
>With the material from Python.org about “get-pip.py” and the 
>“Virtual Environment,” I succeeded in activating/deactivating 
>“venv,” but not “get-pip.py” because Python36 will not 
>execute.
>
>Can you please tell me what I am doing wrong.  I would appreciate any help 
>that you can give me in getting Python installed. 
>
>Thank you for your assistance in this matter.
 
A Google search for "api-ms-win-crt-runtime-l1-1-0.dll missing" turned
up a bunch of resuts. One of those might help you.

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

Re: array.array()'s memory shared with multiprocessing.Process()

[Stephan Houben]

Op 2017-09-12, Thomas Jollans schreef :
> I'm not sure actually. Maybe someone else here can help. I have a hunch
> that on Windows the memory might not be shared in the same way that it
> would on Linux/Unix, since Windows simply doesn't have the same process
> forking capabilities as Unix. 

`multiprocessing` is not relying on the POSIX "inherit an anonymous
mmap()" semantics to get a piece of memory shared across processes.

1. On Windows, it uses the Windows-specific functionality to
   associate a tagname with an mmap and open the specific mmap by tagname.

2. On Posix platforms, it creates a file which is opened and immediately
   unlink()-ed, and the file descriptor is communicated to the child
   process using a UNIX-domain socket.

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

Re: Fw: Problems Installing Python36

[Thomas Jollans]

On 12/09/17 09:46, rdb...@juno.com wrote:
> I have subscribed to the Python List as directed.Below is my information 
> request re-submitted. Thank you. 
> -- Forwarded Message --
> From: "rdb...@juno.com" 
> To: python-list@python.org
> Subject: Problems Installing Python36
> Date: Tue, 12 Sep 2017 01:35:11 GMT
>
>
> I am having difficulty executing Python-3.6.2-amd64.exe.
>
> I am able to install it successfully, but each time Python36 fails to 
> execute. The error message returned is:
>
> “The program can’t start because 
> api-ms-win-crt-runtime-|1-1-0.dll is missing from your computer. Try 
> reinstalling the program to fix this problem."
>  

Are you up-to-date with Windows Updates? If not, installing all
available updates might help.

In any case, I think installing
https://support.microsoft.com/en-us/help/2999226/update-for-universal-c-runtime-in-windows
should do the trick. (But this should be really installed from Windows
Update!)

Other people on this list:
This isn't the first time I've someone with this issue here. It's
probably putting off plenty of potential new users who don't make as
much effort to find a solution. I can't say I understand the ins and
outs of installing things on Windows... is there anything that can be done?

Best,
Thomas

> I have tried repeatedly to install various Python versions (32-bit or 
> 64-bit), but the same error occurs. Is it possibly related to either Windows 
> Paths or to conflicts with other Python compilers/interpreters embedded in 
> programs such as OpenOffice 3 and GNU Gimp 2?
>
> I am using an ASUS laptop with an Intel Pentium CPU B970 @ 2.30 Hz, dual 
> 64-bit cores, running Windows 7 Home Premium, Service Pack 1.
>
> Each time I ran the Installer as the System Administrator and I checked the 
> boxes labeled:  “Install launcher for all users,” and “Add 
> Python 3.6 to PATH,” which appear to have been incorporated properly.
>
> With the material from Python.org about “get-pip.py” and the 
> “Virtual Environment,” I succeeded in activating/deactivating 
> “venv,” but not “get-pip.py” because Python36 will 
> not execute.
>
> Can you please tell me what I am doing wrong.  I would appreciate any help 
> that you can give me in getting Python installed. 
>
> Thank you for your assistance in this matter.
>
>
> Respectively yours,
>
> Randolph Bracey
> Myrtle Beach, SC
>
>
> 
> Doctor Reveals 3 "Death Foods" You Need To Avoid This Summer
> Nucific
> http://thirdpartyoffers.juno.com/TGL3131/59b7912c5c17d112c4c04st03vuc


-- 
Thomas Jollans


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

Re: The Incredible Growth of Python (stackoverflow.blog)

[Leam Hall]

On 09/12/2017 12:29 AM, Chris Angelico wrote:

On Tue, Sep 12, 2017 at 1:42 PM, Paul Rubin  wrote:

Chris Angelico  writes:

students learning Python *today* ... they're learning Python 3.


I'm not so sure of that.  I do know a few people currently learning
Python, and they're using Python 2.


Why? Unless they're going to be maintaining a Py2 codebase, why should
they learn the older version with less features?

At Thinkful (shameless plug[1]), students learn Python 3 almost
exclusively (we do have a data science course in which students learn
either or both, but in the web dev course, it's definitely Py3). I
haven't had anyone run into difficulties with annotations/type hints
(we don't teach them, so how would they be bothered?), print being a
function (everything else is a function so it's no surprise that print
is too), etc, and even the text/bytes split is only a problem when
students are working with non-ASCII data files provided by third
parties, at which point they have to learn about encoding="...". Now,
I just need to convince people to stop putting "first name" and
"surname" fields on their web forms [2], and things will be about
perfect...

ChrisA

[1] I teach via www.thinkful.com. My views are my own, not that of my employer.
[2] 
http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/



Hey Chris,

This is an area the Python community can improve on. Even I would 
encourage someone new to Python and wanting to do webdev to use Python 3.


But if someone comes onto the list, or IRC, and says they need to stay 
on Python 2 then please drop the dozens of e-mails and comments about 
upgrading. Help the person learn; that makes them happier with Python 
and when the time comes to switch to Python 3 they probably will.


My recent experience with some people's inability to take "Sorry, I 
can't" for an answer has been a real turn-off. I have requirements that 
dictate Python. If this was a personal venture I'd already be elsewhere 
purely because the Python community on the list and IRC is so unwelcoming.


I encourage those of you who are Python experts, trainers, or authors: 
lead by example. Help people learn Python. Grow the community. Just 
because TIOBE and IEEE say Python is top dog today doesn't mean those 
stats can't change. The community will drive the success of Python, not 
the technical features.


Leam

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

Re: The Incredible Growth of Python (stackoverflow.blog)

[Chris Angelico]

On Tue, Sep 12, 2017 at 9:20 PM, Leam Hall  wrote:
> Hey Chris,
>
> This is an area the Python community can improve on. Even I would encourage
> someone new to Python and wanting to do webdev to use Python 3.
>
> But if someone comes onto the list, or IRC, and says they need to stay on
> Python 2 then please drop the dozens of e-mails and comments about
> upgrading. Help the person learn; that makes them happier with Python and
> when the time comes to switch to Python 3 they probably will.

If you read back in my emails, you may find that I actually wasn't
telling you to upgrade to Python 3 - just to Python 2.7, which is an
easy upgrade from 2.6, and gives you the security fixes and other
improvements that come from using a supported version of the language.
Is it "hostile" to tell people to upgrade like that? If someone is
using Python 3.2 today, I'm going to strongly recommend upgrading to
the latest 3.x. If someone's using Windows 98, I'm not going to say
"well, here's how to get everything working under Win98", I'm going to
say "upgrade to a better OS".

If that's hostile, I am not sorry to be hostile. At some point, you
have to either get onto something supported, or do all the support
work yourself.

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

Re: The Incredible Growth of Python (stackoverflow.blog)

[Leam Hall]

On 09/12/2017 07:27 AM, Chris Angelico wrote:

On Tue, Sep 12, 2017 at 9:20 PM, Leam Hall  wrote:

Hey Chris,

This is an area the Python community can improve on. Even I would encourage
someone new to Python and wanting to do webdev to use Python 3.

But if someone comes onto the list, or IRC, and says they need to stay on
Python 2 then please drop the dozens of e-mails and comments about
upgrading. Help the person learn; that makes them happier with Python and
when the time comes to switch to Python 3 they probably will.


If you read back in my emails, you may find that I actually wasn't
telling you to upgrade to Python 3 - just to Python 2.7, which is an
easy upgrade from 2.6, and gives you the security fixes and other
improvements that come from using a supported version of the language.
Is it "hostile" to tell people to upgrade like that? If someone is
using Python 3.2 today, I'm going to strongly recommend upgrading to
the latest 3.x. If someone's using Windows 98, I'm not going to say
"well, here's how to get everything working under Win98", I'm going to
say "upgrade to a better OS".

If that's hostile, I am not sorry to be hostile. At some point, you
have to either get onto something supported, or do all the support
work yourself.

ChrisA



Hey Chris; only some folks were overtly hostile.  :)

Yet look at your answer; "upgrade". For a person working on a server 
there's usually no economic choice to do. The OS python must stay in 
place and the newly installed upgrade must be personally maintained, 
updated, and tested when security patches come out. For one desktop 
that's not an issue. For dozens, or hundreds, or thousands, its not 
likely to happen.


I stand by my position; accept the "no" and move forward. Let "no" mean 
"no".


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

Re: The Incredible Growth of Python (stackoverflow.blog)

[Chris Angelico]

On Tue, Sep 12, 2017 at 9:34 PM, Leam Hall  wrote:
> On 09/12/2017 07:27 AM, Chris Angelico wrote:
>>
>> On Tue, Sep 12, 2017 at 9:20 PM, Leam Hall  wrote:
>>>
>>> Hey Chris,
>>>
>>> This is an area the Python community can improve on. Even I would
>>> encourage
>>> someone new to Python and wanting to do webdev to use Python 3.
>>>
>>> But if someone comes onto the list, or IRC, and says they need to stay on
>>> Python 2 then please drop the dozens of e-mails and comments about
>>> upgrading. Help the person learn; that makes them happier with Python and
>>> when the time comes to switch to Python 3 they probably will.
>>
>>
>> If you read back in my emails, you may find that I actually wasn't
>> telling you to upgrade to Python 3 - just to Python 2.7, which is an
>> easy upgrade from 2.6, and gives you the security fixes and other
>> improvements that come from using a supported version of the language.
>> Is it "hostile" to tell people to upgrade like that? If someone is
>> using Python 3.2 today, I'm going to strongly recommend upgrading to
>> the latest 3.x. If someone's using Windows 98, I'm not going to say
>> "well, here's how to get everything working under Win98", I'm going to
>> say "upgrade to a better OS".
>>
>> If that's hostile, I am not sorry to be hostile. At some point, you
>> have to either get onto something supported, or do all the support
>> work yourself.
>>
>> ChrisA
>>
>
> Hey Chris; only some folks were overtly hostile.  :)
>
> Yet look at your answer; "upgrade". For a person working on a server there's
> usually no economic choice to do. The OS python must stay in place and the
> newly installed upgrade must be personally maintained, updated, and tested
> when security patches come out. For one desktop that's not an issue. For
> dozens, or hundreds, or thousands, its not likely to happen.

Until you get hit by a vulnerability that was patched four years ago,
but you didn't get the update. Now your server is down - or, worse,
has been compromised. What's the economic cost of that?

You might choose to accept that risk, but you have to at least be
aware that you're playing with fire. Laziness is not the cheap option
in the long run.

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

Re: The Incredible Growth of Python (stackoverflow.blog)

[Steve D'Aprano]

On Tue, 12 Sep 2017 09:40 pm, Chris Angelico wrote:

[...]
>> Yet look at your answer; "upgrade". For a person working on a server there's
>> usually no economic choice to do. The OS python must stay in place and the
>> newly installed upgrade must be personally maintained, updated, and tested
>> when security patches come out. For one desktop that's not an issue. For
>> dozens, or hundreds, or thousands, its not likely to happen.
> 
> Until you get hit by a vulnerability that was patched four years ago,
> but you didn't get the update. Now your server is down - or, worse,
> has been compromised. What's the economic cost of that?

Chris, that's what your subscription to RHEL pays for: backports of security
fixes that the free Python 2.6 doesn't contain.

You'll probably get them on Centos and Fedora too, the community editions of
RHEL. You *won't* get them from the Python website. That's the whole point of
the ten year support for RHEL (longer if you pay more).


> You might choose to accept that risk, but you have to at least be
> aware that you're playing with fire. Laziness is not the cheap option
> in the long run.

You're making unjustified assumptions about the attack surface here. Maybe any
attacker has to break through three firewalls *and* get root on the server
before they can attack the Python app -- in which case they've got bigger
problems than the Python vulnerability.

It's one thing to mention in a friendly way the advantages of upgrading.

It's another to continue to brow-beat the poster about the (supposed) necessity
to give up their paid RHEL support and security patches in favour of taking
their chances with the free, but more recent, version where they have to
monitor the Python website or mailing lists themselves and manually upgrade
each time there's an security patch.

Feel free to continue to talk in general terms about the costs and benefits of
upgrading, but stop badgering Leam. Not everyone values being on the bleeding
edge, and Red Hat customers as a rule value stability and long term support
over the latest shiny new features.



-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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

Re: Fw: Problems Installing Python36

[Stephan Houben]

Op 2017-09-12, Thomas Jollans schreef :
> This isn't the first time I've someone with this issue here. It's
> probably putting off plenty of potential new users who don't make as
> much effort to find a solution. I can't say I understand the ins and
> outs of installing things on Windows... is there anything that can be done?

I just added issue 31427 on the Python bug tracker proposing
adding this to the Windows FAQ.

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

Re: The Incredible Growth of Python (stackoverflow.blog)

[Leam Hall]

Steve,

Thank you very much. I appreciate your wisdom and support.

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

Re: The Incredible Growth of Python (stackoverflow.blog)

[Ned Batchelder]

On 9/12/17 7:40 AM, Chris Angelico wrote:
> On Tue, Sep 12, 2017 at 9:34 PM, Leam Hall  wrote:
>> On 09/12/2017 07:27 AM, Chris Angelico wrote:
>>> On Tue, Sep 12, 2017 at 9:20 PM, Leam Hall  wrote:
 Hey Chris,

 This is an area the Python community can improve on. Even I would
 encourage
 someone new to Python and wanting to do webdev to use Python 3.

 But if someone comes onto the list, or IRC, and says they need to stay on
 Python 2 then please drop the dozens of e-mails and comments about
 upgrading. Help the person learn; that makes them happier with Python and
 when the time comes to switch to Python 3 they probably will.
>>>
>>> If you read back in my emails, you may find that I actually wasn't
>>> telling you to upgrade to Python 3 - just to Python 2.7, which is an
>>> easy upgrade from 2.6, and gives you the security fixes and other
>>> improvements that come from using a supported version of the language.
>>> Is it "hostile" to tell people to upgrade like that? If someone is
>>> using Python 3.2 today, I'm going to strongly recommend upgrading to
>>> the latest 3.x. If someone's using Windows 98, I'm not going to say
>>> "well, here's how to get everything working under Win98", I'm going to
>>> say "upgrade to a better OS".
>>>
>>> If that's hostile, I am not sorry to be hostile. At some point, you
>>> have to either get onto something supported, or do all the support
>>> work yourself.
>>>
>>> ChrisA
>>>
>> Hey Chris; only some folks were overtly hostile.  :)
>>
>> Yet look at your answer; "upgrade". For a person working on a server there's
>> usually no economic choice to do. The OS python must stay in place and the
>> newly installed upgrade must be personally maintained, updated, and tested
>> when security patches come out. For one desktop that's not an issue. For
>> dozens, or hundreds, or thousands, its not likely to happen.
> Until you get hit by a vulnerability that was patched four years ago,
> but you didn't get the update. Now your server is down - or, worse,
> has been compromised. What's the economic cost of that?
>
> You might choose to accept that risk, but you have to at least be
> aware that you're playing with fire. Laziness is not the cheap option
> in the long run.
>
> ChrisA

Leam has done us the favor of explaining how this list feels to people
coming into it. We should take his point of view seriously.  You are
still arguing about whether software should be upgraded.  Maybe it
should be, but it wasn't was the OP was asking about. 

The OP probably also isn't saving enough for retirement, and it's good
advice to save more, but it's not what they were asking about.  How far
afield from the actual question is it OK to offer unsolicited advice
before it comes off as hostile? Apparently we crossed the line on this
question.

--Ned.

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

Re: The Incredible Growth of Python (stackoverflow.blog)

[Chris Angelico]

On Tue, Sep 12, 2017 at 10:21 PM, Ned Batchelder  wrote:
> On 9/12/17 7:40 AM, Chris Angelico wrote:
>> On Tue, Sep 12, 2017 at 9:34 PM, Leam Hall  wrote:
>>> On 09/12/2017 07:27 AM, Chris Angelico wrote:
 On Tue, Sep 12, 2017 at 9:20 PM, Leam Hall  wrote:
> Hey Chris,
>
> This is an area the Python community can improve on. Even I would
> encourage
> someone new to Python and wanting to do webdev to use Python 3.
>
> But if someone comes onto the list, or IRC, and says they need to stay on
> Python 2 then please drop the dozens of e-mails and comments about
> upgrading. Help the person learn; that makes them happier with Python and
> when the time comes to switch to Python 3 they probably will.

 If you read back in my emails, you may find that I actually wasn't
 telling you to upgrade to Python 3 - just to Python 2.7, which is an
 easy upgrade from 2.6, and gives you the security fixes and other
 improvements that come from using a supported version of the language.
 Is it "hostile" to tell people to upgrade like that? If someone is
 using Python 3.2 today, I'm going to strongly recommend upgrading to
 the latest 3.x. If someone's using Windows 98, I'm not going to say
 "well, here's how to get everything working under Win98", I'm going to
 say "upgrade to a better OS".

 If that's hostile, I am not sorry to be hostile. At some point, you
 have to either get onto something supported, or do all the support
 work yourself.

 ChrisA

>>> Hey Chris; only some folks were overtly hostile.  :)
>>>
>>> Yet look at your answer; "upgrade". For a person working on a server there's
>>> usually no economic choice to do. The OS python must stay in place and the
>>> newly installed upgrade must be personally maintained, updated, and tested
>>> when security patches come out. For one desktop that's not an issue. For
>>> dozens, or hundreds, or thousands, its not likely to happen.
>> Until you get hit by a vulnerability that was patched four years ago,
>> but you didn't get the update. Now your server is down - or, worse,
>> has been compromised. What's the economic cost of that?
>>
>> You might choose to accept that risk, but you have to at least be
>> aware that you're playing with fire. Laziness is not the cheap option
>> in the long run.
>>
>> ChrisA
>
> Leam has done us the favor of explaining how this list feels to people
> coming into it. We should take his point of view seriously.  You are
> still arguing about whether software should be upgraded.  Maybe it
> should be, but it wasn't was the OP was asking about.
>
> The OP probably also isn't saving enough for retirement, and it's good
> advice to save more, but it's not what they were asking about.  How far
> afield from the actual question is it OK to offer unsolicited advice
> before it comes off as hostile? Apparently we crossed the line on this
> question.
>

Okay, I get the picture. Fine. You can stay on a version as old as you
like - but I'm not going to help you with 2.6-specific issues. Fair?

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

Re: The Incredible Growth of Python (stackoverflow.blog)

[Tim Golden]

On 12/09/2017 12:20, Leam Hall wrote:
This is an area the Python community can improve on. Even I would 
encourage someone new to Python and wanting to do webdev to use Python 3.


But if someone comes onto the list, or IRC, and says they need to stay 
on Python 2 then please drop the dozens of e-mails and comments about 
upgrading. Help the person learn; that makes them happier with Python 
and when the time comes to switch to Python 3 they probably will.


My recent experience with some people's inability to take "Sorry, I 
can't" for an answer has been a real turn-off. I have requirements that 
dictate Python. If this was a personal venture I'd already be elsewhere 
purely because the Python community on the list and IRC is so unwelcoming.


I agree. Except for the unusual case where someone's mistakenly chosen 
to use, eg, Python 2.4 because they're using an old text book which 
mentions it as the current version, most people are using the version 
which suits them for one reason or another.


And, if I may put my 2.5p-worth in here, they're probably using the 
operating system which suits them. (Maybe because their employer has 
said so, or because they're familiar or whatever). So saying, as people 
occasionally do, "Upgrade to Linux", even with half-a-wink, is not 
really that funny or helpful.


That said, my experience of this list and other Python forums is that we 
don't do *too* badly at being friendly. However, what we do suffer from 
is an excess of technical helpfulness. In principle it's a good thing, 
but it can give rise to solving a problem with the OP doesn't have. One 
example of which is: over-egging the advantages of Python 3. ("How do I 
do X in Python 2.7?" "Why aren't you using Python 3"). Another might be: 
suggesting a toolkit they're not using. ("How do I use Tkinter to do 
blah?" "Use Pygame; it's much better").


Of course, such advice can certainly be helpful, eg pointing out the 
advantages of requests over urllib2 etc. But trying to answer their 
question as well as pointing out possible alternatives is probably more 
friendly.


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

Re: The Incredible Growth of Python (stackoverflow.blog)

[Steve D'Aprano]

On Tue, 12 Sep 2017 09:20 pm, Leam Hall wrote:

> But if someone comes onto the list, or IRC, and says they need to stay
> on Python 2 then please drop the dozens of e-mails and comments about
> upgrading.
[...]
> My recent experience with some people's inability to take "Sorry, I
> can't" for an answer has been a real turn-off. I have requirements that
> dictate Python. If this was a personal venture I'd already be elsewhere
> purely because the Python community on the list and IRC is so unwelcoming.

Leam, I've defended people choosing to remain on older versions of Python, even
as old as 1.5. The most recent was just a couple of minutes ago, in my response
to Chris. It's not nice or friendly of you to tar the entire community with a
reputation because of one or two people saying something you don't want to
debate.

But it isn't all about you. Just because you started this thread -- oh wait, you
didn't *wink* -- doesn't mean you control its direction. If people want to
discuss the pros and cons of upgrading, without specifically badgering you, you
should remember that *it isn't about you* and don't take it personally.



-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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

Re: The Incredible Growth of Python (stackoverflow.blog)

[Tim Golden]

On 12/09/2017 12:20, Leam Hall wrote:
But if someone comes onto the list, or IRC, and says they need to stay 
on Python 2 then please drop the dozens of e-mails and comments about 
upgrading. 


(Just spotted this quoted by Steven D'Aprano).

Another factor of course is that people are reading and interacting with 
the list/newsgroup in many different ways, and so what appears as a 
pile-on almost certainly isn't (as such). It's the common reaction of a 
number of probably unconnected people with a similar mindset.


Obviously Leam's point is still valid: it looks like a wall of unwanted 
advice. But I wanted to defend "The List" (or "The Newsgroup") which of 
course is just a load of different people.


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

Re: The Incredible Growth of Python (stackoverflow.blog)

[Leam Hall]

On 09/12/2017 08:28 AM, Steve D'Aprano wrote:

On Tue, 12 Sep 2017 09:20 pm, Leam Hall wrote:


But if someone comes onto the list, or IRC, and says they need to stay
on Python 2 then please drop the dozens of e-mails and comments about
upgrading.

[...]

My recent experience with some people's inability to take "Sorry, I
can't" for an answer has been a real turn-off. I have requirements that
dictate Python. If this was a personal venture I'd already be elsewhere
purely because the Python community on the list and IRC is so unwelcoming.


Leam, I've defended people choosing to remain on older versions of Python, even
as old as 1.5. The most recent was just a couple of minutes ago, in my response
to Chris. It's not nice or friendly of you to tar the entire community with a
reputation because of one or two people saying something you don't want to
debate.

But it isn't all about you. Just because you started this thread -- oh wait, you
didn't *wink* -- doesn't mean you control its direction. If people want to
discuss the pros and cons of upgrading, without specifically badgering you, you
should remember that *it isn't about you* and don't take it personally.


WHAT?!?!?!  It isn't all about me?  Dang...

Steve, you're right; sorry for painting with such a broad brush. Even 
the people who occasionally post something that seems problematic (to 
me) are usually helpful.


A few months ago my manager asked about what direction I recommended for 
the team. I'm the opinionated old guy who is new to this team. At the 
time I was really enjoying Ruby; just so dang fun!


I told my manager that we should use python. It is the best choice for 
the team since we're on RHEL 6. Ruby wasn't on the machines but Python 
2.6.6 is. Any code I write that is python 2.6.6 compatible should run on 
every machine.


My answer meant I had to re-direct personal time and attention so I 
could help the team move forward. There are certain things I can do; 
learn to code better, write more tests, and figure out OOP. Some things 
I can't do; changing the supported python version is on that list.


Python is the right choice for a lot of use cases. Python 3 is the right 
choice for a large sub-set of those use cases. Python 2 is the best 
choice for a much smaller subset.



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

Re: The Incredible Growth of Python (stackoverflow.blog)

[Stephan Houben]

Op 2017-09-12, Tim Golden schreef :

> I agree. Except for the unusual case where someone's mistakenly chosen 
> to use, eg, Python 2.4 because they're using an old text book which 
> mentions it as the current version, most people are using the version 
> which suits them for one reason or another.

If it is not clear from the original post that they are consciously
using an old version, I will often try to politely suggest they use the
latest version (i.e. "If there is no particular reason for you to use
Python 1.5.2, may I suggest that you use 3.6 instead?").

The reason is that:

* On many operating systems, just typing "python" will give you
  Python2.7 at best (e.g. macOS!). And the OP may not be aware that
  there are more recent versions.

* In businesses, it is especially common to run on some RHEL version
  $ANCIENT; not so long ago I had a machine where typing "python"
  presented me with Python 2.3!

I agree that *badgering* them about it (as opposed to suggesting it
*once*) is a bad idea.

> And, if I may put my 2.5p-worth in here, they're probably using the 
> operating system which suits them. (Maybe because their employer has 
> said so, or because they're familiar or whatever). So saying, as people 
> occasionally do, "Upgrade to Linux", even with half-a-wink, is not 
> really that funny or helpful.

It's not really the same, though.

Changing the OS is a big undertaking and affects all their programs,
just installing version 3.6 of Python as a private user shouldn't affect
anything else. You can install python in your home directory on your
ancient RHEL box and leave the system Python happily at 2.3.

I nowadays typically never bother with the system Python for my own
development and just install a recent version of my choice locally.  It
saves a lot of headaches. The system Python is there to run system
programs.

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

Re: windows 8 versus urllib2 certificate verify

[Robin Becker]

On 12/09/2017 08:35, dieter wrote:

Robin Becker  writes:
Certificate verification generally depends on local configuration:
specifically, the set of installed trusted root certificates.

I do not know about Windows, but often the root certificates installed
for other packages, e.g. the browser, are used. And different
versions of the same package may install different sets of trusted
certificates. It might also be that your new environment lacks
one of the packages from your old environment - and it has provided
the required root certificate.


Of course, the problem might also be caused by a general problem.
Try to access a "common" https site via urllib2, one you do not have
any problems to connect with a browser (or another "http" utility
like "wget" or "curl") from the same machines.
If this works, the problem is assiciated with the specific certificate.


The certs are fine at least in all the browsers I have access to.

It's pretty hard to use the python that's built in to a pyinstaller exe so I 
have used the certifi method and passed certifi.where() into the urlopen calls.


That seems to work, but obviously if the compiled in root certs become too old 
problems will recur.

--
Robin Becker

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

Re: The Incredible Growth of Python (stackoverflow.blog)

[Paul Moore]

On 12 September 2017 at 13:47, Leam Hall  wrote:
> A few months ago my manager asked about what direction I recommended for the
> team. I'm the opinionated old guy who is new to this team. At the time I was
> really enjoying Ruby; just so dang fun!
>
> I told my manager that we should use python. It is the best choice for the
> team since we're on RHEL 6. Ruby wasn't on the machines but Python 2.6.6 is.
> Any code I write that is python 2.6.6 compatible should run on every
> machine.
>
> My answer meant I had to re-direct personal time and attention so I could
> help the team move forward. There are certain things I can do; learn to code
> better, write more tests, and figure out OOP. Some things I can't do;
> changing the supported python version is on that list.
>
> Python is the right choice for a lot of use cases. Python 3 is the right
> choice for a large sub-set of those use cases. Python 2 is the best choice
> for a much smaller subset.

Sounds like a very reasonable decision - I'm in a similar situation at
times, and I agree with your recommendation. Python's a great tool,
and if you like Ruby you should find it really easy to get into. As
you say, if Ruby isn't available on the machines you're working with,
the hurdle of getting it installed is likely a real blocker. Having
Python installed makes it a good choice - and sticking with the
installed version is definitely correct, otherwise you're no better
off than you were with a language that's not installed by default.

One thing you will have to deal with is that there's a lot less
support available for Python 2.6 these days - most developers working
with Python 2 will use 2.7, and new developers will typically pick
Python 3 if at all possible. For a lot of things, you're relying on
community support, which does mean you are "stuck" with what people
are enthusiastic about. But the good news is that most advice you'll
get is transferrable back to Python 2.6 (with a little care,
particularly if it was originally for Python 3). And it's important to
remember that community support is just that - individuals, offering
help simply because they love Python. And those individuals are
typically (in most communities, not just Python) early adopters, and
strongly prefer working with the latest versions.

The biggest hurdle you may hit is that 3rd party libraries are
starting to drop support of Python 2.6. I don't know if you expect to
use libraries from PyPI - in my environment, the systems that are
locked to Python 2.6 are typically not connected to the internet, so
non-stdlib code is generally not accessible - if that's the case for
you this won't be an issue. Unfortunately, there's not much you can do
about that - it's just one of the issues of working with older,
unsupported versions.

But a big plus with Python is that the stdlib is very comprehensive
(less so with 2.6 than 3.6, but still very good in 2.6). So where
you'd need to rely on external libraries for other languages, you can
do an awful lot with a base 2.6 install. That's a big selling point in
a locked down environment.

Anyway, I'm not sure there's much specific here. But thanks for taking
the time to explain your situation, which hopefully will act as a
reminder that not everyone trying to promote Python has a clean slate
to work with.

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

Re: The Incredible Growth of Python (stackoverflow.blog)

[Rick Johnson]

Steve D'Aprano wrote:
> Chris Angelico wrote:
> 
> [...]
> > > 
> > > Yet look at your answer; "upgrade". For a person working
> > > on a server there's usually no economic choice to do. The
> > > OS python must stay in place and the newly installed
> > > upgrade must be personally maintained, updated, and
> > > tested when security patches come out. For one desktop
> > > that's not an issue. For dozens, or hundreds, or
> > > thousands, its not likely to happen.
> > 
> > Until you get hit by a vulnerability that was patched four
> > years ago, but you didn't get the update. Now your server
> > is down - or, worse, has been compromised. What's the
> > economic cost of that?
> 
> Chris, that's what your subscription to RHEL pays for:
> backports of security fixes that the free Python 2.6
> doesn't contain.  You'll probably get them on Centos and
> Fedora too, the community editions of RHEL. You *won't* get
> them from the Python website. That's the whole point of the
> ten year support for RHEL (longer if you pay more).
> 
> >
> > You might choose to accept that risk, but you have to at
> > least be aware that you're playing with fire. Laziness is
> > not the cheap option in the long run.
> 
> You're making unjustified assumptions about the attack
> surface here. Maybe any attacker has to break through three
> firewalls *and* get root on the server before they can
> attack the Python app -- in which case they've got bigger
> problems than the Python vulnerability.  It's one thing to
> mention in a friendly way the advantages of upgrading.
> It's another to continue to brow-beat the poster about the
> (supposed) necessity to give up their paid RHEL support and
> security patches in favour of taking their chances with the
> free, but more recent, version where they have to monitor
> the Python website or mailing lists themselves and manually
> upgrade each time there's an security patch.  Feel free to
> continue to talk in general terms about the costs and
> benefits of upgrading, but stop badgering Leam. Not
> everyone values being on the bleeding edge, and Red Hat
> customers as a rule value stability and long term support
> over the latest shiny new features.

Great reply! And nice to know that not every Pythonista here
has gone tin-foil-hat crazy over Python3. 

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

Re: The Incredible Growth of Python (stackoverflow.blog)

[Rick Johnson]

On Tuesday, September 12, 2017 at 7:26:40 AM UTC-5, Chris Angelico wrote:
[...]
> Okay, I get the picture. Fine. You can stay on a version as
> old as you like - but I'm not going to help you with
> 2.6-specific issues. Fair?

Chris, now you're just being a jerk. And while the decision
whether or not to help Leam is totally yours, there is no
need to broadcast your selfishness to the ends of the known
universe. If you want to take your ball and go home, you
certainly have that right, "Eric Theodore Cartman", but
there is no need for you to throw verbal spears on the way
out the door. 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The Incredible Growth of Python (stackoverflow.blog)

[leam hall]

On Tue, Sep 12, 2017 at 8:28 AM, Steve D'Aprano 
wrote:

> On Tue, 12 Sep 2017 09:20 pm, Leam Hall wrote:
>
> > But if someone comes onto the list, or IRC, and says they need to stay
> > on Python 2 then please drop the dozens of e-mails and comments about
> > upgrading.
> [...]
> > My recent experience with some people's inability to take "Sorry, I
> > can't" for an answer has been a real turn-off. I have requirements that
> > dictate Python. If this was a personal venture I'd already be elsewhere
> > purely because the Python community on the list and IRC is so
> unwelcoming.
>
> Leam, I've defended people choosing to remain on older versions of Python,
> even
> as old as 1.5. The most recent was just a couple of minutes ago, in my
> response
> to Chris. It's not nice or friendly of you to tar the entire community
> with a
> reputation because of one or two people saying something you don't want to
> debate.
>
> But it isn't all about you. Just because you started this thread -- oh
> wait, you
> didn't *wink* -- doesn't mean you control its direction. If people want to
> discuss the pros and cons of upgrading, without specifically badgering
> you, you
> should remember that *it isn't about you* and don't take it personally.
>

Steve, just a quick follow-up. Thank you for calling me out on this! It's
wrong for me to do something I complain about others doing. Feel free to
reach through the ether and smack me if I do this again.

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

Re: The Incredible Growth of Python (stackoverflow.blog)

[Rick Johnson]

Steve D'Aprano wrote:
> Leam Hall wrote:
> 
> > But if someone comes onto the list, or IRC, and says they
> > need to stay on Python 2 then please drop the dozens of
> > e-mails and comments about upgrading.
> [...]
> > My recent experience with some people's inability to take
> > "Sorry, I can't" for an answer has been a real turn-off. I
> > have requirements that dictate Python. If this was a
> > personal venture I'd already be elsewhere purely because
> > the Python community on the list and IRC is so
> > unwelcoming.
> 
> Leam, I've defended people choosing to remain on older
> versions of Python, even as old as 1.5. The most recent was
> just a couple of minutes ago, in my response to Chris. It's
> not nice or friendly of you to tar the entire community
> with a reputation because of one or two people saying
> something you don't want to debate.  

It is easy to forget that the attack dogs on this list (and
over at Python-ideas) do not represent the opinion of the
entire Python community. The majority of Python programmers
never even participate on these forums, and the majority of
those who _do_ participate, tend to follow along with the
one-sided politics out of fear of loosing access to help. 

So i am not surprised that Leam has formed this opinion of
the entire community based on the behavior of a small, but
highly vocal and aggressive, minority. Chris is usually very
knowledgable and helpful when he sticks to technical issues,
but Python3 has flipped an emotional switch in his brain,
and now he's on some sort of religious crusade, considering
anyone who refuse to adopt Python3, as his mortal enemy.

> But it isn't all about you. Just because you started this
> thread -- oh wait, you didn't *wink* -- doesn't mean you
> control its direction. If people want to discuss the pros
> and cons of upgrading, without specifically badgering you,
> you should remember that *it isn't about you* and don't
> take it personally.

True, but it would be more considerate to start a new thread
titled: "Pros and Cons of Upgrading to Python3", at least
that way, Leam wouldn't get the feeling that everyone has
turned their backs and are talking about him while still in
the same "room". Plus, there is the whole "stay on topic"
thing to consider...
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [Tutor] beginning to code

[Rick Johnson]

Chris Angelico wrote:
> Rick Johnson wrote:
> > Ruby:
> > farray = [1.5, 1.9, 2.0, 1.0]
> > uniqueIntegers = farray.map{|f| f.to_i()}.uniq.length
> >
> > Python:
> > flist = [1.5, 1.9, 2.0, 1.0]
> > uniqueIntegers = len(set(map(lambda f:int(f), flist)))
>
> Python:
>
> floats = [1.5, 1.9, 2.0, 1.0]
> unique_integers = len(set(int(f) for f in floats))
>
> or:
>
> unique_integers = len(set(map(int, floats))
>
> If you're going to use Python, at least use it right.

Okay, you've replaced my map function with an implicit list
comprehension (aka: generator expression)... so how is
either more "right" than the other? What is your
justification that your example is "right", and mine is not?

(1) Is is a speed issue? Then prove it.

(2) Is it a readability issue? If so, then that's an opinion
_you_ get to have.

(3) Is a matter of "python purity"?  If so, then map should be
removed from the language. And don't forget to remove reduce
and filter while you're at it. And then, you may want to
grab a shield, because the functional fanboys will be all
over you like white on rice!

(4) Something else...?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [Tutor] beginning to code

[Chris Angelico]

On Wed, Sep 13, 2017 at 1:03 AM, Rick Johnson
 wrote:
> Chris Angelico wrote:
>> Rick Johnson wrote:
>> > Ruby:
>> > farray = [1.5, 1.9, 2.0, 1.0]
>> > uniqueIntegers = farray.map{|f| f.to_i()}.uniq.length
>> >
>> > Python:
>> > flist = [1.5, 1.9, 2.0, 1.0]
>> > uniqueIntegers = len(set(map(lambda f:int(f), flist)))
>>
>> Python:
>>
>> floats = [1.5, 1.9, 2.0, 1.0]
>> unique_integers = len(set(int(f) for f in floats))
>>
>> or:
>>
>> unique_integers = len(set(map(int, floats))
>>
>> If you're going to use Python, at least use it right.
>
> Okay, you've replaced my map function with an implicit list
> comprehension (aka: generator expression)... so how is
> either more "right" than the other? What is your
> justification that your example is "right", and mine is not?
>

You had:

uniqueIntegers = len(set(map(lambda f:int(f), flist)))

I replaced it with:

unique_integers = len(set(map(int, floats))

Aside from the variable names, the significant difference here is that
I pass int to map directly, where you wrap it up in a useless lambda
function:

lambda f: int(f)

Of course Python is going to look worse if you add stuff like that to your code.

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

Re: [Tutor] beginning to code

[Paul Moore]

On 12 September 2017 at 16:03, Rick Johnson
 wrote:
> Chris Angelico wrote:
>> Rick Johnson wrote:
>> > Ruby:
>> > farray = [1.5, 1.9, 2.0, 1.0]
>> > uniqueIntegers = farray.map{|f| f.to_i()}.uniq.length
>> >
>> > Python:
>> > flist = [1.5, 1.9, 2.0, 1.0]
>> > uniqueIntegers = len(set(map(lambda f:int(f), flist)))
>>
>> Python:
>>
>> floats = [1.5, 1.9, 2.0, 1.0]
>> unique_integers = len(set(int(f) for f in floats))
>>
>> or:
>>
>> unique_integers = len(set(map(int, floats))
>>
>> If you're going to use Python, at least use it right.
>
> Okay, you've replaced my map function with an implicit list
> comprehension (aka: generator expression)... so how is
> either more "right" than the other? What is your
> justification that your example is "right", and mine is not?
>
> (1) Is is a speed issue? Then prove it.
>
> (2) Is it a readability issue? If so, then that's an opinion
> _you_ get to have.
>
> (3) Is a matter of "python purity"?  If so, then map should be
> removed from the language. And don't forget to remove reduce
> and filter while you're at it. And then, you may want to
> grab a shield, because the functional fanboys will be all
> over you like white on rice!
>
> (4) Something else...?

Ignoring stylistic choices (variable naming, map vs generator) then
for me the key distinction here is "lambda f: int(f)" vs just "int".
Python's callables (of which the integer constructor int is one) are
first class objects, so you should just pass them directly. Creating
an anonymous function using lambda that just calls int is slower,
harder to read, and less natural. The lambda is a direct translation
of the Ruby "|f| f.to_i()" - I don't know if Ruby lacks a built in
"convert to integer" function - maybe it does because it takes the
"everything is an object" philosophy much further than Python does,
but that's where "this code was translated from another language"
shows.

Using map vs comprehensions is mostly a stylistic choice. Python
programmers will typically choose a comprehension, so that style looks
more idiomatic, but the map is not wrong. I haven't tested which is
faster - I can't imagine it would make much practical difference in a
real program. Readability is certainly a personal choice - but writing
code that looks natural to other users of the language is an element
of readability (not the only one, but it is one).

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

Re: [Tutor] beginning to code

[INADA Naoki]

> floats = [1.5, 1.9, 2.0, 1.0]
> unique_integers = len(set(int(f) for f in floats))

And it can be written with set comprehension too.

>>> floats = [1.5, 1.9, 2.0, 1.0]
>>> len({int(x) for x in floats})
2

As my personal recommendation, map is OK only
when first argument is predefined.
In other words, I strongly prefer comprehension to map+lambda.

Regards,

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

Brainstorming on recursive class definitions

[Johannes Bauer]

Hi group,

so I'm having a problem that I'd like to solve *nicely*. I know plenty
of ways to solve it, but am curious if there's a solution that allows me
to write the solution in a way that is most comfortable for the user.

I'm trying to map registers of a processor. So assume you have a n bit
address space, the processor might have duplicate units of identical
functionality mapped at different places in memory. For example, assume
there's a GPIO unit that has registers FOO, BAR and KOO and two GPIO
ports GPIOA and GPIOB. I'd like to write code along the lines of this:

class GpioMap(BaseRegisterMap):
FOO = 0x0
BAR = 0x4
KOO = 0x8

class CPURegisterMap(BaseRegisterMap):
GPIOA = GpioMap(0x1)
GPIOB = GpioMap(0x2)

cpu = CPURegisterMap(0x8000)

assert(cpu.addr == 0x8000)
assert(cpu.GPIOA.addr == 0x8000 + 0x1)
assert(cpu.GPIOB.addr == 0x8000 + 0x2)
assert(cpu.GPIOA.FOO.addr == 0x8000 + 0x1 + 0x0)
assert(cpu.GPIOA.KOO.addr == 0x8000 + 0x1 + 0x8)
assert(cpu.GPIOB.BAR.addr == 0x8000 + 0x2 + 0x4)

So, obviously, FOO, BAR and KOO are of type "int" without any "addr"
property, so there would need to be some magic there. Additionally,
through some way the instanciation of GpioMap() would need the knowledge
of its parent base, which I'm not sure is even possible. Maybe (that's
what I'm currently trying to get right) the __getattribute__ would
propagate the information about the accumulated parent's base address to
the child during lookup.

Anyways, I'm looking for your ideas on how to solve such a thing
"nicely". Note that "BaseRegisterMap" is allowed to do dirty things as
long as the definition code has a clean look & feel.

Cheers,
Joe


-- 
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt?
> Zumindest nicht öffentlich!
Ah, der neueste und bis heute genialste Streich unsere großen
Kosmologen: Die Geheim-Vorhersage.
 - Karl Kaos über Rüdiger Thomas in dsa 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [Tutor] beginning to code

[alister via Python-list]

On Tue, 12 Sep 2017 08:03:58 -0700, Rick Johnson wrote:

> Chris Angelico wrote:
>> Rick Johnson wrote:
>> > Ruby:
>> > farray = [1.5, 1.9, 2.0, 1.0]
>> > uniqueIntegers = farray.map{|f| f.to_i()}.uniq.length
>> >
>> > Python:
>> > flist = [1.5, 1.9, 2.0, 1.0]
>> > uniqueIntegers = len(set(map(lambda f:int(f), flist)))
>>
>> Python:
>>
>> floats = [1.5, 1.9, 2.0, 1.0]
>> unique_integers = len(set(int(f) for f in floats))
>>
>> or:
>>
>> unique_integers = len(set(map(int, floats))
>>
>> If you're going to use Python, at least use it right.
> 
> Okay, you've replaced my map function with an implicit list
> comprehension (aka: generator expression)... so how is either more
> "right" than the other? What is your justification that your example is
> "right", and mine is not?
> 
> (1) Is is a speed issue? Then prove it.
> 
> (2) Is it a readability issue? If so, then that's an opinion _you_ get
> to have.
> 
> (3) Is a matter of "python purity"?  If so, then map should be removed
> from the language. And don't forget to remove reduce and filter while
> you're at it. And then, you may want to grab a shield, because the
> functional fanboys will be all over you like white on rice!
> 
> (4) Something else...?

for me the fact that you have had to resort to a lambda when the other 
solutions show it is unnecessary do it for me.

I guess that falls into option 2 but it is an opinion that I can at least 
offer some justification for, especially considering you were using it as 
an example of how ruby was cleaner than python.

were i to be less generous I would suggest that you had deliberately 
picked the worst python method you could think of to make the point



-- 
"jackpot:  you may have an unneccessary change record"
-- message from "diff"
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Brainstorming on recursive class definitions

[Johannes Bauer]

By the way, here's my work in progress:
https://gist.github.com/johndoe31415/7e432b4f47f0030f0903dbd6a401e5dc

I really really love the look & feel, but am unsure if there's a better
way for this?

Cheers,
Joe


-- 
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt?
> Zumindest nicht öffentlich!
Ah, der neueste und bis heute genialste Streich unsere großen
Kosmologen: Die Geheim-Vorhersage.
 - Karl Kaos über Rüdiger Thomas in dsa 
-- 
https://mail.python.org/mailman/listinfo/python-list

Python dress

[Larry Martell]

Not too many females here, but anyway:

https://svahausa.com/collections/shop-by-interest-1/products/python-code-fit-flare-dress

(And if any guys want to wear this, there's nothing wrong with that.)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Brainstorming on recursive class definitions

[moogyd--- via Python-list]

On Tuesday, September 12, 2017 at 5:37:31 PM UTC+2, Johannes Bauer wrote:
> Hi group,
> 
> so I'm having a problem that I'd like to solve *nicely*. I know plenty
> of ways to solve it, but am curious if there's a solution that allows me
> to write the solution in a way that is most comfortable for the user.
> 
> I'm trying to map registers of a processor. So assume you have a n bit
> address space, the processor might have duplicate units of identical
> functionality mapped at different places in memory. For example, assume
> there's a GPIO unit that has registers FOO, BAR and KOO and two GPIO
> ports GPIOA and GPIOB. I'd like to write code along the lines of this:
> 
> class GpioMap(BaseRegisterMap):
>   FOO = 0x0
>   BAR = 0x4
>   KOO = 0x8
> 
> class CPURegisterMap(BaseRegisterMap):
>   GPIOA = GpioMap(0x1)
>   GPIOB = GpioMap(0x2)
> 
> cpu = CPURegisterMap(0x8000)
> 
> assert(cpu.addr == 0x8000)
> assert(cpu.GPIOA.addr == 0x8000 + 0x1)
> assert(cpu.GPIOB.addr == 0x8000 + 0x2)
> assert(cpu.GPIOA.FOO.addr == 0x8000 + 0x1 + 0x0)
> assert(cpu.GPIOA.KOO.addr == 0x8000 + 0x1 + 0x8)
> assert(cpu.GPIOB.BAR.addr == 0x8000 + 0x2 + 0x4)
> 
> So, obviously, FOO, BAR and KOO are of type "int" without any "addr"
> property, so there would need to be some magic there. Additionally,
> through some way the instanciation of GpioMap() would need the knowledge
> of its parent base, which I'm not sure is even possible. Maybe (that's
> what I'm currently trying to get right) the __getattribute__ would
> propagate the information about the accumulated parent's base address to
> the child during lookup.
> 
> Anyways, I'm looking for your ideas on how to solve such a thing
> "nicely". Note that "BaseRegisterMap" is allowed to do dirty things as
> long as the definition code has a clean look & feel.
> 
> Cheers,
> Joe
> 
> 
> -- 
> >> Wo hattest Du das Beben nochmal GENAU vorhergesagt?
> > Zumindest nicht öffentlich!
> Ah, der neueste und bis heute genialste Streich unsere großen
> Kosmologen: Die Geheim-Vorhersage.
>  - Karl Kaos über Rüdiger Thomas in dsa 

A child (e.g. instance of GpioMap) should not have any knowledge of it's own 
base address. This is a function of the GPIORegisyerMap only.
i.e. The GPIORegisyerMap  would do the selection of particular instance.

It may be worth looking at some of the IP-XACT documentation, which defines 
some common terms (IIRC register, address map, address space etc). Having a 
consistent definition here will definitely help moving forward
Although it may seem OTT at the moment, it is something you should consider at 
the outset.
e.g. A single GPIO register may occur at two different addresses, depending on 
the bus master (CPU Core, Debugger, External SPI access).

Steven

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

Re: Run Windows commands from Python console

[Rick Johnson]

Stephan Houben wrote:
> Rick Johnson schreef:
> > It seems to me the best solution is for the TCL/Tk folks
> > to provide a configuration utility that stores user
> > preferences in the registry, or some other OS provided
> > mechanism, as to have these settings reset on every
> > invocation of the application would be inefficient from an
> > enduser perspective.
> 
> You mean, like the existing .Xdefaults mechanism (yes Tk
> also supports that on Windows), and the "option" mechanism?

Not "exactly" (see footnotes [1] and [2]). Those features
are only available to the programmer. What i'm talking about
is an "interface configuration utility" that _bypasses_ the
programmer and allows the _enduser_ to reshape or reorder
the interface widgets.

For instance: (IMO) it is appropriate for a programmer to
define the initial interface commands (be they menu commands
or keyboard shortcuts, or other..), but it is not
appropriate for the programmer to limit the placement of
these menu commands (either by purposeful action or outright
neglect), nor to prevent the redefining of keyboard
shortcuts. Furthermore, many devs refuse to employ the
resizable container widgets such as "tk.PanedWindow". I
would argue that _all_ containers should be user-resizable,
coupled with an application level: "reset all frames to
default size" command.

Typically, most software developers will provide a
configuration dialog so that users can redefine keyboard
shortcuts, however, this feature will only be available *IF*
the developer decides to make it available. Even more rare,
is the ability to re-order the menu commands as the user
sees fit. Some large softwares like Eclipse and Open Office
offer this feature, but again, the configuration power the
end user is given remains at the discretion of the
developer, and many times, the decision to omit these
important configuration features is not a matter of
discretion at all, it's just pure laziness.

Realizing the ubiquitous nature of poor GUI interface
design, and realizing the impossibility of hardcoding a
single interface that will satisfy all users, i have come to
the conclusion that an enduser configuration utility must be
made available by the GUI library _itself_, thereby
bypassing the prejudice and incompetence of developers
entirely, and giving the endusers the ultimate power to
reshape the interface as the endusers see fit.

[1] I had read somewhere once, and my knowledge in this area
is admittingly limited as i have not yet migrated to
Python3's tkinter module, that the Option Database of legacy
Tkinter (python2) was being deprecated in favor of the new
ttk.widget styling defined in tkinter (python3). My
understanding is that the legacy Option Database (which i
have not utilized much myself) was merely a means by which
certain widget attributes (typically: styling attributes)
could be propagated throughout an interface -- so i doubt
(but i could be wrong) that this feature would provide a
_persistent_ means by which a user can reconfigure the
interface outside of simple stylings.

[2] However, if .Xdefaults provides a cross-platform
_persistent_ storage mechanism, then all one would need do
is wrap it in a friendly dialog that would be made available
to every [Tt]kinter enduser (perhaps through a small button
added to every tk.Tk window). And although Tk itself does
not provide a built-in method for moving around menu
commands, one could be implemented fairly easily using the
methods of the existing menu components.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python dress

[Jona Azizaj]

It looks very nice, thanks for sharing :)


On 09/12/2017 06:16 PM, Larry Martell wrote:
> Not too many females here, but anyway:
>
> https://u434.ct.sendgrid.net/wf/click?upn=PEGtk34F2vzY-2FdDEgdADyR5WgaJXp3kK7yjjfCP4LBGKF2bSjvTFWCFYRlwVAQZ5HEeMdCPRw1tUKRf8HLGvHzOQQS1VCWAz-2FXnHFw36zPHseeHhMMPaOQoGFSuR98b4_-2Bhtkm6SDKcrqjRFK9GSlahGOHKvvNKRPEMAZ1tASX-2BnljYyh-2BoqYVc1h6KEMOxobwDxM8Dr0Jy9ZrPUamH2ONoCofjMh1-2F1ZTp8vs28IRq9-2FV-2BKG81NQ1WNnZqms0swnJ63OL0Ai78Q-2FoPsl-2B1T4gBR3ASVhYWQVYVs5TlijuEpg79GoCU7Mxh4SuDwC2QJQ4zf51XQJ-2BcNmZPwKUzr6oO6UidvYAoYDYNMp4HWhnC4-3D
>
> (And if any guys want to wear this, there's nothing wrong with that.)

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

Re: [Tutor] beginning to code

[Rick Johnson]

Chris Angelico wrote:
> Rick Johnson wrote:
> > Chris Angelico wrote:
> > > Rick Johnson wrote:
> > > > 
> > > > Ruby:
> > > > farray = [1.5, 1.9, 2.0, 1.0]
> > > > uniqueIntegers = farray.map{|f| f.to_i()}.uniq.length
> > > >
> > > > Python:
> > > > flist = [1.5, 1.9, 2.0, 1.0]
> > > > uniqueIntegers = len(set(map(lambda f:int(f), flist)))
> > >
> > > Python:
> > >
> > > floats = [1.5, 1.9, 2.0, 1.0]
> > > unique_integers = len(set(int(f) for f in floats))
> > >
> > > or:
> > >
> > > unique_integers = len(set(map(int, floats))
> > >
> > > If you're going to use Python, at least use it right.
> >
> > Okay, you've replaced my map function with an implicit
> > list comprehension (aka: generator expression)... so how
> > is either more "right" than the other? What is your
> > justification that your example is "right", and mine is
> > not?
> 
> You had:
> 
> uniqueIntegers = len(set(map(lambda f:int(f), flist)))
> 
> I replaced it with:
> 
> unique_integers = len(set(map(int, floats))
> 
> Aside from the variable names, the significant difference
> here is that I pass int to map directly, where you wrap it
> up in a useless lambda function:
> 
> lambda f: int(f)

Oops! Yes, i did put a superfluous anonymous function in
there, my bad O:-) Although, to my defense, (and although i
never use this style in real code, but i'm trying to save
face here #_o, so bear with me...) the lambda does make the
call to map a "little" more clearer. For instance, when we
juxtapose:

map(int, flist)

with:

map(lambda f:int(f), flist)

We get a little more insight into the internal workings of
map in the second example, specifically, that each `f` in
`flist` is being cast to integer. Which, incidentally, is
why some folks prefer the explicit generator expressions and
list comprehensions over the implicit nature of map. But
along with your correction of my superfluous lambda, you
offered this additional generator expression form:

unique_integers = len(set(int(f) for f in floats))

And this was the form for which my four questions were
directed (ignoring my superfluous lambda, of course). So i
resubmit my map form as:

flist = [1.5, 1.9, 2.0, 1.0]
uniqueIntegers = len(set(map(int, flist)))

and then we juxtapose your generator expression (with
variable names normalized free of charge ;-):

flist = [1.5, 1.9, 2.0, 1.0]
unique_integers = len(set(int(f) for f in flist))

So, what are your answers to my four questions:

(1) Is it a speed issue? Then prove it.

(2) Is it a readability issue? If so, then that's an
opinion _you_ get to have.

(3) Is it a matter of "python purity"?  If so, then map
should be removed from the language, and don't forget to
remove reduce and filter while you're at it, and then,
you may want to grab a shield because the functional
fanboys will be all over you like white on rice! (psst:
here comes Rustom Mody now!!!)

(4) Something else...?

> Of course Python is going to look worse if you add stuff
> like that to your code.

The lambda was an accident, perhaps even a happy accident,
but my four questions and my original intent stands valid
even in light of my simple mistake. Now dammit, answer the
questions! :-)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [Tutor] beginning to code

[Chris Angelico]

On Wed, Sep 13, 2017 at 3:22 AM, Rick Johnson
 wrote:
> Oops! Yes, i did put a superfluous anonymous function in
> there, my bad O:-) Although, to my defense, (and although i
> never use this style in real code, but i'm trying to save
> face here #_o, so bear with me...) the lambda does make the
> call to map a "little" more clearer. For instance, when we
> juxtapose:
>
> map(int, flist)
>
> with:
>
> map(lambda f:int(f), flist)
>
> We get a little more insight into the internal workings of
> map in the second example, specifically, that each `f` in
> `flist` is being cast to integer.

The point of map() is to map a function over a collection. Its inner
workings are no more exposed by the use of a pass-through lambda
function than without.

> So, what are your answers to my four questions:
>
> (1) Is it a speed issue? Then prove it.
>
> (2) Is it a readability issue? If so, then that's an
> opinion _you_ get to have.
>
> (3) Is it a matter of "python purity"?  If so, then map
> should be removed from the language, and don't forget to
> remove reduce and filter while you're at it, and then,
> you may want to grab a shield because the functional
> fanboys will be all over you like white on rice! (psst:
> here comes Rustom Mody now!!!)
>
> (4) Something else...?
>
>> Of course Python is going to look worse if you add stuff
>> like that to your code.
>
> The lambda was an accident, perhaps even a happy accident,
> but my four questions and my original intent stands valid
> even in light of my simple mistake. Now dammit, answer the
> questions! :-)
> --
> https://mail.python.org/mailman/listinfo/python-list
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [Tutor] beginning to code

[Chris Angelico]

On Wed, Sep 13, 2017 at 3:22 AM, Rick Johnson
 wrote:
> So, what are your answers to my four questions:
>
> (1) Is it a speed issue? Then prove it.
>
> (2) Is it a readability issue? If so, then that's an
> opinion _you_ get to have.
>
> (3) Is it a matter of "python purity"?  If so, then map
> should be removed from the language, and don't forget to
> remove reduce and filter while you're at it, and then,
> you may want to grab a shield because the functional
> fanboys will be all over you like white on rice! (psst:
> here comes Rustom Mody now!!!)
>
> (4) Something else...?


(Oops, premature send.)

#1 is almost certainly true, since non-code is invariably faster than
code (either way, int() gets called). But that's not the point.

#2 is part of the point. But not the main point.

#3 - if you mean that map violates purity in some way, then (a) I
never said to remove it, and (b) Python never brags that purity is its
goal.

#4. Catch-all, I guess.

Do you write:
if x:

or do you write:
if bool(x):

or maybe:
if bool(x) is True:

or perhaps:
if (bool(x) is True) is True:

or even:
if (bool(x) is True) == (True is not False):

Redundant code does not belong.

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

Re: [Tutor] beginning to code

[Rick Johnson]

Paul  Moore wrote:
[...]
> Ignoring stylistic choices (variable naming, map vs
> generator) then for me the key distinction here is "lambda
> f: int(f)" vs just "int". Python's callables (of which the
> integer constructor int is one) are first class objects, so
> you should just pass them directly. Creating an anonymous
> function using lambda that just calls int is slower, harder
> to read, and less natural. The lambda is a direct
> translation of the Ruby "|f| f.to_i()" - I don't know if
> Ruby lacks a built in "convert to integer" function - maybe
> it does because it takes the "everything is an object"
> philosophy much further than Python does, but that's where
> "this code was translated from another language" shows.

I was wondering why i put that lambda in there, and that's
probably why i did it, superficially, to more accurately
compare the syntax of both languages, at the expense of
writing concise Python code.

In any event, i believe my point -- that complex statements
in Ruby follow a more intuitive left-to-right comprehension
flow, whereas Python, which due to a reliance on built-in
functions as opposed to Object methods is directly
responsible for our code being littered with these less
intuitive nested function calls -- remains a valid point.

> Using map vs comprehensions is mostly a stylistic choice.
> Python programmers will typically choose a comprehension,
> so that style looks more idiomatic, but the map is not
> wrong. I haven't tested which is faster - I can't imagine
> it would make much practical difference in a real program.
> Readability is certainly a personal choice - but writing
> code that looks natural to other users of the language is
> an element of readability (not the only one, but it is
> one).

I would agree on all points.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [Tutor] beginning to code

[Rick Johnson]

alister wrote:
> [...]
> were i to be less generous I would suggest that you had
> deliberately picked the worst python method you could think
> of to make the point

Feel free to offer a better solution if you like. INADA
Naoki offered a good solution for Python3 folks, but AFAIK,
set comprehensions are not avialable as a backported "future
feature" for Python2 folks. And surely not for Python1
folks.

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

Re: Python dress

[Stephan Houben]

Op 2017-09-12, Jona Azizaj schreef :
> It looks very nice, thanks for sharing :)

   print(insertionSort)

It's even Python3-compliant!

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

Re: Python dress

[Chris Warrick]

On 12 September 2017 at 21:15, Stephan Houben
 wrote:
> Op 2017-09-12, Jona Azizaj schreef :
>> It looks very nice, thanks for sharing :)
>
>print(insertionSort)
>
> It's even Python3-compliant!
>
> Stephan
> --
> https://mail.python.org/mailman/listinfo/python-list

Meh. That should be a return statement, the thing is not PEP
8-compliant, and Courier is an ugly font.

-- 
Chris Warrick 
PGP: 5EAAEA16
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python dress

[Ben Finney]

Larry Martell  writes:

> https://svahausa.com/collections/shop-by-interest-1/products/python-code-fit-flare-dress
> (And if any guys want to wear this, there's nothing wrong with that.)

Boo, the code is not PEP 8 conformant :-)

If it weren't for the bad code style, I might consider it. The dress
looks good!

-- 
 \  “Contentment is a pearl of great price, and whosoever procures |
  `\it at the expense of ten thousand desires makes a wise and |
_o__)  happy purchase.” —J. Balguy |
Ben Finney

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

Re: Python dress

[Leam Hall]

On 09/12/2017 04:00 PM, Ben Finney wrote:

Larry Martell  writes:


https://svahausa.com/collections/shop-by-interest-1/products/python-code-fit-flare-dress
(And if any guys want to wear this, there's nothing wrong with that.)


Boo, the code is not PEP 8 conformant :-)

If it weren't for the bad code style, I might consider it. The dress
looks good!



Note that a google search of "python muscle shirt" didn't seem to come 
up with any code. Wonder why?  :P

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

Re: Hatch - A modern project, package, and virtual env manager

[ofekmeister]

0.10.0 features environment-aware testing, full Xonsh shell support, and more 
colors! https://github.com/ofek/hatch#0100
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [Tutor] beginning to code

[Paul Moore]

On 12 September 2017 at 18:52, Rick Johnson
 wrote:
> In any event, i believe my point -- that complex statements
> in Ruby follow a more intuitive left-to-right comprehension
> flow, whereas Python, which due to a reliance on built-in
> functions as opposed to Object methods is directly
> responsible for our code being littered with these less
> intuitive nested function calls -- remains a valid point.

Hardly. As you said to Chris, that's an opinion that you get to have -
but trying to claim that your opinion is anything other than that
(just an opinion) is pointless.

> Feel free to offer a better solution if you like. INADA
> Naoki offered a good solution for Python3 folks, but AFAIK,
> set comprehensions are not avialable as a backported "future
> feature" for Python2 folks. And surely not for Python1
> folks.

So what? What's the point in comparing Ruby with years-out-of-date
Python? At this point you're clearly just looking for an argument, so
I'll give up on this thread.

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

Re: Python dress

[Steve D'Aprano]

On Wed, 13 Sep 2017 02:16 am, Larry Martell wrote:

> Not too many females here, but anyway:
> 
>
https://svahausa.com/collections/shop-by-interest-1/products/python-code-fit-flare-dress

Was expecting a dress in a snake-skin pattern.

Was pleasantly surprised to see Insertion Sort in Python on a dress!


> (And if any guys want to wear this, there's nothing wrong with that.)

Assuming they can fit in the offered sizes :-)

Here in Australia, we're having an expensive, divisive, non-binding exercise in
political propaganda, a postal survey on whether or not to continue allowing
discrimination in marriage. The pro-discrimination side has run a TV
advertisement claiming that equal rights for marriage is just the first step
that will end with our sons being told they can wear dresses to school (and
possibly even lions and lambs lying down together in the field).

Apparently that's meant to be the end of the world as we know it, or something.

The amusing thing to my mind is that the pro-discrimination, anti-equality
faction also tend to be the most conservative[1] pro-monarchy faction. I don't
recall seeing them go into paroxysms of gender confusion when Prince Charles,
Duke of Edinburgh, appears in public wearing a kilt.





[1] Gosh, that's a shocker. Bet you didn't see that coming.

-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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

Re: [Tutor] beginning to code

[INADA Naoki]

2017/09/13 午前3:04 "Rick Johnson" :

alister wrote:
> [...]
> were i to be less generous I would suggest that you had
> deliberately picked the worst python method you could think
> of to make the point

Feel free to offer a better solution if you like. INADA
Naoki offered a good solution for Python3 folks, but AFAIK,
set comprehensions are not avialable as a backported "future
feature" for Python2 folks. And surely not for Python1
folks.


FYI, it was backported to Python 2.7.

https://docs.python.org/2/tutorial/datastructures.html#sets

As a OSS maintainer, I and many common libraries drop Python 2.6 support
already.
So I can use it even when I can't drop Python 2 supprt yet.

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

Re: [Tutor] beginning to code

[Steve D'Aprano]

On Wed, 13 Sep 2017 01:18 am, Paul Moore wrote:

> Using map vs comprehensions is mostly a stylistic choice. Python
> programmers will typically choose a comprehension, so that style looks
> more idiomatic, but the map is not wrong. I haven't tested which is
> faster - I can't imagine it would make much practical difference in a
> real program.


Last time I tested it:


map(f, values)  # Python 2 version of map

[f(x) for x in values]


were equally fast when f was some function, but the comprehension:

[2*x + y for x in values]  # for example

is considerably faster than the map solution using lambda:

map(lambda x: 2*x + y, values)

The lesson is: calling a function isn't free. If you can in-line an expression
rather than call a function to evaluate the expression, you gain.

(Although the more expensive the expression, the less significant the function
call overhead becomes.)

The implication is that the more superfluous function wrappers you have, the
slower your code. If our aim is to have slow, unreadable code, we can take the
obvious:

map(int, values)

and progressively slow it down:

map(lambda x: int(x), values)

map(lambda y: (lambda x: int(x))(y), values)

map(lambda z: (lambda y: (lambda x: int(x))(y))(z), values)




-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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

Re: Python dress

[Gregory Ewing]

Larry Martell wrote:

https://svahausa.com/collections/shop-by-interest-1/products/python-code-fit-flare-dress


The only disadvantage might be the GIL interfering with
parallel processing using multiple machines in a laundromat.

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

Re: Python dress

[MRAB]

On 2017-09-13 00:32, Steve D'Aprano wrote:

On Wed, 13 Sep 2017 02:16 am, Larry Martell wrote:


Not too many females here, but anyway:



https://svahausa.com/collections/shop-by-interest-1/products/python-code-fit-flare-dress

Was expecting a dress in a snake-skin pattern.

Was pleasantly surprised to see Insertion Sort in Python on a dress!



(And if any guys want to wear this, there's nothing wrong with that.)


Assuming they can fit in the offered sizes :-)

Here in Australia, we're having an expensive, divisive, non-binding exercise in
political propaganda, a postal survey on whether or not to continue allowing
discrimination in marriage. The pro-discrimination side has run a TV
advertisement claiming that equal rights for marriage is just the first step
that will end with our sons being told they can wear dresses to school (and
possibly even lions and lambs lying down together in the field).

Co-incidentally, there was a story in the news today about a couple in 
the UK who have stopped sending their son to a school that's allowing 
another child to dress as both a boy and a girl. They did the same thing 
with their eldest son at the same school two years ago.



Apparently that's meant to be the end of the world as we know it, or something.

The amusing thing to my mind is that the pro-discrimination, anti-equality
faction also tend to be the most conservative[1] pro-monarchy faction. I don't
recall seeing them go into paroxysms of gender confusion when Prince Charles,
Duke of Edinburgh, appears in public wearing a kilt.

You do know that Prince Charles is the Prince of Wales and that the Duke 
of Edinburgh is his father, don't you? :-)





[1] Gosh, that's a shocker. Bet you didn't see that coming.



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

Re: Python dress

[Rick Johnson]

On Tuesday, September 12, 2017 at 6:59:32 PM UTC-5, Gregory Ewing wrote:
> Larry Martell wrote:
> > https://svahausa.com/collections/shop-by-interest-1/products/python-code-fit-flare-dress
> 
> The only disadvantage might be the GIL interfering with
> parallel processing using multiple machines in a
> laundromat.

Oh, not the only disadvantage: being that 5 of the machines
are running Python3, and 4 are running Python2, and one is
still stubbornly running Python1, and being that the owner
forgot to mark them, if we put the dress in the wrong
machine -- *BOOM* -- exceptions all over the floor. 

Can anyone think of a way to version-test these machines
without wasting a quarter, or requiring the services of a
clean-up crew?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [Tutor] beginning to code

[Rick Johnson]

Chris Angelico wrote:
> Rick Johnson wrote:
> > So, what are your answers to my four questions:
> >
> > (1) Is it a speed issue? Then prove it.
> >
> > (2) Is it a readability issue? If so, then that's an
> > opinion _you_ get to have.
> >
> > (3) Is it a matter of "python purity"?  If so, then map
> > should be removed from the language, and don't forget to
> > remove reduce and filter while you're at it, and then,
> > you may want to grab a shield because the functional
> > fanboys will be all over you like white on rice! (psst:
> > here comes Rustom Mody now!!!)
> >
> > (4) Something else...?
> 
> 
> (Oops, premature send.)

It's okay Chris, it happens. Sometimes we get a little too
excited and loose all control over our bodily functions. O:-)

> #1 is almost certainly true, since non-code is invariably
> faster than code (either way, int() gets called). But
> that's not the point.

I told you to forget about the superfluous lambda, but
alas, you cannot :-(

> #2 is part of the point. But not the main point.
> 
> #3 - if you mean that map violates purity in some way, then
> (a) I never said to remove it, and (b) Python never brags
> that purity is its goal.

If you wanted to say no, you could have just said it...

> #4. Catch-all, I guess.
> 
> Do you write:
> if x:
> 
> or do you write:
> if bool(x):
> 
> or maybe:
> if bool(x) is True:
> 
> or perhaps:
> if (bool(x) is True) is True:
> 
> or even:
> if (bool(x) is True) == (True is not False):
> 
> Redundant code does not belong.

Just as writing overly implicit code is harmful, so too is
writing overly explicit code.

When we read overly implicit code, we are distracted by the
need to interpret the enormous amount of meaning hiding
behind a single symbol. Regular expressions are an example
of overly implicit code, but regular expressions are a
special purpose tool, and they are designed with the idea of
packing a lot of functionality into the fewest symbols.

OTOH, when we read overly explicit code, we are distracted
by the excessive symbols.

So a balance must be found between these two extremes.  For
instance, i have always considered this "Python custom" to
be far too implicit:

if x:
# do something

What are we testing about `x`? 
Obviously, most programmers, especially Python programmers,
will know what is going on here because they have been
trained, and just like any child who has been trained to
ride a bicycle, riding a bicycle becomes _reflexive_, and
the rider, who was once terrified of riding, becomes cocky,
as to them the task now seems simple.

But just because we have been trained that the implicit `if
x:` is shorthand for the reasonable `if bool(x) == True:`,
does not mean the implicit syntax is "correct". No. You,
just as the child who learned to ride a bicycle now believes
that `if x` is right, and not because of some deep objective
analysis, no, but because it is "reflexive" for you to say
so. Your failure here is obvious: you're conflating
Pavlovian conditioning with moral principals.

What are the moral principals of language design?

A tough question to answer objectively, i admit, however, if
we can manage to see beyond their own subjective
interpretations of reality, most of which that have been
molded by years of obedience training (aka: "Oh, that's
soo easy because my master said so, and peer pressure
demands it"), then we might find the objective compromise
between two extremes. In this case, the compromise is:

if bool(x) is True:
# do something...

In this example, we strike a balance between implicit and
explicit code, because in this example, we don't need to
assume what aspect of `x` that we are "testing", no, because
the test is now made crystal clear. We can even expand the
code to English intuitively, as:

if the boolean value of x is True:
# do something...

Now, some quippy person will no doubt complain that: `if
bool(x) is True` will be slower than `if x`. And that's
true! But the reason it's slower is not because it's a bad
idea, no, it's because the language designers have decided
(via emotion, not logic!) that `if x` is the better way to
go, and so they've optimized `if x`. I assure you that, `if
bool(x) is True` can be made to execute exactly as fast as
`if x`, and anybody who claims otherwise is a flat out liar.

There is absolutely no correlation between the length of a
statement and the time required to execute that statement
once it has been "interpreted". Heck, if we wanted to be
silly, we could expand the statement to:

if the boolean value of x is True\
and python is absolutely one hundred percent positive that it is True\
and furthermore there is not even a snowballs chance in hell that it 
could be False\
and the earth is roundish\
and water is wet\
and OJ is not looking for the true killer because he would rather play 
golf\
and mass m

Re: [Tutor] beginning to code

[Chris Angelico]

On Wed, Sep 13, 2017 at 1:01 PM, Rick Johnson
 wrote:
> Chris Angelico wrote:
>> Rick Johnson wrote:
>> > So, what are your answers to my four questions:
>> >
>
> I told you to forget about the superfluous lambda, but
> alas, you cannot :-(

You told me to forget about the key thing I was making my point about,
and yet insisted on answers to your four questions?

> So a balance must be found between these two extremes.  For
> instance, i have always considered this "Python custom" to
> be far too implicit:
>
> if x:
> # do something
>
> What are we testing about `x`?
> Obviously, most programmers, especially Python programmers,
> will know what is going on here because they have been
> trained, and just like any child who has been trained to
> ride a bicycle, riding a bicycle becomes _reflexive_, and
> the rider, who was once terrified of riding, becomes cocky,
> as to them the task now seems simple.
>
> But just because we have been trained that the implicit `if
> x:` is shorthand for the reasonable `if bool(x) == True:`,
> does not mean the implicit syntax is "correct".

The statement "if x:" is not shorthand for any sort of equality
comparison. If you want to say that it's shorthand for "if bool(x):",
then sure, but the "== True" part is entirely superfluous.

> What are the moral principals of language design?

PEP 20.

> A tough question to answer objectively, i admit, however, if
> we can manage to see beyond their own subjective
> interpretations of reality, most of which that have been
> molded by years of obedience training (aka: "Oh, that's
> soo easy because my master said so, and peer pressure
> demands it"), then we might find the objective compromise
> between two extremes. In this case, the compromise is:
>
> if bool(x) is True:
> # do something...
>
> In this example, we strike a balance between implicit and
> explicit code, because in this example, we don't need to
> assume what aspect of `x` that we are "testing", no, because
> the test is now made crystal clear. We can even expand the
> code to English intuitively, as:
>
> if the boolean value of x is True:
> # do something...

"Anything on that list?" is far more idiomatic English than "Is the
boolean value of that list identical to the constant True?".

> Now, some quippy person will no doubt complain that: `if
> bool(x) is True` will be slower than `if x`. And that's
> true! But the reason it's slower is not because it's a bad
> idea, no, it's because the language designers have decided
> (via emotion, not logic!) that `if x` is the better way to
> go, and so they've optimized `if x`. I assure you that, `if
> bool(x) is True` can be made to execute exactly as fast as
> `if x`, and anybody who claims otherwise is a flat out liar.

Actually, you're absolutely correct. You can make them execute just as
quickly. Here:

class X:
def __bool__(self):
while True is not False:
pass
x = X()

Easy.

> There is absolutely no correlation between the length of a
> statement and the time required to execute that statement
> once it has been "interpreted".
> [chomp]
> ...and the byte compiled code would execute at the same
> speed as `if x`. And if it doesn't, then the devs are
> incompetent or they're sabotaging the interpreter for
> political reasons.

So you start with the assumption that "if bool(x) is True" and "if x"
have absolutely identical semantics, and then say that they should be
the same thing. Great! Well, when they do, you can remind someone to
improve the peephole optimizer. Turns out, "bool(x)" is slower because
it has different semantics. What an enormous surprise.

> And as far as your other examples are concerned:
>
>> or perhaps:
>> if (bool(x) is True) is True:
>>
>> or even:
>> if (bool(x) is True) == (True is not False):
>
> they're just reductio ad absurdum.

Yep. So, where are you going to draw the line between "absurd" and
"correct"? I'm going to put it just after "if x:", on the basis that
all superfluous code is bad. Justify the amount of superfluous code
that you want.

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

Re: Using Python 2

[Rick Johnson]

Gregory Ewing wrote:
> Rick Johnson wrote:
> > Heck, when is the last time GvR participated in any
> > discussion outside the hermetic bubble of Python-Dev or
> > Python-Ideas?
> 
> I'd hardly call python-ideas "hermetic". Anyone is free to
> post there and participate in discussions.  Python-dev is
> open to anyone too, the only difference is that python-dev
> intended for things that are actually being worked on,
> whereas python-ideas is for any idea that may or may not
> come to fruition.

I dunno, my experiences in that group have been less than
welcoming, but i won't beat a dead horse...

> If you want to interact with Guido, you need to go to
> a list he frequents. You can't expect him to personally
> reply to every issue on every python-related list and
> group. That would be more than a full-time job for
> anyone.

I'm not so much interested in talking with Guido personally, i
would just like to see him participate in more areas of this
community instead of keeping himself all couped-up in those
"members only" forums. I see no need for the Python
community to be purposefully stratified into social classes.
But i cannot help but feel that some folks in this community
have declared themselves members of an aristocracy.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Using Python 2

[Steven D'Aprano]

On Tue, 12 Sep 2017 20:22:30 -0700, Rick Johnson wrote:

> Gregory Ewing wrote:
>> Rick Johnson wrote:
>> > Heck, when is the last time GvR participated in any discussion
>> > outside the hermetic bubble of Python-Dev or Python-Ideas?
>> 
>> I'd hardly call python-ideas "hermetic". Anyone is free to post there
>> and participate in discussions.  Python-dev is open to anyone too, the
>> only difference is that python-dev intended for things that are
>> actually being worked on, whereas python-ideas is for any idea that may
>> or may not come to fruition.
> 
> I dunno, my experiences in that group have been less than welcoming, but
> i won't beat a dead horse...

Why ever not? You beat all the other dead horses.

"Python is doomed if you don't listen to me."

"Python is doomed because of type hinting."

"Python is doomed because of async."

"Python is doomed because of Python 3."

"Python is doomed because watermelon colourless sleep kumquat."


>> If you want to interact with Guido, you need to go to a list he
>> frequents. You can't expect him to personally reply to every issue on
>> every python-related list and group. That would be more than a
>> full-time job for anyone.
> 
> I'm not so much interested in talking with Guido personally, i would
> just like to see him participate in more areas of this community instead
> of keeping himself all couped-up in those "members only" forums.


Python-Dev and Python-Ideas are no more "members only" than Python-List 
(this forum). As you know, because you subscribed to at least one of them 
some time ago. The only difference is that those forums have less 
patience towards bullshit. As you know, because you soon left.



-- 
Steven D'Aprano
“You are deluded if you think software engineers who can't write 
operating systems or applications without security holes, can write 
virtualization layers without security holes.” —Theo de Raadt
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python dress

[Steven D'Aprano]

On Wed, 13 Sep 2017 01:12:25 +0100, MRAB wrote:

>> I don't recall seeing them go into paroxysms of
>> gender confusion when Prince Charles,
>> Duke of Edinburgh, appears in public wearing a kilt.
> 
> You do know that Prince Charles is the Prince of Wales and that the Duke
> of Edinburgh is his father, don't you? :-)

Ah, yes, thanks for the correction. Of course I was thinking about Prince 
Philip, not Charles.


-- 
Steven D'Aprano
“You are deluded if you think software engineers who can't write 
operating systems or applications without security holes, can write
virtualization layers without security holes.” —Theo de Raadt
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Simple board game GUI framework

[Rick Johnson]

Terry Reedy wrote:
> Paul Moore said:
[...]
> I was going to suggest tkinter.

I would second Terry's advice here. If a low barrier and
simplicity are what you want, then i would suggest tkinter
first and Pygame second. You can do a lot with a tk.Canvas
widget, and for proper image support make sure to install
the third party PIL library. If neither of those are
interesting to you, then you can try any of the third party
GUI or game libraries all the way down to PyOpenGL, where
you get ultimate control, for the small price of your
sanity. (insert maniacal laugh track here)

> > The following code is basically the core of what I need:
> > 
> > import tkinter as tk
> > 
> > def create_board(root):
> >  board = {}
> >  for r in range(8):
> >  for c in range(8):
> >  lbl = tk.Button(bg="white", text="   ", font=("Consolas", 12))
> >  lbl.grid(row=r, column=c)
> >  board[r,c] = lbl

Dude, that tuple is naked! And nudity in public places is
not cool; unless of course your code is a Ms. America model,
or it resides in a nudist colony (Hey, don't forget your
"sitting towel"!), which obviously is not true in either
case. ;-) Try this instead:

 board[(r,c)] = lbl

There. And now, and in more ways than one, we have defined some
bondaries.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [Tutor] beginning to code

[Steven D'Aprano]

On Tue, 12 Sep 2017 20:01:52 -0700, Rick Johnson wrote:

> But just because we have been trained that the implicit `if x:` is
> shorthand for the reasonable `if bool(x) == True:`

That's not reasonable.

bool(x) already returns a True or False flag, comparing it to True is 
superfluous. (Regardless of whether you use `is` or a slower equality 
test.) It is excessively redundantly surplus.

And where do you stop? If you don't believe `bool(x)` is a flag, then you 
can't believe `bool(x) == True` either, leading you into an infinite 
regress of superfluous redundancy:

if (bool(x) == True) == True:

if ((bool(x) == True) == True) == True:

if (((bool(x) == True) == True) == True) == True:

if bool(x) == True) == True) == True) == True) == True:

if (bool(x) == True) == True) == True) == True) == True) == True:
# help, I don't know how to stop


The *only* reasonable place to stop is right at the beginning:

if bool(x):

at least for languages like Pascal and Java where `if` requires a 
specific boolean type.

And assuming x is not already a bool. If it is a bool, you of course 
wouldn't redundantly call bool on it repeatedly again and again 
redundantly:

if bool(bool(bool(bool(bool( ... (x)))...)
# help, I don't know where to stop!!!


If x is already a flag, then it would be silly to waste time calling bool 
even once. You wouldn't write this:

a = int(25)
b = int(30)
c = int( (int(a) + int(b))*int(2) )
values = list([1, 2, 3])
x = list(values)[int(c)]


No, its quite obvious that anyone who would call bool() on something 
which is already a bool, let alone the even more excessively superfluous 
`if bool(x) is True`, is a cargo-cult programmer who isn't fluent enough 
in the Python language to know what they're doing.

And of course the beauty of duck-typing in Python is that *everything* is 
a bool, or at least quacks like a bool and swims like a bool.



[...]
> they're just reductio ad absurdum.

I see that your understanding of logical fallacies is as penetrating and 
profound as your understanding of Python's design.




-- 
Steven D'Aprano
“You are deluded if you think software engineers who can't write 
operating systems or applications without security holes, can write
virtualization layers without security holes.” —Theo de Raadt
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [Tutor] beginning to code

[Rick Johnson]

Steven D'Aprano wrote:
> Rick Johnson wrote:
> 
> > 
> > But just because we have been trained that the implicit
> > `if x:` is shorthand for the reasonable `if bool(x) ==
> > True:`
> 
> That's not reasonable.  bool(x) already returns a True or
> False flag, comparing it to True is superfluous.

So what? That's a simple matter of translating source code
to byte code and has nothing to do with your inability to
grasp that byte code and source code are not a one-to-one
translation. Although the byte code and the source code of a
program carry the same _general_ information about how a
program will execute, the byte code is optimized for machine
communication whereas the source code is optimizes (or
should be!) for human communication. Byte code is meant to
be as concise and optimized as possible, whereas source code
is meant to be more elaborate. Humans are not machines, and
machines are not humans. We communicate in different ways.

Source code must be intuitive, and `if x` is not intuitive,
and if you don't believe me, then ask a non-programmer to
intuit what `if x` means. A neophyte may know enough about
basic logic to guess that the `if` is testing for some kind
True/False value, but the same noob will never guess that
the boolean value of an object can change based on such
abstract notions as "empty versus not empty" or "zero versus
more than zero". So, uhh, good luck with that little survey!

Your flaw is to judge the "if x" statement on the purely
abstract byte-compiled machine level, whereas i am judging
the statement on an intuitive human level. We can define
what happens on the abstract level all we want, but we
cannot define intuition. Neither can we define practicality.
Either a statement is intuitive, or it is not. Either an
action is practical, or it is not.

Do you also understand that we can translate *ANY* source
code into any byte code we want? There are no laws in the
universe that prevent Python from translating the source
code of "if bool(x) is True" to the same byte code that is
currently created by "if x". So stop lying, or prove that
such a translation is impossible.

> (Regardless of whether you use `is` or a slower equality
> test.) It is excessively redundantly surplus.  And where do
> you stop? If you don't believe `bool(x)` is a flag, then
> you can't believe `bool(x) == True` either, leading you
> into an infinite regress of superfluous redundancy:
> 
> [snip: hyperbole]
> 
> The *only* reasonable place to stop is right at the beginning:
> 
> if bool(x):
> 
> at least for languages like Pascal and Java where `if`
> requires a specific boolean type.

Well, i should at least consider this a small victory.
Again, i must stress, that what Python sees is a matter of
the byte code translation, not a matter of what *WE*, as
programmers, see. So your argument is ignoring the real
issue.

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

Re: The Incredible Growth of Python (stackoverflow.blog)

[Paul Rubin]

Chris Angelico  writes:
> Why? Unless they're going to be maintaining a Py2 codebase, why should
> they learn the older version with less features?

Are there actually Py3 codebases?  I guess there must be, even though
I've never seen one.  Every Python codebase of any size that I know of
is Py2.  So yes, of course they're working on a Py2 codebase.  That's
the only kind there is, as far as I know.
-- 
https://mail.python.org/mailman/listinfo/python-list