Re: Python to do CDC on XML files

[Chris Angelico]

On Thu, Mar 24, 2016 at 10:57 AM, Bruce Kirk  wrote:
> I agree, the challenge is the volume of the data to compare is 13. Million 
> records. So it needs to be very fast

13M records is a good lot. To what extent can the data change? You may
find it easiest to do some sort of conversion to text, throwing away
any information that isn't "interesting", and then use the standard
'diff' utility to compare the text files. It's up to you to figure out
what differences are "uninteresting"; it'll depend on your exact data.

As long as you can do the conversion-to-text in a simple and
straight-forward way, the overall operation will be reasonably fast.
If this is a periodic thing (eg you're constantly checking today's
file against yesterday's), saving the dumped text file will mean you
generally need to just convert one file, halving your workload.

This isn't a solution so much as a broad pointer... hope it's at least a start!

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

Re: Python to do CDC on XML files

[Peter Otten]

Bruce Kirk wrote:

> Does anyone know of any existing projects on how to generate a change data
> capture on 2 very large xml files.
> 
> The xml structures are the same, it is the data within the files that may
> differ.
> 
> I need to take a XML file from yesterday and compare it to the XML file
> produced today and not which XML records have changed.
> 
> I have done a google search and I am not able to find much on the subject
> other than software vendors trying to sell me their products. :-)

There is

http://www.logilab.org/project/xmldiff

As an alternative you may try to log the changes as they occur instead of 
inspecting the result. If the application generating the file is not under 
your control, does it offer other output formats, e. g. csv?

Or if the xml file is basically a sequence of one type of node you may 
convert it to a database (sqlite will do) to match and compare the 
"records".

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

Bug in python34 package struct

[Rudi Lopez Lopez]

from struct import pack

print(hex(126))
print(pack('>H',126))


Rudi G. Lopez
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Bug in python34 package struct

[Chris Angelico]

On Thu, Mar 24, 2016 at 7:17 PM, Rudi Lopez Lopez  wrote:
> from struct import pack
>
> print(hex(126))
> print(pack('>H',126))

Explain the bug?

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

Re: Bug in python34 package struct

[Marko Rauhamaa]

Rudi Lopez Lopez :

> from struct import pack
>
> print(hex(126))
> print(pack('>H',126))

I can't see any bug. The tilde (~) has an ASCII code 126.


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

netrc and password containing whitespace

[Lele Gaifax]

Hi all,

I tried to insert an entry in my ~/.netrc for an account having a password
that contains a space, something like:

  machine my-host-name login myname password "My Password"

The standard library netrc module does not seem able to parse it, raising a
NetrcParseError. Other programs (Emacs, to mention one) do the right thing
with an entry like that.

Inspecting the module, I see that it explicitly put the quote chars (both
single and double, that is '"' and "'") in the shlex-based lexer's wordchars:

  def _parse(self, file, fp, default_netrc):
   lexer = shlex.shlex(fp)
   lexer.wordchars += r"""!"#$%&'()*+,-./:;<=>?@[\]^_`{|}~"""
   lexer.commenters = lexer.commenters.replace('#', '')
   ...
   
Since the method read_token() state machine gives higher priority to wordchars
over quotes, it obviously cannot parse the quoted string correctly:

  ...
  elif self.posix and nextchar in self.escape:
  escapedstate = 'a'
  self.state = nextchar
  elif nextchar in self.wordchars:
  self.token = nextchar
  self.state = 'a'
  elif nextchar in self.quotes:
  if not self.posix:
  self.token = nextchar
  self.state = nextchar
  ...

I was not able to lookup an exact definition of netrc's syntax, so I wonder:
is the implementation somewhat flawed, or am I missing something?

Thanks in advance for any hint,
ciao, lele.
-- 
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
l...@metapensiero.it  | -- Fortunato Depero, 1929.

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

newbie question

[ast]

Hi

I have a string which contains a tupe, eg:

s = "(1, 2, 3, 4)"

and I want to recover the tuple in a variable t

t = (1, 2, 3, 4)

how would you do ?


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

Re: newbie question

[David Palao]

Hi,
Use "eval":
s = "(1, 2, 3, 4)"
t = eval(s)

Best

2016-03-24 11:39 GMT+01:00 ast :
> Hi
>
> I have a string which contains a tupe, eg:
>
> s = "(1, 2, 3, 4)"
>
> and I want to recover the tuple in a variable t
>
> t = (1, 2, 3, 4)
>
> how would you do ?
>
>
> --
> https://mail.python.org/mailman/listinfo/python-list
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: newbie question

[ast]

"David Palao"  a écrit dans le message de 
news:mailman.86.1458816553.2244.python-l...@python.org...

Hi,
Use "eval":
s = "(1, 2, 3, 4)"
t = eval(s)

Best




Thank you 


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

Re: newbie question

[Matt Wheeler]

>>> import ast
>>> s = "(1, 2, 3, 4)"
>>> t = ast.literal_eval(s)
>>> t
(1, 2, 3, 4)

On 24 March 2016 at 10:39, ast  wrote:
> Hi
>
> I have a string which contains a tupe, eg:
>
> s = "(1, 2, 3, 4)"
>
> and I want to recover the tuple in a variable t
>
> t = (1, 2, 3, 4)
>
> how would you do ?
>
>
> --
> https://mail.python.org/mailman/listinfo/python-list



-- 
Matt Wheeler
http://funkyh.at
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: newbie question

[Tim Chase]

On 2016-03-24 11:49, David Palao wrote:
>> s = "(1, 2, 3, 4)"
>>
>> and I want to recover the tuple in a variable t
>>
>> t = (1, 2, 3, 4)
>>
>> how would you do ?
>
> Use "eval":
> s = "(1, 2, 3, 4)"
> t = eval(s)

Using eval() has security implications. Use ast.literal_eval for
safety instead:

  import ast
  s = "(1, 2, 3, 4)"
  t = ast.literal_eval(s)

-tkc


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

Re: newbie question

[Sven R. Kunze]

On 24.03.2016 11:57, Matt Wheeler wrote:

import ast
s = "(1, 2, 3, 4)"
t = ast.literal_eval(s)
t

(1, 2, 3, 4)


I suppose that's the better solution in terms of safety.
--
https://mail.python.org/mailman/listinfo/python-list

Re: newbie question

[Steven D'Aprano]

On Thu, 24 Mar 2016 09:39 pm, ast wrote:

> Hi
> 
> I have a string which contains a tupe, eg:
> 
> s = "(1, 2, 3, 4)"
> 
> and I want to recover the tuple in a variable t
> 
> t = (1, 2, 3, 4)
> 
> how would you do ?


py> import ast
py> ast.literal_eval("(1, 2, 3, 4)")
(1, 2, 3, 4)


-- 
Steven

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

Re: Connect to Default Printer

[Grant Edwards]

On 2016-03-24, Bryon Fawcett  wrote:

> Could you please advise me how to connect the python software to my default
> printer.

import os

os.popen("lpr","w").write("Hi there, this just got printed!\r\n")

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

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

[BartC]

On 24/03/2016 03:24, Chris Angelico wrote:

On Thu, Mar 24, 2016 at 12:41 AM, BartC  wrote:

To extend this analogy better, executing byte-code to directly perform a
task itself might be equivalent to travelling on foot, while everyone is
suggesting taking the bus, tube or taxi.



It's easy to see that carrying five boxes of books will slow down
you're walking *dramatically*. In fact, it's probably quicker to take
just one of them, and then come back for another one, and so on. When
you travel by car, it's much harder to measure the cost of the five
boxes, but it made so much difference in walking time that you should
probably take one box at a time, right?

This is how you're currently evaluating Python. Instead of starting
with the most simple and obvious code and refining from there, you're
starting from a whole lot of preconceived ideas about what's "fast" or
"slow", and assuming/expecting that they'll all still be valid. Many
of them won't be, yet you still persist in doing things based on what
you expect to be the case (because of what's fast/slow in C or some
other language). We've explained this a number of times, and one by
one, we're coming to the conclusion that you not only don't understand
Python, you don't *want* to understand Python; and until you actually
understand how the language works, timing stats are dubious.

Do you understand why people aren't taking your results very seriously?


I've been using interpreted languages since the 80s, when they were much 
cruder and slower (and when hardware was much slower too).


Yet I could still use them effectively. (I reckoned that when used 
sensibly and in the right balance, a solution using a dynamic language 
would only be between one and two times slower than using compiled, 
native code. But it was many times more productive.)


So I understand perfectly that such languages have a huge range of 
applications no matter what the speed of the underlying byte-code.


However once you start looking at tasks where the speed /might/ 
matter, then you have to start measuring properly.


And forgetting Python for a minute and concentrating only on its 
byte-code as a language in its own right, how would you go about the job 
of streamlining it?


You might start with  profiling it to see which codes are more 
expensive, which are called most then, all the usual stuff.


But there are all sorts of micro-micro-benchmarks that can concentrate 
on a single byte-code. For example, how long does it take to call an 
empty function with no parameters? Just putting such a call into a 
simple loop can be effective:


Python 3 (on Windows) might take 200ns. Clisp is 1300ns (interpreted, 
presumably). Ruby 170ns. Lua 80ns. Mine 10-20ns. Unoptimised C is 4ns, 
but this is not executing code indirectly as most of the rest have to. 
[Timings include loop overheads that need to be factored out.]


So there might be room for improvement, but those faster languages are 
also simpler. Is Python's richness or dynamism the main factor here? If 
so there is probably little to be done; if not... This is where the fun 
starts.


But I understand that most people aren't interested in this kind of sport.

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

Re: newbie question

[Matt Wheeler]

On Thu, 24 Mar 2016 11:10 Sven R. Kunze,  wrote:

> On 24.03.2016 11:57, Matt Wheeler wrote:
>  import ast
>  s = "(1, 2, 3, 4)"
>  t = ast.literal_eval(s)
>  t
> > (1, 2, 3, 4)
>
> I suppose that's the better solution in terms of safety.
>

It has the added advantage that the enquirer gets to import a module that
shares their name ;)

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

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

