Re: Is it possible to get the Physical memory address of a variable in python?

[dieter]

Sourabh Kalal  writes:

> how we can access the value from using id..
> like x=10
> id(x)
> 3235346364
>
> how i can read value 10 using id 3235346364

You should not do this (read the value instead by looking at "x") --
unless you are debugging at "C" level. For "C" level debugging,
there is a set of "gdb" macros allowing you to display Python
objects giving their "C" level address.

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

Re: How coding in Python is bad for you

[BartC]

On 24/01/2017 04:41, Chris Angelico wrote:

On Tue, Jan 24, 2017 at 3:22 PM, Steven D'Aprano
 wrote:

But more seriously, it's easy to typo an extra indent. It's harder to typo
"endif" when you actually meant to type, oh, "ending = 1 if condition else 3",
say. So faced with ambiguity, and the insistence that the right way to break
ambiguity is to guess ("Do What I Mean, dammit!!!") the most likely guess is
that the indentation is wrong.

But not guaranteed. That's the thing about being ambiguous -- there is a chance
that the indentation is correct.


Indeed. I teach JavaScript as well as Python, and I've seen some
pretty horrendous indentation flaws (examples available if people ask
privately, but I will anonymize them because I'm not here to shame
students) - but there have been nearly as many cases where the
indentation's fine and the bracket nesting isn't. I probably sound
like a broken record [1] with the number of times I've said "check
your indentation", as a hint to where the missed-out close brace or
parenthesis is. True, with "endif" it's a bit harder to typo, but it's
still just as easy to make a copy-and-paste error and end up with code
like this:

if condition:
statement
endif
statement
endif

What's this code meant to do? Can't know.


But whatever it does, a language that enforces 'endif' would report an 
error, so requiring further investigation. Without the 'endifs', it 
would look like this:


 if condition:
 statement
 statement

Legal python.

Presumably you don't like parentheses in function calls for the same 
reasons; you'd prefer 'f a,b,c' rather than 'f(a,b,c)' in case, with 
copy&paste, someone might end up with: 'f(a,b,c),d)'.


Having 'f a,b,c,d' is better; much less chance of those pesky syntax errors!


Remember: If you have only one clock, it might be right and it might
be wrong, but it's consistent. If you have two clocks and they
disagree, you have no clue what the time is.


I've actually got three wall clocks. Usually only one will disagree with 
the other two, meaning it needs a new battery. But don't they use such 
systems in avionics?


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

Re: How coding in Python is bad for you

[Chris Angelico]

On Tue, Jan 24, 2017 at 10:52 PM, BartC  wrote:
>> Remember: If you have only one clock, it might be right and it might
>> be wrong, but it's consistent. If you have two clocks and they
>> disagree, you have no clue what the time is.
>
>
> I've actually got three wall clocks. Usually only one will disagree with the
> other two, meaning it needs a new battery. But don't they use such systems
> in avionics?

See what Steve said about 1 or 3 but never 2. Triple redundancy gives
you a chance to figure out that two of them agree.

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

Re: How coding in Python is bad for you

[BartC]

On 24/01/2017 04:22, Steven D'Aprano wrote:

On Tuesday 24 January 2017 13:38, Chris Angelico wrote:

On Tue, Jan 24, 2017 at 12:47 PM, BartC  wrote:



if 0 then
print ("one")
print ("two")
endif



My point is that you *assume* that showing just "three" is the correct
behaviour. Why? Why do you automatically assume that the indentation
is wrong and the endif is correct? All you have is that the two
disagree.


It's Bart's special language, so the correct behaviour is whatever he says it
is :-)


I chose 'if...endif' above because it's used in a number of well-known 
languages. (Including PHP I think, while others use 'end if' or just 
'end'. In my own language I prefer 'if...fi')




This *especially* applies to languages like C, when open/close delimiters
optional if the block is only a single statement, and where the delimiters are
only a single character.

And sure enough, C is prone to indent/brace mismatch errors.


I didn't use brace syntax in the example for that reason. C has plenty 
of its own problems. Although funnily enough, its preprocessor language 
uses '#if...#endif'; much more sensible!


C suffers also from the 'dangling else' problem, which a 'if...endif' 
syntax doesn't.


Nor does Python's scheme, as the 'else' /has/ to be aligned with the 
corresponding 'if' or 'elif'. However... take this code:


  if a:
  b
  if c:
  d

You want to import an 'else' block from elsewhere to add to that nested if:

  if a:
  b
  if c:
  d
  else:
  e

The trouble is, that other code was not nested; it will need extra 
indentation here. Until that happens however, the above is still legal.


--
Bartc

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

Re: How coding in Python is bad for you

[BartC]

On 24/01/2017 11:58, Chris Angelico wrote:

On Tue, Jan 24, 2017 at 10:52 PM, BartC  wrote:

Remember: If you have only one clock, it might be right and it might
be wrong, but it's consistent. If you have two clocks and they
disagree, you have no clue what the time is.



I've actually got three wall clocks. Usually only one will disagree with the
other two, meaning it needs a new battery. But don't they use such systems
in avionics?


See what Steve said about 1 or 3 but never 2. Triple redundancy gives
you a chance to figure out that two of them agree.


But even with two clocks you will know something is amiss if they don't 
agree, and will seek confirmation from a third. With one clock you can't 
be sure, and could end up missing your flight or whatever.


(Of course, when the clocks go forward in the spring, all the (cheap, 
non-automatic) clocks in my house will show the same incorrect time!)


--
Bartc



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

Re: How coding in Python is bad for you

[Skip Montanaro]

I have nothing to add to the discussion other than too note that Gmail
marks many of the messages as spam. :-)

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

Re: How coding in Python is bad for you

[MRAB]

On 2017-01-24 12:12, BartC wrote:

On 24/01/2017 04:22, Steven D'Aprano wrote:

On Tuesday 24 January 2017 13:38, Chris Angelico wrote:

On Tue, Jan 24, 2017 at 12:47 PM, BartC  wrote:



if 0 then
print ("one")
print ("two")
endif



My point is that you *assume* that showing just "three" is the correct
behaviour. Why? Why do you automatically assume that the indentation
is wrong and the endif is correct? All you have is that the two
disagree.


It's Bart's special language, so the correct behaviour is whatever he says it
is :-)


I chose 'if...endif' above because it's used in a number of well-known
languages. (Including PHP I think, while others use 'end if' or just
'end'. In my own language I prefer 'if...fi')


[snip]

PHP lets you use if...endif or braces.

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

Re: PhotoImage.paste

[MRAB]

On 2017-01-24 07:09, rryan@gmail.com wrote:

I'm trying to build a tkinter GUI with python 3.5, and would like to 
interactively adjust the color palette for an image by moving the mouse in the 
canvas using PIL.  In pseudo-code, I have something like

palette=color_map(x,y)   # x,y are scalars indicating the position of the mouse 
in the Canvas
image.putpalette(palette)
photo.paste(image)

This works just fine, but is very slow.  The photo.paste(image) step takes 
about 0.15 s (using an image that is 4k x 4k).  I read the manual on effbot, 
and they caution that the paste method would be slow if the image is display 
--- and I'm guessing that's what I'm doing.  So my question is, what 
alternatives do I have to speed that step up.

