date:20170910

Terry Reedy :

> On 9/9/2017 6:31 AM, Pavol Lisy wrote:
>> Interesting reading:
>> https://stackoverflow.blog/2017/09/06/incredible-growth-python/?cb=1
>
> So much for Python 3 having killed python ;-)

Hasn't yet, but it would have been interesting to see the 2/3 divide in
the stats.

One shouldn't get complacent. Ten years ago Nokia had a 40% global
market share in cell phones. Now they're gone.

The clouds I see looming over Python's head are:

 * 2-to-3 migration

 * static type annotation

 * asyncio with its a-dialect

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

Re: People choosing Python 3

INADA Naoki :

> I can't wait Python 3 is the default Python of Red Hat, and "python"
> command means Python 3 on Debian and Ubuntu.

I can't wait till Python 3 is available on Red Hat.


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

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

On Sun, Sep 10, 2017 at 5:27 PM, Marko Rauhamaa  wrote:
> Terry Reedy :
>
>> On 9/9/2017 6:31 AM, Pavol Lisy wrote:
>>> Interesting reading:
>>> https://stackoverflow.blog/2017/09/06/incredible-growth-python/?cb=1
>>
>> So much for Python 3 having killed python ;-)
>
> Hasn't yet, but it would have been interesting to see the 2/3 divide in
> the stats.
>
> One shouldn't get complacent. Ten years ago Nokia had a 40% global
> market share in cell phones. Now they're gone.
>
> The clouds I see looming over Python's head are:
>
>  * 2-to-3 migration

If that was going to kill Python, it would have had some impact by
now. There are students learning Python *today* who are never going to
have to worry about the migration, because they're learning Python 3.

>  * static type annotation

I'm not seeing very much of this in the wild yet, but honestly, it's
not that big a deal. You can ignore it if you want to.

>  * asyncio with its a-dialect

Actually, I think this one is a huge enough feature that it's going to
be a big thing to *drive* the uptake of Python.

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

Re: People choosing Python 3

2017-09-10 Thread Chris Warrick

On 10 September 2017 at 09:30, Marko Rauhamaa  wrote:
> INADA Naoki :
>
>> I can't wait Python 3 is the default Python of Red Hat, and "python"
>> command means Python 3 on Debian and Ubuntu.
>
> I can't wait till Python 3 is available on Red Hat.

Python 3.4 is available in EPEL. RHEL 8 will switch to Python 3 as the
main Python interpreter (assuming dnf replaces yum, as it did in
Fedora a while back).

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

Re: People choosing Python 3

2017-09-10 Thread Leam Hall


On 09/10/2017 04:19 AM, Chris Warrick wrote:

On 10 September 2017 at 09:30, Marko Rauhamaa  wrote:

INADA Naoki :


I can't wait Python 3 is the default Python of Red Hat, and "python"
command means Python 3 on Debian and Ubuntu.


I can't wait till Python 3 is available on Red Hat.


Python 3.4 is available in EPEL. RHEL 8 will switch to Python 3 as the
main Python interpreter (assuming dnf replaces yum, as it did in
Fedora a while back).


I'm not sure that RHEL 8 will be Python 3 for the OS tools. Even if it 
is, which version?


From a non-rpm perspective Python 3.6.2 compiles nicely on CentOS 6. 
Once compiled it seems easy to use pip3 to install stuff without 
trampling on the OS's Python 2 install.


Just have to make sure your PATH is set right. By putting /usr/local/bin 
after /usr/bin I can use "py.test" to run tests under Python 2 and 
"pytest" for Python 3.


Leam

p.s. Sorry Chris, meant to send this to the list. You get it twice.
--
https://mail.python.org/mailman/listinfo/python-list

Re: People choosing Python 3

Chris Warrick :

> On 10 September 2017 at 09:30, Marko Rauhamaa  wrote:
>> I can't wait till Python 3 is available on Red Hat.
>
> Python 3.4 is available in EPEL.

As an application developer, I can't make the customers depend on EPEL.
It's Python2 until the distro comes with Python3.

> RHEL 8 will switch to Python 3 as the main Python interpreter
> (assuming dnf replaces yum, as it did in Fedora a while back).

No sign of RHEL 8 anywhere. My guess it will happen in late 2018.

What I'm asking myself is why Red Hat isn't adding Python3 to RHEL 7. I
was very disappointed when 7.4 didn't have it.

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

Re: People choosing Python 3

2017-09-10 Thread Chris Warrick

On 10 September 2017 at 11:24, Leam Hall  wrote:
> On 09/10/2017 04:19 AM, Chris Warrick wrote:
>>
>> On 10 September 2017 at 09:30, Marko Rauhamaa  wrote:
>>>
>>> INADA Naoki :
>>>
 I can't wait Python 3 is the default Python of Red Hat, and "python"
 command means Python 3 on Debian and Ubuntu.
>>>
>>>
>>> I can't wait till Python 3 is available on Red Hat.
>>
>>
>> Python 3.4 is available in EPEL. RHEL 8 will switch to Python 3 as the
>> main Python interpreter (assuming dnf replaces yum, as it did in
>> Fedora a while back).
>>
>
> I'm not sure that RHEL 8 will be Python 3 for the OS tools. Even if it is,
> which version?

RHEL’s release process starts at forking a recent Fedora release. It
wouldn’t make much sense for them to undo the Python 3 progress that
happened over the past few years in Fedora — including dnf, an
improved package manager written in Python 3. If the fork happened
today, the base release would be Fedora 26, which includes Python 3.6,
and some install options don’t include Python 2.

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

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

2017-09-10 Thread Skip Montanaro

>  * asyncio with its a-dialect

What is a/the "a-dialect"?

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

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

2017-09-10 Thread Rustom Mody

On Sunday, September 10, 2017 at 3:15:32 PM UTC+5:30, Skip Montanaro wrote:
> >  * asyncio with its a-dialect
> 
> What is a/the "a-dialect"?
> 
> S

I'd guess its the async/await (semi)keyworded python
Compre with the (IMHO) better suggestion for codef/cocall
https://lists.gt.net/python/dev/1197316?do=post_view_threaded
-- 
https://mail.python.org/mailman/listinfo/python-list

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

2017-09-10 Thread Gene Heskett

On Sunday 10 September 2017 01:06:00 Ben Finney wrote:

