from:"Christopher"


On 5/20/2016 7:31 PM, Chris Angelico wrote:


On Sat, May 21, 2016 at 11:23 AM, Christopher Reimer
 wrote:

On 5/20/2016 3:43 PM, Steven D'Aprano wrote:


But the idea that you should avoid a Python feature while programming in
Python because Javascript doesn't have it, or Ruby, or C, is surely the
height of muddleheaded thinking. You're not programming Javascript, Ruby
or
C, you're programming in Python. The whole point of picking one language
over another is to get access to the tools and features that language
offers. Otherwise you're just wasting your time.


For many years I have resisted specializing in a programming language, as I
can easily write any program in pseudo code and figure out the syntax for a
particular language. Now it does help that most languages have derived from
C and share a common feature set (i.e., string, integer, float, if/else,
while, for, etc.). From my perspective, tacking on an else block to the end
of a for or while loop looks like a bug or a not very well thought out
feature. If I was translating a Python program with for/else or while/else
statements into a different language, those statements will have to be
rewritten anyway.

That's fine, as long as you (a) restrict your programming languages to
those derived from C, and (b) restrict your programming style to the
common subset of them all. Trouble is, that "common subset" is
actually pretty small. Strings behave very differently in C and high
level languages, and for loops are *very* different in different
languages. So you'd be throwing out a large amount of expressiveness,
plus you're completely unable to use languages built on some other
model (eg LISP, or DeScribe Macro Language, or APL).


I don't have a problem with (a) because the majority of the programming 
languages I've been exposed to have derived from the C language. No 
offense to the LISPers, but LISP is a historical curiosity that I might 
blow the dust off and take a look at someday. I'll probably learn 
assembly language before I ever look at LISP. :)


But I disagree with (b) on restricting myself to a common subset of ALL 
the programming languages. Pseudo code allows me to describe a program 
in very general details. Implementing a program in a programming 
language requires getting into very specific details. Of course, there 
are major and minor differences from language to language. If an oddball 
feature gets the job done, I'll use that. Or maybe not. If I'm uncertain 
about something, I'll keep going back and forth until I'm satisfied one 
way or another.


The else block tacked on to for and while loops in Python seems very 
oddball-ish to me. I've always strive to follow best practice whenever 
possible. The one book I've read -- and so far, the only book on that 
feature -- recommends not using it. Based on my previous experience, I 
don't disagree with that author's opinion. If I have a compelling reason 
to use it, I'll use it. Or I'll simplify it to use helper functions.


If I wanted to write portable code, I would have stayed with... Java. O_o

Thank you,

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

Re: for / while else doesn't make sense


On 5/20/2016 3:43 PM, Steven D'Aprano wrote:


But the idea that you should avoid a Python feature while programming in
Python because Javascript doesn't have it, or Ruby, or C, is surely the
height of muddleheaded thinking. You're not programming Javascript, Ruby or
C, you're programming in Python. The whole point of picking one language
over another is to get access to the tools and features that language
offers. Otherwise you're just wasting your time.


For many years I have resisted specializing in a programming language, 
as I can easily write any program in pseudo code and figure out the 
syntax for a particular language. Now it does help that most languages 
have derived from C and share a common feature set (i.e., string, 
integer, float, if/else, while, for, etc.). From my perspective, tacking 
on an else block to the end of a for or while loop looks like a bug or a 
not very well thought out feature. If I was translating a Python program 
with for/else or while/else statements into a different language, those 
statements will have to be rewritten anyway.


Thank you,

Chris R.


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

Re: for / while else doesn't make sense


On 5/20/2016 8:59 AM, Zachary Ware wrote:


On Fri, May 20, 2016 at 3:09 AM, Erik  wrote:

On 20/05/16 00:51, Gregory Ewing wrote:

It's not so bad with "else" because you need to look back
to find out what condition the "else" refers to anyway.


With my tongue only slightly in my cheek, if it was desirable to
"fix"/clarify this syntax then I would suggest adding some optional
(existing) trailing keywords to 'else' in this context that spells it out:

for item in seq:
 if foo(item):
 break