Thank you for any thoughts you might have...
-Russell


How often are you pasting?

Are you pasting whenever the mouse moves, even a little?

If that's the case, try using the .after method to paste only 
occasionally, and then only if the mouse has moved since the last time.


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

Re: How coding in Python is bad for you

[alister]

On Tue, 24 Jan 2017 08:11:02 +1100, Chris Angelico wrote:

> On Tue, Jan 24, 2017 at 8:04 AM, Adam M 
> wrote:
>> On Monday, January 23, 2017 at 3:41:17 PM UTC-5, Jon Ribbens wrote:
>>> On 2017-01-23, alister  wrote:
>>> > On Tue, 24 Jan 2017 07:19:42 +1100, Chris Angelico wrote:
>>> >> I believe that's "bad for you" in the sense that chocolate is bad
>>> >> for you.
>>> >>
>>> >> It isn't.
>>> >
>>> > chocolate is a poison (lethal dose for a human approx 22lb)
>>>
>>> That's a meaningless statement. *Everything* is a poison in sufficient
>>> quantities.
>>
>> I think you need to calibrate your sarcasm filter ;-). By the way
>> coffee  is also dangerous - especially in 50lbs bags (when it hits
>> you).
> 
> Or with sufficient velocity. The LD50 of lead is about 450mg/kg [1],
> which means that a typical 70kg human could ingest about 31 grams of
> lead and have a fifty-fifty chance of survival. But just a few grams of
> lead at the speed of sound will probably kill you. [2]

if you were to take the statistics of WWI or WWII (And probably any other 
major war & compare the number of rounds fired to the number of people 
killed by gunshot then you could say it probably wouldn't ;-)
(No I am not willing to put this to the test)

> 
> ChrisA
> 
> [1] http://whs.rocklinusd.org/documents/Science/Lethal_Dose_Table.pdf
> [2] https://xkcd.com/444/





-- 
Given a choice between grief and nothing, I'd choose grief.
-- William Faulkner
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How coding in Python is bad for you

[alister]

On Mon, 23 Jan 2017 20:39:26 +, Jon Ribbens wrote:

> On 2017-01-23, alister  wrote:
>> On Tue, 24 Jan 2017 07:19:42 +1100, Chris Angelico wrote:
>>> I believe that's "bad for you" in the sense that chocolate is bad for
>>> you.
>>> 
>>> It isn't.
>>
>> chocolate is a poison (lethal dose for a human approx 22lb)
> 
> That's a meaningless statement. *Everything* is a poison in sufficient
> quantities.

indees when I here someone saying "I won't have any xyz because they have 
heard that too much is bad for them" I invariably inform them that too 
much oxygen is poisonous & challenge then to cut that out completely :-)
.



-- 
Peace is much more precious than a piece of land... let there be no more 
wars.
-- Mohammed Anwar Sadat, 1918-1981
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How coding in Python is bad for you

[Jon Ribbens]

On 2017-01-24, alister  wrote:
> On Mon, 23 Jan 2017 20:39:26 +, Jon Ribbens wrote:
>> That's a meaningless statement. *Everything* is a poison in sufficient
>> quantities.
>
> indees when I here someone saying "I won't have any xyz because they have 
> heard that too much is bad for them" I invariably inform them that too 
> much oxygen is poisonous & challenge then to cut that out completely :-)

Just wait until they find out that raw fruit and vegetables contain
hundreds of chemicals!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PhotoImage.paste

[rryan . asu]

Hi MRAB

Yes, I am pasting every time the mouse moves (or every time the tk event 
handler gets called).  I thought about the after method, and I guess i can try 
to implement that.  It seems like that would help in the "jerkiness" of the 
GUI's response, but it leaves me kinda disappointed.  I obviously do not 
understand the inner workings of PIL or tk, but it seems kinda broken that it 
must take 0.2 sec to adjust a palette.  This GUI is a rewrite of a code I had 
in another language, and this palette modifying was much faster.  

I'll try the after method, hoping it'll at least make the GUI a bit more 
responsive.  

Thanks again!
Russell


On Tuesday, January 24, 2017 at 8:08:53 AM UTC-5, MRAB wrote:
> On 2017-01-24 07:09,@gmail.com wrote:
> > I'm trying to build a tkinter GUI with python 3.5, and would like to 
> > interactively adjust the color palette for an image by moving the mouse in 
> > the canvas using PIL.  In pseudo-code, I have something like
> >
> > palette=color_map(x,y)   # x,y are scalars indicating the position of the 
> > mouse in the Canvas
> > image.putpalette(palette)
> > photo.paste(image)
> >
> > This works just fine, but is very slow.  The photo.paste(image) step takes 
> > about 0.15 s (using an image that is 4k x 4k).  I read the manual on 
> > effbot, and they caution that the paste method would be slow if the image 
> > is display --- and I'm guessing that's what I'm doing.  So my question is, 
> > what alternatives do I have to speed that step up.
> >
> > Thank you for any thoughts you might have...
> > -Russell
> >
> How often are you pasting?
> 
> Are you pasting whenever the mouse moves, even a little?
> 
> If that's the case, try using the .after method to paste only 
> occasionally, and then only if the mouse has moved since the last time.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How coding in Python is bad for you

[Ben Bacarisse]

Chris Angelico  writes:

> ... I teach JavaScript as well as Python, and I've seen some
> pretty horrendous indentation flaws (examples available if people ask
> privately, but I will anonymize them because I'm not here to shame
> students) - but there have been nearly as many cases where the
> indentation's fine and the bracket nesting isn't.

Can I ask what editor(s) your students have available?  I ask because
I've not given a moment's thought to indentation or what bracket matches
what for decades due to having a helpful editor.


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

Re: How coding in Python is bad for you

[Chris Angelico]

On Wed, Jan 25, 2017 at 2:51 AM, Ben Bacarisse  wrote:
> Chris Angelico  writes:
> 
>> ... I teach JavaScript as well as Python, and I've seen some
>> pretty horrendous indentation flaws (examples available if people ask
>> privately, but I will anonymize them because I'm not here to shame
>> students) - but there have been nearly as many cases where the
>> indentation's fine and the bracket nesting isn't.
>
> Can I ask what editor(s) your students have available?  I ask because
> I've not given a moment's thought to indentation or what bracket matches
> what for decades due to having a helpful editor.
>

Quite a few, depending on which platform they're using. I'd say
Sublime is the most common choice.

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

Re: How coding in Python is bad for you

[alister]

On Tue, 24 Jan 2017 14:28:55 +, Jon Ribbens wrote:

> On 2017-01-24, alister  wrote:
>> On Mon, 23 Jan 2017 20:39:26 +, Jon Ribbens wrote:
>>> That's a meaningless statement. *Everything* is a poison in sufficient
>>> quantities.
>>
>> indees when I here someone saying "I won't have any xyz because they
>> have heard that too much is bad for them" I invariably inform them that
>> too much oxygen is poisonous & challenge then to cut that out
>> completely :-)
> 
> Just wait until they find out that raw fruit and vegetables contain
> hundreds of chemicals!