> Gene Heskett  writes:
> > On Saturday 09 September 2017 21:48:44 Chris Angelico wrote:
> > > The Python Secret Underground emphatically does not exist.
> >
> > Humm. here all this time I thought you were a charter member. :)
>
> With all the authority vested in me as a charter member, I can
> categorically say the Python Secret Underground does not exist.
>
Chuckle. But this is far out in the puckerbrush, and I'm out of string 
for my weed-eater.  And we got here in record time. ;-)
> --
>  \   “Pinky, are you pondering what I'm pondering?” “Well, I think
> | `\ so, Brain, but first you'd have to take that whole bridge
> | _o__) apart, wouldn't you?” —_Pinky and The
> Brain_ | Ben Finney


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

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

On Sun, Sep 10, 2017 at 7:45 PM, Skip Montanaro
 wrote:
>>  * asyncio with its a-dialect
>
> What is a/the "a-dialect"?

Want to make something iterable? Define __iter__. Want to make it
async-iterable (with "async for")? Define __aiter__. It's a bit clunky
if you want the same object to be iterable both ways, but I don't know
of any real-world situations where that's the case.

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

Python in Perspective

2017-09-10 Thread Leam Hall


y'all,

My god-kids and their proginators lost most everything because of 
Harvey. I spent much of yesterday worrying about a friend who had gone 
quiet as he evacuated his family ahead of Irma.


Please keep Python in perspective. Whether we use 1.5 or 4rc1 is a lot 
less critical than using Python to work together well and solving big 
problems as friends.


In years gone by I spent time on the soapbox but never came away cleaner 
or with stronger friendships. I just ranted and spent years wondering 
why nothing actually changed. Please don't make my mistake; come up with 
your own.


Together. As friends.

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

Re: People choosing Python 3

2017-09-10 Thread Gene Heskett

On Sunday 10 September 2017 05:25:51 Leam Hall wrote:

> On 09/10/2017 04:19 AM, Chris Warrick wrote:
> > On 10 September 2017 at 09:30, Marko Rauhamaa  
wrote:
> >> INADA Naoki :
> >>> I can't wait Python 3 is the default Python of Red Hat, and
> >>> "python" command means Python 3 on Debian and Ubuntu.
> >>
> >> I can't wait till Python 3 is available on Red Hat.
> >
> > Python 3.4 is available in EPEL. RHEL 8 will switch to Python 3 as
> > the main Python interpreter (assuming dnf replaces yum, as it did in
> > Fedora a while back).
>
> I'm not sure that RHEL 8 will be Python 3 for the OS tools. Even if it
> is, which version?
>
>  From a non-rpm perspective Python 3.6.2 compiles nicely on CentOS 6.
> Once compiled it seems easy to use pip3 to install stuff without
> trampling on the OS's Python 2 install.
>
> Just have to make sure your PATH is set right. By putting
> /usr/local/bin after /usr/bin I can use "py.test" to run tests under
> Python 2 and "pytest" for Python 3.
>
> Leam

But that is contrary to the usual practice, fixed so that stuff built and 
installed locally, with identical names to the distro's /usr/bin 
contents, is found first in /usr/local/bin and the newer version is 
used.

That "usual practice" is going to be a very high hill to climb. I 
personally would never consider it as a solution to this p2 vs p3 
problem.


> p.s. Sorry Chris, meant to send this to the list. You get it twice.


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

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

2017-09-10 Thread Stephan Houben

Op 2017-09-10, Chris Angelico schreef :
> Want to make something iterable? Define __iter__. Want to make it
> async-iterable (with "async for")? Define __aiter__. It's a bit clunky
> if you want the same object to be iterable both ways, but I don't know
> of any real-world situations where that's the case.

Would we not eventually want a file object to deliver its lines
asynchronously (with non-blocking reads under the hood) if
iterated over with "async for", while preserving the current
blocking behavior in the "for" case?

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

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

Skip Montanaro :

>>  * asyncio with its a-dialect
>
> What is a/the "a-dialect"?

await
async def
async for
__aiter__
__anext__
async with
__aenter__
__aexit__

What's more, when you turn a function into an async, you need to
refactor a large part of your program.


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

Re: People choosing Python 3

2017-09-10 Thread Stephan Houben

Op 2017-09-10, Marko Rauhamaa schreef :
> As an application developer, I can't make the customers depend on EPEL.
> It's Python2 until the distro comes with Python3.

Why not bundle the Python interpreter with your application?
It seems to work for Windows developers...

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

Re: Python in Perspective

2017-09-10 Thread Tristan B. Kildaire


On 2017-09-10 12:21 PM, Leam Hall wrote:

y'all,

My god-kids and their proginators lost most everything because of 
Harvey. I spent much of yesterday worrying about a friend who had gone 
quiet as he evacuated his family ahead of Irma.


Please keep Python in perspective. Whether we use 1.5 or 4rc1 is a lot 
less critical than using Python to work together well and solving big 
problems as friends.


In years gone by I spent time on the soapbox but never came away cleaner 
or with stronger friendships. I just ranted and spent years wondering 
why nothing actually changed. Please don't make my mistake; come up with 
your own.


Together. As friends.

Leam

I agree. Don't get too caught up in these things. :)

Hope all goes well mate and that things get better for you and your 
reletives and friends.

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

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

2017-09-10 Thread gerlando . falauto

> 
> I suspect it's down to timing.
> 
> What you're putting into the queue is a reference to the array, and it's 
> only some time later that the array itself is pickled and then sent (the 
> work being done in the 'background').
> 
> Modifying the array before (or while) it's actually being sent would 
> explain the problem you're seeing.

That would also have been my guess. However, according to documentation:

> When an object is put on a queue, the object is pickled and a background 
> thread later flushes the pickled data to an underlying pipe.

In my understanding this means the object is pickled *before* the background 
thread takes care of flushing the data to the pipe. Is that a mistake in the 
documentation then?

Any suggestion for a way to work around this limitation?
Or perhaps a different approach altogether I could use to reduce CPU load?
What the main thread actually does is dequeue data from a high-speed 
USB-to-serial (2.000.000 bps), that's why I came up with the array.array() 
solution to store collected data, hoping for the smallest possible overhead.
Thanks!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: People choosing Python 3

Stephan Houben :

> Op 2017-09-10, Marko Rauhamaa schreef :
>> As an application developer, I can't make the customers depend on EPEL.
>> It's Python2 until the distro comes with Python3.
>
> Why not bundle the Python interpreter with your application?
> It seems to work for Windows developers...

I've seen that done for Python and other technologies. It is an
expensive route to take. Also, it can be insecure. When vulnerabilities
are found, they are communicated to the maintainers of, say, Python.
When Python is fixed and released, the vulnerability is revealed, but
the version bundled with your product is still broken. You have to be
prepared perform an emergency release of your product and hope you don't
mess things up.


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

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

Stephan Houben :

> Op 2017-09-10, Chris Angelico schreef :
>> Want to make something iterable? Define __iter__. Want to make it
>> async-iterable (with "async for")? Define __aiter__. It's a bit clunky
>> if you want the same object to be iterable both ways, but I don't know
>> of any real-world situations where that's the case.
>
> Would we not eventually want a file object to deliver its lines
> asynchronously (with non-blocking reads under the hood) if
> iterated over with "async for", while preserving the current
> blocking behavior in the "for" case?

I'm not exactly sure what your point is.

"async for" is needed to allow a for loop to iterate over a sequence
that is generated asynchronously. If you accidentally use a regular
"for" (and chances are you will), you will experience weird behavior.

As for file objects supporting asynchronous iterators, I agree they
should. Linux is not quite ready for nonblocking file access yet (the
kernel developers are busy trying to make it happen).

Note that you will not only need an async version of a file iterator but
also versions for the "open()" function, directory walking etc.


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

ايجى وورلد

2017-09-10 Thread mohmmedmohmmedalagmyabdalrhman

ايجى وورلد
http://egyworld.bid
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Using Python 2

2017-09-10 Thread Ian Kelly

On Sat, Sep 9, 2017 at 9:26 PM, Rick Johnson
 wrote:
> On Friday, September 8, 2017 at 8:57:56 AM UTC-5, Ned Batchelder wrote:
>> On 9/8/17 6:12 AM, Leam Hall wrote:
>> > I've read comments about Python 3 moving from the Zen of Python. I'm a
>> > "plain and simple" person myself. Complexity to support what CompSci
>> > folks want, which was used to describe some of the Python 3 changes,
>> > doesn't help me get work done.
>>
>> I've heard a lot of FUD about the Python 3 transition, but this one is
>> new to me.  What is it that CompSci folks want that developers don't
>> want, that ruined Python 3?
>
> TWO WORDS: "Type" and "Hints"

Fail.

1. Type hints were only added in 3.5, not Python 3.0, so this does not
support the claim that Python 3 changes were made to support CS.

2. Type hints are completely optional, so this does not support the
claim that Python 3 added complexity that is counter-productive to
"simple" users. If you want to keep your program simple, you can: just
don't use them.

3. Type hints are practical. You may not need or desire them for pet
projects, but large-scale projects with a large team of developers
require a large degree of testing. Static typing supports this. This
is a feature for enterprise users, not theorists.
-- 
https://mail.python.org/mailman/listinfo/python-list

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

On Sun, Sep 10, 2017 at 8:08 PM, Marko Rauhamaa  wrote:
> Skip Montanaro :
>
>>>  * asyncio with its a-dialect
>>
>> What is a/the "a-dialect"?
>
> What's more, when you turn a function into an async, you need to
> refactor a large part of your program.

That's not Python-specific. If you're going to change your program
from single-threaded single-process synchronous to any of
multi-threaded, multi-process, or asynchronous (all of which involve
multiple pieces running concurrently or interleaved), you have to
build your program with that in mind. It's best NOT to try to convert,
but to build it that way from the start. Give threaded socket servers
a try - you'll learn a lot. It's really not hard.

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

Re: Python programming language vulnerabilities

2017-09-10 Thread Serhiy Storchaka

08.09.17 20:34, Stephen Michell пише:

I chair ISO/IEC/JTC1/SC22/WG23 Programming Language Vulnerabilities. We publish
an international technical report, ISO IEC TR 24772 Guide to avoiding
programming language vulnerabilities through language selection use. Annex D in
this document addresses vulnerabilities in Python. This document is freely
available from ISO and IEC.

We are updating this technical report, adding a few vulnerabilities and
updating language applicability as programming languages evolve. We are also
subdividing the document by making the language-specific annexes each their own
technical report. For the Python Part, the major portions are written, but we
have about 6 potential vulnerabilities left to complete.

We need help in finishing the Python TR. We are looking for a few Python
experts that have experience in implementing Python language systems, or
experts in implementing significant systems in Python (for technical level,
persons that provide technical supervision to implementers, or that write and
maintain organizational Python coding standards.

Any links? There are a lot of documents on
http://www.open-std.org/JTC1/SC22/WG23/docs/documents, but some links
are dead, and I have no found Annex D in
http://www.open-std.org/JTC1/SC22/WG23/docs/ISO-IECJTC1-SC22-WG23_N0742-tr24772-1-after-meeting-50-20170817.pdf.

Maybe https://python-security.readthedocs.io/ can be useful to you.

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

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

Chris Angelico wrote:
> Marko Rauhamaa wrote:

[...]

> > The clouds I see looming over Python's head are:
> >
> >  * 2-to-3 migration
> 
> If that was going to kill Python, it would have had some
> impact by now. There are students learning Python *today*
> who are never going to have to worry about the migration,
> because they're learning Python 3.
> 
> >  * static type annotation
> 
> I'm not seeing very much of this in the wild yet, but
> honestly, it's not that big a deal. You can ignore it if
> you want to.

Kinda difficult to ignore type annotations when they are
intermixed with the code!

I never really had a problem with the idea of Python having
type-hints, so long as the ugly annotations were kept
_separated_ from the .py[w] files, but for some reason, the
devs decided that mucking up Python's clean syntax for the
sake of (what you claim is) a small minority of type-hint
fanboys, was okay...

The fanboys of type-hints claim that we will never (or
hardly ever) see these annotations in the wild, but again,
if that is the case, *IF* usage of this feature is really
that rare, then why should it be given such power to
undermine the readability of Python code? It is not too
late! We are still in the very early stages of type-hints,
and we can undo the damage that this "feature" will cause if
we remove the hints from the .py[w] files entirely. Let the
burden be on those who want this feature, not on those who
don't want it.

Futhermore, if we consider the damage that small changes
(like the print statement versus print function and
raw_input versus input) have caused, how can we expect
(short of a self delusion) that type-hints will have no
negative effects?

There is one aspect of the internet that will never change,
namely: persistance, and from now, and until Python
disappears from the universe, there will always be a need to
explain why `print` was changed from a statement to a
function, along with an explanation of the subtle
differences between python2's raw_input() and input() versus
Python3's input(), not to mention the age old ramblings
about classic classes versus new classes. And as much as
we'd all like for these confusions to go away, they won't,
because there is no way to "clean" the internet of every
Python2 tutorial, blog or website that mentions these bygone
features.

The stain of Python3's violent and radical changes to the
core philosophy of the language may never be washed clean,
and although we might have survived Python3 _eventually_,
type-hints is like a wooden stake driven into the heart of
this community. It's almost like they _want_ to destroy this
language. 

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

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

2017-09-10 Thread breamoreboy

On Sunday, September 10, 2017 at 6:07:00 AM UTC+1, Ben Finney wrote:
> Gene Heskett writes:
> 
> > On Saturday 09 September 2017 21:48:44 Chris Angelico wrote:
> >
> > > The Python Secret Underground emphatically does not exist.
> >
> > Humm. here all this time I thought you were a charter member. :)
> 
> With all the authority vested in me as a charter member, I can
> categorically say the Python Secret Underground does not exist.
> 
> -- 
>  \   “Pinky, are you pondering what I'm pondering?” “Well, I think |
>   `\ so, Brain, but first you'd have to take that whole bridge |
> _o__) apart, wouldn't you?” —_Pinky and The Brain_ |
> Ben Finney