else if not break:
 nomatch()

With tongue firmly cheeked, you can always use the special `:#` operator:

for item in seq:
if foo(item):
break
else:# if no break:
nomatch()

This has the benefit that you can use whatever syntax you like after
the `:#`, and use it in any version of Python you want.


According to "Effective Python: 59 Specific Ways to Write Better Python" 
by Brett Slatkin, Item 12 recommends against using the else block after 
for and while loops (see page 25): "Avoid using else blocks after loops 
because their behavior isn't intuitive and can be confusing."


Until I read the book, I wasn't aware of this feature (or bug). Doesn't 
seem like a feature I would use since it's not commonly found in other 
programming languages. As the author demonstrates in his book, I would 
probably write a helper function instead.


Item 13 does recommend using the else block for try/except/else/finally 
in exception handling. :)


Thank you,

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

Re: How do I subclass the @property setter method?


On 5/20/2016 11:50 AM, Christopher Reimer wrote:


This code does work, blows up the unit test, and keeps PyCharm happy.

@property
def position(self):
return super().position

@position.setter
def position(self, position):
pass

Re-declaring @property and calling super seems redundant.  Not sure if 
I found a bug with the PyCharm hint feature or I'm not subclassing the 
@property setter correctly. Which is it?


Never mind. This is a known bug for PyCharm IDE.

https://youtrack.jetbrains.com/issue/PY-12803

I sent a separate email to technical support to inquire if this bug and 
similar bugs will ever get fixed. This issue was initially reported 
three years ago. Not sure if I should post my own bug report.


Thank you,

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

How do I subclass the @property setter method?


Greetings,

My chess engine has a Piece class with the following methods that use 
the @property decorator to read and write the position value.


@property
def position(self):
return self._position

@position.setter
def position(self, position):
if self._first_move:
self._first_move = False
self._position = position

Blank is a subclass of the Piece class that represents an empty space on 
the board and  is a placeholder in the Board class _state dict. Since 
Blank is a placeholder and not a playable game piece, I want to make 
@position.setter non-operational (i.e, make no changes to the position 
value).


@Piece.position.setter
def position(self, position):
pass

This code works and the corresponding unit test blows up because I 
haven't changed it yet, but the PyCharm IDE complains that the 
Blank.position signature doesn't match the Piece.position signature. 
Never mind that I copy and paste the identical declaration from the 
Piece class.


This code does work, blows up the unit test, and keeps PyCharm happy.

@property
def position(self):
return super().position

@position.setter
def position(self, position):
pass

Re-declaring @property and calling super seems redundant.  Not sure if I 
found a bug with the PyCharm hint feature or I'm not subclassing the 
@property setter correctly. Which is it?


Thank you,

Chris R.

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

Re: Python PygLatin


On 5/8/2016 10:53 AM, alister wrote:

On Mon, 09 May 2016 03:12:14 +1000, Steven D'Aprano wrote:


On Sun, 8 May 2016 08:21 pm, Cai Gengyang wrote:


If one looks at the Forbes List, you will see that there are 4
programmers amongst the top ten richest people in the world (Bill
Gates, Mark Zuckerberg, Larry Ellison and Jeff Bezos) , a very large
percentage. Science and Technology is in a sense the most egalitarian
field in the world, because it involves using your brains and
creativity. You don't need to have a father who is a director at
Goldman Sachs or a mother who is the admissions officer at Harvard to
succeed in this line.

Bill Gates III's father was a prominent lawyer, his mother was on the
board of directors for First Interstate BancSystem and United Way, and
one of his grandfathers was a national bank president. Gates himself
went to Harvard.

Zuckerberg's paternal grandparents were successful middle class,
described as  being the first on the block to own a colour TV. (This was
back in the days when colour TVs were an expensive toy that few could
afford.) His parents were also very successful professionals: a dentist
and a psychiatrist. And he too went to Harvard. Despite the jeans and
tee-shirts Zuckerberg is known for wearing, he's firmly from the
professional/upper class.

Bezos comes from a family of land-holders from Texas. His grandfather
was regional director of the U.S. Atomic Energy Commission, and was
financially successful enough to retire at an early age. He didn't go to
Harvard, but he did go to Princeton.