then send them of to one of the sitre relating to Di-Hydrogen Monoxide...

I know of one organic food producer that has even tried to deny the use 
the stuff ;-)



-- 
AP/STT.  Helsinki, Dec 5th, 6:22 AM.  For immediate release.

In order to allay fears about the continuity of the Linux project, Linus
Torvalds together with his manager Tove Monni have released "Linus
v2.0", affectionately known as "Kernel Hacker - The Next Generation".

Linux stock prices on Wall Street rose sharply after the announcement;
as one well-known analyst who wishes to remain anonymous says - "It
shows a long-term commitment, and while we expect a short-term decrease
in productivity, we feel that this solidifies the development in the
long run".

Other analysts downplay the importance of the event, and claim that just
about anybody could have done it.  "I'm glad somebody finally told them
about the birds and the bees" one sceptic comments cryptically.  But
even the skeptics agree that it is an interesting turn of events.

Others bring up other issues with the new version - "I'm especially
intrigued by the fact that the new version is female, and look forward
to seeing what the impact of that will be on future development.  Will
"Red Hat Linux" change to "Pink Hat Linux", for example?"
-- Linus Torvalds announcing that he became father of a girl
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How coding in Python is bad for you

[Ben Bacarisse]

Chris Angelico  writes:

> On Wed, Jan 25, 2017 at 2:51 AM, Ben Bacarisse  wrote:
>> Chris Angelico  writes:
>> 
>>> ... I teach JavaScript as well as Python, and I've seen some
>>> pretty horrendous indentation flaws (examples available if people ask
>>> privately, but I will anonymize them because I'm not here to shame
>>> students) - but there have been nearly as many cases where the
>>> indentation's fine and the bracket nesting isn't.
>>
>> Can I ask what editor(s) your students have available?  I ask because
>> I've not given a moment's thought to indentation or what bracket matches
>> what for decades due to having a helpful editor.
>>
>
> Quite a few, depending on which platform they're using. I'd say
> Sublime is the most common choice.

So what's going in your opinion?  The errors are in the group who don't
use the right tools or what?

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

Re: How coding in Python is bad for you

[BartC]

On 24/01/2017 15:51, Ben Bacarisse wrote:

Chris Angelico  writes:


... I teach JavaScript as well as Python, and I've seen some
pretty horrendous indentation flaws (examples available if people ask
privately, but I will anonymize them because I'm not here to shame
students) - but there have been nearly as many cases where the
indentation's fine and the bracket nesting isn't.


Can I ask what editor(s) your students have available?  I ask because
I've not given a moment's thought to indentation or what bracket matches
what for decades due to having a helpful editor.


How would your editor detect the error in the example I gave earlier?

(Where a tab has been inadvertently removed - or added - but the result 
is still valid Python code.)


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

Re: How coding in Python is bad for you