How has Python managed world domination without the aid of Pinky and the Brain?

--
Kindest regards.

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

Re: Using Python 2

Ian Kelly :

> 2. Type hints are completely optional, so this does not support the
> claim that Python 3 added complexity that is counter-productive to
> "simple" users. If you want to keep your program simple, you can: just
> don't use them.

We'll see about that. I'm afraid type hints will become ubiquitous and
turn Python into another Java.

> 3. Type hints are practical. You may not need or desire them for pet
> projects, but large-scale projects with a large team of developers
> require a large degree of testing. Static typing supports this. This
> is a feature for enterprise users, not theorists.

Ah, the *enterprise*, where the holy grail is to guarantee that junior
programmers can't make mistakes.

Been there. I'm afraid this is not a joke:

  https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition>

Python, COBOL for the next generation.


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

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

Chris Angelico :

> On Sun, Sep 10, 2017 at 8:08 PM, Marko Rauhamaa  wrote:
>> What's more, when you turn a function into an async, you need to
>> refactor a large part of your program.
>
> That's not Python-specific. If you're going to change your program
> from single-threaded single-process synchronous to any of
> multi-threaded, multi-process, or asynchronous (all of which involve
> multiple pieces running concurrently or interleaved), you have to
> build your program with that in mind. It's best NOT to try to convert,
> but to build it that way from the start. Give threaded socket servers
> a try - you'll learn a lot. It's really not hard.