[Steven D'Aprano]

On Thu, 24 Mar 2016 02:24 pm, Chris Angelico wrote:


> This is how you're currently evaluating Python. Instead of starting
> with the most simple and obvious code 

One problem is that what counts as "simple and obvious" depends on what you
are used to. Coming from a background of Pascal, iterating over a list like
this:

for i in range(len(mylist)):
print mylist[i]

was both simple and obvious. It took me years to break myself of that habit.

Likewise clearing a list:

for i in range(len(mylist)-1, -1, 0):
del mylist[i]


Fortunately I didn't need to do that very often.

The point is that you, like most of the prominent posters here, have many
years of experience in programming in Python. How do you expect Bart to
come up with the same "simple and obvious" code as you?


> and refining from there, you're 
> starting from a whole lot of preconceived ideas about what's "fast" or
> "slow", and assuming/expecting that they'll all still be valid. 

Bart has done a much better job than most people at trying different things,
despite the hostility he's been receiving. I don't think he's fully in
the "dynamic scripting/glue/programming language" headspace, and I still
have some disagreements with some of his opinions, but he's actually shown
himself to be quite open to concrete suggestions made.

Bart, if you're reading, can I suggest that any future benchmarks should be
relatively constrained and short, so it is easier to read and understand
them, and suggest improvements. 



> Many 
> of them won't be, yet you still persist in doing things based on what
> you expect to be the case (because of what's fast/slow in C or some
> other language). We've explained this a number of times, and one by
> one, we're coming to the conclusion that you not only don't understand
> Python, you don't *want* to understand Python; and until you actually
> understand how the language works, timing stats are dubious.
> 
> Do you understand why people aren't taking your results very seriously?

You know what is missing from this conversation?

For one of Bart's critics to actually show faster code.

There's plenty of people telling him off for writing unpythonic and slow
code, but I haven't seen anyone actually demonstrating that Python is
faster than his results show.




-- 
Steven

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

Re: newbie question

[Steven D'Aprano]

On Thu, 24 Mar 2016 09:49 pm, David Palao wrote:

> Hi,
> Use "eval":
> s = "(1, 2, 3, 4)"
> t = eval(s)

Don't use eval unless you absolutely, categorically, 100% trust the source
of the string.

Otherwise, you are letting the person who provided the string run any code
they like on your computer. You want malware? That's how you get malware.




-- 
Steven

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

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

[Chris Angelico]

On Fri, Mar 25, 2016 at 12:50 AM, Steven D'Aprano  wrote:
> On Thu, 24 Mar 2016 02:24 pm, Chris Angelico wrote:
>
>
>> This is how you're currently evaluating Python. Instead of starting
>> with the most simple and obvious code
>
> One problem is that what counts as "simple and obvious" depends on what you
> are used to. Coming from a background of Pascal, iterating over a list like
> this:
>
> for i in range(len(mylist)):
> print mylist[i]
>
> was both simple and obvious. It took me years to break myself of that habit.
>
> Likewise clearing a list:
>
> for i in range(len(mylist)-1, -1, 0):
> del mylist[i]
>
>
> Fortunately I didn't need to do that very often.
>
> The point is that you, like most of the prominent posters here, have many
> years of experience in programming in Python. How do you expect Bart to
> come up with the same "simple and obvious" code as you?

I don't, until it's pointed out. At that point, someone who respects
the language will at least pay *some* heed to the changed
recommendations; what we're seeing here is that he continues to use C
idioms and then complain that Python is slow. I don't expect him to
magically know what Python idioms are, but when the thread has gone on
this long and he's still showing the same style of code, that's when I
start to agree with Ben that he's not paying heed to Pythonic vs
non-Pythonic.

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

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

[BartC]

On 24/03/2016 13:50, Steven D'Aprano wrote:

On Thu, 24 Mar 2016 02:24 pm, Chris Angelico wrote:



This is how you're currently evaluating Python. Instead of starting
with the most simple and obvious code


One problem is that what counts as "simple and obvious" depends on what you
are used to. Coming from a background of Pascal, iterating over a list like
this:

for i in range(len(mylist)):
 print mylist[i]

was both simple and obvious. It took me years to break myself of that habit.

Likewise clearing a list:

for i in range(len(mylist)-1, -1, 0):
 del mylist[i]


That's wouldn't be I'd call clearing a list, more like destroying it 
completely!


How would you actually clear a list by traversing it (ie. not just 
building a new one)?


This doesn't work:

  for x in L:
 x=0

as each x only refers to the value in each element of L, not the element 
itself (like the pass-by-reference problem).


I'd presumably have to do:

 for i in range(len(L)):
   L[i]=0

--
Bartc

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

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

[Jon Ribbens]

On 2016-03-24, BartC  wrote:
> On 24/03/2016 13:50, Steven D'Aprano wrote:
>> Likewise clearing a list:
>>
>> for i in range(len(mylist)-1, -1, 0):
>>  del mylist[i]
>
> That's wouldn't be I'd call clearing a list, more like destroying it 
> completely!
>
> How would you actually clear a list by traversing it (ie. not just 
> building a new one)?
>
> This doesn't work:
>
>for x in L:
>   x=0
>
> as each x only refers to the value in each element of L, not the element 
> itself (like the pass-by-reference problem).
>
> I'd presumably have to do:
>
>   for i in range(len(L)):
> L[i]=0

That's kind've a weird thing to want to do; if you thought you needed
to do that then most likely what you should actually be doing is
re-writing your code so you no longer need to. However, you could do:

  L[:] = [0] * len(L)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

[BartC]

On 24/03/2016 14:08, Jon Ribbens wrote:

On 2016-03-24, BartC  wrote:

On 24/03/2016 13:50, Steven D'Aprano wrote:

Likewise clearing a list:

for i in range(len(mylist)-1, -1, 0):
  del mylist[i]


That's wouldn't be I'd call clearing a list, more like destroying it
completely!

How would you actually clear a list by traversing it (ie. not just
building a new one)?

This doesn't work:

for x in L:
   x=0

as each x only refers to the value in each element of L, not the element
itself (like the pass-by-reference problem).

I'd presumably have to do:

   for i in range(len(L)):
 L[i]=0


That's kind've a weird thing to want to do;


The thing I'm trying to demonstrate is changing an element of a list 
that you are traversing in a loop. Not necessarily set all elements to 
the same value.


 if you thought you needed

to do that then most likely what you should actually be doing is
re-writing your code so you no longer need to. However, you could do:

   L[:] = [0] * len(L)


OK, but that's just building a new list as I've already mentioned.

Or is the Pythonic way, when you want to change some elements of a list 
to just build a new one that incorporates those changes?


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

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

[Matt Wheeler]

On 24 March 2016 at 14:04, BartC  wrote:
>On 24/03/2016 13:50, Steven D'Aprano wrote:
>> for i in range(len(mylist)-1, -1, 0):
>>  del mylist[i]
>
> That's wouldn't be I'd call clearing a list, more like destroying it
> completely!

Look more closely. The semantics of using the del keyword with an
index are to delete that element. The list isn't destroyed, it just
has each element removed in turn.

The point is that one can just do `mylist.clear()`

> How would you actually clear a list by traversing it (ie. not just building
> a new one)?
>
> This doesn't work:
>
>   for x in L:
>  x=0
>
> as each x only refers to the value in each element of L, not the element
> itself (like the pass-by-reference problem).
>
> I'd presumably have to do:
>
>  for i in range(len(L)):
>L[i]=0

That doesn't clear the list, that results in a list of the same length
where every element is 0. That might sound like the same thing if
you're used to a bounded array of ints, for example, but in Python
it's very much not.

-- 
Matt Wheeler
http://funkyh.at
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

[Marko Rauhamaa]

BartC :

> And forgetting Python for a minute and concentrating only on its
> byte-code as a language in its own right, how would you go about the
> job of streamlining it?

CPython's bytecode is not crucial for CPython's execution speed. The
bytecode is mainly a method of improving the performance of loading
modules. IOW, it seeks to optimize parsing.

CPython's VM does not have to execute the bytecode as-is. It can further
compile and reprocess it internally to optimize speed and other
attributes.

As far as CPython is considered, a .pyc file contains precisely the same
information as the .py file. Thus, executing .pyc is no faster than
executing a .py file (ignoring the parsing overhead). The only advantage
of streamlining bytecode is to speed up load times, which is a complete
nonissue in most production environments.

Really, your optimization efforts should concentrate not on bytecode but
on runtime data structures, algorithms, heuristics, equivalence
transformations, reachability analysis, profiling and such.


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

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

[Jussi Piitulainen]

BartC writes:
> On 24/03/2016 14:08, Jon Ribbens wrote:
>> On 2016-03-24, BartC wrote:
>>> I'd presumably have to do:
>>>
>>>for i in range(len(L)):
>>>  L[i]=0
>>
>> That's kind've a weird thing to want to do;
>
> The thing I'm trying to demonstrate is changing an element of a list
> that you are traversing in a loop. Not necessarily set all elements to
> the same value.

You understand correctly, but it may be more natural in practice to
write it this way:

for k, item in enumerate(them):
them[k] = f(item)

I _think_ I might write it that way even when "f(item)" does not depend
on the old value at all, but I don't expect to be in that situation.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

[BartC]

On 24/03/2016 14:01, Chris Angelico wrote:


I don't, until it's pointed out. At that point, someone who respects
the language will at least pay *some* heed to the changed
recommendations; what we're seeing here is that he continues to use C
idioms and then complain that Python is slow. I don't expect him to
magically know what Python idioms are, but when the thread has gone on
this long and he's still showing the same style of code, that's when I
start to agree with Ben that he's not paying heed to Pythonic vs
non-Pythonic.


Have a look at the short thread 'Rotation' in comp.programming starting 
4-Jan-2016.


(Possible link: 
https://groups.google.com/forum/#!searchin/comp.programming/rotation/comp.programming/aQh4n2HGtaU/sSbcyjqfEQAJ)


Someone posts an algorithm in C++, I post a version in my language, 
someone else calls that a 'blub' solution and offers a much shorter 
version in /their/ language.


I point out that their solution just uses a built-in to do the work. It 
by-passes the question of the algorithm, which was the point of the 
thread. I also point out that I also gave a one-line version in my language.


What you're trying to say I guess is that such a one-liner would be 
Pythonic. And what I'm saying is that that would defeat the object of 
what I'm trying to do.


--
Bartc

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

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

[Rustom Mody]

On Thursday, March 24, 2016 at 7:46:55 PM UTC+5:30, Marko Rauhamaa wrote:
> BartC :
> 
> > And forgetting Python for a minute and concentrating only on its
> > byte-code as a language in its own right, how would you go about the
> > job of streamlining it?

> Really, your optimization efforts should concentrate not on bytecode but
> on runtime data structures, algorithms, heuristics, equivalence
> transformations, reachability analysis, profiling and such.

'A' is a scientific programmer; he optimizes his scientific programs
'C' is a financial programmer; he optimizes his finance programs
'B(art)' is a bytecode-interpreter programmer; How does he optimize his bytecode
interpreters?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

[Mark Lawrence]

On 24/03/2016 14:22, Matt Wheeler wrote:


The point is that one can just do `mylist.clear()`



Only in 3.3 and up.  In Python 2.x you have to do it the old fashioned, 
long winded way.


mylist[:] = []

--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

Re: netrc and password containing whitespace

[Random832]

On Thu, Mar 24, 2016, at 06:14, Lele Gaifax wrote:
> I tried to insert an entry in my ~/.netrc for an account having a
> password that contains a space, something like:
>
>   machine my-host-name login myname password "My Password"
>
> The standard library netrc module does not seem able to parse it,
> raising a NetrcParseError. Other programs (Emacs, to mention one) do
> the right thing with an entry like that.
>
> I was not able to lookup an exact definition of netrc's syntax, so I
> wonder: is the implementation somewhat flawed, or am I missing
> something?

The implementation seems very basic... I ran into trouble trying to
store entries with no password (with the idea in mind of having my
program prompt for the password), though, out of curiosity, does ftp
handle your quoted passwords?

Also, I'm surprised that you're using .netrc for emacs - in my
experience the file emacs uses is called .authinfo.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

[BartC]

On 24/03/2016 14:34, Jussi Piitulainen wrote:

BartC writes:

On 24/03/2016 14:08, Jon Ribbens wrote:

On 2016-03-24, BartC wrote:

I'd presumably have to do:

for i in range(len(L)):
  L[i]=0


That's kind've a weird thing to want to do;


The thing I'm trying to demonstrate is changing an element of a list
that you are traversing in a loop. Not necessarily set all elements to
the same value.


You understand correctly, but it may be more natural in practice to
write it this way:

 for k, item in enumerate(them):
 them[k] = f(item)

I _think_ I might write it that way even when "f(item)" does not depend
on the old value at all, but I don't expect to be in that situation.



Yes, you're right. Usually the update is conditional on the existing 
value. But my too-simple example would have had an unneeded item variable.


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

Re: netrc and password containing whitespace

[Lele Gaifax]

Random832  writes:

> The implementation seems very basic... I ran into trouble trying to
> store entries with no password (with the idea in mind of having my
> program prompt for the password), though, out of curiosity, does ftp
> handle your quoted passwords?

Uhm, dunno :-) I think it's been more than two decades since my last use of
FTP...

I use it as a generic auths pocket, mainly for emails and IRC. I found the
glitch adding an entry for a new account in my offlineimap configuration.

> Also, I'm surprised that you're using .netrc for emacs - in my
> experience the file emacs uses is called .authinfo.

AFAICT, that's just the default file name stored in netrc-file, the format is
really the same.

Using .netrc has the advantage that other programs can use
it, like the cited offlineimap. Aside that, the functionality is exposed in
Emacs as netrc-xxx, and comes from net/netrc.el.

Cfr. also https://www.emacswiki.org/emacs/GnusAuthinfo.

ciao, lele.
-- 
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
l...@metapensiero.it  | -- Fortunato Depero, 1929.

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

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

[Random832]

On Thu, Mar 24, 2016, at 10:49, BartC wrote:
> On 24/03/2016 14:34, Jussi Piitulainen wrote:
> > You understand correctly, but it may be more natural in practice to
> > write it this way:
> >
> >  for k, item in enumerate(them):
> >  them[k] = f(item)
> >
> > I _think_ I might write it that way even when "f(item)" does not depend
> > on the old value at all, but I don't expect to be in that situation.
> >
> 
> Yes, you're right. Usually the update is conditional on the existing 
> value. But my too-simple example would have had an unneeded item
> variable.

How about them[:] = map(f, them)?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: newbie question

[Grant Edwards]

On 2016-03-24, Steven D'Aprano  wrote:
> On Thu, 24 Mar 2016 09:49 pm, David Palao wrote:
>
>> Hi,
>> Use "eval":
>> s = "(1, 2, 3, 4)"
>> t = eval(s)
>
> Don't use eval unless you absolutely, categorically, 100% trust the source
> of the string.

And then still don't use it. :)

eval is only safe if you're passing it a literal string containing
nothing but a literal constant expression -- in which case the eval is
superflous.

OK, I admit I've used it for quick hacks on occasion.  But, I
shouldn't have.

-- 
Grant

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

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

[BartC]

On 24/03/2016 15:03, Jon Ribbens wrote:

On 2016-03-24, BartC  wrote:

On 24/03/2016 14:08, Jon Ribbens wrote:

if you thought you needed to do that then most likely what you
should actually be doing is re-writing your code so you no longer
need to. However, you could do:

L[:] = [0] * len(L)


OK, but that's just building a new list as I've already mentioned.


No it isn't, it's replacing the elements in-place,


Replace them with what, if not an entirely new list built from 
'[0]*len(L)'? (And which would briefly require twice the memory occupied 
by the old list, if I'm not mistaken.)



Or is the Pythonic way, when you want to change some elements of a list
to just build a new one that incorporates those changes?


I think it would depend on how many elements you were changing and
why. It doesn't come up all that often because of the ease in which
Python functions can return multiple values but sometimes you might
make a function which takes as a parameter a list which the function
will mutate.


Answering my own question, obviously changing some elements of a list 
has to be Pythonic, otherwise there wouldn't be lists, only non-mutable 
tuples. Although I was talking more within the context of a for-in loop.


--
Bartc


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

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

[Jon Ribbens]

On 2016-03-24, BartC  wrote:
> On 24/03/2016 15:03, Jon Ribbens wrote:
>> On 2016-03-24, BartC  wrote:
>>> On 24/03/2016 14:08, Jon Ribbens wrote:
 if you thought you needed to do that then most likely what you
 should actually be doing is re-writing your code so you no longer
 need to. However, you could do:

 L[:] = [0] * len(L)
>>>
>>> OK, but that's just building a new list as I've already mentioned.
>>
>> No it isn't, it's replacing the elements in-place,
>
> Replace them with what, if not an entirely new list built from 
> '[0]*len(L)'? (And which would briefly require twice the memory occupied 
> by the old list, if I'm not mistaken.)

It's replacing them with elements from an entirely new list, which is
then discarded, and only the original list remains.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

[Jon Ribbens]

On 2016-03-24, BartC  wrote:
> On 24/03/2016 14:08, Jon Ribbens wrote:
>> if you thought you needed to do that then most likely what you
>> should actually be doing is re-writing your code so you no longer
>> need to. However, you could do:
>>
>>L[:] = [0] * len(L)
>
> OK, but that's just building a new list as I've already mentioned.

No it isn't, it's replacing the elements in-place, that's what the
"L[:]" bit means. Replacing the list object itself would be:
L = [0] * len(L)

> Or is the Pythonic way, when you want to change some elements of a list 
> to just build a new one that incorporates those changes?

I think it would depend on how many elements you were changing and
why. It doesn't come up all that often because of the ease in which
Python functions can return multiple values but sometimes you might
make a function which takes as a parameter a list which the function
will mutate.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

[Ned Batchelder]

On Thursday, March 24, 2016 at 9:51:11 AM UTC-4, Steven D'Aprano wrote:
> You know what is missing from this conversation?
> 
> For one of Bart's critics to actually show faster code.
> 
> There's plenty of people telling him off for writing unpythonic and slow
> code, but I haven't seen anyone actually demonstrating that Python is
> faster than his results show.

As I mentioned before, I'm happy to explain the fuller Python way to
write code, but I don't think Bart wants to learn it, because he is
focused on a different goal than, "write real Python code the best
possible way."

Here, for example, is a real lexer for JavaScript that I wrote:
https://bitbucket.org/ned/jslex/src

It makes heavy use of regexes to go fast.  I don't have benchmarks
against other implementations unfortunately.

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

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

[Random832]

On Thu, Mar 24, 2016, at 11:18, BartC wrote:
> On 24/03/2016 15:03, Jon Ribbens wrote:
> > No it isn't, it's replacing the elements in-place,
> 
> Replace them with what, if not an entirely new list built from 
> '[0]*len(L)'?

Well, the *contents* of such a list, obviously. But the original list's
contents are replaced, meaning that e.g. all other references to the
list remain valid etc.

> (And which would briefly require twice the memory occupied 
> by the old list, if I'm not mistaken.)

Sure, *briefly*. And if you really care about that, you can do L[:] = (0
for x in L); or itertools.repeat(0, len(L)).
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Connect to Default Printer

[Terry Reedy]

On 3/23/2016 8:39 PM, Bryon Fawcett wrote:


Could you please advise me how to connect the python software to my default
printer.


IDLE prints to default printer with function print_window in 
idlelib/IOBinding.py.  The two GetOption calls return these two strings 
(from config-main.def).


For print-command-posix, 'lpr %s'
For print-command-win, 'start /min notepad /p %s'

You should be able to adapt to your needs.  Perhaps you do not need the 
messageboxes.


--
Terry Jan Reedy

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

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

[BartC]

On 24/03/2016 15:30, Ned Batchelder wrote:

On Thursday, March 24, 2016 at 9:51:11 AM UTC-4, Steven D'Aprano wrote:

You know what is missing from this conversation?

For one of Bart's critics to actually show faster code.

There's plenty of people telling him off for writing unpythonic and slow
code, but I haven't seen anyone actually demonstrating that Python is
faster than his results show.


As I mentioned before, I'm happy to explain the fuller Python way to
write code, but I don't think Bart wants to learn it, because he is
focused on a different goal than, "write real Python code the best
possible way."

Here, for example, is a real lexer for JavaScript that I wrote:
https://bitbucket.org/ned/jslex/src



Thanks for that.

I don't have any JS to throw at it, but it seems happy with any bits of 
source code or even just text.


Using your short driver program (with the prints commented out), and 
tested with 'bible.txt' as input (ie. mostly English words), then your 
JS lexer was roughly half the speed of the Python version I linked to 
last week (with the if-elif chains and working with strings).


Both tested with 2.7.x. Using PyPy speeded both versions up about 3 times.

Your code however is more beautiful than mine...

> It makes heavy use of regexes to go fast.  I don't have benchmarks
> against other implementations unfortunately.

(A rough lines-per-second figure would give a general idea.)

--
Bartc

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

Re: Key Binding Problem

[Wildman via Python-list]

On Thu, 24 Mar 2016 08:06:28 -0400, Dennis Lee Bieber wrote:

> On Wed, 23 Mar 2016 21:17:57 -0500, Wildman via Python-list
>  declaimed the following:
> 
>>
>>I was referring to procedures called by a button click as
>>opposed to a procedure calledd from elsewhere in the code.
>>I guess there is no difference.  I assume that is what you
>>meant.
> 
>   I'd have to see /how/ it is called. The "button click" is an event
> handled by the GUI framework, to which you've bound a handler. Such items
> (which may be attached to resize, menu, text fields, etc.) would need the
> structure the framework uses... So if a method of a class, that means a
> first argument placeholder of "self", and most likely a second for some
> "event" data structure. You'd have to check the documentation for what it
> expects.
> 
>   callback by framework:  theButton.pressed((clock, x, y))
>   defined as: def pressed(self, 
> event):
>   (granted, having the mouse x/y coordinates may not mean much for a
> screen button)
> 
>   callback by framework:  mouseHandler.move((clock, x, y, lmb, rmb, mmb))
>   defined as: def move(self, event):
>   (xmb is left/right/middle mouse button state)
> 
> 
>   But if it is not being called by the framework, the arrangement/number
> of arguments is under your control. If it is a method of a class instance,
> it will receive the instance object as the first argument:
> object.method(arglist) => method(self, arglist) {where self IS object}.

I believe I understand.  Thanks.  If you can't tell, I'm new to
Python so the learning process is on-going.

-- 
 GNU/Linux user #557453
The cow died so I don't need your bull!
-- 
https://mail.python.org/mailman/listinfo/python-list

Python

[Niyoo *Unkown*]

The reason I uninstalled Python was because it was 32 bit not 64 bit and I
couldn't find the 64 bit version.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python

[alister]

On Thu, 24 Mar 2016 12:21:29 -0400, Niyoo *Unkown* wrote:

> The reason I uninstalled Python was because it was 32 bit not 64 bit and
> I couldn't find the 64 bit version.

that's nice



-- 
That which is not good for the swarm, neither is it good for the bee.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python

[Zachary Ware]

On Thu, Mar 24, 2016 at 11:21 AM, Niyoo *Unkown*
 wrote:
> The reason I uninstalled Python was because it was 32 bit not 64 bit and I
> couldn't find the 64 bit version.

Have a look at this page: https://www.python.org/downloads/windows/

The 64 bit versions are the "x86_64" ones.

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

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

[Ned Batchelder]

On Thursday, March 24, 2016 at 12:12:55 PM UTC-4, BartC wrote:
> On 24/03/2016 15:30, Ned Batchelder wrote:
> > On Thursday, March 24, 2016 at 9:51:11 AM UTC-4, Steven D'Aprano wrote:
> >> You know what is missing from this conversation?
> >>
> >> For one of Bart's critics to actually show faster code.
> >>
> >> There's plenty of people telling him off for writing unpythonic and slow
> >> code, but I haven't seen anyone actually demonstrating that Python is
> >> faster than his results show.
> >
> > As I mentioned before, I'm happy to explain the fuller Python way to
> > write code, but I don't think Bart wants to learn it, because he is
> > focused on a different goal than, "write real Python code the best
> > possible way."
> >
> > Here, for example, is a real lexer for JavaScript that I wrote:
> > https://bitbucket.org/ned/jslex/src
> >
> 
> Thanks for that.
> 
> I don't have any JS to throw at it, but it seems happy with any bits of 
> source code or even just text.
> 
> Using your short driver program (with the prints commented out), and 
> tested with 'bible.txt' as input (ie. mostly English words), then your 
> JS lexer was roughly half the speed of the Python version I linked to 
> last week (with the if-elif chains and working with strings).

I have tried to find your code, but cannot find in the forest of this thread.
Can you provide a link to it online?  I would be very interested to understand
the difference in performance.

Thanks,

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

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

[Steven D'Aprano]

On Fri, 25 Mar 2016 01:04 am, BartC wrote:

> On 24/03/2016 13:50, Steven D'Aprano wrote:
>> On Thu, 24 Mar 2016 02:24 pm, Chris Angelico wrote:
>>
>>
>>> This is how you're currently evaluating Python. Instead of starting
>>> with the most simple and obvious code
>>
>> One problem is that what counts as "simple and obvious" depends on what
>> you are used to. Coming from a background of Pascal, iterating over a
>> list like this:
>>
>> for i in range(len(mylist)):
>>  print mylist[i]
>>
>> was both simple and obvious. It took me years to break myself of that
>> habit.
>>
>> Likewise clearing a list:
>>
>> for i in range(len(mylist)-1, -1, 0):
>>  del mylist[i]
> 
> That's wouldn't be I'd call clearing a list, more like destroying it
> completely!

No, the list still exists, and mylist (the name) is still bound to it. It is
just an empty list (length zero).


> How would you actually clear a list by traversing it (ie. not just
> building a new one)?

The two "right ways" of clearing a list (i.e. setting it to an empty list)
is to use slice assignment:

mylist[:] = []

or call the mylist.clear() method.


> This doesn't work:
> 
>for x in L:
>   x=0
> 
> as each x only refers to the value in each element of L, not the element
> itself (like the pass-by-reference problem).

Correct, except I wouldn't call it a problem. That's just not how Python
semantics work. I only know of a handful of languages that support
pass-by-reference:

Pascal
C++
Visual Basic
Some other Basics (maybe? I'm not sure)
Algol (actually pass-by-name)

 
> I'd presumably have to do:
> 
>   for i in range(len(L)):
> L[i]=0

I wouldn't describe that as "clearing the list". It is merely setting the
existing values to some known quantity which happens to be zero. Why zero?
Why not None, or 99, or float("nan")? (Don't answer that, it's a rhetorical
question.)

In any case, I would expect that the most efficient way to set all the list
values to a particular value would be:

mylist[:] = [0]*len(mylist)

Let's find out. On my computer, using Python 3.3:


py> mylist = list(range(10))
py> with Stopwatch():
... mylist[:] = [0]*len(mylist)
...
time taken: 0.005215 seconds


Compared to:

py> mylist = list(range(10))
py> with Stopwatch():
... for i in range(len(mylist)):
... mylist[i] = 0
...
time taken: 0.037431 seconds



That's a difference of about an order of magnitude.


The Stopwatch function used for timing is very nearly the same as the recipe
posted here:

https://code.activestate.com/recipes/577896-benchmark-code-with-the-with-statement/



-- 
Steven

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

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

[Steven D'Aprano]

On Fri, 25 Mar 2016 01:16 am, BartC wrote:

> Or is the Pythonic way, when you want to change some elements of a list
> to just build a new one that incorporates those changes?


If you are only changing a few elements, or one at a time in some random
order, then just change the element. Lists have random access, so you can
easily change a single item:

mylist[975] = "Hello world"


But if you intend to change the entire list, *in general* it is faster to
create a new list and copy the items into the old list. This is called
*slicing*, to be specific, we're assigning to a "slice" corresponding to
the entire list:

mylist[:] = newlist

But we don't have to assign to the entire list. We can assign to a sublist:

mylist[2:102] = newlist

and mylist will shrink or expand as needed.

It is most convenient to use the list replication operator * to build the
new list:

[0, 1]*100  # like [0, 1, 0, 1, 0, 1, 0, 1, ... , 0, 1]

or a list comprehension:

[i**2 for i in range(100)]  # like [0**2, 1**2, 2**2, 3**3, 4**2, ... 99**2]


But most of the time you might not even care about modifying the list in
place. Why spend the time to copy the new list over? Just reassign the
variable to the new list.


mylist = [i**2 for i in range(100)]



The difference between mylist = ... and mylist[:] = ... comes down to what
happens to other references. Suppose you have some object with a list
attribute:


instance.data = [1, 2, 3]

Now we bind that list to another name (say, you pass it to a function, where
the list gets assigned to a local variable):

mylist = instance.data


mylist and instance.data both "point to" the same underlying list object.
Modifications to one will be seen by the other, as they both refer to the
same list. If you do 

mylist[:] = ...

that is an in-place modification of the list, and will be seen by all
references to that list. But if you do 

mylist = ...

that is a binding operation, and it reassigns the name "mylist" without
touching the list object itself, or the instance.data reference.

Analogy: if Barack Obama cuts himself shaving, the POTUS will have the same
cut, because they are one and the same person (at least for now). But in
another year or so, if Obama cuts himself, the POTUS will not notice,
because the name POTUS will have been rebound to a different person.


-- 
Steven

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

Re: newbie question

[Sven R. Kunze]

On 24.03.2016 14:22, Matt Wheeler wrote:

On Thu, 24 Mar 2016 11:10 Sven R. Kunze,  wrote:


On 24.03.2016 11:57, Matt Wheeler wrote:

import ast
s = "(1, 2, 3, 4)"
t = ast.literal_eval(s)
t

(1, 2, 3, 4)

I suppose that's the better solution in terms of safety.


It has the added advantage that the enquirer gets to import a module that
shares their name ;)


One shouldn't underestimate this. ;-)
--
https://mail.python.org/mailman/listinfo/python-list

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

[Steven D'Aprano]

On Fri, 25 Mar 2016 02:03 am, Jon Ribbens wrote:

> On 2016-03-24, BartC  wrote:
>> On 24/03/2016 14:08, Jon Ribbens wrote:
>>> if you thought you needed to do that then most likely what you
>>> should actually be doing is re-writing your code so you no longer
>>> need to. However, you could do:
>>>
>>>L[:] = [0] * len(L)
>>
>> OK, but that's just building a new list as I've already mentioned.
> 
> No it isn't, it's replacing the elements in-place, that's what the
> "L[:]" bit means. Replacing the list object itself would be:
> L = [0] * len(L)

Yes it is: a new list is built, copied, then discarded.

Python builds the [0]*len(L) list first, then copies the elements from it
into the existing L (which in CPython is just a fast memcopy of a whole
bunch of pointers, plus a resize of L), then garbage collects the new list.

A *sufficiently smart* Python interpreter might be able to optimize that
even further, but since it's just copying pointers from one array to
another, it's already pretty quick.

I imagine that, if you had enough memory, a *sufficiently enormous* list
would actually be faster to modify in place using the Pascal-ish idiom:

for i in range(len(L)):
L[i] = 0


rather than building a temporary list and copying it. But I've never been
able to demonstrate that: no matter how big a list I created, it was always
faster to create a second one and then do slice assignment than to iterate
over it in a for loop changing each item in place.

This demonstrates that what logically ought to be more efficient (changing
values in place) is not necessarily *actually* more efficient.



-- 
Steven

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

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

[BartC]

On 24/03/2016 17:13, Ned Batchelder wrote:

On Thursday, March 24, 2016 at 12:12:55 PM UTC-4, BartC wrote:

On 24/03/2016 15:30, Ned Batchelder wrote:

On Thursday, March 24, 2016 at 9:51:11 AM UTC-4, Steven D'Aprano wrote:

You know what is missing from this conversation?

For one of Bart's critics to actually show faster code.

There's plenty of people telling him off for writing unpythonic and slow
code, but I haven't seen anyone actually demonstrating that Python is
faster than his results show.


As I mentioned before, I'm happy to explain the fuller Python way to
write code, but I don't think Bart wants to learn it, because he is
focused on a different goal than, "write real Python code the best
possible way."

Here, for example, is a real lexer for JavaScript that I wrote:
https://bitbucket.org/ned/jslex/src



Thanks for that.

I don't have any JS to throw at it, but it seems happy with any bits of
source code or even just text.

Using your short driver program (with the prints commented out), and
tested with 'bible.txt' as input (ie. mostly English words), then your
JS lexer was roughly half the speed of the Python version I linked to
last week (with the if-elif chains and working with strings).


I have tried to find your code, but cannot find in the forest of this thread.
Can you provide a link to it online?  I would be very interested to understand
the difference in performance.


This the version I used today:

http://pastebin.com/dtM8WnFZ

(others I've experimented with aren't much faster or slower.)

Testing it with lots of C source, the difference is narrower.

(Note that the two will be doing different jobs; one or two things are 
not complete on mine, such as the final calculation for floating point 
literals. And the number of tokens read is a bit different. But then 
they are expecting a different language.


Also, I only tested with large monolithic files (to make measuring easier).

In terms of getting through the same amount of input however, I think 
the comparisons aren't too far off.)


This is the test code I used for your JS lexer:

"""A main program for jslex."""

import sys
from jslex import JsLexer

def show_js_tokens(jstext, ws=False):
line = 1
lexer = JsLexer()
n=0
for name, tok in lexer.lex(jstext):
n+=1
#print_it = True
#if name == 'ws' and not ws:
#print_it = False
#if print_it:
#print "%4d %s: %r" % (line, name, tok)
line += tok.count("\n")
print line,n

if __name__ == '__main__':
file="bigpy"
#file="sqlite"
#file="bible.txt"

show_js_tokens(open(file).read())

--
Bartc

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

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

[Steven D'Aprano]

On Fri, 25 Mar 2016 12:01 am, BartC wrote:

> But there are all sorts of micro-micro-benchmarks that can concentrate
> on a single byte-code. For example, how long does it take to call an
> empty function with no parameters? Just putting such a call into a
> simple loop can be effective:
>
> Python 3 (on Windows) might take 200ns. Clisp is 1300ns (interpreted,
> presumably). Ruby 170ns. Lua 80ns. Mine 10-20ns. Unoptimised C is 4ns,
> but this is not executing code indirectly as most of the rest have to.

"Might"? Are you making those numbers up?

> [Timings include loop overheads that need to be factored out.]

Then those numbers are pointless. The Python figure, for example, might be
199ns for the loop overhead and 1ns for the function call, or 1ns for the
loop overhead and 199ns for the function call. Or anything in between. How
do you know which is which?

> So there might be room for improvement, but those faster languages are
> also simpler. 

Right.

Let's compare two almost identical looking lines in Python and C:

y = x + 1

y = x + 1;


Apart from the semi-colon, they do exactly the same thing, right?

Well, no. Not even close.

In the case of C, the line is limited to working with some specific type
(say, an int32). Even there, if the addition might overflow, the behaviour
is undefined and the compiler can do anything it wants (including time
travel, or erasing your hard disk).

In the case of Python, the line will work with a potentially infinite number
of types: int, float, complex, Fraction, Decimal, subclasses of all the
above, custom numeric types, and anything else that quacks like a number.
There's no undefined behaviour: at worst, you will get an exception.
There's no integer overflow: you can set x = 10**100 and add one to it, and
the result will be mathematically exact.

Even though the two lines *look* the same, they are as different as chalk
and cheese. If you wrote C code that had the same semantics as the Python
code, chances are it wouldn't be much faster than Python.

This shouldn't be surprising. Python, or at least the standard CPython
interpreter, is written in C. It is, effectively, a DSL ("Domain Specific
Language") for C: all the things which are hard in C, like memory
management, polymorphic code, not segfaulting, etc., are handled for you.

So yes, faster languages are often simpler. They are fast because they do
less. As the saying goes, the fastest code is the code that isn't run.



> Is Python's richness or dynamism the main factor here? If 
> so there is probably little to be done; if not... This is where the fun
> starts.
> 
> But I understand that most people aren't interested in this kind of sport.

Checkout the benchmark game:

http://benchmarksgame.alioth.debian.org/




-- 
Steven

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

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

[alister]

On Thu, 24 Mar 2016 14:04:53 +, BartC wrote:

> On 24/03/2016 13:50, Steven D'Aprano wrote:
>> On Thu, 24 Mar 2016 02:24 pm, Chris Angelico wrote:
>>
>>
>>> This is how you're currently evaluating Python. Instead of starting
>>> with the most simple and obvious code
>>
>> One problem is that what counts as "simple and obvious" depends on what
>> you are used to. Coming from a background of Pascal, iterating over a
>> list like this:
>>
>> for i in range(len(mylist)):
>>  print mylist[i]
>>
>> was both simple and obvious. It took me years to break myself of that
>> habit.
>>
>> Likewise clearing a list:
>>
>> for i in range(len(mylist)-1, -1, 0):
>>  del mylist[i]
> 
> That's wouldn't be I'd call clearing a list, more like destroying it
> completely!
> 
> How would you actually clear a list by traversing it (ie. not just
> building a new one)?
> 
> This doesn't work:
> 
>for x in L:
>   x=0
> 
> as each x only refers to the value in each element of L, not the element
> itself (like the pass-by-reference problem).
> 
> I'd presumably have to do:
> 
>   for i in range(len(L)):
> L[i]=0

close
I would suggest the following pastern is more "Pythonic" although 
possibly overkill for this scenario

a=[1,2,3,4,5]
for i,x in enumerate(a):
a[i]=None




-- 
Practice yourself what you preach.
-- Titus Maccius Plautus
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

[alister]

On Thu, 24 Mar 2016 14:28:32 +, BartC wrote:

> On 24/03/2016 14:01, Chris Angelico wrote:
> 
>> I don't, until it's pointed out. At that point, someone who respects
>> the language will at least pay *some* heed to the changed
>> recommendations; what we're seeing here is that he continues to use C
>> idioms and then complain that Python is slow. I don't expect him to
>> magically know what Python idioms are, but when the thread has gone on
>> this long and he's still showing the same style of code, that's when I
>> start to agree with Ben that he's not paying heed to Pythonic vs
>> non-Pythonic.
> 
> Have a look at the short thread 'Rotation' in comp.programming starting
> 4-Jan-2016.
> 
> (Possible link:
> https://groups.google.com/forum/#!searchin/comp.programming/rotation/
comp.programming/aQh4n2HGtaU/sSbcyjqfEQAJ)
> 
> Someone posts an algorithm in C++, I post a version in my language,
> someone else calls that a 'blub' solution and offers a much shorter
> version in /their/ language.
> 
> I point out that their solution just uses a built-in to do the work. It
> by-passes the question of the algorithm, which was the point of the
> thread. I also point out that I also gave a one-line version in my
> language.
> 
> What you're trying to say I guess is that such a one-liner would be
> Pythonic. And what I'm saying is that that would defeat the object of
> what I'm trying to do.

if you're trying to demonstrate the deficiency of one algorithm over 
another then you should be testing them in the same language.

If you are trying to compare one language to another then the task should 
be written in the most efficient means for then language.
language "A" has a builtin function "X" where as language "B" does not, 
that just shows that "A" is better suited to the task than "B", "B" 
probably has other areas where "A" is not so good.

otherwise why not wright in assembler/machine code which has to be the 
most efficient language (because all the others eventually fall back to 
executing these processor instructions anyway




-- 
We're constantly being bombarded by insulting and humiliating music, which
people are making for you the way they make those Wonder Bread products.
Just as food can be bad for your system, music can be bad for your 
spirtual
and emotional feelings.  It might taste good or clever, but in the long 
run,
it's not going to do anything for you.
-- Bob Dylan, "LA Times", September 5, 1984
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

[Jon Ribbens]

On 2016-03-24, Steven D'Aprano  wrote:
> On Fri, 25 Mar 2016 02:03 am, Jon Ribbens wrote:
>> On 2016-03-24, BartC  wrote:
>>> On 24/03/2016 14:08, Jon Ribbens wrote:
 if you thought you needed to do that then most likely what you
 should actually be doing is re-writing your code so you no longer
 need to. However, you could do:

L[:] = [0] * len(L)
>>>
>>> OK, but that's just building a new list as I've already mentioned.
>> 
>> No it isn't, it's replacing the elements in-place, that's what the
>> "L[:]" bit means. Replacing the list object itself would be:
>> L = [0] * len(L)
>
> Yes it is: a new list is built, copied, then discarded.

Obviously (as already mentioned in my earlier reply). But the point is
that it is not "just building a new list", as if that were true then L
would not be pointing to the same list afterwards.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

[Michael Torrie]

On 03/21/2016 06:43 AM, BartC wrote:
> On 21/03/2016 12:08, Ned Batchelder wrote:
>> On Sunday, March 20, 2016 at 9:15:32 PM UTC-4, BartC wrote:
>>>
>>> A tokeniser along those lines in Python, with most of the bits filled
>>> in, is here:
>>>
>>> http://pastebin.com/dtM8WnFZ
>>>
>>
>> Bart, we get it: you don't like the trade-offs that Python has made.
> ...
>> You don't like Python.  Can we leave it at that?
> 
> On the contrary, I do like it. It's just a shame it's made those 
> trade-offs as a bit more speed would have made it more useful to me.

Have you looked at compiled, python-inspired languages like Num
(http://nim-lang.org/). If it's syntax you like and some other Python
things like for the for loop works, maybe something like this would be
useful to you.

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

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

[BartC]

On 24/03/2016 18:10, Steven D'Aprano wrote:

On Fri, 25 Mar 2016 12:01 am, BartC wrote:



Python 3 (on Windows) might take 200ns. Clisp is 1300ns (interpreted,
presumably). Ruby 170ns. Lua 80ns. Mine 10-20ns. Unoptimised C is 4ns,
but this is not executing code indirectly as most of the rest have to.


"Might"? Are you making those numbers up?


No.


[Timings include loop overheads that need to be factored out.]


Then those numbers are pointless.


Yes, they would need some adjustment to do this stuff properly. FWIW the 
loop overheads were about 30% in Python, 40% in Ruby, and 20% in mine.



The Python figure, for example, might be
199ns for the loop overhead and 1ns for the function call, or 1ns for the
loop overhead and 199ns for the function call. Or anything in between. How
do you know which is which?


It sounds like they would both need some work!


So there might be room for improvement, but those faster languages are
also simpler.



In the case of C, the line is limited to working with some specific type
(say, an int32). Even there, if the addition might overflow, the behaviour
is undefined and the compiler can do anything it wants (including time
travel,


I'm pretty sure it can't do time travel...

 or erasing your hard disk).


In the case of Python, the line will work with a potentially infinite number
of types: int, float, complex, Fraction, Decimal, subclasses of all the
above, custom numeric types, and anything else that quacks like a number.


Yes, it has to do some dynamic type dispatch. All the languages except C 
were dynamic (C cheats in so many ways).


However, my bit of code (a for-loop calling an empty function) doesn't 
on the surface, do anything that requires type dispatch, or does it?


This is where we come to the first differences between how Python works 
and how, say, my language works (I don't know about Lua, Ruby and Lisp.)


Python bytecode for empty function bill():

 4   0 LOAD_CONST   0 (None)
 3 RETURN_VALUE

Inner loop calling bill():

>>   13 FOR_ITER13 (to 29)
 16 STORE_FAST   0 (n)

  8  19 LOAD_GLOBAL  1 (bill)
 22 CALL_FUNCTION0 (0 positional... )
 25 POP_TOP
 26 JUMP_ABSOLUTE   13


My bytecode for function bill():

0: 000   - return

My inner loop bytecode:

1: 005  %4:
1: 006   - call [&t.bill], 0
1: 006   - to_f %4, [t.start.av$1:-1]


Half the explanation is right here: I use 1 op in the function, and 2 in 
the loop. Python uses 2 in the function, and 6 in the loop.


(I use a dedicated repeat-N-times loop that needs no explicit loop 
variable, only an internal integer count. I use a special 'proc' form of 
function with no return value. And I use static functions so the 
byte-code knows the function being called, and knows it returns no value 
that needs to be popped.)


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

Tkinter --> Why multiple windows

[kevind0718]

Hello:

newbie Tkinter question

If I run the code below two windows appear.
One empty and one with the text box and button.

Why?  please

KD



from Tkinter import *

class MyDialog:
def __init__(self, parent):

top = self.top = Toplevel(parent)

Label(top, text="Value").pack()

self.e = Entry(top)
self.e.pack(padx=5)

b = Button(top, text="OK", command=self.ok)
b.pack(pady=5)

def ok(self):

print "value is", self.e.get()

self.top.destroy()


root = Tk()

d = MyDialog(root)

root.wait_window(d.top)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Tkinter --> Why multiple windows

[Random832]

On Thu, Mar 24, 2016, at 16:24, kevind0...@gmail.com wrote:
> Hello:
> 
> newbie Tkinter question
> 
> If I run the code below two windows appear.
> One empty and one with the text box and button.

The empty one is the root window.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Tkinter --> Why multiple windows

[kevind0718]

On Thursday, March 24, 2016 at 4:29:03 PM UTC-4, Random832 wrote:
> On Thu, Mar 24, 2016, at 16:24, kevind0...@gmail.com wrote:
> > Hello:
> > 
> > newbie Tkinter question
> > 
> > If I run the code below two windows appear.
> > One empty and one with the text box and button.
> 
> The empty one is the root window.

I kinda guessed that.  
Is there any downside to hiding it using root.withdraw().

thanks for quick responce.

KD



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

[OT'ish] Is there a list as good as this for Javascript

[cl]

I use Python wherever I can and find this list (as a usenet group via
gmane) an invaluable help at times.

Occasionally I have to make forays into Javascript, can anyone
recommend a place similar to this list where Javascript questions can
be asked?  The trouble is that there are very many usenet Javascript
lists and it's difficult to guess which one[es] might be good.

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

Re: [OT'ish] Is there a list as good as this for Javascript

[Grant Edwards]

On 2016-03-24, c...@isbd.net  wrote:

> I use Python wherever I can and find this list (as a usenet group
> via gmane) an invaluable help at times.
>
> Occasionally I have to make forays into Javascript, can anyone
> recommend a place similar to this list where Javascript questions
> can be asked?

Are you asking about

 1) Javascript itself (the language)?

 2) jQuery or some other client-side framework?

 3) The DOM model and API provided by various web browsers?

In most forums 99% of the threads are about 2 and 3.

> The trouble is that there are very many usenet Javascript lists and
> it's difficult to guess which one[es] might be good.

That's a tough one.  I dabble in Javascript in order to support the
Web UI's on some of the embedded products I work on, and I've yet to
find a high quality forum for Javascript questions.  Javascript
programing seems to be dominated by cargo-cult programmers with little
understanding of the language.  They just sort of cut-n-paste code
snippets they find online and then hope.  It's not quite as bad as PHP
in that regard, but that's not saying mutch.  [IMO, the design of the
Javascript language itself is _far_ better than the "design" of the
PHP language, and that the results of cargo-cult programming in
Javascript usually turn out better than they do in PHP.]

If you do find anything like c.l.p for Javascript, let us know...

-- 
Grant Edwards   grant.b.edwardsYow! I'm sitting on my
  at   SPEED QUEEN ... To me,
  gmail.comit's ENJOYABLE ... I'm WARM
   ... I'm VIBRATORY ...
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

[Mark Lawrence]

On 24/03/2016 19:54, BartC wrote:

On 24/03/2016 18:10, Steven D'Aprano wrote:

On Fri, 25 Mar 2016 12:01 am, BartC wrote:




Then those numbers are pointless.


Yes, they would need some adjustment to do this stuff properly.


Please give up before you get sued by the families of the people who 
have died laughing.


--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

Re: [OT'ish] Is there a list as good as this for Javascript

[cl]

Grant Edwards  wrote:
> On 2016-03-24, c...@isbd.net  wrote:
> 
> > I use Python wherever I can and find this list (as a usenet group
> > via gmane) an invaluable help at times.
> >
> > Occasionally I have to make forays into Javascript, can anyone
> > recommend a place similar to this list where Javascript questions
> > can be asked?
> 
> Are you asking about
> 
>  1) Javascript itself (the language)?
> 
Probably mostly this.

>  2) jQuery or some other client-side framework?
> 
A little of this, but not much.


>  3) The DOM model and API provided by various web browsers?
> 
Not this.


> In most forums 99% of the threads are about 2 and 3.
> 
> > The trouble is that there are very many usenet Javascript lists and
> > it's difficult to guess which one[es] might be good.
> 
> That's a tough one.  I dabble in Javascript in order to support the
> Web UI's on some of the embedded products I work on, and I've yet to
> find a high quality forum for Javascript questions.  Javascript
> programing seems to be dominated by cargo-cult programmers with little
> understanding of the language.  They just sort of cut-n-paste code
> snippets they find online and then hope.  It's not quite as bad as PHP
> in that regard, but that's not saying mutch.  [IMO, the design of the
> Javascript language itself is _far_ better than the "design" of the
> PHP language, and that the results of cargo-cult programming in
> Javascript usually turn out better than they do in PHP.]
> 
Yes, it seems that the 'right way' in Javascript is often almost the
opposite of the 'right way' in other langueages.  Optimise at the
expense of readability seems to be the main aim.


> If you do find anything like c.l.p for Javascript, let us know...
> 
OK!  :-)

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

Re: [OT'ish] Is there a list as good as this for Javascript

[Mark Lawrence]

On 24/03/2016 22:08, c...@isbd.net wrote:



If you do find anything like c.l.p for Javascript, let us know...


OK!  :-)



I'd try c.l.bartc as he is the world's leading expert on everything that 
you need to know about any language, whereby the only thing to know is 
how fast is it.  It's just fantastic, you don't have to bother about the 
source code that you write, all you have to bother about is the 
underlying byte code.


--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

[Mark Lawrence]

On 24/03/2016 14:37, Rustom Mody wrote:

On Thursday, March 24, 2016 at 7:46:55 PM UTC+5:30, Marko Rauhamaa wrote:

BartC :


And forgetting Python for a minute and concentrating only on its
byte-code as a language in its own right, how would you go about the
job of streamlining it?



Really, your optimization efforts should concentrate not on bytecode but
on runtime data structures, algorithms, heuristics, equivalence
transformations, reachability analysis, profiling and such.


'A' is a scientific programmer; he optimizes his scientific programs
'C' is a financial programmer; he optimizes his finance programs
'B(art)' is a bytecode-interpreter programmer; How does he optimize his bytecode
interpreters?



'A' makes sure as best they can that their program is correct.
'C' makes sure as best they can that their program is correct.
'B' doesn't care provided it is quick.

--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

[Mark Lawrence]

On 12/03/2016 01:16, BartC wrote:

Please go and play with this.

https://www.ibm.com/developerworks/community/blogs/jfp/entry/A_Comparison_Of_C_Julia_Python_Numba_Cython_Scipy_and_BLAS_on_LU_Factorization?lang=en

--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

Re: [OT'ish] Is there a list as good as this for Javascript

[Chris Angelico]

On Fri, Mar 25, 2016 at 9:31 AM, Mark Lawrence  wrote:
> On 24/03/2016 22:08, c...@isbd.net wrote:
>>
>>
>>> If you do find anything like c.l.p for Javascript, let us know...
>>>
>> OK!  :-)
>>
>
> I'd try c.l.bartc as he is the world's leading expert on everything that you
> need to know about any language, whereby the only thing to know is how fast
> is it.  It's just fantastic, you don't have to bother about the source code
> that you write, all you have to bother about is the underlying byte code.

Enough. You don't need to drag this into arbitrary threads.

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

Re: [OT'ish] Is there a list as good as this for Javascript

[cl]

Mark Lawrence  wrote:
> On 24/03/2016 22:08, c...@isbd.net wrote:
> >
> >> If you do find anything like c.l.p for Javascript, let us know...
> >>
> > OK!  :-)
> >
> 
> I'd try c.l.bartc as he is the world's leading expert on everything that 
> you need to know about any language, whereby the only thing to know is 
> how fast is it.  It's just fantastic, you don't have to bother about the 
> source code that you write, all you have to bother about is the 
> underlying byte code.
> 
Many a true word.

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

Re: [OT'ish] Is there a list as good as this for Javascript

[Mark Lawrence]

On 24/03/2016 22:49, Chris Angelico wrote:

On Fri, Mar 25, 2016 at 9:31 AM, Mark Lawrence  wrote:

On 24/03/2016 22:08, c...@isbd.net wrote:




If you do find anything like c.l.p for Javascript, let us know...


OK!  :-)



I'd try c.l.bartc as he is the world's leading expert on everything that you
need to know about any language, whereby the only thing to know is how fast
is it.  It's just fantastic, you don't have to bother about the source code
that you write, all you have to bother about is the underlying byte code.


Enough. You don't need to drag this into arbitrary threads.

ChrisA



No.  While this idiot, BartC, is let loose on this forum, I'll say what 
I like.  It is quite clear that he hasn't got the faintest idea, and the 
sooner he is kicked into touch, like the RUE, the better for the Python 
community.


"I'll just factor out the loop in this test".

Yeah, right.

--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

Re: [OT'ish] Is there a list as good as this for Javascript

[Mark Lawrence]

On 24/03/2016 22:45, c...@isbd.net wrote:

Mark Lawrence  wrote:

On 24/03/2016 22:08, c...@isbd.net wrote:



If you do find anything like c.l.p for Javascript, let us know...


OK!  :-)



I'd try c.l.bartc as he is the world's leading expert on everything that
you need to know about any language, whereby the only thing to know is
how fast is it.  It's just fantastic, you don't have to bother about the
source code that you write, all you have to bother about is the
underlying byte code.


Many a true word.



I wasn't jesting.  BartC is a complete insult to the entire Python 
community, and I find it quite staggering that he has been allowed to 
spew his complete cobblers for so long and get away with it.  It is so 
blatantly obvious that he knows precisely nothing about Python, but 
still the moderators on this list let him get away with it.


--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

Re: [OT'ish] Is there a list as good as this for Javascript

[Joel Goldstick]

On Thu, Mar 24, 2016 at 7:06 PM, Mark Lawrence 
wrote:

> On 24/03/2016 22:45, c...@isbd.net wrote:
>
>> Mark Lawrence  wrote:
>>
>>> On 24/03/2016 22:08, c...@isbd.net wrote:
>>>

 If you do find anything like c.l.p for Javascript, let us know...
>
> OK!  :-)


>>> I'd try c.l.bartc as he is the world's leading expert on everything that
>>> you need to know about any language, whereby the only thing to know is
>>> how fast is it.  It's just fantastic, you don't have to bother about the
>>> source code that you write, all you have to bother about is the
>>> underlying byte code.
>>>
>>> Many a true word.
>>
>>
> I wasn't jesting.  BartC is a complete insult to the entire Python
> community, and I find it quite staggering that he has been allowed to spew
> his complete cobblers for so long and get away with it.  It is so blatantly
> obvious that he knows precisely nothing about Python, but still the
> moderators on this list let him get away with it.
>
>
> --
> My fellow Pythonistas, ask not what our language can do for you, ask
> what you can do for our language.
>
> Mark Lawrence
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>


at least ferous cranis is gone!
-- 
Joel Goldstick
http://joelgoldstick.com/ 
http://cc-baseballstats.info/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [OT'ish] Is there a list as good as this for Javascript

[Ian Kelly]

On Thu, Mar 24, 2016 at 4:58 PM, Mark Lawrence  wrote:
> No.  While this idiot, BartC, is let loose on this forum, I'll say what I
> like.

Good to know. I've been on the fence about this for a long time, but
lately the frequency of your outbursts seems to have increased, and
you're being more of a nuisance to this list than the people whom
you're complaining about.

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

Re: [OT'ish] Is there a list as good as this for Javascript

[Mark Lawrence]

On 24/03/2016 23:33, Ian Kelly wrote:

On Thu, Mar 24, 2016 at 4:58 PM, Mark Lawrence  wrote:

No.  While this idiot, BartC, is let loose on this forum, I'll say what I
like.


Good to know. I've been on the fence about this for a long time, but
lately the frequency of your outbursts seems to have increased, and
you're being more of a nuisance to this list than the people whom
you're complaining about.

*plonk*



I just love it.  A complete moron like BartC insults the Python 
community day in, day out, yet I'm the problem?   When he can actually 
write a decent line of Python code and avoid discussing speed I'll think 
about him as a professional programmer.  I cannot see this happening 
when all he talks about is byte code.  He's clearly never read anything 
like Steve Maguire's "Writing Solid Code".


--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

Re: [OT'ish] Is there a list as good as this for Javascript

[Larry Martell]

On Thu, Mar 24, 2016 at 4:53 PM,   wrote:
> I use Python wherever I can and find this list (as a usenet group via
> gmane) an invaluable help at times.
>
> Occasionally I have to make forays into Javascript, can anyone
> recommend a place similar to this list where Javascript questions can
> be asked?  The trouble is that there are very many usenet Javascript
> lists and it's difficult to guess which one[es] might be good.

I don't know of any JS specific mailing lists. When I have a JS
question I usually use stackoverflow. But there is also the web design
mailing list, which will accept JS questions. See
http://www.webdesign-l.com/

For jQuery questions I use the jquery forum - http://forum.jquery.com/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

[Ned Batchelder]

On Thursday, March 24, 2016 at 2:03:58 PM UTC-4, BartC wrote:
> On 24/03/2016 17:13, Ned Batchelder wrote:
> > On Thursday, March 24, 2016 at 12:12:55 PM UTC-4, BartC wrote:
> >> On 24/03/2016 15:30, Ned Batchelder wrote:
> >>> On Thursday, March 24, 2016 at 9:51:11 AM UTC-4, Steven D'Aprano wrote:
>  You know what is missing from this conversation?
> 
>  For one of Bart's critics to actually show faster code.
> 
>  There's plenty of people telling him off for writing unpythonic and slow
>  code, but I haven't seen anyone actually demonstrating that Python is
>  faster than his results show.
> >>>
> >>> As I mentioned before, I'm happy to explain the fuller Python way to
> >>> write code, but I don't think Bart wants to learn it, because he is
> >>> focused on a different goal than, "write real Python code the best
> >>> possible way."
> >>>
> >>> Here, for example, is a real lexer for JavaScript that I wrote:
> >>> https://bitbucket.org/ned/jslex/src
> >>>
> >>
> >> Thanks for that.
> >>
> >> I don't have any JS to throw at it, but it seems happy with any bits of
> >> source code or even just text.
> >>
> >> Using your short driver program (with the prints commented out), and
> >> tested with 'bible.txt' as input (ie. mostly English words), then your
> >> JS lexer was roughly half the speed of the Python version I linked to
> >> last week (with the if-elif chains and working with strings).
> >
> > I have tried to find your code, but cannot find in the forest of this 
> > thread.
> > Can you provide a link to it online?  I would be very interested to 
> > understand
> > the difference in performance.
> 
> This the version I used today:
> 
> http://pastebin.com/dtM8WnFZ
> 

Thanks. It is faster than mine. The lesson I learned is, if you (I) make
regexes too fancy, they are slower than the low-tech way. :)  I suspect
there is a way to use the re module more efficiently, but I don't have
the time at the moment to figure out how.

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

Re: [OT'ish] Is there a list as good as this for Javascript

[Ned Batchelder]

On Thursday, March 24, 2016 at 7:47:34 PM UTC-4, Mark Lawrence wrote:
> On 24/03/2016 23:33, Ian Kelly wrote:
> > On Thu, Mar 24, 2016 at 4:58 PM, Mark Lawrence  
> > wrote:
> >> No.  While this idiot, BartC, is let loose on this forum, I'll say what I
> >> like.
> >
> > Good to know. I've been on the fence about this for a long time, but
> > lately the frequency of your outbursts seems to have increased, and
> > you're being more of a nuisance to this list than the people whom
> > you're complaining about.
> >
> > *plonk*
> >
> 
> I just love it.  A complete moron like BartC insults the Python 
> community day in, day out, yet I'm the problem?   When he can actually 
> write a decent line of Python code and avoid discussing speed I'll think 
> about him as a professional programmer.  I cannot see this happening 
> when all he talks about is byte code.  He's clearly never read anything 
> like Steve Maguire's "Writing Solid Code".

Yes Mark, you are a problem.  You insult people personally. There is no need
for that.  BartC is a challenge, I agree, but he has not said anything
personal against you or anyone else.

Stop making personal attacks.  Find another way to deal with your frustration.

The Python Code of Conduct says to treat people with respect.  You aren't
doing that.  I know you feel like Bart has been disrespectful by dragging out
threads and ignoring important parts of the Python language.  I agree, that
is frustrating, but it different than making personal insults.

Stop it.  You are hurting this list and you are hurting Python.

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

Web Scraping

[121sukha via Python-list]

I am new to python and I want to use web scraping to download songs from 
website.
how do I write code to check if the website has uploaded a new song and have 
that song automatically be downloaded onto my computer. I know how to use the 
requests.get() module but i am more interested in knowing how to download and 
save every new song that the website uploads on the site. I would extremely 
appreciate the help from anyone. Thanks!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Tkinter --> Why multiple windows

[Wildman via Python-list]

On Thu, 24 Mar 2016 13:24:16 -0700, kevind0718 wrote:

> Hello:
> 
> newbie Tkinter question
> 
> If I run the code below two windows appear.
> One empty and one with the text box and button.
> 
> Why?  please
> 
> KD
> 
> 
> 
> from Tkinter import *
> 
> class MyDialog:
> def __init__(self, parent):
> 
> top = self.top = Toplevel(parent)
> 
> Label(top, text="Value").pack()
> 
> self.e = Entry(top)
> self.e.pack(padx=5)
> 
> b = Button(top, text="OK", command=self.ok)
> b.pack(pady=5)
> 
> def ok(self):
> 
> print "value is", self.e.get()
> 
> self.top.destroy()
> 
> 
> root = Tk()
> 
> d = MyDialog(root)
> 
> root.wait_window(d.top)

Try this:

from Tkinter import *

class MyDialog(Frame):

def __init__(self, parent):
Frame.__init__(self, parent)
self.parent = parent
self.pack(fill=BOTH, expand=1)
self.parent.title("MyDialog")
Label(self, text="Value").pack()
self.e = Entry(self)
self.e.pack(padx=5)
self.b = Button(self, text="OK", command=self.ok)
self.b.pack(pady=5)

def ok(self):
print "value is", self.e.get()

root = Tk()
d = MyDialog(root)
root.mainloop()

-- 
 GNU/Linux user #557453
May the Source be with you.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Tkinter --> Why multiple windows

[Terry Reedy]

On 3/24/2016 4:43 PM, kevind0...@gmail.com wrote:

On Thursday, March 24, 2016 at 4:29:03 PM UTC-4, Random832 wrote:

On Thu, Mar 24, 2016, at 16:24, kevind0...@gmail.com wrote:



If I run the code below two windows appear.
One empty and one with the text box and button.

>>> Why?

The answer to that sort of question is nearly always "Because that is 
what you asked for"



The empty one is the root window.

I kinda guessed that.
Is there any downside to hiding it using root.withdraw().


In your example, there is no apparent reason to hid root and use a 
Toplevel.  IDLE, however, is currently a multiwindow application with no 
main window and it uses 'root.withdraw'.


(In fact, it appears to do so twice in the IDLE process -- possibly a 
mistake.)

--
Terry Jan Reedy

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

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

[Michael Torrie]

On 03/24/2016 04:18 PM, Mark Lawrence wrote:
> On 24/03/2016 19:54, BartC wrote:
>> On 24/03/2016 18:10, Steven D'Aprano wrote:
>>> On Fri, 25 Mar 2016 12:01 am, BartC wrote:
>>
>>>
>>> Then those numbers are pointless.
>>
>> Yes, they would need some adjustment to do this stuff properly.
> 
> Please give up before you get sued by the families of the people who 
> have died laughing.

Mark, please stop with the disparaging remarks.  Just ignore this thread
since it bother's you so much.  Whether or not you or anyone else
disagrees with Bart's programming techniques, his use of Python, or
anything else, this is no excuse for name disparaging remarks.  If Bart
doesn't wish to learn whatever it is you wish to teach, that's his
problem. I know you're a long-time poster to this list, but your
comments of late have been getting a bit inflammatory.  I am a bit
amazed that Bart is still willing to communicate on this list after the
flack he's got from you and a couple of others.  I applaud Steve's voice
of reason from time to time on this thread.

I've been trying to follow things on this thread, and I understand a bit
about Pythonic ideomatic style and I know what Python is really good at
and some of what it's not so good at, but it seems like one of Bart's
original contentions was that given a certain problem, coded in a
non-pythonic way, got slower under Python 3 than it was under Python 2
(if I recall correctly).  In other words a performance regression.
Somehow this seems to have gotten lost in the squabble over how one
should use Python.
-- 
https://mail.python.org/mailman/listinfo/python-list

Negative responses (Re: [OT'ish] Is there a list)

[Rustom Mody]

On Friday, March 25, 2016 at 6:08:43 AM UTC+5:30, Ned Batchelder wrote:
> Yes Mark, you are a problem.  You insult people personally. There is no need
> for that.  BartC is a challenge, I agree, but he has not said anything
> personal against you or anyone else.
> 
> Stop making personal attacks.  Find another way to deal with your frustration.
> 
> The Python Code of Conduct says to treat people with respect.  You aren't
> doing that.  I know you feel like Bart has been disrespectful by dragging out
> threads and ignoring important parts of the Python language.  I agree, that
> is frustrating, but it different than making personal insults.
> 
> Stop it.  You are hurting this list and you are hurting Python.

I'd also like to point out the damage done by Mark to complete noobs.
- Somebody asks about inability to install python
  Response: Everybody keeps asking this... Look up the list
- Some typical noob question.
  Response: Dont top post (or some other format/meta/OT ie irrelevant response

If getting new people asking new questions is a priority, something needs to be 
done about these kinds of rude responses.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Key Binding Problem

[Wildman via Python-list]

On Thu, 24 Mar 2016 21:43:26 -0400, Dennis Lee Bieber wrote:

> On Thu, 24 Mar 2016 11:19:52 -0500, Wildman via Python-list
>  declaimed the following:
> 
>>
>>I believe I understand.  Thanks.  If you can't tell, I'm new to
>>Python so the learning process is on-going.
> 
>   And you decided to throw in a GUI framework at the same time...

Coming from VB6, it seemed the natural thing to do.

>   I've only written one program using Tkinter (and I stuck the old PMW
> library on top of that) -- it was quite horrid of a program. I have used
> the file-requester in a few others though, but that is a stand-alone
> widget/dialog.

I am a hobby programmer so I do this just for the pleasure of
creating something.  I started with 16bit assembly back in the
day and from there went to various flavors of BASIC including
PowerBASIC and Visual Basic.  Never made the transition to .net.
Didn't see a need.  I have yet to find anything that I can't do
with Classic VB6 that I want to do.

>   My only other GUI experience is a rudimentary "Jeopardy" framework
> (called Jeparody -- did not include timers and player buttons) done on a
> whim for an investment mailing list, using VB6... And a significant
> application in which I emulated the display features of a Ramtek 9300
> graphics engine using DECWindows with Graphical Kernel System on top (and
> no "GUI Builder" -- just a hand-written GUI description file).
> 
>   I'd recommend going through the Python Tutorial, study the standard
> types in the Library manual, and maybe skim through the Python Reference...
> THEN maybe consider a GUI...

Good advice.  I have found some good tuts on Youtube for Python
and Tk.  That gave me a good start.  And I have several websites
bookmarked for other tutorials and references.  Plus that several
knowledgeable people right here who are willing to help.

-- 
 GNU/Linux user #557453
"Be at war with your vices, at peace with your neighbors,
and let every new year find you a better man."
  -Benjamin Franklin
-- 
https://mail.python.org/mailman/listinfo/python-list

Problem With Embedded Icon and Python 3.4

[Wildman via Python-list]

I have a program that I have been trying to rewrite so it will
run on Python 2.7 and 3.4.  It has been a pain to say the least.
Thank $DIETY for aliases.  Anyway, I got it all working except
for one thing.  The program has an embedded icon.  It is displayed
in the window's titlebar.  The icon is a 16x16 png that has been
base64 encoded using a Linux utility called memencoder.  The code
below works perfectly with Python 2.7.  The icon data is complete
for anyone that wants to try to run this code:

encoded_icon = """\
iVBORw0KGgoNSUhEUgAAABAQCAMoLQ9TBGdBTUEAALGPC/xhBQAAACBj
SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAACAVBMVEUmAAAJ
AAD/AAAOAAACAAABAAAVAAArAAANAAAPAACMAADqV1dYAAAVAAArAACmKiw2AABcAACM
CguXBgcYAACrAgKdGRuZKCuPCAk9AACDAAAFAAABAADQAAAhAAARAAACAAABAAD/AADO
AABaAAAfAABFAAD/AAANAAADAAAOAAAHAAD/AAAYAAAL
AAADAAAIAAAtAAABAABXAACnAAC7AABoAABsAACdAABy
AAATAAAIAAB8AACeCwvDW1vboaHZmJi+Tk6mJSXFcHDNg4O8VlaeEhGEAACVAgLCZmbSkpTM
fX3LiImXERJUAAATAAChGhvLZmmlREdnAAATAACgHyCzQUW7WlybRkpXAACLBgepZWqZZWt+
ExSoFRataW+vq7WqucSdc3t3EhMjAABLAACNAgKMICJ3GRtTAACiAACiEhScHR9vAAAk
AAABAAABAAD36+v+
/v785+j539/+8/P27+/gwcPz///1urz+WFnTjI3/cXH5dXfn+f3Z6fDQyM7W/v/bs7vfYGbi
c3jfkJbI9v++5vO2w82vusT///+h6spZkXRSTlMA
AAEAAQAADEdRFwAdVEQKAAEABFtjUDAENFJ9WAIABDUoGwEIFRIf
AgJRyunZVjSw2MZsCzrm3NH5egMAjv/YGwGcxL/eIVHu40crvPn+9IoHBUaPjUAEFk5dTREC
AQEBAAABAAEAAAIAmCbO4wFiS0dEqr4GV74JcEhZcwAACxMAAAsTAQCanBgA
AAAHdElNRQfgAxUUFToQYVhV5klEQVQY02NQZUAGjEwMagzMDCysbGAuO4O6BoMmgxaH
to6unr6BoZExp4kpAxeDmbmFpZW1ja2dvYOjEzdQIY+zi6ubO6+Hp5e3D1inr59/QGBQcEho
WHgEH5DPHxk1cdLk6JgpU6fFxsUDBRISp8+YOStp9py58+YnpwAFUtMWLFy0OD1jydJlyzOz
gAIC2TkrVubm5RcUFhWXlIIMLSuvqKyqFqypratvEAIJCIs0NomKMYtLSEpJg62VkZWTZ2Bo
bnFSUFRSVmFobWuHeqzDiYGhs4uhu6cXKuAEFOjrZ0AFThMAxbo5a0L7F4cldEVYdGRh
dGU6Y3JlYXRlADIwMTYtMDMtMjFUMTU6MjA6MzMtMDU6MDBXJmdFJXRFWHRkYXRlOm1v
ZGlmeQAyMDE2LTAzLTIxVDE1OjE5OjI3LTA1OjAwe2m2vwBJRU5ErkJggg=="""

root = Tk()
decoded_icon=base64.decodestring(encoded_icon)
image_icon = Image.open(io.BytesIO(decoded_icon))
icon = ImageTk.PhotoImage(image_icon)
root.call('wm', 'iconphoto', root._w, icon)
app = Window(root)
root.mainloop()


When I run the program with Python 3.4, I get this error:

Traceback (most recent call last):
  File "/usr/lib/python3.4/base64.py", line 519, in _input_type_check
m = memoryview(s)
TypeError: memoryview: str object does not have the buffer interface

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "./myprogram.py", line 276, in 
decoded_icon=base64.decodestring(encoded_icon)
  File "/usr/lib/python3.4/base64.py", line 561, in decodestring
return decodebytes(s)
  File "/usr/lib/python3.4/base64.py", line 553, in decodebytes
_input_type_check(s)
  File "/usr/lib/python3.4/base64.py", line 522, in _input_type_check
raise TypeError(msg) from err
TypeError: expected bytes-like object, not str


I tried converting the icon string to a byte variable like this:

encoded_icon = bytes("""\
iVBORw0KGgoNSUhEUgAAABAQCAMoLQ9TBGdBTUEAALGPC/xhBQAAACBj
(...)
ZGlmeQAyMDE2LTAzLTIxVDE1OjE5OjI3LTA1OjAwe2m2vwBJRU5ErkJggg==""")


That give me a different error:

Traceback (most recent call last):
  File "./myprogram.py", line 269, in 
ZGlmeQAyMDE2LTAzLTIxVDE1OjE5OjI3LTA1OjAwe2m2vwBJRU5ErkJggg==""")
TypeError: string argument without an encoding

I'm not sure what that means.  I looks like it wants the string
to be encoded but it already is.  And why the reference to only
the last line of the string?

I am at a loss here.  Any help would be greatly appreciated.

-- 
 GNU/Linux user #557453
Old enough to know better... too young to resist.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Problem With Embedded Icon and Python 3.4

[Terry Reedy]

On 3/25/2016 1:10 AM, Wildman via Python-list wrote:

I have a program that I have been trying to rewrite so it will
run on Python 2.7 and 3.4.  It has been a pain to say the least.
Thank $DIETY for aliases.  Anyway, I got it all working except
for one thing.  The program has an embedded icon.  It is displayed
in the window's titlebar.  The icon is a 16x16 png that has been
base64 encoded using a Linux utility called memencoder.  The code
below works perfectly with Python 2.7.  The icon data is complete
for anyone that wants to try to run this code:

encoded_icon = """\


To make this literal a bytes literal, prepend 'b'.

encoded_icon = b'''\


iVBORw0KGgoNSUhEUgAAABAQCAMoLQ9TBGdBTUEAALGPC/xhBQAAACBj
SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAACAVBMVEUmAAAJ
AAD/AAAOAAACAAABAAAVAAArAAANAAAPAACMAADqV1dYAAAVAAArAACmKiw2AABcAACM
CguXBgcYAACrAgKdGRuZKCuPCAk9AACDAAAFAAABAADQAAAhAAARAAACAAABAAD/AADO
AABaAAAfAABFAAD/AAANAAADAAAOAAAHAAD/AAAYAAAL
AAADAAAIAAAtAAABAABXAACnAAC7AABoAABsAACdAABy
AAATAAAIAAB8AACeCwvDW1vboaHZmJi+Tk6mJSXFcHDNg4O8VlaeEhGEAACVAgLCZmbSkpTM
fX3LiImXERJUAAATAAChGhvLZmmlREdnAAATAACgHyCzQUW7WlybRkpXAACLBgepZWqZZWt+
ExSoFRataW+vq7WqucSdc3t3EhMjAABLAACNAgKMICJ3GRtTAACiAACiEhScHR9vAAAk
AAABAAABAAD36+v+
/v785+j539/+8/P27+/gwcPz///1urz+WFnTjI3/cXH5dXfn+f3Z6fDQyM7W/v/bs7vfYGbi
c3jfkJbI9v++5vO2w82vusT///+h6spZkXRSTlMA
AAEAAQAADEdRFwAdVEQKAAEABFtjUDAENFJ9WAIABDUoGwEIFRIf
AgJRyunZVjSw2MZsCzrm3NH5egMAjv/YGwGcxL/eIVHu40crvPn+9IoHBUaPjUAEFk5dTREC
AQEBAAABAAEAAAIAmCbO4wFiS0dEqr4GV74JcEhZcwAACxMAAAsTAQCanBgA
AAAHdElNRQfgAxUUFToQYVhV5klEQVQY02NQZUAGjEwMagzMDCysbGAuO4O6BoMmgxaH
to6unr6BoZExp4kpAxeDmbmFpZW1ja2dvYOjEzdQIY+zi6ubO6+Hp5e3D1inr59/QGBQcEho
WHgEH5DPHxk1cdLk6JgpU6fFxsUDBRISp8+YOStp9py58+YnpwAFUtMWLFy0OD1jydJlyzOz
gAIC2TkrVubm5RcUFhWXlIIMLSuvqKyqFqypratvEAIJCIs0NomKMYtLSEpJg62VkZWTZ2Bo
bnFSUFRSVmFobWuHeqzDiYGhs4uhu6cXKuAEFOjrZ0AFThMAxbo5a0L7F4cldEVYdGRh
dGU6Y3JlYXRlADIwMTYtMDMtMjFUMTU6MjA6MzMtMDU6MDBXJmdFJXRFWHRkYXRlOm1v
ZGlmeQAyMDE2LTAzLTIxVDE1OjE5OjI3LTA1OjAwe2m2vwBJRU5ErkJggg=="""

root = Tk()
decoded_icon=base64.decodestring(encoded_icon)
image_icon = Image.open(io.BytesIO(decoded_icon))
icon = ImageTk.PhotoImage(image_icon)
root.call('wm', 'iconphoto', root._w, icon)
app = Window(root)
root.mainloop()


When I run the program with Python 3.4, I get this error:

Traceback (most recent call last):
   File "/usr/lib/python3.4/base64.py", line 519, in _input_type_check
 m = memoryview(s)
TypeError: memoryview: str object does not have the buffer interface


bytes do have the buffer interface, so I expect that using bytes instead 
of str will work.



--
Terry Jan Reedy

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

Re: Problem With Embedded Icon and Python 3.4

[Zachary Ware]

On Fri, Mar 25, 2016 at 12:10 AM, Wildman via Python-list
 wrote:
> I have a program that I have been trying to rewrite so it will
> run on Python 2.7 and 3.4.  It has been a pain to say the least.
> Thank $DIETY for aliases.  Anyway, I got it all working except
> for one thing.  The program has an embedded icon.  It is displayed
> in the window's titlebar.  The icon is a 16x16 png that has been
> base64 encoded using a Linux utility called memencoder.  The code
> below works perfectly with Python 2.7.  The icon data is complete
> for anyone that wants to try to run this code:
>
> encoded_icon = """\
[...]
> I tried converting the icon string to a byte variable like this:
>
> encoded_icon = bytes("""\
> iVBORw0KGgoNSUhEUgAAABAQCAMoLQ9TBGdBTUEAALGPC/xhBQAAACBj
> (...)
> ZGlmeQAyMDE2LTAzLTIxVDE1OjE5OjI3LTA1OjAwe2m2vwBJRU5ErkJggg==""")
>
>
> That give me a different error:
>
> Traceback (most recent call last):
>   File "./myprogram.py", line 269, in 
> ZGlmeQAyMDE2LTAzLTIxVDE1OjE5OjI3LTA1OjAwe2m2vwBJRU5ErkJggg==""")
> TypeError: string argument without an encoding
>
> I'm not sure what that means.  I looks like it wants the string
> to be encoded but it already is.

The bytes constructor in Python 3 requires you to provide an encoding
(utf-8, ascii, latin-1, koi8, etc) when passing in a string, otherwise
it doesn't know what bytes you want and refuses to guess.  You could
fix this by adding `encoding='ascii'` to the bytes() call–but I'm not
certain that that would work in 2.7, and there's a much easier method,
noted later.

> And why the reference to only
> the last line of the string?

Because the traceback would be huge if it included the entire function
call, and there's no need to.  You can find the error from just that
line.  It would be arguably more useful to show the first line, but
that's more difficult to do.

> I am at a loss here.  Any help would be greatly appreciated.

What you need here is a bytes literal, which is accomplished by
prepending a 'b' to the string literal.   Your `encoded_icon = """\`
just needs to become `encoded_icon = b"""\`.  See here [1] for more
information.

-- 
Zach

[1] 
https://docs.python.org/3/reference/lexical_analysis.html#string-and-bytes-literals
-- 
https://mail.python.org/mailman/listinfo/python-list