[Steve D'Aprano]

On Wed, 25 Jan 2017 03:21 am, Ben Bacarisse wrote:

> Chris Angelico  writes:
> 
>> On Wed, Jan 25, 2017 at 2:51 AM, Ben Bacarisse 
>> wrote:
[...]
>>> Can I ask what editor(s) your students have available?  I ask because
>>> I've not given a moment's thought to indentation or what bracket matches
>>> what for decades due to having a helpful editor.
>>>
>>
>> Quite a few, depending on which platform they're using. I'd say
>> Sublime is the most common choice.
> 
> So what's going in your opinion?  The errors are in the group who don't
> use the right tools or what?


If braces can be inserted automatically by the compiler, then they are
useless and should be left out of the language.



-- 
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: How coding in Python is bad for you

[Grant Edwards]

On 2017-01-24, Chris Angelico  wrote:

> No no no. You have two orthogonal styles (indentation and tokens), but
> then you added another of the same style (another pair of tokens). You
> need a third orthogonal style. I suggest that each nesting level be
> heralded by an increase in indentation, an open brace, and a new text
> colour.

Bravo!

Actually, some news/mail readers pretty much do that with quote
levels, and it works pretty well.  Assuming you're not color blind,
don't care about hardcopy on monochrome printers, don't care about
screenreaders, don't use monochrome monitors, etc.

-- 
Grant Edwards   grant.b.edwardsYow! I want the presidency
  at   so bad I can already taste
  gmail.comthe hors d'oeuvres.

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

Re: PhotoImage.paste

[Peter Otten]

rryan@gmail.com wrote:

> I'm trying to build a tkinter GUI with python 3.5, and would like to
> interactively adjust the color palette for an image by moving the mouse in
> the canvas using PIL.  In pseudo-code, I have something like
> 
> palette=color_map(x,y)   # x,y are scalars indicating the position of the
> mouse in the Canvas image.putpalette(palette)
> photo.paste(image)
> 
> This works just fine, but is very slow.  The photo.paste(image) step takes
> about 0.15 s (using an image that is 4k x 4k).  I read the manual on
> effbot, and they caution that the paste method would be slow if the image
> is display --- and I'm guessing that's what I'm doing.

So you have read

"""
Note: Pasting into an RGBA image that is displayed is a very slow operation. 
It’s usually better to create a new image object.
"""

on .

> So my question is, what alternatives do I have to speed that step up.

Did you try to create a new image, as the note suggests?

> Thank you for any thoughts you might have...
> -Russell


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

Re: How coding in Python is bad for you

[Steve D'Aprano]

On Tue, 24 Jan 2017 10:52 pm, BartC wrote:

>> if condition:
>> statement
>> endif
>> statement
>> endif
>>
>> What's this code meant to do? Can't know.
> 
> But whatever it does, a language that enforces 'endif' would report an
> error, so requiring further investigation. Without the 'endifs', it
> would look like this:
> 
> if condition:
> statement
> statement
> 
> Legal python.

Indeed. And 99.99% of the time it is correct Python as well.

I suspect that the use of redundant braces or end delimiters has something
to do with attitudes to risk. Or even, dare I say it, with confidence in
your own programming skill.

If (generic) you are risk adverse, or have low confidence in your ability,
then you might want all the help you can get from the compiler and insist
on having end delimiter for blocks. Think about how rare it is that it will
really matter: 

- you're editing an if block;
- and you do something that changes the block structure;
- but you do it wrong;
- and the failure is something which is still syntactically legal;
- but you don't notice;
- and the failure isn't instantly picked up by your tests;
- or you don't have tests which exercise that part of the code.

That's fairly unusually. How often does it happen? If you're a beginner, or
programming while high/drunk/sick/distracted, it might happen a lot. (I've
seen programmers who are seemingly incapable of writing `y = x + 1` without
six syntax errors and two logic errors.) But, I think, the average
half-decent coder should find that this isn't really a problem more than,
oh, once or twice a year. Or less.

By "a problem" I mean either a bug sneaks through into production, or they
find the bug but it takes more than an hour's debugging.

So if you're risk adverse, you're thinking about that wasted hour, or the
possibility of a bug sneaking into production code. (As if they don't
already, B&D compilers or not.)

But if you're more tolerant of risk (at least when it comes to coding), or
have more confidence in your ability, you might think:

- these bugs are rare;
- an hour isn't a long time to spend debugging;
- besides it probably won't be an hour;
- it's more likely to be five minutes with a debugger;
- and what's the worst that can happen? this isn't a nuclear power plant, 
  we'll fix the bug in the next release.

It's not that we don't see the benefit of those braces or end delimiters.
But we just don't think they're important enough to carry them around all
the time. Most of my `if` blocks are short, say, two or three lines. Adding
an "endif" after the block increases them by 33% or 50%. Multiply by the
hundreds, thousands, perhaps tens of thousands of block statements I'll
ever write or read, and that's a huge overhead for very little benefit.

And the next time I see a piece of code that ends:

end
end
end
end
end

the author is going to get a kickin'.

So for some of us, endif or however you want to spell it, is just noise,
eating up valuable vertical real estate. We recognise that it is
*theoretically* useful, but the *actual* usefulness in practice is so rare
that it really doesn't matter enough to make it worth while.

There's no right or wrong answer here. Once you get past the actual bug
magnets like C with its optional braces problem, and dangling elses, or
equivalent, the choice becomes one of taste.

There's a million brace-style languages out there for those who want them,
and only a handful like Python. Why can't you folks leave Python the way we
want it, instead of insisting it's wrong?


> Presumably you don't like parentheses in function calls for the same
> reasons; you'd prefer 'f a,b,c' rather than 'f(a,b,c)' in case, with
> copy&paste, someone might end up with: 'f(a,b,c),d)'.

No, because f a, b, c is ambigious.

spam(a, b, eggs(c, d), e)

would become in your system:

spam a, b, eggs c, d, e

and there's no way to tell which arguments are passed to eggs().

(Come on Bart, you've been designing languages for decades. You know this.)





-- 
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: How coding in Python is bad for you

[Chris Angelico]

On Wed, Jan 25, 2017 at 3:21 AM, Ben Bacarisse  wrote:
> Chris Angelico  writes:
>
>> On Wed, Jan 25, 2017 at 2:51 AM, Ben Bacarisse  wrote:
>>> Chris Angelico  writes:
>>> 
 ... I teach JavaScript as well as Python, and I've seen some
 pretty horrendous indentation flaws (examples available if people ask
 privately, but I will anonymize them because I'm not here to shame
 students) - but there have been nearly as many cases where the
 indentation's fine and the bracket nesting isn't.
>>>
>>> Can I ask what editor(s) your students have available?  I ask because
>>> I've not given a moment's thought to indentation or what bracket matches
>>> what for decades due to having a helpful editor.
>>>
>>
>> Quite a few, depending on which platform they're using. I'd say
>> Sublime is the most common choice.
>
> So what's going in your opinion?  The errors are in the group who don't
> use the right tools or what?

In my opinion, what's going on is that exploring code is a messy
process, and that the more little finicky things you have to get
right, the more likely you'll get something wrong. Which one you get
wrong is pretty much arbitrary.

Getting indentation wrong in JS won't affect the interpreter, but it
majorly affects the human. Which one would you rather confuse?

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

Re: How coding in Python is bad for you

[BartC]

On 24/01/2017 17:07, Steve D'Aprano wrote:

On Tue, 24 Jan 2017 10:52 pm, BartC wrote:


if condition:
statement
endif
statement
endif

What's this code meant to do? Can't know.


But whatever it does, a language that enforces 'endif' would report an
error, so requiring further investigation. Without the 'endifs', it
would look like this:

if condition:
statement
statement

Legal python.


Indeed.



And 99.99% of the time it is correct Python as well.


You don't know that. If this has been pasted from elsewhere, you need to 
match up the indentation level with the current code.



I suspect that the use of redundant braces or end delimiters has something
to do with attitudes to risk. Or even, dare I say it, with confidence in
your own programming skill.


(I'm in the early stages of implementing a C compiler at the moment. The 
test input is a single 750Kloc source file (900Kloc when 400 include 
files are taken account of).


If I've accidentally lost a space or tab while messing about with it, 
and it's significant, I would rather the compiler reported it! As I'm 
not going to spot it by perusing the 15,000 pages of code.)



It's not that we don't see the benefit of those braces or end delimiters.
But we just don't think they're important enough to carry them around all
the time.


I don't use Python enough for it to be a problem, yet it /has/ been a 
problem. I paste code from elsewhere into my editor; usually the 
indentation is a mess of spaces, and usually the whole thing is indented 
if the imported from a post here.


But if you now try to manually fix the indentation, invariably there 
comes a point where you don't know if a particular line has the new 
indentation, or the old. The original structure is temporarily lost. 
Possibly permanently; you may have to refer to the original. Or, worse, 
you don't realise there is a mistake in the new indentation and the 
structure has been subtly altered.


This means that a straightforward tweak to a bit a source code is so 
error-prone that you are obliged to use automatic tools to do the job.


 Most of my `if` blocks are short, say, two or three lines. Adding

an "endif" after the block increases them by 33% or 50%. Multiply by the
hundreds, thousands, perhaps tens of thousands of block statements I'll
ever write or read, and that's a huge overhead for very little benefit.

And the next time I see a piece of code that ends:

end
end
end
end
end

the author is going to get a kickin'.


Yes, but for using too much nesting!

Sometimes all these 'ends' are a nuisance, but IMO they are valuable, 
especially if they appear like this:


end if
end for

as they give extra information. They can also inject extra vertical 
space which can be useful (although your example gives too much).


But they also TELL YOU that you are at the end of a set of blocks! In 
Python, the above wouldn't appear at all; if you're lucky, you'll get 
one blank line. Whether that signals the end of all five blocks, or 
three, or none, depends on what comes next: you have to scroll further 
and infer from that which of the blocks have terminated.


(I've mentioned in another thread the movie Monty Python and the Holy 
Grail, which doesn't have normal closing credits, just a black screen 
being projected. Eventually the audience realise there is nothing more 
to see... Just having 'The End' appear wouldn't be as quirky but it 
would save some time!)



There's a million brace-style languages out there for those who want them,
and only a handful like Python. Why can't you folks leave Python the way we
want it, instead of insisting it's wrong?


Nothing's going to happen to Python and its unique block style. I'm just 
pointing out some of the flaws.


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

Re: String Replacement

[Peter Pearson]

On Mon, 23 Jan 2017 13:23:38 -0800 (PST), subhabangal...@gmail.com wrote:
> I have a string like 
>
> "Trump is $ the president of USA % Obama was $ the president
> of USA % Putin is $ the premier of Russia%"
>
> Here, I want to extract the portions from $...%, which would be
>
> "the president of USA", 
> "the president of USA", 
> "the premier of Russia"
[snip]

This might get you started:

$ cat temp.py
import re

x = ("Trump is $ the president of USA % Obama was $ the pres"
 "ident of USA % Putin is $ the premier of Russia%")

for y in re.finditer(r"(?P[^\$]*)\$(?P[^%]*)%", x):
print("'{0}' -- '{1}'".format(y.group("first"), y.group("second")))

$ python3 temp.py
'Trump is ' -- ' the president of USA '
' Obama was ' -- ' the president of USA '
' Putin is ' -- ' the premier of Russia'



-- 
To email me, substitute nowhere->runbox, invalid->com.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How coding in Python is bad for you

[Ben Bacarisse]

Steve D'Aprano  writes:

> On Wed, 25 Jan 2017 03:21 am, Ben Bacarisse wrote:
>
>> Chris Angelico  writes:
>> 
>>> On Wed, Jan 25, 2017 at 2:51 AM, Ben Bacarisse 
>>> wrote:
> [...]
 Can I ask what editor(s) your students have available?  I ask because
 I've not given a moment's thought to indentation or what bracket matches
 what for decades due to having a helpful editor.

>>>
>>> Quite a few, depending on which platform they're using. I'd say
>>> Sublime is the most common choice.
>> 
>> So what's going in your opinion?  The errors are in the group who don't
>> use the right tools or what?
>
> If braces can be inserted automatically by the compiler, then they are
> useless and should be left out of the language.

I'm, not sure I agree but that would be a whole new topic.  I'm talking
about tools (editors specifically) that help the author to write what
they intend to write.

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

Re: How coding in Python is bad for you

[Ben Bacarisse]

BartC  writes:

> On 24/01/2017 15:51, Ben Bacarisse wrote:
>> Chris Angelico  writes:
>> 
>>> ... I teach JavaScript as well as Python, and I've seen some
>>> pretty horrendous indentation flaws (examples available if people ask
>>> privately, but I will anonymize them because I'm not here to shame
>>> students) - but there have been nearly as many cases where the
>>> indentation's fine and the bracket nesting isn't.
>>
>> Can I ask what editor(s) your students have available?  I ask because
>> I've not given a moment's thought to indentation or what bracket matches
>> what for decades due to having a helpful editor.
>
> How would your editor detect the error in the example I gave earlier?

I'm not talking about detecting errors -- that's for the programmer --
but the editor can help the programmer to be sure they wrote what they
meant by doing things like matching brackets and auto-indenting code in
{}s.  (I'm replying to a post about JavaScript which has {}s.)

The trouble is that I've been programming for so long that I can't
remember what it's like to make block and/or indent errors.  Obviously I
make typos but they don't survive more than a few seconds.  I hoped that
Chris's students would provide an insight into how the tools do or
don't help.

> (Where a tab has been inadvertently removed - or added - but the
>result is still valid Python code.)

In Python the editor could, for example, highlight the block you are
typing in, so as soon as you leave the body of the 'if' it would stop
being marked and the containing code would be highlighted.  Just moving
the cursor up and down would show you what block everything is in.  I
don't know if any editors help like this -- that's part of my reason to
ask.

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

Re: PhotoImage.paste

[rryan . asu]

Hi Peter,

Yes, that was the first thing I did, even before using the paste method.  I 
read the warning on effbot and other sites, and simply coded it up as

new_image.putpalette(palette)
photo=ImageTk.PhotoImage(image=new_image)
canvas_object=canvas.create_iamge(x,y,image=photo)

And this was a small bit faster, but still quite slow (say 0.1 s).  So just to 
understand the warning on effbot, I tried using paste, where'd I just do 
something like

image.putpalette(palette)
photo.paste(image)

and that took about 0.15 s. But my canvas has a few other things displayed on 
it, so each time that you create a new image/canvas object, I still have to run 
the lift method to order the items appropriately.  So all in all, the new image 
method wasn't that much better --- and ultimately still too slow for my 
interest.  

It seems that for some reason PIL just has this a limitation, which is really 
sad.  I think I can skirt the issue by when you start the mouse action, grab 
the bounding box from the view and only apply the new palette math to that 
subregion.  Then when the mouse action is finished, load the palette to the 
entire image with paste, and accept the time is 0.15 sec --- but this is not 
done in "real time".  This is will be a substantial amount of coding and quite 
ugly.  I'm just surprised that this is so clunky. 

Thanks for the suggestion.
Russell




On Tuesday, January 24, 2017 at 11:59:49 AM UTC-5, Peter Otten wrote:
>@gmail.com wrote:
> 
> > I'm trying to build a tkinter GUI with python 3.5, and would like to
> > interactively adjust the color palette for an image by moving the mouse in
> > the canvas using PIL.  In pseudo-code, I have something like
> > 
> > palette=color_map(x,y)   # x,y are scalars indicating the position of the
> > mouse in the Canvas image.putpalette(palette)
> > photo.paste(image)
> > 
> > This works just fine, but is very slow.  The photo.paste(image) step takes
> > about 0.15 s (using an image that is 4k x 4k).  I read the manual on
> > effbot, and they caution that the paste method would be slow if the image
> > is display --- and I'm guessing that's what I'm doing.
> 
> So you have read
> 
> """
> Note: Pasting into an RGBA image that is displayed is a very slow operation. 
> It’s usually better to create a new image object.
> """
> 
> on .
> 
> > So my question is, what alternatives do I have to speed that step up.
> 
> Did you try to create a new image, as the note suggests?
> 
> > Thank you for any thoughts you might have...
> > -Russell
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How coding in Python is bad for you

[Ben Bacarisse]

Chris Angelico  writes:

> On Wed, Jan 25, 2017 at 3:21 AM, Ben Bacarisse  wrote:
>> Chris Angelico  writes:
>>
>>> On Wed, Jan 25, 2017 at 2:51 AM, Ben Bacarisse  wrote:
 Chris Angelico  writes:
 
> ... I teach JavaScript as well as Python, and I've seen some
> pretty horrendous indentation flaws (examples available if people ask
> privately, but I will anonymize them because I'm not here to shame
> students) - but there have been nearly as many cases where the
> indentation's fine and the bracket nesting isn't.

 Can I ask what editor(s) your students have available?  I ask because
 I've not given a moment's thought to indentation or what bracket matches
 what for decades due to having a helpful editor.

>>>
>>> Quite a few, depending on which platform they're using. I'd say
>>> Sublime is the most common choice.
>>
>> So what's going in your opinion?  The errors are in the group who don't
>> use the right tools or what?
>
> In my opinion, what's going on is that exploring code is a messy
> process, and that the more little finicky things you have to get
> right, the more likely you'll get something wrong. Which one you get
> wrong is pretty much arbitrary.

Do you think the tools (the editor in particular) could be more helpful?
As I said elsewhere I've forgotten how these sorts of errors happen so I
have very little insight into how to prevent them.  With token-marked
blocks I feel (though I don't know) that matching and auto-indenting
help me to know I've written what I intended to write.  I was just
surprised that these errors happened enough for you to comment on them.

> Getting indentation wrong in JS won't affect the interpreter, but it
> majorly affects the human. Which one would you rather confuse?

I'm guessing that's a rhetorical question! (It obviously depends on the
situation.)  I suspect that part of the reason these errors occur is
precisely because they don't matter to the interpreter and students are
doing a lot of self-easement based on "does it work?" tests.  This is
why Python is a win in such situations -- you can't write confusingly
indented code, only wrong code.

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

How an editor can help with block nesting (was Re: How coding in Python is bad for you)

[Chris Angelico]

On Wed, Jan 25, 2017 at 6:31 AM, Ben Bacarisse  wrote:
> I'm not talking about detecting errors -- that's for the programmer --
> but the editor can help the programmer to be sure they wrote what they
> meant by doing things like matching brackets and auto-indenting code in
> {}s.  (I'm replying to a post about JavaScript which has {}s.)
>
> The trouble is that I've been programming for so long that I can't
> remember what it's like to make block and/or indent errors.  Obviously I
> make typos but they don't survive more than a few seconds.  I hoped that
> Chris's students would provide an insight into how the tools do or
> don't help.
>
> In Python the editor could, for example, highlight the block you are
> typing in, so as soon as you leave the body of the 'if' it would stop
> being marked and the containing code would be highlighted.  Just moving
> the cursor up and down would show you what block everything is in.  I
> don't know if any editors help like this -- that's part of my reason to
> ask.

This is a huge topic, and worthy of its own thread.

I've toyed with a lot of different editors myself, and in the end, I
actually found that features like this are less valuable than having
an editor that's light on its toes and responds snappily even on
lower-end hardware (and I like using the same editor with the same
configs on all my systems). so I'm using SciTE. The most common editor
among my students is probably Sublime, followed by Atom, and they have
fairly similar feature sets.

Ultimately, programming is a messy business. You start out with an
imperfect idea of what you want, and progressively refine from there.
So anything that lets you "sketch" your code more easily is a good
thing. I think we can all agree on that part, right? It's just a
question of what _kind_ of help the editor gives.

The main two forms of help that I get or see from editors are:
1) Actually doing stuff for you, where it's 95% certain what you want
2) Visually showing you what your code is doing.

The first category includes stuff like auto-indentation (add an
indentation level when you have an open brace, or when there's a colon
ending the previous line), and the second category includes stuff that
highlights language keywords, or tells you about local vs global
names, or shows you where the matching bracket is for the one your
cursor's on.

I kinda like the idea of showing what the innermost active block
heading is for any given line of code. That would be fairly
straight-forward: scroll up till you find a non-blank line with less
indentation than the one you're on, and put a marker there. The
nearest equivalent I have is a feature that one of my cow-orkers asked
for once: a Python version of "jump to nearest brace". I bound it to
Ctrl-E, and played with the feature, but never really found it useful
- it was of mild value but I could generally eyeball it just as
easily. Would be curious to see how it works with a colour highlight
rather than an active "go to the top of this block" keystroke.
(Bikeshed: should _every_ active block heading be highlighted, or just
the innermost one? If you're inside a function, a loop, and a
condition, should the 'def', 'for', and 'if' lines all be
highlighted?)

With my JavaScript students, the greatest help is probably a keystroke
beautifier. You edit your code with sloppy indentation, and then bam,
it reindents for you. The trouble is that they can end up with code
where the indentation matches the braces, but *both are now wrong*.
I'd be very curious to see an "auto-bracket-closer" that adjusts the
brackets to match the indentation. Here's an example piece of
JavaScript - imagine this has been through a few rounds of editing:

function reducer(state=initial_state, action={}) {
switch (action.type) {
case 'FROBNOSTICATE':
let items = info_store.filter((item) => {
console.log("item:", item);
return action.frob == item.frobbability;
)}
console.log("Keeping:", items)
return {...state, frobbables: items}
}
default: break;
}
return state;
}

Now, I've deliberately made the indentation follow my intention, and
then messed up the brackets. An editor should be able to look at this
and pinpoint the places where the indentation changes unexpectedly,
and either automatically correct it, or raise an error (in the case of
the omitted open brace in the above example). I'd be curious to see
how well this works for people,  particularly novices. But it'd have
to be implemented first :)

Python removes some of this by not using braces for block delimiters,
but you can still get the same phenomenon with nested list/dict
displays, function calls, etc. So the code would be identical, except
that a colon at the end of a line indicates indentation too.

Anyone want to code this into an editor and see how it performs?

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

With class as contextmanager

[This Wiederkehr]

Hellou

having a class definition:

class Test():

@classmethod
def __enter__(cls):
pass

@classmethod
def __exit__(cls, exception_type, execption_value, callback):
pass

now using this as a contextmanager does not work, even though Test is an
object and has the two required methods __enter__ and __exit__.

it fails with:
#Attribute Error: __enter__


This is not working because behind the scene it does something like:
type(Test).__enter__(Test)

But isn't this supposed to be working?

I am asking because I'd like to implement the clean up behaviour for
multiple instances directly into the class:

with Test:
testinstance1 = Test()
testinstance2 = Test()
# on context exit Test.__exit__ should take care on cleaning up
testinstance1 and testinstance2.


Regards

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

Re: With class as contextmanager

[Ian Kelly]

On Tue, Jan 24, 2017 at 2:31 PM, This Wiederkehr
 wrote:
> Hellou
>
> having a class definition:
>
> class Test():
>
> @classmethod
> def __enter__(cls):
> pass
>
> @classmethod
> def __exit__(cls, exception_type, execption_value, callback):
> pass
>
> now using this as a contextmanager does not work, even though Test is an
> object and has the two required methods __enter__ and __exit__.
>
> it fails with:
> #Attribute Error: __enter__
>
>
> This is not working because behind the scene it does something like:
> type(Test).__enter__(Test)
>
> But isn't this supposed to be working?
>
> I am asking because I'd like to implement the clean up behaviour for
> multiple instances directly into the class:
>
> with Test:
> testinstance1 = Test()
> testinstance2 = Test()
> # on context exit Test.__exit__ should take care on cleaning up
> testinstance1 and testinstance2.

Special dunder methods are generally only looked up on the object's
class, not on the object itself. If you wish to use a class object as a
context manager then you need to define __enter__ and __exit__ on the
class's class, i.e. its metaclass.

Alternatively you could separate the context manager from the testing
class and make Test be just an object that defines __enter__, __exit__
and __call__, with __call__ creating and returning a new instance of
the actual testing class.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: With class as contextmanager

[Ethan Furman]

On 01/24/2017 01:31 PM, This Wiederkehr wrote:


having a class definition:

class Test():

@classmethod
def __enter__(cls):
 pass

@classmethod
def __exit__(cls, exception_type, execption_value, callback):
 pass

now using this as a contextmanager does not work, even though Test is an
object and has the two required methods __enter__ and __exit__.


It is not working because you are trying to use the class itself, and not it's 
instances, as a context manager (which also means you don't need classmethod):

Wrong:

  with Test:

Correct:

  with Test():


I am asking because I'd like to implement the clean up behaviour for
multiple instances directly into the class:

with Test:
testinstance1 = Test()
testinstance2 = Test()
# on context exit Test.__exit__ should take care on cleaning up
testinstance1 and testinstance2.


You might be able to make this work with a custom type (aka using a custom 
metaclass) -- but that could be a bunch of work.

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

Re: With class as contextmanager

[Ethan Furman]

On 01/24/2017 02:35 PM, Ethan Furman wrote:

On 01/24/2017 01:31 PM, This Wiederkehr wrote:



having a class definition:

class Test():

@classmethod
def __enter__(cls):
 pass

@classmethod
def __exit__(cls, exception_type, execption_value, callback):
 pass

now using this as a contextmanager does not work, even though Test is an
object and has the two required methods __enter__ and __exit__.


It is not working because you are trying to use the class itself, and not it's 
instances, as a context manager (which also means you don't need classmethod):

Wrong:

   with Test:

Correct:

   with Test():


I am asking because I'd like to implement the clean up behaviour for
multiple instances directly into the class:

with Test:
testinstance1 = Test()
testinstance2 = Test()
# on context exit Test.__exit__ should take care on cleaning up
testinstance1 and testinstance2.


You might be able to make this work with a custom type (aka using a custom 
metaclass) -- but that could be a bunch of work.


Okay, here's the easy part:

--- 8< 
class TestType(type):
def __enter__(cls):
pass
def __exit__(cls, *args):
pass

class Test(metaclass=TestType):
pass

with Test:
print('worked!')
--- 8< 

Let us know how it turns out.

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

Referencing section name by interpolation in ConfigParser

[Hans-Peter Jansen]

Hi,

I would like to use a interpolated section name, e.g.:

[Section]
secref: %{section}s/whatever

should result in:

>>> config['Section']['secref']
'Section/whatever'

Any idea anybody, how to archive this with minimum fuzz?

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

Re: How an editor can help with block nesting (was Re: How coding in Python is bad for you)

[Steve D'Aprano]

On Wed, 25 Jan 2017 08:19 am, Chris Angelico wrote:

> I kinda like the idea of showing what the innermost active block
> heading is for any given line of code. That would be fairly
> straight-forward: scroll up till you find a non-blank line with less
> indentation than the one you're on, and put a marker there. The
> nearest equivalent I have is a feature that one of my cow-orkers asked
> for once: a Python version of "jump to nearest brace". I bound it to
> Ctrl-E, and played with the feature, but never really found it useful
> - it was of mild value but I could generally eyeball it just as
> easily. 

Indeed. Good programming practice suggests that your block should ideally be
under half an dozen lines and certainly less than a full screenful. If you
need a command to jump to the top or bottom of the block, your blocks are
too big and need refactoring.


> Would be curious to see how it works with a colour highlight 
> rather than an active "go to the top of this block" keystroke.
> (Bikeshed: should _every_ active block heading be highlighted, or just
> the innermost one? If you're inside a function, a loop, and a
> condition, should the 'def', 'for', and 'if' lines all be
> highlighted?)

I actually don't see the point.

For an experienced coder, you already have all the clue you need to see the
block structure: the indentation level.

(If you are indenting by a single space, or even two spaces, you're probably 
hamstringing yourself and hurting your ability to recognise structure at a
glance.)

Adding an extra colour cue to duplicate the information given by indentation
just adds to the noise level of code. But if you were to do the experiment,
I'd *only* colour the currently edited block, by marking the margins with a
subtle colour. You know how many GUI editors highlight the current line
with a faint colour? Something similar. You could make the colour different
for each block, I guess, if you wanted to be fancy.


> With my JavaScript students, the greatest help is probably a keystroke
> beautifier. You edit your code with sloppy indentation, and then bam,
> it reindents for you. 

Really? I wouldn't want that, or find it helpful to type badly formatted
code. I would want one of two things:

(1) Indentation is up to you. You either get it syntactically right, or the
code won't run, like Python. That teaches you to get the indentation right
through negative reinforcement.

Of course merely getting the indentation syntactically correct doesn't mean
it is *semantically* correct, but the editor or compiler doesn't know what
you mean, only what you say. If you cannot get the syntax right, you can't
hope to communicate to the compiler. So learning to get the syntax right is
a necessary first step to learning to program.


(2) Or the editor won't let you enter sloppy indentation in the first place.
This teaches you good indentation by example.

Every time you hit return, the editor automatically indents as needed. If
you mistakenly change the indentation (or fail to change the indentation
when needed), then when you hit return on that line (or any other editing
command that moves to another line), the editor either fixes the
indentation for you, if it can, or flags the line as a syntax error if it
cannot determine the right thing to do.


For example, suppose I already have this, where | is the current text
insertion point:

def func(a, b):
if condition:
spam() |

I hit ENTER, and the editor automatically indents to the current block
level. There's nothing new about that, most editors already do this:


def func(a, b):
if condition:
spam()
|

But now I type something which cannot possibly be indented there:

def func(a, b):
if condition:
spam()
elif something: |

and hit ENTER again. There's nothing ambiguous about this, and the editor
could (and should?) re-indent the elif line, giving this:

def func(a, b):
if condition:
spam()
elif something:
|

In other words, with the second scenario, you can never have more than one
mis-indented line at a time during the normal course of editing. (At least
not without really working to defeat the editor.)




-- 
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: How an editor can help with block nesting (was Re: How coding in Python is bad for you)

[Chris Angelico]

On Wed, Jan 25, 2017 at 12:31 PM, Steve D'Aprano
 wrote:
>> With my JavaScript students, the greatest help is probably a keystroke
>> beautifier. You edit your code with sloppy indentation, and then bam,
>> it reindents for you.
>
> Really? I wouldn't want that, or find it helpful to type badly formatted
> code.

This isn't something I use (when I want a beautifier, it's because I'm
de-minifying some code to figure out what it does, so I just paste it
into http://jsbeautifier.org/ or something), but I've seen my students
move braces around and then hit the beautifier, where I would
highlight the text and hit Tab or Shift-Tab to adjust the indentation
level.

> I would want one of two things:
>
> (1) Indentation is up to you. You either get it syntactically right, or the
> code won't run, like Python. That teaches you to get the indentation right
> through negative reinforcement.
>
> (2) Or the editor won't let you enter sloppy indentation in the first place.
> This teaches you good indentation by example.
>
> [chomp details of entering code for the first time]

Tell me, how often do you enter code and it works the first time? :)

Much more common - and this is especially true of student programmers,
but we're none of us immune to it - the code gets tinkered with and
edited and manipulated many times before it's finally working. Stuff
gets reordered, conditionals get added or removed, etc, etc, etc. So
there are a few possibilities:

1) Get the symbols right, then adjust the indentation to match
2) Get the indentation right, then adjust the symbols to match
3) Check before permitting code to be committed, and reject if they don't match
4) Check before permitting code even to be run
5) Ignore the indentation because it "doesn't matter", and then waste
your instructor's time when you call him in to help you figure out
where your bug is.