Ellison is the son of an unwed mother who gave him up for adoption by
her aunt and uncle, comfortably middle-class. That makes him the closest
out of the group as a "regular guy".

And at least 2 of the above reached their position using business
practices that could be described as less than 100% honorable & above
board.


What do you expect from people who haven't graduated from Harvard? :P

Thank you,

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

Re: Python is an Equal Opportunity Programming Language


On 5/8/2016 9:27 AM, Steven D'Aprano wrote:

On Sun, 8 May 2016 08:22 pm, beliav...@aol.com wrote:


There are
far more female than male teachers. I don't attribute it to anti-male
suppression but to greater female interest in working with children.

Of course there is suppression of male teachers, particularly but not only
for very young children.


A college instructor encouraged me to become a teacher,  especially as 
boys from single mom families needed a daily role model. I looked into 
it and took some preparatory childhood classes. When the local 
university had a presentation for their teacher program, I went, saw how 
sausage got made, and ran like hell.


Thank you,

Chris R.

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

Re: Python is an Equal Opportunity Programming Language


On 5/8/2016 8:09 AM, Rustom Mody wrote:

See:
https://www.washingtonpost.com/news/rampage/wp/2016/05/07/ivy-league-economist-interrogated-for-doing-math-on-american-airlines-flight/

Closing line: "In America today, the only thing more terrifying than foreigners 
is...math."


Wonder how close to terrorists pythonists are


I wonder how many Americans are aware that they use Hindu-Arabic 
numerals in daily transactions?


https://en.wikipedia.org/wiki/Hindu%E2%80%93Arabic_numeral_system

Thank you,

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

Re: Python is an Equal Opportunity Programming Language


On 5/7/2016 11:58 PM, Marko Rauhamaa wrote:

Chris Angelico :


So the question is: Do we care about country equality or individual
equality? You can't have both.

That's why there's been a long-standing initiative to split California
into multiple states:

   https://en.wikipedia.org/wiki/Six_Californias>

Each state gets two senate seats, and California, being the most
populous state, suffers.


The Six Californias is a proposal to divide up the 54 electoral votes 
that California has in presidential elections, which is a solidly blue 
state for the Democrats. Half the population lives in the Los Angeles, 
San Francisco and Sacramento regions. Put these three regions into 
separate states, the other three regions will become solidly red states 
for the Republicans and tilt the presidential elections in their favor. 
The proposal is a solution for the underlying problem that the 
California Republican Party has more in common with the endangered 
spotted owl than one-tenth of the US population. It's easier to redraw 
the lines than compete for votes.


Thank you,

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

Re: Pylint prefers list comprehension over filter...

On 5/8/2016 5:02 AM, Steven D'Aprano wrote:

On Sun, 8 May 2016 08:01 am, Christopher Reimer wrote:

On 5/7/2016 2:22 PM, Chris Angelico wrote:

Also, be sure you read this part of PEP 8:

https://www.python.org/dev/peps/pep-0008/#a-foolish-consistency-is-the-hobgoblin-of-little-minds

Recruiters and hiring managers *are* hobgoblins with with little minds.
And definitely not PEP8-complaint. :)

Do you think that recruiters and hiring managers read your code at all, let
alone that they read it will an eye to PEP 8 compliance?

I meant more than a few technical professionals who got pushed out of
the job to become recruiters. They tend to ask about everything on the
resume to poke holes where they can. Each time I tightened the wording
of my resume whenever they exposed something. If I posted a GitHub link
on my resume, they *would* check it out. If they know Python, they
*would* run it.

As for PEP 8 compliance, it was a joke (see the smiley). Laugh, it was
funny.

No recruiter[1] will do this. No recruiter will even know what PEP 8 is.
They're looking for technical buzzwords ("ten years experience with
Django"), they aren't qualified to judge whether your Django code is good,
bad or indifferent. That's up to the client.

When I used to apply to Linux system admin jobs, the recruiters would
have a checklist box for the "Red Hat GUI Thing" as an absolute
requirement. My Linux work experience was exclusively remote command
line. On the rare occasions that I have used the Linux GUI, I always
used what got installed as the default GUI for Fedora or Mint.