It's not Python-specific but it *is* async-specific. Multithreading,
multiprocessing and callback hell don't result in similar cascading
effects.

Even otherwise, I'm not at all convinced by the whole coroutine concept.


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

Re: Using Python 2

Steve D'Aprano wrote:
> Rick Johnson wrote:
> > Marko Rauhamaa wrote:
> > >
> > > The risk to Python will be whether the occasion is
> > > exploited by fanboys of competing programming languages.
> > > The migration from Python 2 might be to something else
> > > than Python 3 in some circles.
> > 
> > That has been my observation as well.
> 
> It certainly has been. I still remember your panicked, "the
> sky is falling" posts terrified that unless we re-defined
> Python to your specifications, the entire Python community
> would rush to Ruby.  

You exaggerate. I do remember waging a "PyWarts" campaign
some years back, but those posts were an appeal to remedy
_real_ problems i discovered in a few specific stdlib
modules, namely: IDLE, Tkinter, re, os.path, zipfile,
tarfile, and possibly others i have since forgotten about...

> That was, oh, ten or twelve years ago, if I remember
> correctly. How did that prediction work out for you?

Well, i would say that when i first arrived on the "python
scene" (roughy about the time Python3 was released, possibly
a year or two before), the community was (thanks to the
maturity and stability of Python2) far more cohesive and
vibrant. Since then, we have been hemorrhaging python
loyalist and the core devs have become evermore isolated
from the broader community, even clannish. If you remember,
that was back in the naive days when the TIOBE index was all
the rage.

Heck, when is the last time GvR participated in any
discussion outside the hermetic bubble of Python-Dev or
Python-Ideas? Certainly he has not bothered to participate
in any fashion on this open forum, and perhaps, many of the
posts here are not worthy of his time, but some certainly
are. Such behavior leads many of us to believe that we are
second class citizens.

OTOH, in one of the few occasions that i participated in the
Ruby forums, Yukihiro "Matz" Matsumoto responded positively
to one of my posts (which i believe, but i may have
misremembered, was an appeal for consistency of function
call syntax, as Ruby allowed the parenthesis to be omitted
when no arguments were passed, naturally, i prefered
consistency, and Matz agreed. And the fact that he took the
time to respond to a lurker proved that he is a man of the
people, which sadly, is not the case for "our dear leader".

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

Re: Using Python 2

Ian wrote:
> Rick Johnson wrote:
> > Ned Batchelder wrote:
> > > Leam Hall wrote:
> > > > 
> > > > I've read comments about Python 3 moving from the Zen of
> > > > Python. I'm a "plain and simple" person myself.
> > > > Complexity to support what CompSci folks want, which was
> > > > used to describe some of the Python 3 changes, doesn't
> > > > help me get work done.
> > >
> > > I've heard a lot of FUD about the Python 3 transition,
> > > but this one is new to me.  What is it that CompSci folks
> > > want that developers don't want, that ruined Python 3?
> >
> > TWO WORDS: "Type" and "Hints"
> 
> Fail.
> 
> 1. Type hints were only added in 3.5, not Python 3.0, so
> this does not support the claim that Python 3 changes were
> made to support CS.

But it is true that CS purist want type annotations while 99%
of the everyday Python programmers can live happily without
them. "Practicality beats purity". 

> 2. Type hints are completely optional, so this does not
> support the claim that Python 3 added complexity that is
> counter-productive to "simple" users. If you want to keep
> your program simple, you can: just don't use them.

True, individual programmers can choose to omit type-hints
from their own code, but they cannot choose to omit type-
hints from the code they are forced to read. Once type
annotations start propagating in the wild, the syntactical
noise of statically typed languages will be ever-present in
Python code, only problem is, we will get *NONE* of the
advantages of _real_ statically typed languages, namely:
executables, compiler optimizations, and enhanced execution
speed. Heck, all we get in return for our painful eyeball
parsings are (maybe) better linters. Which is not an ROI
worthy of my sweat equity.

> 3. Type hints are practical. You may not need or desire
> them for pet projects, but large-scale projects with a
> large team of developers require a large degree of testing.
> Static typing supports this. This is a feature for
> enterprise users, not theorists.

I was never against Python having a type annotation feature,
no, i am only against the inclusion of this syntacticly noisy
feature in the .py[w] files. Mandating that type annotations
be defined in _external_ stub files places the onerous on
those who care about type annotations (a micro minority of
CS purist), and removes it from those who don't (the
remaining majority of Python programmers). 

I'm telling you, we can still prevent this feature from
destroying the language, *IF* we act quickly.

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

Re: Run Windows commands from Python console

Stephan Houben wrote:
> Rick Johnson schreef:
>
> > One of the nice (current) features of Tkinter menus (that
> > i sometimes miss on my windows box!) is the ability to
> > "tear- off" a menu cascade and use it as a sort of "pseudo
> > tool bar".
>
> I was under the impression that Tk also supported tear-off
> menus under Windows (but not under macOS).

And it does. I was only complaining that the Microsoft
Windows GUI does not have this feature, not that it is
unavailable on Windows + Python + Tkinter. Sorry for the
confusion.

> However, many applications apparently explicitly suppress
> this functionality by doing
>
>   Menu(..., tearoff=0)