Python makes the second option easier (by having no symbols for the
most common indentation), but doesn't eliminate the problem entirely.
The fifth option is what most often happens. The first is the "hit the
beautifier key" option, and is fine as long as you absolutely
definitely got the symbols right. I'm thinking the third or fourth
might be the best :)

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

Re: How an editor can help with block nesting (was Re: How coding in Python is bad for you)

[Dan Sommers]

On Wed, 25 Jan 2017 12:31:11 +1100, Steve D'Aprano wrote:

> But now I type something which cannot possibly be indented there:
> 
> def func(a, b):
> if condition:
> spam()
> elif something: |
> 
> and hit ENTER again. There's nothing ambiguous about this, and the
> editor could (and should?) re-indent the elif line, giving this:
> 
> def func(a, b):
> if condition:
> spam()
> elif something:
> |
> 
> In other words, with the second scenario, you can never have more than
> one mis-indented line at a time during the normal course of
> editing. (At least not without really working to defeat the editor.)

And then you get to this one:

def f(x):
if condition:
spam()
if g(x):
eggs()
elif something_else: |

Now, everyone, say it with me:  In the face of ambiguity, refuse the
temptation to guess.

In languages with braces, re-indenting lines as I press ENTER is
possible (I happen not to like that behavior, but that's a personal
preference, and editors that won't get out of the way and let me edit my
own code get deleted).