The first time I said I didn't know what the "Red Hat GUI Thing" was and
explained that I was fast learner, the recruiter hung up on me. I tried
to argue with other recruiters that I knew the command line equivalent
for the GUI. No dice. Some recruiters even accused me of making up
techno-babble. They all hung up on me. After a dozen phone calls like
that (all for positions at different companies), I generally stopped
applying to Linux jobs.

This year I built an inexpensive PC to run Linux and installed the
current Red Hat Linux. Guess what? The "Red Hat GUI Thing" wasn't
installed. In fact, the GUI was Gnome by default. According to my
coworkers, Red Hat started phasing out their own branded GUI several
years ago. I guess the recruiters haven't gotten the memo yet, as I had
a phone call about the "Red Hat GUI Thing" last year.

A hiring manager with a technical background might, once you are in
consideration for the job. More likely they will delegate any judgement to
a technical manager, or programmer, who may or may not be a hobgoblin with
a little mind.

Every hiring manager I've ever interviewed with had a technical
background. The only exception was when the final interview was with the
marketing director at hardware company. I declined to take the job. If
you know your Dilbert, it's bad luck when a hardware company is run by
the marketing department. I wasn't surprised that the company filed
bankruptcy a few years later.

Thank you,

Chris R.

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

Re: Pylint prefers list comprehension over filter...


On 5/7/2016 6:40 PM, Terry Reedy wrote:

On 5/7/2016 3:17 PM, Christopher Reimer wrote:


For my purposes, I'm using the list comprehension over filter to keep
pylint happy.


How sad.  The pylint developers arrogantly take it on themselves to
revise Python, against the wishes of Guido and the other core
developers, and you and feel obligated to follow them.

They should at least add a disclaimer "Using the default options, pylint
checks that your code complies with the pylint-approved subset of Python."


I wasn't aware that I was picking sides in a religious war by altering 
one line of code. O_o


Thank you,

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

Re: Pylint prefers list comprehension over filter...


On 5/7/2016 1:31 PM, Marko Rauhamaa wrote:

Christopher Reimer :

Never know when an asshat hiring manager would reject my resume out of
hand because my code fell short with pylint.

Remember that it's not only the company checking you out but also you
checking the company out.

Would you want to work for an asshat hiring manager?

Of course, you might not have the luxury of being picky.


Most asshat managers I've dealt with often say to me, "Here's a mole 
hole, go fix it." I look at the mole hole (little problem), look at the 
mountain (big problem) in the distant, and jump over the mole hole to 
start climbing the mountain. After I reduce the mountain to a mole hole, 
the asshat manager gets promoted and I'm looking for a job again.


Thank you,

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

Re: Pylint prefers list comprehension over filter...

On 5/7/2016 2:22 PM, Chris Angelico wrote:

On Sun, May 8, 2016 at 5:17 AM, Christopher Reimer
wrote:
Since the code I'm working on is resume fodder (i.e., "Yes, I code in
Python! Check out my chess engine code on GitHub!"), I want it to be
as Pythonic and PEP8-compliant as possible. That includes scoring
10/10 with pylint. Never know when an asshat hiring manager would
reject my resume out of hand because my code fell short with pylint.
For my purposes, I'm using the list comprehension over filter to keep
pylint happy.

Wrong thinking. Make it Pythonic - but don't concern yourself with
pylint's final score. Read pylint's output and learn from it, but
don't treat a 10/10 score as the ultimate in ratings, because it just
isn't.

I agree with that in principle. But...

Also, be sure you read this part of PEP 8:

https://www.python.org/dev/peps/pep-0008/#a-foolish-consistency-is-the-hobgoblin-of-little-minds
Recruiters and hiring managers *are* hobgoblins with with little minds.
And definitely not PEP8-complaint. :)