Yes, which is unfortunate, as the decision should be made by
the enduser, not the dev. I myself have been guilty of
suppressing this feature in my own applications, which is
evidence that these usability features should bypass the
developer entirely, and be controlled exclusively by the end
user. We devs have a tendency to think that we know what is
best for our users (*cough* pydev!), but even modest
experience with modern software would prove that assertion
to be wrong.

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. I suppose we could implement such a
configuration utility exclusively for Tkinter, if we wanted,
and perhaps it would serve as a model for the Tk folks...
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python in Perspective

2017-09-10 Thread MRAB


On 2017-09-10 11:21, Leam Hall wrote:

y'all,

My god-kids and their proginators lost most everything because of
Harvey. I spent much of yesterday worrying about a friend who had gone
quiet as he evacuated his family ahead of Irma.

Please keep Python in perspective. Whether we use 1.5 or 4rc1 is a lot
less critical than using Python to work together well and solving big
problems as friends.

In years gone by I spent time on the soapbox but never came away cleaner
or with stronger friendships. I just ranted and spent years wondering
why nothing actually changed. Please don't make my mistake; come up with
your own.

Together. As friends.

Leam


That reminds me of this quote about football (soccer):

"Some people think football is a matter of life and death. I assure you, 
it's much more serious than that." - Bill Shankly

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

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

2017-09-10 Thread MRAB


On 2017-09-10 12:40, gerlando.fala...@gmail.com wrote:


I suspect it's down to timing.

What you're putting into the queue is a reference to the array, and it's 
only some time later that the array itself is pickled and then sent (the 
work being done in the 'background').


Modifying the array before (or while) it's actually being sent would 
explain the problem you're seeing.


That would also have been my guess. However, according to documentation:

When an object is put on a queue, the object is pickled and a background 
thread later flushes the pickled data to an underlying pipe.


In my understanding this means the object is pickled *before* the background 
thread takes care of flushing the data to the pipe. Is that a mistake in the 
documentation then?

Any suggestion for a way to work around this limitation?
Or perhaps a different approach altogether I could use to reduce CPU load?
What the main thread actually does is dequeue data from a high-speed 
USB-to-serial (2.000.000 bps), that's why I came up with the array.array() 
solution to store collected data, hoping for the smallest possible overhead.
Thanks!


I've had a quick look at the source code.

When an object is put into the queue, it's actually put into an internal 
buffer (a deque), and then the method returns.


An internal thread works through the buffer and pickles the objects.

Therefore, just because the method has returned, it doesn't mean that 
it's now safe to modify the object.

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

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

Dennis Lee Bieber :

>   In contrast, every sample I've seen of the async library comes
> across as "magic happens here -- at some point in time".

That magic can be learned, in principle. I'm afraid few programmers will
be willing/able to get over the hump, and there are a number of tricky
aspects to be extra careful about.

The situation *did* get significantly better with "async" replacing
"@coroutine" and "await" replacing "yield from". However, it is easy to
accidentally forget to place the "await" keyword where it belongs and
quite a bit of troubleshooting can go into locating the mistake because
the faulty program runs without an (immediate) exception.


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

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

2017-09-10 Thread Ned Batchelder

On 9/10/17 10:46 AM, Rick Johnson wrote:
> The stain of Python3's violent and radical changes to the
> core philosophy of the language may never be washed clean,
> and although we might have survived Python3 _eventually_,
> type-hints is like a wooden stake driven into the heart of
> this community. It's almost like they _want_ to destroy this
> language. 

Given the recent Stack Overflow blog post about Python's accelerating
growth, and TIOBE rating it #1, you'd think the sky-is-falling
doom-sayers would get tired of being wrong all the time.

I guess not.

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

v2.0 released of: a Boulder Dash clone with retro graphics and sound

2017-09-10 Thread Irmen de Jong

On 06/09/2017 23:17, Irmen de Jong wrote:

> 
> https://github.com/irmen/bouldercaves
> 

My Boulder Dash clone is now at version 2.0 because a few important things that 
were
lacking are now implemented:

* authentic mode:
The game is now displayed in a small screen that scrolls smoothly over the 
level, like
the original game. It also has the retro c-64 color palette enabled. You enable 
this via
a command line option.

* pre-recorded demo:
If you press F9 or wait a while at the title screen, the game plays back a 
prerecorded
demo of cave A, like the original game.

* synthesized sounds:
Instead of using sampled sounds you can now run the game with a software sound
synthesizer that creates the sounds in real time, including the title music. 
I've tried
to simulate the sounds of the original game but ended up with slightly 
different ones.
Maybe I'll tweak the synth to make them closer to the original, but there's a 
charm to
the variation as well I think.

All in all I am very pleased with the results. I didn't expect it to be possible
creating a decently performing arcade game using just the bare essentials:
- default tkinter to draw everything on the screen
- pillow to load images
- sounddevice to play sounds (optional).

I posted this update because I now consider it a full game [1] and I think it's
interesting to see that this can be realized in Python without any of the 
specialized
'game libraries' (pygame, etc) being used. While tkinter sometimes has troubles 
updating
the screen at 30 hz, the Python code itself is barely breaking a sweat, even 
the sound
synth.

Have fun
Irmen de Jong

[1] full game: errr... there's still no highscore table. Sorry :)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [Tutor] beginning to code

2017-09-10 Thread leam hall

I will add my +1 to the careful editing of code. Python's use of white
space is pretty good once you get used to it. My Ruby code looks a lot like
my Python code.  :)

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

Re: Python programming language vulnerabilities

2017-09-10 Thread Stephen Michell

My apologies. I maintain that website.

There should have been no broken links. I will fix that.

The previous version of TR 24772 had annexes for language-specific material. We 
have split those out, so the main document (Tr 24772-1) only has language 
independent material. The last Python document is N0702 at 
open-std.org/sc22/wg23//docs/documents.html. This document was one that Serihy 
could not access. That link is fixed, so it can be accessed now.


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

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

2017-09-10 Thread iurly

Il giorno domenica 10 settembre 2017 18:53:33 UTC+2, MRAB ha scritto:
> On 2017-09-10 12:40, gerlando.fala...@gmail.com wrote:
> >> 
> >> I suspect it's down to timing.
> >> 
> >> What you're putting into the queue is a reference to the array, and it's 
> >> only some time later that the array itself is pickled and then sent (the 
> >> work being done in the 'background').
> >> 
> >> Modifying the array before (or while) it's actually being sent would 
> >> explain the problem you're seeing.
> > 
> > That would also have been my guess. However, according to documentation:
> > 
> >> When an object is put on a queue, the object is pickled and a background 
> >> thread later flushes the pickled data to an underlying pipe.
> > 
> > In my understanding this means the object is pickled *before* the 
> > background thread takes care of flushing the data to the pipe. Is that a 
> > mistake in the documentation then?
> > 
> > Any suggestion for a way to work around this limitation?
> > Or perhaps a different approach altogether I could use to reduce CPU load?
> > What the main thread actually does is dequeue data from a high-speed 
> > USB-to-serial (2.000.000 bps), that's why I came up with the array.array() 
> > solution to store collected data, hoping for the smallest possible overhead.
> > Thanks!
> > 
> I've had a quick look at the source code.
> 
> When an object is put into the queue, it's actually put into an internal 
> buffer (a deque), and then the method returns.
> 
> An internal thread works through the buffer and pickles the objects.
> 
> Therefore, just because the method has returned, it doesn't mean that 
> it's now safe to modify the object.