In Python, I prefer to get the indent right myself before I press ENTER.

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

Re: How coding in Python is bad for you

[BartC]

On 25/01/2017 01:04, Dennis Lee Bieber wrote:

On Tue, 24 Jan 2017 17:50:56 +, BartC  declaimed the
following:



If I've accidentally lost a space or tab while messing about with it,
and it's significant, I would rather the compiler reported it! As I'm
not going to spot it by perusing the 15,000 pages of code.)


None of the C/Java/Pascal/Ada family will report a missing space or
tab.


The point is, it usually doesn't matter as in most situations it's not 
significant. But if it was significant it would be useful for the 
language to pick it up. (Usually it would be in such languages, but not 
always.)


And if C code is posted on usenet, and leading whitespace is lost, as 
often happens, then the results are still valid code.


Losing leading white space with Python code would cause serious problems 
as it contains program structure that is not backed up by explicit block 
markers (which could have been used to reconstruct the indentation).



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

Re: How coding in Python is bad for you

[Tim Chase]

On 2017-01-24 20:04, Dennis Lee Bieber wrote:
>>You don't know that. If this has been pasted from elsewhere, you
>>need to match up the indentation level with the current code.
> 
>   So? The editor(s) I tend to use have the ability to shift
> indent in/out for selected blocks. Do the paste, highlight the
> pasted content, and shift the indent as needed.