When I was out of work for two years (2009-10), underemployed for six
months (working 20 hours per month), and filed for Chapter Seven
bankruptcy in 2011, I only had 20 job interviews during that time. That
was a learning experience. I did everything possible to present myself
and my resume as perfectly as possible. When I had another bout of
unemployment that lasted eight months (2013-14), I had 60 job interviews
and three job offers to pick from at the end. Of course, that was for IT
support contracts. Maybe programming jobs will have fewer hobgoblins.

Thank you,

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

Re: python chess engines


On 5/3/2016 10:13 PM, DFS wrote:

Wanted to start a new thread, rather than use the 'motivated' thread.

Can you play your game at the console?


Nope. Only displays the board on the console. An early version had the 
forward movement for pawns implemented.


The way I think about a chess engine is it doesn't even display a 
board.  It accepts a move as input, records the move, analyzes the 
positions after the move, and returns the next move.


My code has display and engine as separate classes with a main loop 
coordinating things between the two. The main loop requests the board 
state (dict) from the engine class and passes that to show board on the 
display class.



Here's the UCI protocol.
http://download.shredderchess.com/div/uci.zip


Very interesting. Something to add to my research notes. I'll muddle 
through with my code and let it grow organically for now.  If I decide 
to write a chess engine that implements the UCI protocol, I'll start 
over with a clean slate.


Thank you,

Chris R.

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

Re: pylint woes


On 5/7/2016 12:52 PM, Ray Cote wrote:


I’m impressed with 10/10.
My approach is to ensure flake8 (a combination of pyflakes and pep8
checking) does not report any warnings and then run pyLint as a final
check.


I just installed pyflakes and ran it against my 10/10 files. It's not 
complaining about anything. So I ran it against my unit tests that I'm 
still writing, haven't cleaned up and checked against pylint. I got 
dinged for using a star import on a file with a common variables, which 
was an easy fix.


Thank you,

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

Re: Pylint prefers list comprehension over filter...


On 5/5/2016 6:37 PM, Stephen Hansen wrote:

On Thu, May 5, 2016, at 06:26 PM, Christopher Reimer wrote:

Which is one is correct (Pythonic)? Or does it matter?

First, pylint is somewhat opinionated, and its default options shouldn't
be taken as gospel. There's no correct: filter is fine.


Since the code I'm working on is resume fodder (i.e., "Yes, I code in 
Python! Check out my chess engine code on GitHub!"), I want it to be as 
Pythonic and PEP8-compliant as possible. That includes scoring 10/10 
with pylint. Never know when an asshat hiring manager would reject my 
resume out of hand because my code fell short with pylint.


For my purposes, I'm using the list comprehension over filter to keep 
pylint happy.


Thank you,

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

Re: pylint woes


On 5/7/2016 12:23 PM, Stephen Hansen wrote:

On Sat, May 7, 2016, at 11:52 AM, Christopher Reimer wrote:

You can do better.  You should strive for 10/10 whenever possible,
figure out why you fall short and ask for help on the parts that don't
make sense.

I think this is giving far too much weight to pylint's opinion on what
is "good" or "bad" programming habits.


I forgot to add the warning, "Use pylint with a dash of salt on a lemon 
slice and a shot of tequila." :)


Thank you,

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

Re: Pylint prefers list comprehension over filter...


On 5/5/2016 7:57 PM, Stephen Hansen wrote:

On Thu, May 5, 2016, at 07:46 PM, Dan Sommers wrote:

On Thu, 05 May 2016 18:37:11 -0700, Stephen Hansen wrote:


 ''.join(x for x in string if x.isupper())
The difference is, both filter and your list comprehension *build a
list* which is not needed, and wasteful. The above skips building a
list, instead returning a generator ...

filter used to build a list, but now it doesn't (where "used to" means
Python 2.7 and "now" means Python 3.5; I'm too lazy to track down the
exact point(s) at which it changed):

Oh, didn't know that. Then again the OP was converting the output of
filter *into* a list, which wasted a list either way.


My line of code was something I copied off the Internet and modified it 
until it did I exactly what I wanted it to do. That means that the many 
Python 2 code examples available on the Internet are using a redundant 
list operation with Python 3. Isn't that a "smell" that pylint should 
pick up on?


Thank you,

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

Re: pylint woes