I see. So that explains everything. However, I wonder if that's the intended 
behavior and/or that should be documented somehow.
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!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python programming language vulnerabilities

2017-09-10 Thread Skip Montanaro

That link's not working for me, even after changing the double slash
to a single slash.

Skip

On Sun, Sep 10, 2017 at 1:45 PM, Stephen Michell
 wrote:
> My apologies. I maintain that website.
>
> There should have been no broken links. I will fix that.
>
> The previous version of TR 24772 had annexes for language-specific material. 
> We have split those out, so the main document (Tr 24772-1) only has language 
> independent material. The last Python document is N0702 at 
> open-std.org/sc22/wg23//docs/documents.html. This document was one that 
> Serihy could not access. That link is fixed, so it can be accessed now.
>
>
> --
> https://mail.python.org/mailman/listinfo/python-list
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python programming language vulnerabilities

2017-09-10 Thread Skip Montanaro

These links work:

* 
http://open-std.org/JTC1/SC22/WG23/docs/ISO-IECJTC1-SC22-WG23_N0702-tr24772-4-draft-python-before-mtg-48-2017-03-10.pdf
* 
http://open-std.org/JTC1/SC22/WG23/docs/ISO-IECJTC1-SC22-WG23_N0702-tr24772-4-draft-python-before-mtg-48-2017-03-10.docx

Skip


On Sun, Sep 10, 2017 at 4:14 PM, Skip Montanaro
 wrote:
> That link's not working for me, even after changing the double slash
> to a single slash.
>
> Skip
>
> On Sun, Sep 10, 2017 at 1:45 PM, Stephen Michell
>  wrote:
>> My apologies. I maintain that website.
>>
>> There should have been no broken links. I will fix that.
>>
>> The previous version of TR 24772 had annexes for language-specific material. 
>> We have split those out, so the main document (Tr 24772-1) only has language 
>> independent material. The last Python document is N0702 at 
>> open-std.org/sc22/wg23//docs/documents.html. This document was one that 
>> Serihy could not access. That link is fixed, so it can be accessed now.
>>
>>
>> --
>> https://mail.python.org/mailman/listinfo/python-list
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Using Python 2

2017-09-10 Thread Gregory Ewing


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.

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.

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

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

On Sunday, September 10, 2017 at 12:36:52 PM UTC-5, Ned Batchelder wrote:
> On 9/10/17 10:46 AM, Rick Johnson wrote:
> > The stain of Python3's violent and radical changes to the
> > core philosophy of the language may never be washed clean,
> > and although we might have survived Python3 _eventually_,
> > type-hints is like a wooden stake driven into the heart of
> > this community. It's almost like they _want_ to destroy
> > this language.
> 
> Given the recent Stack Overflow blog post about Python's
> accelerating growth, and TIOBE rating it #1, you'd think
> the sky-is-falling doom-sayers would get tired of being
> wrong all the time.

You mean the same TIOBE index[1] that ranks programming
languages based on search engine queries?

You mean the same TIOBE index[2] that currently ranks Python
as 5th in 2017; 7th in 2012; 6th in 2007; 11th in 2002; and
27th in 1997? Hey, when you're at the bottom, the only
direction you can go is up!

When has Python ever been #1 on the TIOBE index? 

It is Java who has reigned supreme!

TIOBE is junk science, and sorry to burst your bubble, but
Stack Overflow blog posts are just opinion pieces. In fact,
it seems the most informative part of the article can be
found in the comment section, and in a single paragraph, a
bright lad outlines the dangers of picking low hanging fruit
from statistical fairy trees:

""" An interesting analysis, but one problem with
statistical analysis is assigning a causation to a
correlation. So, the correlation is one of number of views.
The causation assumption is because of the number of users.
However, there are other potential causation theories, such
as lack of documentation, inexperience of users/viewers,
source of viewership (e.g. students versus professionals),
etc.""" -- Sid1138

So the "request for help" has more to do with noobs than
actual usage, and while Python may indeed be "popular", and
yes, that "popularity" has risen significantly over the last
few decades, we must ask ourselves: what group is Python
most popular with? If the answer is first year CS students,
then Python is merely an incidental rung on the ascension up
an academic ladder, soon to be forgotten in the professional
lives of these CS students, and replaced by the more
enterprise friendly langauges of Java and/or C.

Python (at least historically) was a great introductory
language because of the clean syntax and the batteries
included stdlib, which spared first year students the misery
of abstract syntaxes, rigid structural orthodoxy, and
tyrannical purist methodologies of more asinine languages.

And while many of us here share a great fondness for the
Python language, we must not delude ourselves into thinking
that Python is going to be some "new wave of the future".
Python is a toy language that is great for teaching, and
loads of fun to write, but it'll never compete at an
enterprise level with long established languages like Java
or C. And if the Grand Poobah believes that type-hints will
magically elevate the highly dynamic Python to enterprise
level, urm, well, then... as my good friend Nietzsche
informs me, a confrontation with the absurd may be in his
near future.

The future belongs to compiled, statically typed languages
who combine the low level necessities with the higher level
practicalities. The Go language is a step in that direction,
but with such an abysmal stdlib, it has yet to "go" very
far.

[1] https://en.wikipedia.org/wiki/TIOBE_index
[2] https://www.tiobe.com/tiobe-index/

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

Re: Design: method in class or general function?

2017-09-10 Thread Leam Hall


On 09/08/2017 03:06 AM, Peter Otten wrote:

leam hall wrote:


On Thu, Sep 7, 2017 at 8:16 AM, Steve D'Aprano
 wrote:


On Thu, 7 Sep 2017 07:20 pm, Leam Hall wrote:


OOP newbie on Python 2.6.


Python 2.6 is ancient, and is missing many nice features. You should
consider
using the latest version, 3.6.



I've wrestled with that discussion for a while and Python 3 loses every
time. There's literally no good reason for me to move to Python 3 earlier
than mid-2020's. Please accept the fact that there are hundreds of
thousands of servers, if not millions, running Python 2.x. Whether or not
Python 3 has any neat cool stuff is irrelevant to those of us seeking to
use Python to get today's work done.