The editor I use (vim) doesn't even require me to re-select the range
to shift it.  Just using

  >']

or

  <']

will indent/dedent from the cursor to the line where your paste ended.

Hurray for laziness :-)

-tkc


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

Re: With class as contextmanager

[Terry Reedy]

On 1/24/2017 4:31 PM, This Wiederkehr wrote:


having a class definition:

class Test():

@classmethod
def __enter__(cls):
pass

@classmethod
def __exit__(cls, exception_type, execption_value, callback):
pass

now using this as a contextmanager does not work, even though Test is an
object and has the two required methods __enter__ and __exit__.

it fails with:
#Attribute Error: __enter__


This is not working because behind the scene it does something like:
type(Test).__enter__(Test)

But isn't this supposed to be working?


No.  Unqualified 'method' means instance method, not class method.

One can simulate instance methods like so:

>>> import types
>>> def f(self): print('f called')

>>> class C: pass

>>> c = C()
>>> c.m = types.MethodType(f, c)
>>> c.m()
f called

However, this will not work for dunder methods where the lookup for the 
method starts with the class and not the object itself.


>>> def h(self): return 1

>>> c.__hash__ = types.MethodType(h, c)
>>> hash(c)  # calls type(c).__hash__, not c.__hash__
-9223371924496369383

--
Terry Jan Reedy

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

Re: How coding in Python is bad for you

[Gregory Ewing]

Dennis Lee Bieber wrote:

While I'm trying to figure out what significance Centrum vitamins have
with being "non-GMO"...


Possibly they're just complying with some legal requirement or
other to declare whether the product has any GMO components.
If so, bit of a silly regulation, I'll agree. What we really
want to know is whether they use any dihydrogen monoxide in the
manufacturing process!

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

Re: PhotoImage.paste

[Gregory Ewing]

Dennis Lee Bieber wrote:

But practically everything these days uses true/high color, in which
each pixel encodes the exact color to be displayed. This means that
changing all matching pixels from one given color to another given color
requires rewriting those pixels color data.


Yes, and a 4k x 4k RGBA image is about 64MB of data.
I'm not surprised it takes a noticeable amount of
time to change all of that.

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

any one used moviepy please come in!!! I need help, thanks!

[Tony Chen]

I have to use moviepy in one of my project. So I downloaded it, and tried the 
example code on the website. It gives me this error. Anyone can give me some 
help? Thank you very much!

it gives this error:
[MoviePy] This command returned an error !Traceback (most recent call last):
  File "tst.py", line 5, in 
txt_clip = TextClip("My Holidays 2013", fontsize = 70, color = 'white')
  File "/usr/local/lib/python2.7/dist-packages/moviepy/video/VideoClip.py", 
line 1145, in __init__
raise IOError(error)
IOError: MoviePy Error: creation of None failed because of the following error:

convert: not authorized `@/tmp/tmpjistPm.txt' @ 
error/property.c/InterpretImageProperties/3405.
convert: no images defined `PNG32:/tmp/tmpJM0NVq.png' @ 
error/convert.c/ConvertImageCommand/3210.
.

.This error can be due to the fact that ImageMagick is not installed on your 
computer, or (for Windows users) that you didn't specify the path to the 
ImageMagick binary in file conf.py, or.that the path you specified is incorrect
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: any one used moviepy please come in!!! I need help, thanks!

[Chris Angelico]

On Wed, Jan 25, 2017 at 6:22 PM, Tony Chen  wrote:
> This error can be due to the fact that ImageMagick is not installed on your 
> computer, or (for Windows users) that you didn't specify the path to the 
> ImageMagick binary in file conf.py, or.that the path you specified is 
> incorrect

So... is ImageMagick installed?

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

Hide text in entry box when i click on it.(GUI using Tkinter in python)

[hmmeeranrizvi18]

Hello Guys,
Here i am creating a entry box with some text,i need to hide the text when i 
click on it.
Here is my code

from Tkinter import *
obj = Tk()
b = Entry(obj,width=100)
b.insert(0,"Enter the value to search")
b.pack()
mainloop()

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

Re: How coding in Python is bad for you

[Bob Martin]

in 770220 20170124 070853 Chris Angelico  wrote:
>On Tue, Jan 24, 2017 at 6:00 PM, Bob Martin  wrote:
>> in 770207 20170124 005601 Chris Angelico  wrote:
>>
>>>REXX has even less structure than Python - it doesn't even have
>>>functions, just labels, so you can actually have two functions that
>>>share a common tail. And yes, you can abuse that horrendously to
>>>create unreadable code. Is REXX a bad language because of that? No.
>>>You can use structure badly, and you can use freedom badly.
>>
>> Of course Rexx has functions!
>
>Built-ins, yes, but when you define your own, it's by giving a label.
>It isn't a function until it's called as a function.

Just because the word "function" isn't in the header doesn't change matters.
The word "procedure" can appear in the header, but it can be called as a
procedure or a function. 
-- 
https://mail.python.org/mailman/listinfo/python-list