I create instances of Character class with an attribute dict of

'skills'. The 'skills' dict has the name of a skill as the key and an
int as a value. The code adds or modifies skills before outputting the
Character.

Is it better design to have a Character.method that takes a 'skill' key
and optional value or to have a general function that takes an
instance, a dict, a key, and an optional value?


I'm afraid your example is too generic for me to give an opinion. Do you
literally mean a method called "method"? What does it do?




Using this:
https://github.com/makhidkarun/py_tools/blob/master/lib/character.py

Line 19 sets "self.skills" either from the passed in data or from
https://github.com/makhidkarun/py_tools/blob/master/lib/character_tools.py
#L34-L48

So Character.skills is a dict with a string key and an int value. I need
to be able to add skills and my first attempt is a function:
https://github.com/makhidkarun/py_tools/blob/master/lib/character_tools.py
#L52-L56

Should the "add_skills" function be a method in the character class or be
made a more generic function to add/modify a key/value pair in a dict that
is an attribute of an instance? Other tasks will require the add/modify
functionality but coding that increases complexity. At least for me,
anyway.

Sorry about being unclear earlier, coffee was still kicking in and I'm
still a newbie that mixes up terms.


I'm pleading "method" as it allows per-class implementation.

Say you use per-career subclasses of a general Character class. There are
default per-career skill sets, but usually a Character can acquire a skill
that is not needed in his career -- with the exception that Rogues cannot
tap dance ;)

Below is a way to implement that with a specialised add_skill() method:

$ cat basic_oo.py
from __future__ import print_function
import random
from collections import defaultdict


class Character(object):
 DEFAULT_SKILLS = ['Blade', 'GunCbt', 'Admin', 'Streetwise']

 def __init__(self):
 self.skills = defaultdict(int)

 def add_random_skills(self, terms):
 skillnames = self.DEFAULT_SKILLS
 for _ in range(2*terms):
 self.add_skill(random.choice(skillnames))

 def add_skill(self, name, amount=1):
 self.skills[name] += amount

 def __str__(self):
 skills = ", ".join(
 "{}={}".format(name, amount)
 for name, amount in sorted(self.skills.items())
 if amount != 0
 )
 return "{}({})".format(self.__class__.__name__, skills)


class Rogue(Character):
 def add_skill(self, name, amount=1):
 if name == "TapDance":
 raise ValueError("Sorry, this rogue will never tap dance")
 super(Rogue, self).add_skill(name, amount)


class Marine(Character):
 DEFAULT_SKILLS = ['GunCbt', 'VaccSuit', 'Leadership', 'Vehicle']


def main():
 NUM_CHARACTERS = 5
 CHARACTERS = [Marine, Rogue]

 characters = [
 random.choice(CHARACTERS)() for _ in range(NUM_CHARACTERS)
 ]

 for c in characters:
 c.add_random_skills(5)
 c.add_skill("RepairBicycles", random.randrange(3))
 try:
 c.add_skill("TapDance", 3)
 except ValueError as err:
 print(err)

 for c in characters:
 print(c)


if __name__ == "__main__":
 main()

$ python basic_oo.py
Sorry, this rogue will never tap dance
Sorry, this rogue will never tap dance
Sorry, this rogue will never tap dance
Rogue(Admin=3, Blade=4, GunCbt=2, Streetwise=1)
Marine(GunCbt=5, Leadership=4, TapDance=3, VaccSuit=1)
Rogue(Blade=3, GunCbt=2, RepairBicycles=2, Streetwise=5)
Rogue(Admin=1, Blade=2, GunCbt=5, RepairBicycles=1, Streetwise=2)
Marine(GunCbt=1, Leadership=3, RepairBicycles=2, TapDance=3, VaccSuit=2,
Vehicle=4)



Okay Peter, I took your idea and mangled it beyond recognition. There's 
a design constraint I hadn't mentioned: an instance of Character should 
be able to have multiple careers.


Also, an instance can be created from scratch, created from a full set 
of data, or created from a partial set of data.


Here's my current code, focusing on creating a lot of merchants: 
https://github.com/makhidkarun/py_tools/blob/merchant/lib/character.py#L60-L61


python chargen.py
Toby Verstraete

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

2017-09-10 Thread llanitedave

And not one mention of Unicode.  I consider this progress.

On Sunday, September 10, 2017 at 7:46:54 AM UTC-7, Rick Johnson wrote:
> Chris Angelico wrote:
> > Marko Rauhamaa wrote:
> 
> [...]
> 
> > > The clouds I see looming over Python's head are:
> > >
> > >  * 2-to-3 migration
> > 
> > If that was going to kill Python, it would have had some
> > impact by now. There are students learning Python *today*
> > who are never going to have to worry about the migration,
> > because they're learning Python 3.
> > 
> > >  * static type annotation
> > 
> > I'm not seeing very much of this in the wild yet, but
> > honestly, it's not that big a deal. You can ignore it if
> > you want to.
> 
> Kinda difficult to ignore type annotations when they are
> intermixed with the code!
> 
> I never really had a problem with the idea of Python having
> type-hints, so long as the ugly annotations were kept
> _separated_ from the .py[w] files, but for some reason, the
> devs decided that mucking up Python's clean syntax for the
> sake of (what you claim is) a small minority of type-hint
> fanboys, was okay...
> 
> The fanboys of type-hints claim that we will never (or
> hardly ever) see these annotations in the wild, but again,
> if that is the case, *IF* usage of this feature is really
> that rare, then why should it be given such power to
> undermine the readability of Python code? It is not too
> late! We are still in the very early stages of type-hints,
> and we can undo the damage that this "feature" will cause if
> we remove the hints from the .py[w] files entirely. Let the
> burden be on those who want this feature, not on those who
> don't want it.
> 
> Futhermore, if we consider the damage that small changes
> (like the print statement versus print function and
> raw_input versus input) have caused, how can we expect
> (short of a self delusion) that type-hints will have no
> negative effects?
> 
> There is one aspect of the internet that will never change,
> namely: persistance, and from now, and until Python
> disappears from the universe, there will always be a need to
> explain why `print` was changed from a statement to a
> function, along with an explanation of the subtle
> differences between python2's raw_input() and input() versus
> Python3's input(), not to mention the age old ramblings
> about classic classes versus new classes. And as much as
> we'd all like for these confusions to go away, they won't,
> because there is no way to "clean" the internet of every
> Python2 tutorial, blog or website that mentions these bygone
> features.
> 
> The stain of Python3's violent and radical changes to the
> core philosophy of the language may never be washed clean,
> and although we might have survived Python3 _eventually_,
> type-hints is like a wooden stake driven into the heart of
> this community. It's almost like they _want_ to destroy this
> language.

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

Re: [Tutor] beginning to code

On Sunday, September 10, 2017 at 1:14:40 PM UTC-5, leam hall wrote:
> I will add my +1 to the careful editing of code. Python's
> use of white space is pretty good once you get used to it.

Python's mandate that all blocks must use whitespace is by
far my favorite feature. A clean code structure is very
important to me, but consistency is most important of all.

> My Ruby code looks a lot like my Python code.  :)

Nothing wrong with that! Ruby adopts the "Tim Toady"[1]
approach to coding, as opposed to Python's loosely followed:
"There should be one-- and preferably only one --obvious way
to do it."  And while your Ruby code may look similar to
your Python code, if you examine random Ruby scripts in the
wild, you will find a wide variety of structures and
multiple forms of doing the same thing that on superficial
examination, at least, may not be readily apparent. For
instance, in Python, there is only one way to write a "for
loop":

for var on iterable:
# do something

However, Ruby allows multiple forms, the first of which
almost exactly mimics Python syntax (except for the `end`
keyword and the mising colon):

for var in iterable 
# do something
end

But Ruby offers a second form using a method of the
"iterable object", with the block denoted by 'do' and `end`
keywords:

iterable.each do |var|
# do something
end

And futhermore, Ruby offers a third form using a method of
the "iterable object" (as before), except, this time, using
braces to denote the block:

iterable.each{|var|
# do something
}

Whew! Now how's that for a meet and greet with Tim Toady? As for
me, when i write a "for loop" in Ruby, i choose the second
form, because:

(1) I won't use braces to denote my blocks unless i can
write the entire construct on a single line, as in:

iterable.each{|var| # do something} 

(2) When i use the first form (you know, the one that
resembles Python code), i sometimes become confused and
forget that i'm writing Ruby code altogether, and then i get
slammed with syntax errors later. Most of the time, it's
because i instinctively placed a colon at the end of the
first line of a "for loop" structure -- Damn you Python! :-)

At one point, i became so sick of repeating this simple
mistake, i was forced to write a script that would search
for misplaced colons and hilight them for me, which
unsurprisingly, greatly increased my workflow!

Ruby is a neat language, and while Python will probably
always be my favorite little scripting language, Ruby has
some advantages over Python. 

 EXAMPLE 1:

Firstly, method chaining in Ruby follows a naturally
intuitive left-to-right progression. Consider a contrived
example where we have an array of floats, and we need to
determine how many unique integers can be derived from
these floats.

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

Holy Buhjeebus! Was that Lisp or Python code? o_O 

Obviously Ruby is superior in this test, as the python code
is nothing but an unintuitive and nested mess. "Flat is
better than nested"...

 EXAMPLE 2:

(oops, looks like i'm being cut short. I'll get back to this
Pepsi challenge ASAP. So stay tuned...)

[1] https://en.wikipedia.org/wiki/There%27s_more_than_one_way_to_do_it
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [Tutor] beginning to code

On Mon, Sep 11, 2017 at 11:29 AM, 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.

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

Re: Using Python 2

2017-09-10 Thread Michael Torrie

On 09/10/2017 09:20 AM, Marko Rauhamaa wrote:
> Been there. I'm afraid this is not a joke:
> 
>   https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition>

Wow that's pretty amazing!  Thanks for sharing that link.

> Python, COBOL for the next generation.

I guess we'll have to see. COBOL did pretty well for a long time.

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

Re: Design: method in class or general function?

2017-09-10 Thread Michael Torrie

On 09/10/2017 06:16 PM, Leam Hall wrote:
> The Career seems to be a "Decorator" pattern given my limited 
> understanding of design patterns. Concur? If so I'll go study that some 
> more.

A career seems to be something one "has."  So a classic "has a"
characteristic, which means it should be an attribute of an instance,
rather than involved in inheritance of the class itself.

> Do you feel this path should still make a Career a class?

Career certainly could be a class, instances of which can be stored in a
character's instance as attributes?  Not having read the whole thread,
it seems like yes, making Career a class would allow you flexibility to
implement the multiple careers per character easily.

A particular career is definite the "is a" relationship (a professional
programming career is a career), which means inheritance can work for it.

I could be wrong, though!
-- 
https://mail.python.org/mailman/listinfo/python-list

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

2017-09-10 Thread Steve D'Aprano

On Mon, 11 Sep 2017 12:46 am, Rick Johnson wrote:

> if we consider the damage that small changes
> (like the print statement versus print function and
> raw_input versus input) have caused


The word for negative damage is "improvement".



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

2017-09-10 Thread Steve D'Aprano

On Mon, 11 Sep 2017 03:14 am, Marko Rauhamaa wrote:

> Dennis Lee Bieber :
> 
>> In contrast, every sample I've seen of the async library comes
>> across as "magic happens here -- at some point in time".
> 
> That magic can be learned, in principle. I'm afraid few programmers will
> be willing/able to get over the hump, and there are a number of tricky
> aspects to be extra careful about.

The huge popularity of asynchronous routines in the Javascript and Node.JS
community is evidence that it won't be "few programmers" but a whole lot of
them.



-- 
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 in Perspective

2017-09-10 Thread Rustom Mody

On Monday, September 11, 2017 at 3:08:51 AM UTC+5:30, bream...@gmail.com wrote:
> On Sunday, September 10, 2017 at 11:21:26 AM UTC+1, Leam Hall wrote:
> > y'all,
> > 
> > My god-kids and their proginators lost most everything because of 
> > Harvey. I spent much of yesterday worrying about a friend who had gone 
> > quiet as he evacuated his family ahead of Irma.
> > 
> > Please keep Python in perspective. Whether we use 1.5 or 4rc1 is a lot 
> > less critical than using Python to work together well and solving big 
> > problems as friends.
> > 
> > In years gone by I spent time on the soapbox but never came away cleaner 
> > or with stronger friendships. I just ranted and spent years wondering 
> > why nothing actually changed. Please don't make my mistake; come up with 
> > your own.
> > 
> > Together. As friends.
> > 
> > Leam
> 
> What do you have to say about the people who die every year in the monsoon, 
> as they are dying right now, as opposed to the occasional hurricane that hits 
> the richest nation in the world?  Will Trump the Chump cure all the worlds 
> ills, or is he too busy looking after his highly paid mates in the oil and 
> gas industries, who are actively paying for the education system in some US 
> states to the detriment of facts, as in there is no man made global warming?

Dont know whether to laugh or to weep
http://time.com/4935117/hurricane-irma-guns-florida/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [Tutor] beginning to code

2017-09-10 Thread Steve D'Aprano

On Mon, 11 Sep 2017 04:14 am, leam hall wrote:

> I will add my +1 to the careful editing of code. Python's use of white
> space is pretty good once you get used to it. My Ruby code looks a lot like
> my Python code.  :)

I believe you've replied to the wrong list. I think you meant to reply to the
Tutor list.



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