date:20160309


On 08/03/2016 23:59, Steven D'Aprano wrote:

On Wed, 9 Mar 2016 06:15 am, BartC wrote:

[...]

But this was hardly necessary as it was so obvious: it takes 150ms to
process a 300-pixel image, 20 seconds for a 2Mpixel one, and (I have to
switch to PyPy here as I've never had time to hang about for it) 180
seconds for 80Mpixel file.

Surely the start-up time would be the same no matter what the input.



Mark seems to think that it's completely irrelevant, but that's surely wrong.



The exact opposite actually.  I'm trying to make sense of these so 
called benchmark figures, and quite frankly can't make head nor tail of 
them.  BartC also cannot seem to grasp that the vast majority of people 
often couldn't care less about them, but continues banging on as if 
Python will never take off as it's too slow, whereas the reality is that 
it's been doing rather well.


--
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: turtle ??

2016-03-09 Thread Peter Otten

Ömer sarı wrote:

> l would like to ask a question as l m a little bit confused .

In computing details matter, and in communication odd personal habits 
distract from the actual message. Please reconsider your use of an "l" as a 
replacement for "I".

> l do practice
> in "how to think like a computer scientist:learning with python3.l
> installed python 2.7.10 and upper version 3.5 python.when l run  example
> code in the book , it gave me error.you can find the code , below. ""

At least as important are the specifics of the "error". Did Python print a a 
"traceback"? This gives detailed information about the error and where in 
the code it occurs. You should always provide it (cut and paste, don't 
paraphrase).

> import turtle # Allows us to use turtles
>  wn = turtle.Screen()  # Creates a playground for turtles
>  alex = turtle.Turtle()# Create a turtle, assign to alex
> 
>  alex.forward(50)  # Tell alex to move forward by 50 units
>  alex.left(90) # Tell alex to turn by 90 degrees
>  alex.forward(30)  # Complete the second side of a rectangle
> 
>  wn.mainloop() # Wait for user to close window
> 
> "" example code taken from "how to think like a computer
> scientist:learning with python3" chapter3. so l wonder which version of
> python l need to use for that code make work??

There are bigger differences between Python 2 and Python 3 than between 
Python 3.1 and Python 3.5. An example written for Python 3.1 is more likely 
to run with Python 3.5 than 2.7. Therefore I recommend that you work through 
the book using the 3.5 interpreter.

> .another question , is there
> any module which is named as arcpy?

Please use separate posts for unrelated questions. Try a search engine 
before you bother humans.

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

Re: Review Request of Python Code

2016-03-09 Thread Friedrich Rentsch




On 03/09/2016 05:18 AM, [email protected] wrote:

Dear Group,

I am trying to write a code for pulling data from MySQL at the backend and 
annotating words and trying to put the results as separated sentences with each 
line. The code is generally running fine but I am feeling it may be better in 
the end of giving out sentences, and for small data sets it is okay but with 
50,000 news articles it is performing dead slow. I am using Python2.7.11 on 
Windows 7 with 8GB RAM.

I am trying to copy the code here, for your kind review.

import MySQLdb
import nltk
def sql_connect_NewTest1():
 db = MySQLdb.connect(host="localhost",
  user="*",
  passwd="*",
  db="abcd_efgh")
 cur = db.cursor()
 #cur.execute("SELECT * FROM newsinput limit 0,5;") #REPORTING RUNTIME 
ERROR
 cur.execute("SELECT * FROM newsinput limit 0,50;")
 dict_open=open("/python27/NewTotalTag.txt","r") #OPENING THE DICTIONARY 
FILE
 dict_read=dict_open.read()
 dict_word=dict_read.split()
 a4=dict_word #Assignment for code.
 list1=[]
 flist1=[]
 nlist=[]
 for row in cur.fetchall():
 #print row[2]
 var1=row[3]
 #print var1 #Printing lines
 #var2=len(var1) # Length of file
 var3=var1.split(".") #SPLITTING INTO LINES
 #print var3 #Printing The Lines
 #list1.append(var1)
 var4=len(var3) #Number of all lines
 #print "No",var4
 for line in var3:
 #print line
 #flist1.append(line)
 linew=line.split()
 for word in linew:
 if word in a4:
 windex=a4.index(word)
 windex1=windex+1
 word1=a4[windex1]
 word2=word+"/"+word1
 nlist.append(word2)
 #print list1
 #print nlist
 elif word not in a4:
 word3=word+"/"+"NA"
 nlist.append(word3)
 #print list1
 #print nlist
 else:
 print "None"
 
 #print "###",flist1

 #print len(flist1)
 #db.close()
 #print nlist
 lol = lambda lst, sz: [lst[i:i+sz] for i in range(0, len(lst), sz)] 
#TRYING TO SPLIT THE RESULTS AS SENTENCES
 nlist1=lol(nlist,7)
 #print nlist1
 for i in nlist1:
 string1=" ".join(i)
 print i
 #print string1
 

Thanks in Advance.
 
 


I have a modular processing framework in its final stages of completion 
whose purpose is to save (a lot of) time coding the kind of problem you 
describe. I intend to upload the system and am currently interested in 
real-world cases for the manual. I tried coding your problem, thinking 
it would take no more than a minute. It wasn't that easy, because don't 
say what input you have, nor what you expect your program to do. 
Inferring the missing info from your code takes more time that I can 
spare. So, if you would give a few lines of your input and explain your 
purpose, I'd be happy to help.


Frederic

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

Re: Pickle getstate setstate and restoring n/w - beazley pg 172

2016-03-09 Thread Veek. M

dieter wrote:

> "Veek. M"  writes:
> 
>> import socket
>> class Client(object):
>>  def __init__(self,addr):
>>   self.server_addr = addr
>>   self.sock = socket.socket(socket.AF_INET,socket.SOCK_STREAM)
>>   self.sock.connect(addr)
>>
>>  def __getstate__(self):
>>   return self.server_addr
>>  
>>  def __setstate__(self,value):
>>   self.server_addr = value
>>   self.sock = socket.socket(socket.AF_INET,socket.SOCK_STREAM)
>>   self.sock.connect(self.server_addr)
>> -
>>
>> We'd use it like so:
>> x = Client(192.168.0.1)
>> import pickle
>> pickle.dump(x) #getstate gets called and returns IP for pickling.
>>
>> #program exits, we restart it
>> x=Client(None)
>> x = pickle.load(fh) #Is the IP passed to setstate??
>> x.__setstate__(self, unpickledIP) ???
>> Is this correct?
> 
> Not completely.
> 
> "pickle" operates on objects - and calls "__getstate__" and
> "__setstate__" internally. Thus, you get something like:
> 
>   client = Client()
>   pickle.dump(client, open(fn, "wb"))
>   
>   recreated_client = pickle.load(open(fn, "rb"))

hmm.. yeah, as in the fh - file handle will be passed for 
pickling/unpickling - that's not important..

what i wanted to know was, x = Client('192.168.0.1') will create an 
object 'x' with the IP inside it. When I do:
pickle.dump(x)
pickle doesn't know where in the object the IP is, so he'll call 
__getstate__ and expect the return value to be the IP, right?

Similarly, whilst unpickling, __setstate__ will be called in a manner 
similar to this:
x.__setstate__(self, unpickledIP)

__setstate__ can then populate 'x' by doing 
self.x = str(unpickledIP)

the type info is not lost during pickling is it, therefore 'str' is not 
required is it? 



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

Re: Pyhon 2.x or 3.x, which is faster?

On Wed, 9 Mar 2016 05:08 pm, Marko Rauhamaa wrote:

> Steven D'Aprano :
> 
>> Possibly a really amateurish, lazy job, but still done.
>>
>> [...] Brilliant! I love helpful tools like that!
>>
>> How many years did you say you have been programming?
> 
> Let's keep it civil, please.

Oh, you're no fun!

But seriously, I thought I was. BartC is a big boy and I'm sure he can take
some criticism of his code without his feels being hurt and needing a hug.

Even if I used ... sarcasm.

-- 
Steven

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

Re: turtle ??

On Wed, 9 Mar 2016 08:06 pm, Peter Otten wrote:

> Ömer sarı wrote:
> 
>> l would like to ask a question as l m a little bit confused .
> 
> In computing details matter, and in communication odd personal habits
> distract from the actual message. Please reconsider your use of an "l" as
> a replacement for "I".

While I don't disagree, it is possible that Ömer sarı is typing on a
keyboard that doesn't have an I, or makes it difficult to use. The last
letter of his(?) name is LATIN SMALL LETTER DOTLESS I, which suggests
possibly a Turkish or Armenian keyboard. I don't know how easy it is to get
I as opposed to İ (LATIN CAPITAL LETTER I WITH DOT ABOVE). So we might like
to give him a little slack.

But apart from that, I agree: in the long term, if Ömer is going to be
programming, he'll need to do something about that keyboard.

-- 
Steven

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

Re: Pyhon 2.x or 3.x, which is faster?


On 09/03/2016 08:40, Mark Lawrence wrote:

On 08/03/2016 23:59, Steven D'Aprano wrote:

On Wed, 9 Mar 2016 06:15 am, BartC wrote:

[...]

But this was hardly necessary as it was so obvious: it takes 150ms to
process a 300-pixel image, 20 seconds for a 2Mpixel one, and (I have to
switch to PyPy here as I've never had time to hang about for it) 180
seconds for 80Mpixel file.

Surely the start-up time would be the same no matter what the input.



Mark seems to think that it's completely irrelevant, but that's surely
wrong.



The exact opposite actually.  I'm trying to make sense of these so
called benchmark figures, and quite frankly can't make head nor tail of
them.  BartC also cannot seem to grasp that the vast majority of people
often couldn't care less about them, but continues banging on as if
Python will never take off as it's too slow, whereas the reality is that
it's been doing rather well.


The majority of its users (and not just Python; there are plenty of 
these dynamic languages such as Javascript) probably don't care about it.


They might not appreciate the fact that when they run a script, they are 
most likely executing a library written in a different language by 
people who /do/ care about performance.


There quite a few projects around to get these dynamic languages up to 
to speed, so that there is less reliance on needing to code in languages 
such as C and C++. (If languages such as Python were just as fast in 
executing pure code, who would want to use C++? No one.)


I suspect here that you're just one of those users who don't care what 
goes on behind the scenes.


Now it might be there are so many libraries around already implemented, 
that there is little need for anyone to need to do any pure coding any 
more; you just throw together a script to invoke a library that someone 
else has painstakingly put together in a different language.


That's one point of view.

Here's another: you have a program in Python that you'd quite like to 
port to another dynamic language. Transcribing actual Python code is 
straightforward. Until you come to an import of a module that you can't 
find, because it's not written in Python. Now what? Now, you might 
appreciate the advantage of a program in 100% pure Python.


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

Re: Review Request of Python Code

2016-03-09 Thread Matt Wheeler

I'm just going to focus on a couple of lines as others are already
looking at the whole thing:

On 9 March 2016 at 04:18,   wrote:
> [snip].
> if word in a4:
> [stuff]
> elif word not in a4:
> [other stuff]
> else:
> print "None"

This is bad for a couple of reasons.

Most obviously, your `else: print "None"` case can never be reached.
word not in a4 is the inverse of word in a4.
That also means for the `not` case the entire a4 list is scanned
*twice*, and the second time is completely pointless.

This can be simplified to
 if word in a4:
 [stuff]
 else:
 [other stuff]

But we can still do better. A list is a poor choice for this kind of
lookup, as Python has no way to find elements other than by checking
them one after another. (given (one of the) name(s) you've given it
sounds a bit like "dictionary" I assume it contains rather a lot of
items)

If you change one other line:

> dict_word=dict_read.split()
> a4=dict_word #Assignment for code.

a4=set(dict_word)
#(this could of course be shortened further but I'll leave that to you/others)

You'll probably see a massive speedup in your code, possibly even
dwarfing the speedup you see from more sensible database access like
INADA Naoki suggested (though you should definitely still do that
too!), especially if your word list is very large.

This is because the set type uses a hashmap internally, making lookups
for matches extremely fast, compared to scanning through the list.

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

Re: Review Request of Python Code

2016-03-09 Thread Matt Wheeler

On 9 March 2016 at 12:06, Matt Wheeler  wrote:
> But we can still do better. A list is a poor choice for this kind of
> lookup, as Python has no way to find elements other than by checking
> them one after another. (given (one of the) name(s) you've given it
> sounds a bit like "dictionary" I assume it contains rather a lot of
> items)

Sorry, I've just read your original code properly and see that you're
looking up the next item in the list, this means a set is not
suitable, as it doesn't preserve order (however, your original code is
open to an IndexError if the last element in your list is matched).

If you could provide a sample of the NewTotalTag.txt file data that
would be helpful, but working with the information I've got we can
still get a comparable speedup, by constructing a dict upfront mapping
each word to the next one[1]:

dict_word=dict_read.split()
dict_word.append('N/A')
# Assuming that 'N/A' is a reasonable output if the last word in your
list is matched.
# This works around the IndexError your current code is exposed to.
# The slice ([:-1]) means we don't try to add the last item to the new a4 dict.
a4={}
for index,word in enumerate(words[:-1]):
a4[word] = dict_word[index+1]

This creates a dict where each key maps to the corresponding next
word, which you can use later in your lookup instead of fetching by
index. i.e. a4[word] instead of a4[windex+1].
This means you're saving yet *another* scan through of the entire list
(`a4.index(word)` has to scan yet again) for the positive matches.

[1] though I suspect if we get to see a sample of your data file there
may be a better way

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

Re: Question

On 2016-03-09, Ian Kelly  wrote:
> It looks like the shell environment that comes with Git for Windows is
> actually Windows Powershell [1], so presumably the activate.ps1 script
> that's already provided by venv is what's needed, not a bash script.

This is not true. I installed Git for Windows and what it gave me was
"Git Bash" which as you say runs in a window titled "MINGW64".

If I try to run the activate.ps1 script it says:

$ env/Scripts/activate.ps1
env/Scripts/activate.ps1: line 1: syntax error near unexpected token 
`[switch]$NonDestructive'
env/Scripts/activate.ps1: line 1: `function global:deactivate 
([switch]$NonDestructive) {'
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Pyhon 2.x or 3.x, which is faster?

2016-03-09 Thread Marko Rauhamaa

Steven D'Aprano :

> On Wed, 9 Mar 2016 05:08 pm, Marko Rauhamaa wrote:
>
>> Steven D'Aprano :
>> 
>>> Possibly a really amateurish, lazy job, but still done.
>>>
>>> [...] Brilliant! I love helpful tools like that!
>>>
>>> How many years did you say you have been programming?
>> 
>> Let's keep it civil, please.
>
> Oh, you're no fun!
>
> But seriously, I thought I was. BartC is a big boy and I'm sure he can
> take some criticism of his code without his feels being hurt and
> needing a hug.

It came off as standard schoolyard bullying.

   If your child often tries to explain away misdeeds with 'We were just
   having fun ...', [...] you may just have a bully in the making living
   under your roof.

   http://www.kidspot.com.au/schoolzone/Bullying-My-child-is-a-bu
   lly+4615+395+article.htm>


> Even if I used ... sarcasm.

   The dictionary defines Sarcasm as: "The use of irony to mock or
   convey contempt"

   http://www.scienceofpeople.com/2011/12/sarcasm-why-it-hurts-us/>


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

Re: Question

On 2016-03-08, Steven D'Aprano  wrote:
> On Wed, 9 Mar 2016 04:19 am, Ian Kelly wrote:
>> On Mon, Mar 7, 2016 at 6:41 PM, Jon Ribbens
>>  wrote:
>>> 'virtualenv' works even less well, it just says:
>>>
>>> $ virtualenv test
>>> Using base prefix 'd:\\program files (x86)\\python35-32'
>>> New python executable in D:\Users\Jon
>>> Ribbens\Documents\Python\test\Scripts\python.exe ERROR: The executable
>>> "D:\Users\Jon Ribbens\Documents\Python\test\Scripts\python.exe" could not
>>> be run: [WinError 5] Access is denied
>> 
>> Ah, I probably never tried using it inside a user dir. On Windows I
>> typically do development in a path close to the drive root, e.g.
>> C:\dev.
>
> Am I missing something? It looks to me like a straight forward permissions
> error? I don't know how difficult that is to solve on Windows, but I don't
> think it has anything to do with the path itself, only the permissions of
> the path.

I don't see how it could be a "straight forward permissions error".
The file it is saying "Access Denied" on is a file that was just
created by virtualenv, so if there is something wrong with its
permissions then that is a bug in virtualenv. Plus, there isn't
anything wrong with its permissions because if I run
test/Scripts/python.exe from the command line it works fine.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python path

On Wed, 9 Mar 2016 06:29 pm, ast wrote:

> Hello
> 
> Python path may be read with:
> 
 import sys
 sys.path
> 
> There is an environnement variable $PYTHONPATH (windows)
> to set if you want to add some additionnal directories to the
> path.
> 
> But the default path seems not to be stored in any environnement
> variable. Is it correct ? Is it stored somewhere else ?

The system.path is created from four different sources:

(1) The directory of the script you are running, if you are running a
script, otherwise the current directory.

(2) Any paths listed in PYTHONPATH (if it is set).

(3) A small number of fixed paths, which are built into the interpreter.

(4) Finally the site.py module does extensive customization of sys.path.

The documentation for sys.path says:

A list of strings that specifies the search path for 
modules. Initialized from the environment variable 
PYTHONPATH, plus an installation-dependent default.

https://docs.python.org/2/library/site.html
https://docs.python.org/3/library/site.html

The following is my guess as to what happens... if anyone knows for sure, I
would appreciate if you can point me at some docs.

When the Python interpreter is compiled, it knows what operating system it
is being built for, and knows where in the file system it should put its
library files. (This can be configured by when you build the interpreter.)
For example, on Linux, it will might use /usr/local/lib/ as the default
location for the standard library. Then, when you run Python, it
initialises sys.path with a set of fixed, installation-specific entries.
For Python 3.3. on Linux, I get these:

/usr/local/lib/python33.zip
/usr/local/lib/python3.3/
/usr/local/lib/python3.3/plat-linux
/usr/local/lib/python3.3/lib-dynload

This is configured when you compile the Python interpreter, you cannot
change it afterwards. If you want to change it, you need to download the
source and recompile.

Python then runs the site module, which is a site-specific configuration
module. By default, site.py will add a number of paths. See the
documentation for details:

https://docs.python.org/2/library/site.html
https://docs.python.org/3/library/site.html

Then, site.py will try to find and run sitecustomize.py, if it exists.

Then, it will try to find and run usercustomize.py, if it exists (unless
user site customization has been disabled). Normally you would put
usercustomize.py in your user site-packages directory. E.g for Python 2.7
you would use:

~/.local/lib/python2.7/site-packages

and for Python 3.3:

~/.local/lib/python3.3/site-packages

(where ~ is your home directory).

Python will also honour .pth files in any of these locations, if they exist.
See the site.py documentation for more details.

You can also set a PYTHONSTARTUP environment variable to point to a startup
file, and have the startup file set sys.path. But that only runs when using
the interactive interpreter.

> I have heard about *.pth files to store some directories to be added
> to path but I didn't found any such files on my system.

Normally you wouldn't expect to.

-- 
Steven

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

Re: Reason for not allowing import twice but allowing reload()

Sorry for the delay in answering!

On Sat, 5 Mar 2016 11:51 pm, [email protected] wrote:

> Steven,
> 
>> There are better ways to manage your Python path than to manually insert
>> paths into sys.path like that. What version of Python are you using?
> 
> I would love to know, apart from PYTHONPATH and sys.path.append() route.
> 
> I am using Python 2.7.11 to start with as suggested by my employer.

Python creates sys.path from four different sources:

(1) The directory of the script you are running, if you are running a
script, otherwise the current directory.

(2) Any paths listed in the PYTHONPATH environment variable.

(3) A small number of fixed paths, which are built into the interpreter.

(4) Finally the site.py module does extensive customization of sys.path.

If you have just one or two paths to add, PYTHONPATH is the easiest and most
convenient. But for more extensive additions to the path, number (4) is the
way to go. It gives you many options!

Let's suppose I want to add two locations to my path alone, not for any
other users:

/home/loretta/python
/home/loretta/scripts

Here are four methods for adding user-specific locations to sys.path, plus
two more for adding system-wide locations that apply to all users:

Method 1: PYTHONPATH environment variable
=

In my ~/.bashrc file, I put this line:

export PYTHONPATH="/home/loretta/python:/home/loretta/scripts"

Method 2: startup file
==

(This method only works when I run the interactive interpreter, not when
running scripts.)

In my ~/.bashrc file, I put this line:

export PYTHONSTARTUP="/home/loretta/startup.py"

Then I edit startup.py to include any python code I like:

print "Running Python startup file..."
import sys
sys.path.append('/home/loretta/python')
sys.path.append('/home/loretta/scripts')
print "Done!"

Method 3: usercustomize.py
==

I create a file:

~/.local/lib/python2.7/site-packages/usercustomize.py

which can contain any Python code I like. Import sys and add to the path:

import sys
sys.path.append('/home/loretta/python')
sys.path.append('/home/loretta/scripts')

Method 4: user .pth file

I create a file containing the paths I want to add, one path per line:

/home/loretta/python
/home/loretta/scripts

Blank lines and lines starting with # are ignored.

I save this to:

~/.local/lib/python2.7/site-packages/loretta.pth

I can have as many .pth files as I like, and name them anything I like, so
long as the names end with .pth and they are in my local site packages
directory.

Method 5: sitecustomize.py
==

This is like usercustomize.py (method 3), except it applies to all users.

Create a file sitecustomize.py, and put it in Python's standard library,
which is usually found here:

/usr/local/lib/python2.7/

You will need to be root to do this.

Method 6: site .pth file

This is like method 4, except it applies to all users.

Create a .pth file containing the paths you want added, and put it in
Python's standard library. You will need to be the root user to do this.

-- 
Steven

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

Re: Pyhon 2.x or 3.x, which is faster?


On 09/03/2016 02:18, Steven D'Aprano wrote:

On Wed, 9 Mar 2016 12:28 pm, BartC wrote:


(Which wasn't as painful as I'd expected. However the next project I
have in mind is 20K lines rather than 0.7K. For that I'm looking at some
mechanical translation I think. And probably some library to wrap around
Python's i/o.)


You almost certainly don't need another wrapper around Python's I/O, making
it slower still. You need to understand what Python's I/O is doing.


Well, the original project will be using its file i/o library. So it'll 
use the same interface that will be reimplemented on top of Python i/o.


And input operations mainly consist of grabbing an entire file at once. 
Output is a little more mixed.



If you open a file in binary mode, Python will give you a stream of bytes
(ordinal values 0 through 255 inclusive). Python won't modify or change
those bytes in any way. Whatever it reads from disk, it will give to you.

If you open a file in text mode, Python 3 will give you a stream of Unicode
code points (ordinal values 0 through 0x10). Earlier versions of Python
3 may behave somewhat strangely with so-called "astral characters": I
recommend that you avoid anything below version 3.3. Unless you are
including (e.g.) Chinese or ancient Phoenician in your text file, you
probably won't care.


I've just tried a UTF-8 file and getting some odd results. With a file 
containing [three euro symbols]:


€€€

(including a 3-byte utf-8 marker at the start), and opened in text mode, 
Python 3 gives me this series of bytes (ie. the ord() of each character):


239
187
191
226
8218
172
226
8218
172
226
8218
172

And prints the resulting string as: ï»¿â‚¬â‚¬â‚¬. Although this latter 
might depend on my console's code page setting. Changing it to UTF-8 
however (CHCP 65001 in Windows) gives me this error when I run the 
program again:


--
Fatal Python error: Py_Initialize: can't initialize sys standard streams
LookupError: unknown encoding: cp65001

This application has requested the Runtime to terminate it in an unusual 
way.

Please contact the application's support team for more information.
--

(That was with 3.1; 3.4 gives the same set of characters as above, and 
shows the string differently, but still wrong. While PyPy 3.2.4 gives a 
different set of byte values, all 0..255, and a different string again, 
although it now contains some actual € characters.


So I think I'll skip Unicode handling to start off with! (I've already 
had plenty of fun and games with it in the past.)


--
Bartc



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

Re: Pyhon 2.x or 3.x, which is faster?

On Thu, Mar 10, 2016 at 1:03 AM, BartC  wrote:
> I've just tried a UTF-8 file and getting some odd results. With a file
> containing [three euro symbols]:
>
> €€€
>
> (including a 3-byte utf-8 marker at the start), and opened in text mode,
> Python 3 gives me this series of bytes (ie. the ord() of each character):
>
> 239
> 187
> 191
> 226
> 8218
> 172
> 226
> 8218
> 172
> 226
> 8218
> 172
>
> And prints the resulting string as: ï»¿â‚¬â‚¬â‚¬.

The first three bytes are the "UTF-8 BOM", which suggests you may have
created this in a broken editor like Notepad.

For the rest, I'm not sure how you told Python to open this as text,
but you certainly did NOT specify an encoding of UTF-8. The 8218
entries in there are completely bogus. Can you show your code, please,
and also what you get if you open the file as binary?

Unicode handling is easy as long as you (a) understand the fundamental
difference between text and bytes, and (b) declare your encodings.
Python isn't magical. It can't know the encoding without being told.

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

Re: turtle ??

2016-03-09 Thread Joel Goldstick

On Wed, Mar 9, 2016 at 6:55 AM, Steven D'Aprano  wrote:

> On Wed, 9 Mar 2016 08:06 pm, Peter Otten wrote:
>
> > Ömer sarı wrote:
> >
> >> l would like to ask a question as l m a little bit confused .
> >
> > In computing details matter, and in communication odd personal habits
> > distract from the actual message. Please reconsider your use of an "l" as
> > a replacement for "I".
>
> While I don't disagree, it is possible that Ömer sarı is typing on a
> keyboard that doesn't have an I, or makes it difficult to use. The last
> letter of his(?) name is LATIN SMALL LETTER DOTLESS I, which suggests
> possibly a Turkish or Armenian keyboard. I don't know how easy it is to get
> I as opposed to İ (LATIN CAPITAL LETTER I WITH DOT ABOVE). So we might like
> to give him a little slack.
>
> But apart from that, I agree: in the long term, if Ömer is going to be
> programming, he'll need to do something about that keyboard.
>
> Firstly, it says python3 in the title, so use python3
>

I ran the code with python 2.7.  However, python3 is most likely required
for other exercises in the book.  Here are my results:

>>> import turtle
>>> wn = turtle.Screen()
>>> alex = turtle.Turtle()
>>> alex.forward(50)
>>> alex.left(90)
>>> alex.forward(30)
>>> wn.mainloop()
Traceback (most recent call last):
  File "", line 1, in 
AttributeError: '_Screen' object has no attribute 'mainloop'
>>>

 Python opened a window and drew the lines.  I don't know turtle, so maybe
this can't be run interactively with wn.mainloop()


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



-- 
Joel Goldstick
http://joelgoldstick.com/ 
http://cc-baseballstats.info/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Pyhon 2.x or 3.x, which is faster?

On 09/03/2016 14:11, Chris Angelico wrote:

On Thu, Mar 10, 2016 at 1:03 AM, BartC  wrote:

I've just tried a UTF-8 file and getting some odd results. With a file
containing [three euro symbols]:

€€€

(including a 3-byte utf-8 marker at the start), and opened in text mode,
Python 3 gives me this series of bytes (ie. the ord() of each character):

239
187
191
226
8218
172
226
8218
172
226
8218
172

And prints the resulting string as: ï»¿â‚¬â‚¬â‚¬.

The first three bytes are the "UTF-8 BOM", which suggests you may have
created this in a broken editor like Notepad.

Yes, that's what I used, but what's broken about it? If Python doesn't 
understand the BOM, it should still resynchronise after a few bytes.

> For the rest, I'm not sure how you told Python to open this as text,
> but you certainly did NOT specify an encoding of UTF-8. The 8218
> entries in there are completely bogus. Can you show your code, please,
> and also what you get if you open the file as binary?

This is the code:

f=open("input","r")
t=f.read(1000)
f.close()

print ("T",type(t),len(t))

print (t)

for i in t:
print (ord(i))

This doesn't specify any specific code encoding; I don't know how, and 
Steven didn't mention anything other than a text file. The input data is 
represented by this dump, and this is also what binary mode gives:

: ef bb bf e2 82 ac e2 82 ac e2 82 ac

Unicode handling is easy as long as you (a) understand the fundamental
difference between text and bytes, and (b) declare your encodings.
Python isn't magical. It can't know the encoding without being told.

Hence the BOM bytes.

(Isn't it better that it's automatic? Someone sends you a text file that 
you want to open within a Python program. Are you supposed to analyze it 
first, or expect the sender to tell you what it is (they probably won't 
know) then need to hack the program to read it properly?)

--
Bartc

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

Re: Pyhon 2.x or 3.x, which is faster?

On Thu, 10 Mar 2016 01:11 am, Chris Angelico wrote:

> The first three bytes are the "UTF-8 BOM", which suggests you may have
> created this in a broken editor like Notepad.

Notepad may be horribly crippled, but I'm not entirely sure "broken" is the
right word for it. Does it do anything *wrong*? I don't think so.

UTF-8 pseudo-BOM (more of a signature, less of a Byte Order Mark) is
officially unofficially supported by the Unicode consortium, if you know
what I mean. They specifically point out it is not a BOM, and that you can
use it if you wish, but they'd rather you didn't.

-- 
Steven

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

Re: Pyhon 2.x or 3.x, which is faster?

On 2016-03-09, BartC  wrote:
> (Isn't it better that it's automatic? Someone sends you a text file that 
> you want to open within a Python program. Are you supposed to analyze it 
> first, or expect the sender to tell you what it is (they probably won't 
> know) then need to hack the program to read it properly?)

Yes, that is exactly what you're supposed to do. But if you really
want to do it the wrong way then look here:
https://github.com/chardet/chardet
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Pyhon 2.x or 3.x, which is faster?

On Thu, Mar 10, 2016 at 1:39 AM, BartC  wrote:
> On 09/03/2016 14:11, Chris Angelico wrote:
>>
>> On Thu, Mar 10, 2016 at 1:03 AM, BartC  wrote:
>>>
>>> I've just tried a UTF-8 file and getting some odd results. With a file
>>> containing [three euro symbols]:
>>>
>>> €€€
>>>
>>> (including a 3-byte utf-8 marker at the start), and opened in text mode,
>>> Python 3 gives me this series of bytes (ie. the ord() of each character):
>>>
>>> 239
>>> 187
>>> 191
>>> 226
>>> 8218
>>> 172
>>> 226
>>> 8218
>>> 172
>>> 226
>>> 8218
>>> 172
>>>
>>> And prints the resulting string as: ï»¿â‚¬â‚¬â‚¬.
>>
>>
>> The first three bytes are the "UTF-8 BOM", which suggests you may have
>> created this in a broken editor like Notepad.
>
>
> Yes, that's what I used, but what's broken about it? If Python doesn't
> understand the BOM, it should still resynchronise after a few bytes.

It's an extra character. You thought the file contained three
characters; it actually contained four.

>> For the rest, I'm not sure how you told Python to open this as text,
>> but you certainly did NOT specify an encoding of UTF-8. The 8218
>> entries in there are completely bogus. Can you show your code, please,
>> and also what you get if you open the file as binary?
>
> This is the code:
>
> f=open("input","r")
> t=f.read(1000)
> f.close()
>
> print ("T",type(t),len(t))
>
> print (t)
>
> for i in t:
> print (ord(i))
>
> This doesn't specify any specific code encoding; I don't know how, and
> Steven didn't mention anything other than a text file. The input data is
> represented by this dump, and this is also what binary mode gives:
>
> : ef bb bf e2 82 ac e2 82 ac e2 82 ac

Okay. Try changing your first line to this:

f = open("input", encoding="utf-8")

By default, you get a system-specific encoding, which in your case
appears to be one of the Windows codepages. That's why you're getting
nonsense out of it - you write in one encoding and read in another.
It's commonly called mojibake.

>> Unicode handling is easy as long as you (a) understand the fundamental
>> difference between text and bytes, and (b) declare your encodings.
>> Python isn't magical. It can't know the encoding without being told.
>
>
> Hence the BOM bytes.
>
> (Isn't it better that it's automatic? Someone sends you a text file that you
> want to open within a Python program. Are you supposed to analyze it first,
> or expect the sender to tell you what it is (they probably won't know) then
> need to hack the program to read it properly?)

No, it's not better to be automatic. They are supposed to tell you
what it is. Someone somewhere saved the file using a particular
encoding. In this example, you chose when you told Notepad to save it
as UTF-8; so you carry that information with the file, and open it
using the encoding="UTF-8" parameter.

Analyzing files to try to guess their encodings is fundamentally hard.
I have a source of occasional text files that basically just dumps
stuff on me without any metadata, and I have to figure out (a) what
the encoding is, and (b) what language the text is in. I can generally
assume that the files are ASCII-compatible (on the rare occasions when
they're not, they're usually going to be UTF-16, which is fairly easy
to spot), and then I have two levels of heuristics to try to guess a
most-likely encoding - but ultimately, the script just decodes the
text as best it can, and then hands the result up to the human. If the
result looks mostly like Spanish but has acute accents instead of
tildes over the n's, it's probably the wrong codepage. Or if the text
is all completely meaningless junk, it's probably Cyrillic or Greek
letters, and needs to be decoded using an appropriate eight-bit
encoding. It often ends up being trial-and-error to figure out what
encoding was actually used.

Trying to guess the encoding of text in a file full of bytes is like
trying to guess the modem settings (8N1? 7E1?). If the other end
doesn't tell you, you'll probably end up with something that carries
some decodable content, but not the original content. It's almost
completely useless.

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

Re: Pyhon 2.x or 3.x, which is faster?

On Thu, 10 Mar 2016 01:03 am, BartC wrote:

> On 09/03/2016 02:18, Steven D'Aprano wrote:
>> On Wed, 9 Mar 2016 12:28 pm, BartC wrote:
>>
>>> (Which wasn't as painful as I'd expected. However the next project I
>>> have in mind is 20K lines rather than 0.7K. For that I'm looking at some
>>> mechanical translation I think. And probably some library to wrap around
>>> Python's i/o.)
>>
>> You almost certainly don't need another wrapper around Python's I/O,
>> making it slower still. You need to understand what Python's I/O is
>> doing.
> 
> Well, the original project will be using its file i/o library. So it'll
> use the same interface that will be reimplemented on top of Python i/o.

Just don't complain that it's slow :-)


> And input operations mainly consist of grabbing an entire file at once.

with open(pathname) as f:
data = f.read()


> Output is a little more mixed.

It often is.



> I've just tried a UTF-8 file and getting some odd results. With a file
> containing [three euro symbols]:
> 
> €€€
> 
> (including a 3-byte utf-8 marker at the start), and opened in text mode,
> Python 3 gives me this series of bytes (ie. the ord() of each character):
> 
> 239
> 187
> 191
> 226
> 8218
> 172
> 226
> 8218
> 172
> 226
> 8218
> 172

Er, do you think that 8218 is a *byte*? (Hint: 1 byte = 8 bits, at least on
any platform you are likely to be running.)

Bart, you have a bad habit of giving us the output of your code, with an
implied "explain this", but without showing us the code you used to
generate the output. Without seeing the code you used, I have *no idea* how
you could get that result. If you read the file in binary, you should get
this:

b'\xef\xbb\xbf\xe2\x82\xac\xe2\x82\xac\xe2\x82\xac'

Or in decimal:

239, 187, 191, 226, 130, 172, 226, 130, 172, 226, 130, 172

How you are getting 8218 instead of 130, I have no idea!

If you read the file as text, but using the wrong encoding, say Latin-1, you
would get this:

'ï»¿â\x82¬â\x82¬â\x82¬'

or in decimal:

239, 187, 191, 226, 130, 172, 226, 130, 172, 226, 130, 172

Without seeing your code, I cannot possibly diagnose what you are doing.



> And prints the resulting string as: ï»¿â‚¬â‚¬â‚¬. Although this latter
> might depend on my console's code page setting. 

That is very likely to be the reason for printing strange things. Life is
much easier on Linux and OS-X, where the console works with UTF-8 by
default.


> Changing it to UTF-8 
> however (CHCP 65001 in Windows) gives me this error when I run the
> program again:
> 
> --
> Fatal Python error: Py_Initialize: can't initialize sys standard streams
> LookupError: unknown encoding: cp65001
> 
> This application has requested the Runtime to terminate it in an unusual
> way.
> Please contact the application's support team for more information.
> --

I'm afraid I don't know how to deal with that. It's a Windows-specific
issue.





-- 
Steven

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

Re: Pyhon 2.x or 3.x, which is faster?

On Thu, Mar 10, 2016 at 1:57 AM, Steven D'Aprano  wrote:
> On Thu, 10 Mar 2016 01:11 am, Chris Angelico wrote:
>
>> The first three bytes are the "UTF-8 BOM", which suggests you may have
>> created this in a broken editor like Notepad.
>
> Notepad may be horribly crippled, but I'm not entirely sure "broken" is the
> right word for it. Does it do anything *wrong*? I don't think so.
>

Well, okay, this particular behaviour isn't technically "broken". But
Notepad is broken in enough other ways that it's best to avoid it.
(For example, its text *de*coding is famously buggy.)

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

Re: Pyhon 2.x or 3.x, which is faster?

On 2016-03-09, Steven D'Aprano  wrote:
> generate the output. Without seeing the code you used, I have *no idea* how
> you could get that result. If you read the file in binary, you should get
> this:
>
> b'\xef\xbb\xbf\xe2\x82\xac\xe2\x82\xac\xe2\x82\xac'
>
> Or in decimal:
>
> 239, 187, 191, 226, 130, 172, 226, 130, 172, 226, 130, 172
>
> How you are getting 8218 instead of 130, I have no idea!

Decode as "windows-1252".

>> Changing it to UTF-8 however (CHCP 65001 in Windows) gives me this
>> error when I run the program again:
>> 
>> --
>> Fatal Python error: Py_Initialize: can't initialize sys standard streams
>> LookupError: unknown encoding: cp65001

cp65001 was added in Python 3.3, any earlier version (including any
Python 2) will not understand it.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Pyhon 2.x or 3.x, which is faster?

2016-03-09 Thread Tim Golden

On 09/03/2016 15:06, Jon Ribbens wrote:
> On 2016-03-09, Steven D'Aprano  wrote:
>> generate the output. Without seeing the code you used, I have *no idea* how
>> you could get that result. If you read the file in binary, you should get
>> this:
>>
>> b'\xef\xbb\xbf\xe2\x82\xac\xe2\x82\xac\xe2\x82\xac'
>>
>> Or in decimal:
>>
>> 239, 187, 191, 226, 130, 172, 226, 130, 172, 226, 130, 172
>>
>> How you are getting 8218 instead of 130, I have no idea!
> 
> Decode as "windows-1252".
> 
>>> Changing it to UTF-8 however (CHCP 65001 in Windows) gives me this
>>> error when I run the program again:
>>>
>>> --
>>> Fatal Python error: Py_Initialize: can't initialize sys standard streams
>>> LookupError: unknown encoding: cp65001
> 
> cp65001 was added in Python 3.3, any earlier version (including any
> Python 2) will not understand it.

It's also somewhat flaky in other ways

  https://mail.python.org/pipermail/python-list/2015-December/700351.html

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

Public Service Announcement: planetpython.org

2016-03-09 Thread Tim Golden

For those who didn't know, we have a feed aggregator at
https://planetpython.org. We're trying to clean up out-of-date or
incorrect feed URLs.

Planet Python config & (occasional) development happens on Github. So
please check the Planet config files [1] to see if your blog is listed
correctly, or is listed but should no longer be. And send us a PR or an
email ([email protected]).

Of course, please also let us know if you want your blog added also via
PR or email.

TJG

[1] https://github.com/python/planet/blob/master/config/config.ini
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Pyhon 2.x or 3.x, which is faster?

On Thu, 10 Mar 2016 01:39 am, BartC wrote:

> This is the code:
> 
> f=open("input","r")
> t=f.read(1000)
> f.close()

If you don't give read an argument, it will try to read the entire file:

t = f.read()

> print ("T",type(t),len(t))
> print (t)
> for i in t:
> print (ord(i))
> 
> This doesn't specify any specific code encoding; I don't know how, and
> Steven didn't mention anything other than a text file. 

I did warn you that, and I quote, "There's more, but that's the basics". You
could always read the Fine Manual, or even the interactive help (always a
boon for the busy programmer):

help(open) starts with:

open(...)
open(file, mode='r', buffering=-1, encoding=None,
 errors=None, newline=None, closefd=True, opener=None) 
-> file object

Open file and return a stream.  Raise IOError upon failure.

To specify an encoding, pass the name of the encoding as argument:

open(filename, "r", encoding="utf-8-sig")

for UTF-8 files as created by Notepad, and 

open(filename, "r", encoding="utf-8")

for UTF-8 files without the leading 3-byte signature.

> The input data is 
> represented by this dump, and this is also what binary mode gives:
> 
> : ef bb bf e2 82 ac e2 82 ac e2 82 ac

That matches the bytes I suggested in a previous post:

b'\xef\xbb\xbf\xe2\x82\xac\xe2\x82\xac\xe2\x82\xac'

but not the values you quoted, specifically the triples of:

226, 8218, 172 (decimal) or in hex: e2 201a ac

Obviously hex 201a is too big to fit in a byte. I'm not sure how you could
have got that. Human error perhaps?

>> Unicode handling is easy as long as you (a) understand the fundamental
>> difference between text and bytes, and (b) declare your encodings.
>> Python isn't magical. It can't know the encoding without being told.
> 
> Hence the BOM bytes.

Alas, if only it were that simple. But encoding is *metadata*, not data, and
cannot reliably be read from the file itself. It may be a useful heuristic,
which is *mostly* reliable, but it cannot be considered foolproof.

How do you distinguish between a UTF-8 signature and a Latin-1 file that
happens to start with these three characters "ï»¿"? Or a MacRoman file that
happens to start with the three characters "Ôªø"? To mention just a few.

The problem is, any stream of bytes can only be correctly recognised as text
if you know what encoding the bytes represent:

py> dump = b'\xef\xbb\xbf\x2d\x2d\x2d'
py> dump.decode('utf-8-sig')
'---'
py> dump.decode('latin-1')
'ï»¿---'
py> dump.decode('MacRoman')
'Ôªø---'
py> dump.decode('cp1251')
'п»ї---'

> (Isn't it better that it's automatic? Someone sends you a text file that
> you want to open within a Python program. Are you supposed to analyze it
> first, or expect the sender to tell you what it is (they probably won't
> know) then need to hack the program to read it properly?)

You cannot know for sure what encoding a text file uses, unless it has been
recorded somewhere outside of the text file and transmitted it "out of
band". That is, you ask the sender. And you are right, they probably won't
know. Then you try to guess, and if you guess wrong, the text you read will
contain moji-bake:

https://en.wikipedia.org/wiki/Mojibake

See also:

https://en.wikipedia.org/wiki/Charset_detection

https://en.wikipedia.org/wiki/Bush_hid_the_facts

-- 
Steven

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

Re: turtle ??

2016-03-09 Thread Terry Reedy


On 3/9/2016 2:39 AM, Ömer sarı wrote:

import turtle # Allows us to use turtles
  wn = turtle.Screen()  # Creates a playground for turtles
  alex = turtle.Turtle()# Create a turtle, assign to alex

  alex.forward(50)  # Tell alex to move forward by 50 units
  alex.left(90) # Tell alex to turn by 90 degrees
  alex.forward(30)  # Complete the second side of a rectangle

  wn.mainloop() # Wait for user to close window


Use 'turtle.mainloop' instead.

--
Terry Jan Reedy


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

Re: Pyhon 2.x or 3.x, which is faster?

On Thu, 10 Mar 2016 01:54 am, Chris Angelico wrote:

> I have a source of occasional text files that basically just dumps
> stuff on me without any metadata, and I have to figure out (a) what
> the encoding is, and (b) what language the text is in.

https://pypi.python.org/pypi/chardet

> then I have two levels of heuristics to try to guess a
> most-likely encoding

I'm curious, what do you do?

(I stress that trying to guess the character set or encoding from the text
itself is a second-last ditch tactic, for when you really don't know and
can't find out what the encoding is. The final, last-ditch tactic is to
just say "bugger it, I'll pretend it's Latin-1" and get a mess of
moji-bake, but at least an ASCII characters will decode alright, and as an
English speaker, that's all that's important to me :-)

-- 
Steven

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

Re: Pyhon 2.x or 3.x, which is faster?

On Thu, 10 Mar 2016 02:06 am, Jon Ribbens wrote:

> On 2016-03-09, Steven D'Aprano  wrote:
>> generate the output. Without seeing the code you used, I have *no idea*
>> how you could get that result. If you read the file in binary, you should
>> get this:
>>
>> b'\xef\xbb\xbf\xe2\x82\xac\xe2\x82\xac\xe2\x82\xac'
>>
>> Or in decimal:
>>
>> 239, 187, 191, 226, 130, 172, 226, 130, 172, 226, 130, 172
>>
>> How you are getting 8218 instead of 130, I have no idea!
> 
> Decode as "windows-1252".

Nicely done!


py> b'\xef\xbb\xbf\xe2\x82\xac\xe2\x82\xac\xe2\x82\xac'.decode('cp1252')
'ï»¿â‚¬â‚¬â‚¬'
py> [ord(c) for c in _]
[239, 187, 191, 226, 8218, 172, 226, 8218, 172, 226, 8218, 172]



-- 
Steven

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

Re: Pyhon 2.x or 3.x, which is faster?

2016-03-09 Thread Terry Reedy

On 3/9/2016 9:03 AM, BartC wrote:

I've just tried a UTF-8 file and getting some odd results. With a file
containing [three euro symbols]:

€€€

(including a 3-byte utf-8 marker at the start), and opened in text mode,
Python 3 gives me this series of bytes (ie. the ord() of each character):

239
187
191
226
8218
172
226
8218
172
226
8218
172

And prints the resulting string as: ï»¿â‚¬â‚¬â‚¬. Although this latter
might depend on my console's code page setting.

It definitely does.

Changing it to UTF-8 however (CHCP 65001 in Windows)

CP65001 is MS's ugly pretense of unicode compatibility.  It has been 
known to be buggy for over a decade, though some people claim to have 
gotten some use of it.

> gives me this error when I run the  program again:

--
Fatal Python error: Py_Initialize: can't initialize sys standard streams
LookupError: unknown encoding: cp65001

This application has requested the Runtime to terminate it in an unusual
way.
Please contact the application's support team for more information.
--

So I think I'll skip Unicode handling to start off with! (I've already
had plenty of fun and games with it in the past.)

At least on Windows, use IDLE for the BMP subset of unicode.  tk and 
hence tkinter and IDLE can handle any char in the BMP subset.  I believe 
that which are actually displayed and which are shown as boxes depends 
on the font.  On my US Win10 system:

IDLE with Lucida Console:
>>> s = '€€€'
>>> s
'€€€'

In the console interpreter: '???' is printed.

--
Terry Jan Reedy

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

Re: Pyhon 2.x or 3.x, which is faster?

On Thu, Mar 10, 2016 at 2:33 AM, Steven D'Aprano  wrote:
> On Thu, 10 Mar 2016 01:54 am, Chris Angelico wrote:
>
>> I have a source of occasional text files that basically just dumps
>> stuff on me without any metadata, and I have to figure out (a) what
>> the encoding is, and (b) what language the text is in.
>
> https://pypi.python.org/pypi/chardet
>
>> then I have two levels of heuristics to try to guess a
>> most-likely encoding
>
> I'm curious, what do you do?

Collect subtitles files from random internet contributors and
determine whether they add to the existing corpus of material. The
first heuristic level is chardet, as mentioned; but with the specific
files that I'm processing, it has some semi-consistent errors, so I
scripted around that - eg "if chardet says ISO-8859-2, and these byte
patterns exist, it's probably actually codepage 1250". IIRC the second
level is entirely translating from an ISO-8859 to the
nearest-equivalent Windows codepage.

> (I stress that trying to guess the character set or encoding from the text
> itself is a second-last ditch tactic, for when you really don't know and
> can't find out what the encoding is. The final, last-ditch tactic is to
> just say "bugger it, I'll pretend it's Latin-1" and get a mess of
> moji-bake, but at least an ASCII characters will decode alright, and as an
> English speaker, that's all that's important to me :-)

What I do is attempt to guess, *and then hand it to the user*. I have
a little "cdless" script that does a chardet on a file, decodes
accordingly, and pipes the result into 'less' [1]. The most powerful
character encoding detection tool in my arsenal is 'less'.

Pretending that text is Latin-1 is actually a pretty good start. If I
didn't have chardet, I'd be mainly using this:

https://github.com/Rosuav/shed/blob/master/charconv.py

With no args, this will take the beginning of the file (it tries to
get one paragraph of up to 1KB) and decode it using all the ISO-8859-*
encodings, displaying the results for human analysis. That's
surprisingly effective for a manual job. A large number of European
languages use a lot of ASCII letters and then each have their own
distinct non-ASCII characters in between; the only truly confusable
encodings are the ones that are entirely non-ASCII (Cyrillic, Arabic,
Greek, Hebrew - ISO-8859-5 through 8), and mis-decoding one as another
usually results in complete nonsense (words with impossible
vowel/consonant combinations, for instance). It does take *linguistic*
analysis (as opposed to purely mathematical/charcode), but it isn't
too hard.

ChrisA

[1] ... and since Unix pipes carry bytes, not text, this involves
encoding it as UTF-8. But that's an implementation detail between
cdless and less.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Pyhon 2.x or 3.x, which is faster?

On Wed, 9 Mar 2016 01:03 pm, Dennis Lee Bieber wrote:

> On Wed, 09 Mar 2016 10:28:40 +1100, Steven D'Aprano 
> declaimed the following:
> 
> 
>>
>>Python will never expand \n to \r\n. But it may translate \r\n to \n.
>>
> Not on input, but it will on output (on Windows)

That surprises me. Perhaps I read the documentation wrongly? Ah yes,
apparently I did -- Python optionally will modify line endings in both
directions, controlled by the user. In Python 3:

https://docs.python.org/3.5/library/functions.html#open

Thanks for the correction.

-- 
Steven

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

Re: A mistake which almost went me mad

On Thursday, March 3, 2016 at 4:22:07 AM UTC-6, ast wrote:
> Hello
> 
> This has to be told
> 
> I created a file pickle.py in order to test some files
> read/write with objects and put it in a directory
> which is on my python path. 
> 
> Then the nightmare began
> 
> - Idle no longer works, window no longer opens 
> when double clicked, no errors messsages
> 
> - python -m pip list doesnt work, crash with an 
> error message related to pickle
> 
> I uninstalled python34 and reinstalled it, same problem
> I uninstalled python34 and instaled 3.5, same problem
> 
> ...
> 
> I finally understood that pickle.py is the name of the file
> containing the official pickle module.
> 
> This module is probably used by various python programs,
> IDLE, pip ...
> 
> Instead of reading official pickle, python read my file ...

This is a design flaw of the python language. If all standard library modules 
would have been protected from the global namespace by a single symbol -- say 
"stdlib" or "py" or whatever -- we would only need to avoid *ONE* symbol, 
instead of hundreds of them!!! Third party modules should have their own 
namespace as well. 

 from stdlib import re
 from stdlib.re import search
 from extlib import PIL
 from extlib.PIL import Image, ImageTk

Since those responsible for this flaw are unable, or unwilling, to fix it, the 
only solution for *YOU* is to (1) memorize every module name that exists in the 
python standard library, and also those that exist in your "site-packages" 
directory, or (2) hide all your personal modules behind a single symbol by 
utilizing a package.

 +mylib
   __init__.py
   pickle.py

import mylib.pickle as mypickle
mypickle.do_something()

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

[ANN] First PyCon Israel (May 2,3)

2016-03-09 Thread Miki Tebeka

Greetings,

The first PyCon Israel is happening! It's taking place on May 2-3, 2016, will 
be attended by hundreds of Pythonistas, and is sponsored by major international 
and local companies that use Python as part of their daily work.

CFP is open, please head over to http://il.pycon.org/2016/ to see more details.

See you there,
--
Miki
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Adding Icon To Tkinter Window

On Saturday, March 5, 2016 at 12:08:27 PM UTC-6, Grant Edwards wrote:
> You'll have to be a lot more specific about what you mean by "add an
> icon to a window".  Do you just want to display an .ico file within a
> window?

I think he wants to use his *OWN* icon on a window's title bar, instead of the 
default icon that Tkinter uses. It would help if he posted the code he tried, 
along with any exceptions that were raised. 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Adding Icon To Tkinter Window

On Saturday, March 5, 2016 at 3:39:00 PM UTC-6, Terry Reedy wrote: 
> No single simple statement work for all situations.  You should have 
> specified OS, Python version, and tcl/tk version.  (IDLE's Help -> About 
> IDLE displays full tk version).

Yes, because Tkinter is not as cross-platform as it's hyped to be.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Pyhon 2.x or 3.x, which is faster?


On 09/03/2016 14:57, Steven D'Aprano wrote:

On Thu, 10 Mar 2016 01:11 am, Chris Angelico wrote:


The first three bytes are the "UTF-8 BOM", which suggests you may have
created this in a broken editor like Notepad.


Notepad may be horribly crippled, but I'm not entirely sure "broken" is the
right word for it. Does it do anything *wrong*? I don't think so.


(Well, it's quite difficult to get it to save to the right filename (it 
insists on sticking ".txt" on the end even when the file name already 
has an extension).


And if you're not looking, it will 'Save As' in some arbitrary 
directory, because it remembers it from the last time you used it a 
month ago for a different project and in a different location. Very 
puzzling when you try and load it again and it's nowhere to be seen!


It doesn't occur it to use to use the same directory it's just loaded a 
file from as a default.


But it does have a reasonable choice of output encodings.)

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

Re: Pyhon 2.x or 3.x, which is faster?

On Wed, 9 Mar 2016 11:53 pm, Marko Rauhamaa wrote:

> It came off as standard schoolyard bullying.

You must have lived a privileged life if you think a little sarcasm is what
school bullies do.

If we're going to exchange pop psychology tales, I don't know what it's like
for young girls, but in my experience when it comes to boys sarcasm is far
more likely to be used by the *victims* of bullying as a (pathetically
ineffective) defence mechanism.

Of course, things may be different on the Internet. Bullies cannot, as a
rule, punch you in the face and stomp on your lunch like they can in the
schoolyard, so perhaps they have learned to co-opt the tactics of their
erstwhile victims.

>If your child often tries to explain away misdeeds with 'We were just
>having fun ...', [...] you may just have a bully in the making living
>under your roof.

They might even be a psychopath. They could even grow up to be a serial
killer! Why, they might even be the next Hitler!!! Better drown them in the
bathtub now, before they kill 6 million people and start a world war!!!1!

Or... maybe they actually were just having fun, just like they said, and the
parents are over-protective, over-suspicious, over-reacting killjoys who
misinterpret the rough and tumble of play as abuse.

>> Even if I used ... sarcasm.
> 
>The dictionary defines Sarcasm as: "The use of irony to mock or
>convey contempt"

Well duh. I was mocking and conveying my contempt of Bart's error handling
code ("sys.exit()"). Wasn't that obvious? Perhaps I could add some markup
next time:

"Brilliant! I love code like this!"

Or do you think it would sting less if I were merely brutally honest?

"Your code is bad and you should feel bad for having written it."

Or perhaps "If you were a student of mine, I would fail you for that code."

Or perhaps you think I should have given him an A+ and an elephant stamp for
effort? "We're all winners here, yay!"

I think Bart made the right response under the circumstances: he pointed out
that his code was obviously quick and dirty code for testing purposes and
not intended as production code, and he mocked me for not having noticed
this fact, as he was completely right to do. But I was mislead by his
earlier comments, and thought that it was production code (even if his
user-base consisted of just one person, himself).

-- 
Steven

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

Re: Adding Icon To Tkinter Window - Followup

2016-03-09 Thread Serhiy Storchaka


On 06.03.16 18:30, Wildman via Python-list wrote:

That does not work...

$ ./makexface.py
Traceback (most recent call last):
   File "./makexface.py", line 236, in 
 root.wm_iconphoto(True, img)
   File "/usr/lib/python2.7/lib-tk/Tkinter.py", line 1897, in __getattr__
 return getattr(self.tk, attr)
AttributeError: wm_iconphoto


This works in Python 3.x. In 2.7 you should use

root.tk.call('wm', 'iconphoto', str(root), '-default', img, ...)

Note that it is worth to specify images for several different sizes (up 
to 128x128 for OS X).


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

Re: Public Service Announcement: planetpython.org


On 09/03/2016 15:27, Tim Golden wrote:

For those who didn't know, we have a feed aggregator at
https://planetpython.org. We're trying to clean up out-of-date or
incorrect feed URLs.



This is available from news.gmane.org as gwene.org.python.planet

I just wish that I'd found out about the one stop shop that is gmane 
years before I acually did.


--
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: turtle ??

2016-03-09 Thread MRAB


On 2016-03-09 11:55, Steven D'Aprano wrote:

On Wed, 9 Mar 2016 08:06 pm, Peter Otten wrote:


Ömer sarı wrote:


l would like to ask a question as l m a little bit confused .


In computing details matter, and in communication odd personal habits
distract from the actual message. Please reconsider your use of an "l" as
a replacement for "I".


While I don't disagree, it is possible that Ömer sarı is typing on a
keyboard that doesn't have an I, or makes it difficult to use. The last
letter of his(?) name is LATIN SMALL LETTER DOTLESS I, which suggests
possibly a Turkish or Armenian keyboard. I don't know how easy it is to get
I as opposed to İ (LATIN CAPITAL LETTER I WITH DOT ABOVE). So we might like
to give him a little slack.

But apart from that, I agree: in the long term, if Ömer is going to be
programming, he'll need to do something about that keyboard.


FYI, the uppercase of "ı" is "I" and the lowercase of "İ" is "i".

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

Re: even faster heaps

2016-03-09 Thread Sven R. Kunze


On 08.03.2016 08:12, srinivas devaki wrote:

Hi,
sorry i didn't get to your last mail as i'm having exams at that time.


No problem. :) I hope they went all well for you.


Everything is good so far.

but if at all the purpose is to add features to the stdlib heap and
keeping the speed offered by the stdlib, why aren't you allowing the
duplicate elements which is possible with stdlib heap.


Don't let the old boy have time to rest, he? ;-)

But that's good. We all need a kick in the ass from time to time in 
order to get thing running. :-)



to be able to add duplicate elements you just have to make the set as
a dict with counter as the value. afterall it is highly common to have
priority task scheduling with equal priorities to the tasks.

as far as the benchmarks are concerned it didn't change much with the
current dataset. but it is not valid to compare them as the current
dataset is intended for unique elements. but with the dict the dataset
can contain elements which have equal keys.


So, my initial design idea was to wrap these items up in their own 
wrapper and thus avoiding the duplicate issue. I discussed this with Cem 
here http://code.activestate.com/lists/python-list/697567/  :)



on my machine with 10 repetitions in the test_xheap_time.py
** results for the code which supports duplicate elements
[email protected]/eightnoteight/xheap **

(u'init', u'heapq  ', u' 0.45 ( 1.00x)  4.59 ( 1.00x) 52.24 (
1.00x) 553.80 ( 1.00x)')
(u'', u'Heap   ', u' 0.48 ( 1.07x)  5.41 ( 1.18x) 75.89 (
1.45x) 786.46 ( 1.42x)')
(u'', u'RemovalHeap', u' 0.86 ( 1.93x)  9.98 ( 2.18x) 131.28 (
2.51x) 1364.14 ( 2.46x)')

(u'pop ', u'heapq  ', u' 0.09 ( 1.00x)  1.27 ( 1.00x) 15.64 (
1.00x) 184.76 ( 1.00x)')
(u'', u'Heap   ', u' 0.10 ( 1.07x)  1.33 ( 1.05x) 16.30 (
1.04x) 191.43 ( 1.04x)')
(u'', u'RemovalHeap', u' 0.15 ( 1.64x)  1.87 ( 1.47x) 21.33 (
1.36x) 242.31 ( 1.31x)')

(u'push', u'heapq  ', u' 0.04 ( 1.00x)  0.33 ( 1.00x)  3.53 (
1.00x) 32.99 ( 1.00x)')
(u'', u'Heap   ', u' 0.05 ( 1.20x)  0.41 ( 1.25x)  4.37 (
1.24x) 44.14 ( 1.34x)')
(u'', u'RemovalHeap', u' 0.06 ( 1.58x)  0.56 ( 1.70x)  5.85 (
1.66x) 59.59 ( 1.81x)')


(u'init', u'heapq', u' 0.45 ( 1.00x)  8.00 ( 1.00x) 109.50 (
1.00x) 898.50 ( 1.00x)')
(u'', u'OrderHeap', u' 0.50 ( 1.10x)  8.75 ( 1.09x) 112.63 (
1.03x) 1108.26 ( 1.23x)')
(u'', u'XHeap', u' 0.93 ( 2.06x) 13.88 ( 1.74x) 170.97 (
1.56x) 1709.94 ( 1.90x)')

(u'pop ', u'heapq', u' 0.04 ( 1.00x)  0.54 ( 1.00x)  6.50 ( 1.00x)
76.64 ( 1.00x)')
(u'', u'OrderHeap', u' 0.06 ( 1.73x)  0.80 ( 1.49x)  9.16 ( 1.41x)
101.68 ( 1.33x)')
(u'', u'XHeap', u' 0.10 ( 2.65x)  1.14 ( 2.13x) 12.60 ( 1.94x)
137.73 ( 1.80x)')

(u'push', u'heapq', u' 0.01 ( 1.00x)  0.17 ( 1.00x)  1.86 ( 1.00x)
14.85 ( 1.00x)')
(u'', u'OrderHeap', u' 0.04 ( 3.88x)  0.47 ( 2.86x)  4.80 ( 2.58x)
42.98 ( 2.89x)')
(u'', u'XHeap', u' 0.04 ( 3.79x)  0.47 ( 2.85x)  4.85 ( 2.61x)
43.94 ( 2.96x)')


(u'remove', u'RemovalHeap', u' 0.07 ( 1.00x)  0.73 ( 1.00x)  7.38 (
1.00x) 75.18 ( 1.00x)')
(u'  ', u'XHeap  ', u' 0.05 ( 0.79x)  0.55 ( 0.75x)  5.52 (
0.75x) 55.08 ( 0.73x)')




** benchmark for current git HEAD d0707fba2401a3cef8aed54028fe6d7e9497faa5 **


(u'init', u'heapq  ', u' 0.49 ( 1.00x)  5.03 ( 1.00x) 58.71 (
1.00x) 600.91 ( 1.00x)')
(u'', u'Heap   ', u' 0.51 ( 1.05x)  5.83 ( 1.16x) 82.88 (
1.41x) 886.22 ( 1.47x)')
(u'', u'RemovalHeap', u' 0.58 ( 1.19x)  7.19 ( 1.43x) 106.80 (
1.82x) 1108.52 ( 1.84x)')

(u'pop ', u'heapq  ', u' 0.10 ( 1.00x)  1.41 ( 1.00x) 17.64 (
1.00x) 209.82 ( 1.00x)')
(u'', u'Heap   ', u' 0.11 ( 1.07x)  1.47 ( 1.04x) 18.27 (
1.04x) 215.14 ( 1.03x)')
(u'', u'RemovalHeap', u' 0.15 ( 1.52x)  1.91 ( 1.35x) 22.64 (
1.28x) 258.68 ( 1.23x)')

(u'push', u'heapq  ', u' 0.04 ( 1.00x)  0.32 ( 1.00x)  3.49 (
1.00x) 33.92 ( 1.00x)')
(u'', u'Heap   ', u' 0.05 ( 1.18x)  0.39 ( 1.22x)  4.21 (
1.20x) 42.03 ( 1.24x)')
(u'', u'RemovalHeap', u' 0.06 ( 1.52x)  0.52 ( 1.62x)  5.60 (
1.60x) 56.54 ( 1.67x)')

---

pip install failure for cryptography, gnureadline

2016-03-09 Thread Pietro Paolini

Hi everybody,

I am not really familiar with the Py subsystem, even though I have got some
guidance from some colleague, I am getting stuck when installing a list of
packages contained in a file, running such command :


pip install -r /home/pietro/projects/cloud-provisioning/requirements.txt

Brings me :


Collecting docutils>=0.10 (from botocore<1.4.0,>=1.3.0->boto3==1.2.3->-r
/home/pietro/projects/cloud-provisioning/requirements.txt (line 9))
Building wheels for collected packages: cryptography, gnureadline
  Running setup.py bdist_wheel for cryptography: started
  Running setup.py bdist_wheel for cryptography: finished with status
'error'
  Complete output from command
/home/pietro/python-environment/cloud-provisioning-ve-2/bin/python -u -c
"import setuptools,
tokenize;__file__='/tmp/pip-build-pzgHry/cryptography/setup.py';exec(compile(getattr(tokenize,
'open', open)(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))"
bdist_wheel -d /tmp/tmpoDkrDHpip-wheel- --python-tag cp27:
  running bdist_wheel
  running build
  running build_py
  creating build
  creating build/lib.linux-x86_64-2.7
  creating build/lib.linux-x86_64-2.7/cryptography
  copying src/cryptography/__init__.py ->
build/lib.linux-x86_64-2.7/cryptography
  copying src/cryptography/utils.py ->
build/lib.linux-x86_64-2.7/cryptography
  copying src/cryptography/x509.py ->
build/lib.linux-x86_64-2.7/cryptography
  copying src/cryptography/fernet.py ->
build/lib.linux-x86_64-2.7/cryptography
  copying src/cryptography/exceptions.py ->
build/lib.linux-x86_64-2.7/cryptography
  copying src/cryptography/__about__.py ->
build/lib.linux-x86_64-2.7/cryptography
  creating build/lib.linux-x86_64-2.7/cryptography/hazmat
  copying src/cryptography/hazmat/__init__.py ->
build/lib.linux-x86_64-2.7/cryptography/hazmat
  creating build/lib.linux-x86_64-2.7/cryptography/hazmat/primitives
  copying src/cryptography/hazmat/primitives/interfaces.py ->
build/lib.linux-x86_64-2.7/cryptography/hazmat/primitives
  copying src/cryptography/hazmat/primitives/__init__.py ->
build/lib.linux-x86_64-2.7/cryptography/hazmat/primitives
  copying src/cryptography/hazmat/primitives/serialization.py ->
build/lib.linux-x86_64-2.7/cryptography/hazmat/primitives
  ography/hazmat/backends/commoncrypto
  copying src/cryptography/hazmat/backends/commoncrypto/hashes.py ->
build/lib.linux-x86_64-2.7/cryptography/hazmat/backends/commoncrypto
  copying src/cryptography/hazmat/backends/commoncrypto/hmac.py ->
build/lib.linux-x86_64-2.7/cryptography/hazmat/backends/commoncrypto
  copying src/cryptography/hazmat/backends/commoncrypto/backend.py ->
build/lib.linux-x86_64-2.7/cryptography/hazmat/backends/commoncrypto
  running egg_info
  writing requirements to src/cryptography.egg-info/requires.txt
  writing src/cryptography.egg-info/PKG-INFO
  writing top-level names to src/cryptography.egg-info/top_level.txt
  writing dependency_links to src/cryptography.egg-info/dependency_links.txt
  writing entry points to src/cryptography.egg-info/entry_points.txt
  warning: manifest_maker: standard file '-c' not found
  []
  reading manifest file 'src/cryptography.egg-info/SOURCES.txt'
  reading manifest template 'MANIFEST.in'
  no previously-included directories found matching 'docs/_build'
  warning: no previously-included files matching '*' found under directory
'vectors'
  writing manifest file 'src/cryptography.egg-info/SOURCES.txt'
  creating build/lib.linux-x86_64-2.7/cryptography/hazmat/primitives/src
  copying src/cryptography/hazmat/primitives/src/constant_time.c ->
build/lib.linux-x86_64-2.7/cryptography/hazmat/primitives/src
  copying src/cryptography/hazmat/primitives/src/constant_time.h ->
build/lib.linux-x86_64-2.7/cryptography/hazmat/primitives/src
  creating
build/lib.linux-x86_64-2.7/cryptography/hazmat/bindings/__pycache__
  copying
src/cryptography/hazmat/bindings/__pycache__/_Cryptography_cffi_590da19fxffc7b1ce.c
-> build/lib.linux-x86_64-2.7/cryptography/hazmat/bindings/__pycache__
  copying
src/cryptography/hazmat/bindings/__pycache__/_Cryptography_cffi_8f86901cxc1767c5a.c
-> build/lib.linux-x86_64-2.7/cryptography/hazmat/bindings/__pycache__
  copying
src/cryptography/hazmat/bindings/__pycache__/_Cryptography_cffi_d5a71fe5xf53f5318.c
-> build/lib.linux-x86_64-2.7/cryptography/hazmat/bindings/__pycache__
  running build_ext
  building '_Cryptography_cffi_d5a71fe5xf53f5318' extension
  creating build/temp.linux-x86_64-2.7
  creating build/temp.linux-x86_64-2.7/src
  creating build/temp.linux-x86_64-2.7/src/cryptography
  creating build/temp.linux-x86_64-2.7/src/cryptography/hazmat
  creating build/temp.linux-x86_64-2.7/src/cryptography/hazmat/bindings
  creating
build/temp.linux-x86_64-2.7/src/cryptography/hazmat/bindings/__pycache__
  x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall
-Wstrict-prototypes -fno-strict-aliasing -D_FORTIFY_SOURCE=2 -g
-fstack-protector-strong -Wformat -Werror=format-security -fPIC
-I/usr/include/python2.7 -c
src/cryptograph

RE: Adding Icon To Tkinter Window - Followup

2016-03-09 Thread Joaquin Alzola

>  root.wm_iconphoto(True, img)

What are the images format allowed?
This email is confidential and may be subject to privilege. If you are not the 
intended recipient, please do not copy or disclose its content but contact the 
sender immediately upon receipt.
-- 
https://mail.python.org/mailman/listinfo/python-list

it doesn't want to open

2016-03-09 Thread mashaer elmekki








Sent from Windows Mail
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: even faster heaps

2016-03-09 Thread Sven R. Kunze


On 06.03.2016 14:59, Sven R. Kunze wrote:
Using the original xheap benchmark 
, I could 
see huge speedups: from 50x/25x down to 3x/2x compared to heapq. 
That's a massive improvement. I will publish an update soon.


An here it is: http://srkunze.blogspot.com/2016/03/even-faster-heaps.html


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

Re: it doesn't want to open

2016-03-09 Thread Grant Edwards

Um, twist it the other way?

-- 
Grant Edwards   grant.b.edwardsYow! Excuse me, but didn't
  at   I tell you there's NO HOPE
  gmail.comfor the survival of OFFSET
   PRINTING?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: even faster heaps

2016-03-09 Thread Sven R. Kunze


On 09.03.2016 19:19, Sven R. Kunze wrote:



ps: there are two error's when i ran tests with test_xheap.


Damn. I see this is Python 2 and Python 3 related. Thanks for bringing 
this to my attention. I am going to fix this soon.


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

Re: exit from Tkinter mainloop Python 2.7

On Friday, March 4, 2016 at 3:50:43 PM UTC-6, [email protected] wrote:
> Thanks for your attention to this matter.
> My code now look like this: [...]

All of the help offered in this thread ignores the elephant
in the room. What are you trying to achieve here Kevin? To
me, this looks like some sort of dialog, but if it is a
dialog, the whole design is a miserable failure. And why in
the hell would you call the w.quit() method when the user
presses a "continue" button? Do you realize that the quit
method does not "close the dialog" (if you can call this a
dialog), no, but simply instructs Tkinter to stop processing
events? Once a user clicks your "continue" button, he can no
longer interact with the GUI, and the user is left in a
state of befuddlement.

Those who've attempted to help you have suggested that you
utilize the quit method in your "continue button callback"
so that the widgets will stay alive long enough for you to
fetch the value, but that is horrible advice. Trust me, the
quit method is not something you want to use unless you know
what you're doing. It's should never be used in daily
coding, and only in very specific advanced circumstances.

The destroy method that you utilized initially *IS* the
correct course of action here. You see, your interface is
not a failure because of the destroy method, no, it is a
failure because you failed to (1) fetch the values in the
button callback BEFORE the widgets are destroyed, and (2)
You failed to store those values somewhere that will be
persistent after the function returns. But even if you
followed both of these suggestions, you design is flawed.

If you want to create a proper "dialog interface", the key
is not to use the "quit" method, but to follow these simple
design rules:

  (1) Present the user with a "focused window" that contains
  "form" filled with "input fields" that will facilitate the
  inputting of the required values. Typically, but not
  always, you'll want this window to block program execution
  until the user submits the form (FYI: Dialogs that block
  are commonly referred to as "modal dialogs")

  (2) Include at least one button to submit the values. This
  button is typically named "Okay", or "Yes" or "Submit".
  But when the user presses this button, the dialog will
  *NOT* be closed until the values have been validated. If
  the values are found to be inadequate, the dialog will
  inform the user of his mistakes and refocus the input-form
  for editing. A more advanced dialog will utilize fields
  that validate their *OWN* values in "real time". These
  "real time validations" are less likely to confuse a user,
  and they facilitate a more efficient interface since the
  user will be aware of mistakes as they occur.

  (3) Include at least one button to cancel the interaction.
  Sometimes, a user will open a dialog accidentally, or for
  some other reason decide that they need a way out. For
  instance: Imagine all the times that you've accidentally
  pressed the X button on a window. If the window closed
  without first asking you "Do you really want to close
  without saving changes", you'd be screwed!

A proper "dialog window" will be constructed of three basic
top-level components:

+--+
|DIALOG_TITLE  |
+--+
|  |
|   DIALOG_BODY|
|  |
+--+
|  DIALOG_BUTTONS  |
+--+

The DIALOG_TITLE is simply a string that will be displayed
in the title bar of the dialog. The DIALOG_BODY is a fluid
area in the middle that can be filled with user-editable
fields, and the DIALOG_BUTTONS is an area at the bottom
where appropriate buttons will be displayed.

A proper dialog object will allow the caller to display the
dialog in either "modal" or "non-modal" forms, and it will
expose hooks that will allow the programmer to customize the
validation and submission of the form data. An even more
advanced version will require the programmer to extend a
"form object" and pass it into the constructor.

Fortunately, the tkSimpleDialog has already wrapped *SOME*
of this functionality up for you. All you need to do is
import the class and override a few "virtual methods" to
achieve your desired goal. The tkSimpleDialod.Dialog class
exposes 3 hooks that you can utilize to modify the behavior

  (1) body: In this method you create your widgets.It
  requires one argument which is a tk.Frame instance that
  the widgets can be made a child of.

  (2) validate: in this method you validate your widgets and
  return a Boolean flag. If you don't need any validation
  then don't bother to override it.

  (3) apply: In this method you can do something with the
  "dialog.result" *AFTER* the dialog closes. Typically
  though, you will handle this action from outside the
  dialog object. But in certain limited circumstances, it
  can si

Re: it doesn't want to open

On Wednesday, March 9, 2016 at 12:48:45 PM UTC-6, Grant Edwards wrote:
> Um, twist it the other way?

I don't think he's trying to open a can Grant, this sounds like a *REAL* 
emergency. My guess is that he is emailing us from the toilet because he needs 
advice on how to free a stuck zipper. Unfortunately for him, i don't have any 
good answers for that one -- he may just have to sacrifice those jeans.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: it doesn't want to open

2016-03-09 Thread sohcahtoa82

On Wednesday, March 9, 2016 at 10:40:27 AM UTC-8, mashaer elmekki wrote:
> Sent from Windows Mail

Did you try to attach a screenshot or something?  This mailing list is text 
only.  Your attachment will be removed.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Creating barrel distortion of video

2016-03-09 Thread semeon . risom

On Tuesday, 8 March 2016 19:53:10 UTC-6, Chris Angelico  wrote:
> On Wed, Mar 9, 2016 at 12:32 PM,   wrote:
> > This may seem like an odd request for the main python google group, but I 
> > thought this question might have answers coming from different backgrounds 
> > that utilize python.
> >
> > I'm trying to find a way of rendering an optical distortion on a video I 
> > will be presenting through the use of a head-mounted display. This 
> > distortion is necessary to correct the video due to the optics being used. 
> > Any advice on a module(s) or examples that already do this?
> >
> 
> Hi! Seems like a perfectly reasonable request; there are tens of
> thousands of packages listed on the Python Package Index, and this
> mailing list is one of the best places to find advice!
> 
> Are you playing the video in real-time, or is it stored in a file that
> you'll end up playing? If the latter, I would recommend looking into
> FFMpeg (or its fork AVConv), which has an insane number of features,
> and quite likely has what you want. It'll read in a file and write out
> a file.
> 
> If it's real-time, though, I'm not sure what's best to do. Do you know
> exactly what distortion you're trying to perform here?
> 
> ChrisA

It'll be a barrel distortion. I won't need real time processing, and I'll be 
sure to check out both FFMpeg and it's fork. Thank you!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Creating barrel distortion of video

2016-03-09 Thread semeon . risom

On Tuesday, 8 March 2016 19:46:18 UTC-6, Ben Finney  wrote:
> [email protected] writes:
> 
> > This may seem like an odd request for the main python google group
> 
> (Note that this is not a Google group. Google may be presenting this
> forum to you, but it's not exclusive to Google and many of us don't
> participate there.)
> 
> > but I thought this question might have answers coming from different
> > backgrounds that utilize python.
> 
> Your question is fine for this forum. Thanks for investigating Python!
> 
> > I'm trying to find a way of rendering an optical distortion on a video
> > I will be presenting through the use of a head-mounted display. This
> > distortion is necessary to correct the video due to the optics being
> > used. Any advice on a module(s) or examples that already do this?
> 
> I have no experience with such a library. Possible candidates include:
> 
> * moviepy: Video editing with Python
>   https://pypi.python.org/pypi/moviepy/>
> 
> * pygame: wrapper module for the SDL multimedia library
>   https://pypi.python.org/pypi/Pygame/1.7.1>
> 
> -- 
>  \  "Holy hole in a donut, Batman!" --Robin |
>   `\   |
> _o__)  |
> Ben Finney

I'll check both of these out. Thank you
-- 
https://mail.python.org/mailman/listinfo/python-list

Improving performance in matrix operations

2016-03-09 Thread Drimades

I'm doing some tests with operations on numpy matrices in Python. As an 
example, it takes about 3000 seconds to compute eigenvalues and eigenvectors 
using scipy.linalg.eig(a) for a matrix 6000x6000. Is it an acceptable time? Any 
suggestions to improve? Does C++ perform better with matrices? Another thing to 
consider is that matrices I'm processing are heavily sparse.
Do they implement any parallelism? While my code is running, one of my cores is 
100% busy, the other one 30% busy.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Improving performance in matrix operations

2016-03-09 Thread Fabien


On 03/09/2016 09:09 PM, Drimades wrote:

Another thing to consider is that matrices I'm processing are heavily sparse.


Did you look at scipy.sparse.linalg ?

http://docs.scipy.org/doc/scipy/reference/sparse.linalg.html
--
https://mail.python.org/mailman/listinfo/python-list

Re: Pyhon 2.x or 3.x, which is faster?


On 09/03/2016 12:02, BartC wrote:

On 09/03/2016 08:40, Mark Lawrence wrote:

Here's another: you have a program in Python that you'd quite like to
port to another dynamic language. Transcribing actual Python code is
straightforward. Until you come to an import of a module that you can't
find, because it's not written in Python. Now what? Now, you might
appreciate the advantage of a program in 100% pure Python.



That is not Python's problem, or my problem, that is your problem.

Not that it matters, when you release BartC or whatever you call your 
language it'll take over the world, so I'm looking forward to dropping 
Python.  What is the release date?  Could it be the same as that for 
Python 2.8 or RickedPython?  Will the unicode handling be better than 
that of the dread Python 3.3+, PEP393 Flexible String Representation as 
repeatedly pointed out by the RUE?  Performance wise will it be tested 
against real world benchmarks or microbechmarks?  Better still, will it 
be bug free, such that I don't have to waste my time on the equivalent 
of bugs.python.org raising problems, which should have been foreseen by 
your one man crew?


--
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: Pickle getstate setstate and restoring n/w - beazley pg 172

2016-03-09 Thread Ian Kelly

On Wed, Mar 9, 2016 at 2:14 AM, Veek. M  wrote:
> what i wanted to know was, x = Client('192.168.0.1') will create an
> object 'x' with the IP inside it. When I do:
> pickle.dump(x)
> pickle doesn't know where in the object the IP is, so he'll call
> __getstate__ and expect the return value to be the IP, right?

pickle doesn't care what the return value is, other than it needs to
be something picklable. I suggest returning a dict containing the IP
address, to make it easier to add additional state later if needed.

That said, I wouldn't pickle a TCP client in the first place. You may
be able to restore the client state, but you can't easily restore any
server state, which could easily lead to mismatching network states.
Also, what do you think should happen if the connection fails while
unpickling?

> Similarly, whilst unpickling, __setstate__ will be called in a manner
> similar to this:
> x.__setstate__(self, unpickledIP)
>
> __setstate__ can then populate 'x' by doing
> self.x = str(unpickledIP)
>
> the type info is not lost during pickling is it, therefore 'str' is not
> required is it?

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

Re: Pyhon 2.x or 3.x, which is faster?

On 09/03/2016 21:13, Mark Lawrence wrote:

On 09/03/2016 12:02, BartC wrote:

On 09/03/2016 08:40, Mark Lawrence wrote:

Here's another: you have a program in Python that you'd quite like to
port to another dynamic language. Transcribing actual Python code is
straightforward. Until you come to an import of a module that you can't
find, because it's not written in Python. Now what? Now, you might
appreciate the advantage of a program in 100% pure Python.

That is not Python's problem, or my problem, that is your problem.

Maybe that's not the best example of why someone might prefer a 'Python' 
program to be actually written in Python. Sometimes you want to 
understand how code works or what it does or simply to learn from it. 
(Or sometimes, to rip bits off.) Then it's frustrating when you come up 
against a dead-end so quickly. Because the real meat isn't in Python at all.

Actually, you're doing a good job of arguing for not doing using Python 
for real coding! Apart from just launching tasks.

Not that it matters, when you release BartC or whatever you call your
language it'll take over the world, so I'm looking forward to dropping
Python.  What is the release date?

(A first version might have been around 1986. I can't remember exactly. 
Perhaps you think this is vapourware? It's not a commercial product at 
the minute, just a hobby. Originally it was a scripting language for a 
commercial app of mine.)

Could it be the same as that for
 Performance wise will it be tested
against real world benchmarks or microbechmarks?

(The byte-code compiler for the current version is written in itself. It 
can compile itself (some 25Kloc) in about 1 second (that's running 
interpreted, dynamic byte-code on a not-very-fast PC).

The interpreter for the byte-code is also written in another language of 
mine, which statically typed. The compiler for the latter is written in 
the interpreted language too.

I'd quite like to port either of these compilers to Python, to see what 
PyPy can do with them. (It would also be quite cool to have them in pure 
Python). But I've find these difficult to optimise, because they have 
diverse execution patterns, while PyPy likes loops. I'll see.

A compiler is another good 'pure language' task because, apart from 
input and output at each end, all the computation is self-contained.)

> Python 2.8 or RickedPython?  Will the unicode handling be better than
> that of the dread Python 3.3+, PEP393 Flexible String Representation 
> as repeatedly pointed out by the RUE?

I'm not much interested in Unicode at the minute. I'll pass.

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

Re: Pyhon 2.x or 3.x, which is faster?

On 09/03/2016 23:14, BartC wrote:

On 09/03/2016 21:13, Mark Lawrence wrote:

On 09/03/2016 12:02, BartC wrote:

On 09/03/2016 08:40, Mark Lawrence wrote:

Here's another: you have a program in Python that you'd quite like to
port to another dynamic language. Transcribing actual Python code is
straightforward. Until you come to an import of a module that you can't
find, because it's not written in Python. Now what? Now, you might
appreciate the advantage of a program in 100% pure Python.

That is not Python's problem, or my problem, that is your problem.

Maybe that's not the best example of why someone might prefer a 'Python'
program to be actually written in Python. Sometimes you want to
understand how code works or what it does or simply to learn from it.
(Or sometimes, to rip bits off.) Then it's frustrating when you come up
against a dead-end so quickly. Because the real meat isn't in Python at
all.

Actually, you're doing a good job of arguing for not doing using Python
for real coding! Apart from just launching tasks.

Not that it matters, when you release BartC or whatever you call your
language it'll take over the world, so I'm looking forward to dropping
Python.  What is the release date?

(A first version might have been around 1986. I can't remember exactly.
Perhaps you think this is vapourware? It's not a commercial product at
the minute, just a hobby. Originally it was a scripting language for a
commercial app of mine.)

Could it be the same as that for
 Performance wise will it be tested
against real world benchmarks or microbechmarks?

(The byte-code compiler for the current version is written in itself. It
can compile itself (some 25Kloc) in about 1 second (that's running
interpreted, dynamic byte-code on a not-very-fast PC).

Please answer my question, will it be tested against real world 
benchmarks or microbenchmarks?  The above paragraph, and several 
following paragraphs, are completely irrelevant.

The interpreter for the byte-code is also written in another language of
mine, which statically typed. The compiler for the latter is written in
the interpreted language too.

I'd quite like to port either of these compilers to Python, to see what
PyPy can do with them. (It would also be quite cool to have them in pure
Python). But I've find these difficult to optimise, because they have
diverse execution patterns, while PyPy likes loops. I'll see.

A compiler is another good 'pure language' task because, apart from
input and output at each end, all the computation is self-contained.)

I've no idea what this is meant to mean.

 > Python 2.8 or RickedPython?  Will the unicode handling be better than
 > that of the dread Python 3.3+, PEP393 Flexible String Representation
 > as repeatedly pointed out by the RUE?

I'm not much interested in Unicode at the minute. I'll pass.

Your final comment sums up perfectly your knowledge of computing in 
2016.  I find it fitting that something so funny is put forward on the 
Python mailing list/news group/whatever, given the derivation of the 
name Python.

--
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: Pyhon 2.x or 3.x, which is faster?

On Thu, Mar 10, 2016 at 10:14 AM, BartC  wrote:
> On 09/03/2016 21:13, Mark Lawrence wrote:
>>
>> On 09/03/2016 12:02, BartC wrote:
>>>
>>> On 09/03/2016 08:40, Mark Lawrence wrote:
>>>
>>> Here's another: you have a program in Python that you'd quite like to
>>> port to another dynamic language. Transcribing actual Python code is
>>> straightforward. Until you come to an import of a module that you can't
>>> find, because it's not written in Python. Now what? Now, you might
>>> appreciate the advantage of a program in 100% pure Python.
>>>
>>
>> That is not Python's problem, or my problem, that is your problem.
>
>
> Maybe that's not the best example of why someone might prefer a 'Python'
> program to be actually written in Python. Sometimes you want to understand
> how code works or what it does or simply to learn from it. (Or sometimes, to
> rip bits off.) Then it's frustrating when you come up against a dead-end so
> quickly. Because the real meat isn't in Python at all.

What *is* the real meat of a program? Every action is defined in terms
of smaller actions - a Python program is built out of Python
primitives and function calls, a C program is built out of C
primitives and function calls, an 80x86 machine code program is built
out of 80x86 CPU instructions and calls to other code. Does my MUD
server need to have its own memory allocation code? No. Does it need
an algorithm for adding two integers together? Certainly not! And nor
does it need PNG encoding and decoding algorithms; I simply call on
Image.PNG.encode() and Image.PNG.decode() to do the work, passing
images around in my code as first-class objects. Does it detract from
my code? Not in the least. My code treats "load an image from a PNG
file" as a fundamental operation, and gets on with doing its stuff.

Reinventing the wheel does NOT intrinsically make your code better.
Unless there's something you're doing that's fundamentally different
from what's already available (maybe a database client that uses
non-blocking sockets with async/await), it's usually better to use
what someone else has written. I'd much rather use a one-liner that
reads an image from the disk than wade through your pages and pages of
bitshift operations in Python (especially as it's all uncommented -
how can I know if it's even correct, other than by finding a reference
algorithm written in C?).

>> Python 2.8 or RickedPython?  Will the unicode handling be better than
>> that of the dread Python 3.3+, PEP393 Flexible String Representation > as
>> repeatedly pointed out by the RUE?
>
> I'm not much interested in Unicode at the minute. I'll pass.

Then *get interested*. Unicode is the only way that you'll ever not be
parochially bound to a subset of English - or, worse, bound to an
arbitrary eight-bit codepage that you don't even control the choice
of, such that your program behaves differently on different systems.
FIX YOUR LANGUAGE and support non-English text. Integers, floating
point numbers, lists, and images all need encodings; so does text.
It's an abstract data type, just as the others are.

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

Re: Pyhon 2.x or 3.x, which is faster?

On 2016-03-09, Chris Angelico  wrote:
> Then *get interested*. Unicode is the only way that you'll ever not be
> parochially bound to a subset of English - or, worse, bound to an
> arbitrary eight-bit codepage that you don't even control the choice
> of, such that your program behaves differently on different systems.
> FIX YOUR LANGUAGE and support non-English text.

You can't even support English text properly without Unicode.
Plenty of English words use non-ASCII characters:
café, crêpe, façade, naïve, dæmon, etc.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Pyhon 2.x or 3.x, which is faster?

On Thu, Mar 10, 2016 at 10:48 AM, Jon Ribbens
 wrote:
> On 2016-03-09, Chris Angelico  wrote:
>> Then *get interested*. Unicode is the only way that you'll ever not be
>> parochially bound to a subset of English - or, worse, bound to an
>> arbitrary eight-bit codepage that you don't even control the choice
>> of, such that your program behaves differently on different systems.
>> FIX YOUR LANGUAGE and support non-English text.
>
> You can't even support English text properly without Unicode.
> Plenty of English words use non-ASCII characters:
> café, crêpe, façade, naïve, dæmon, etc.

Like I said, a subset of English.

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

Re: Pyhon 2.x or 3.x, which is faster?

Chris Angelico  writes:

> On Thu, Mar 10, 2016 at 10:14 AM, BartC  wrote:
> > I'm not much interested in Unicode at the minute. I'll pass.
>
> Then *get interested*. Unicode is the only way that you'll ever not be
> parochially bound to a subset of English - or, worse, bound to an
> arbitrary eight-bit codepage that you don't even control the choice
> of, such that your program behaves differently on different systems.

Yes. Any program (and therefore, any programmer) that deals with text in
any way today needs to be Unicode-aware.

This is true whether or not you care about diverse languages. It's no
longer the case that ASCII is enough *even if you arbitrarily limit your
program to English text*.

English text uses non-ASCII characters all the time. Proper punctuation
(e.g. quotation, dashes). Proper spacing (e.g. thin space, no-break
space). Currency symbols (e.g. the Yuan, the Euro, the pound). Official
symbols (e.g. copyright, trademark, degree, section).

If your program fails to preserve these and many other non-ASCII
characters, fails to treat them like any other text, your program does
not handle English-language text.

Many names – of people and places and organisations – cannot be spelled
correctly, even in English, without using non-ASCII characters.

Text was never the same as bytes. Programs hobbled along in the 20th
century making that false assumption, and the problems led to the
creation of Unicode.

Your program will read and write bytes in byte streams (such as files).
They will not write text directly. The only sense in which you can say
that you get text from a file is if you know the text encoding of the
bytes.

This is just a brute fact. You can't have text being anywhere near
bytes, without knowing the text encoding. Guessing is not good enough in
the third millennium.

-- 
 \ “[…] we don’t understand what we mean when we say that [God] is |
  `\‘good’, ‘wise’, or ‘intelligent’.” —Karen Armstrong, _The Case |
_o__)   For God_, 2009 |
Ben Finney

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

Re: Pyhon 2.x or 3.x, which is faster?


On 09/03/2016 23:35, Mark Lawrence wrote:

On 09/03/2016 23:14, BartC wrote:



(The byte-code compiler for the current version is written in itself. It
can compile itself (some 25Kloc) in about 1 second (that's running
interpreted, dynamic byte-code on a not-very-fast PC).


Please answer my question, will it be tested against real world
benchmarks or microbenchmarks?  The above paragraph, and several
following paragraphs, are completely irrelevant.


You think a bloody great compiler is a microbenchmark?!


A compiler is another good 'pure language' task because, apart from
input and output at each end, all the computation is self-contained.)


I've no idea what this is meant to mean.


It means the task doesn't do any function calls to external libraries.

If you're benchmarking, that's usually what you want.


I'm not much interested in Unicode at the minute. I'll pass.



Your final comment sums up perfectly your knowledge of computing in
2016.


You're utterly determined to belittle everything I do aren't you!

But, yeah, I was writing international applications decades ago. I'm not 
working for anyone now and don't need to bother.


From what I've seen, a lot of software can't get it right anyway.

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

Re: Pickle getstate setstate and restoring n/w - beazley pg 172

2016-03-09 Thread Veek. M

Ian Kelly wrote:

> On Wed, Mar 9, 2016 at 2:14 AM, Veek. M  wrote:
>> what i wanted to know was, x = Client('192.168.0.1') will create an
>> object 'x' with the IP inside it. When I do:
>> pickle.dump(x)
>> pickle doesn't know where in the object the IP is, so he'll call
>> __getstate__ and expect the return value to be the IP, right?
> 
> pickle doesn't care what the return value is, other than it needs to
> be something picklable. I suggest returning a dict containing the IP
> address, to make it easier to add additional state later if needed.
> 
> That said, I wouldn't pickle a TCP client in the first place. You may
> be able to restore the client state, but you can't easily restore any
> server state, which could easily lead to mismatching network states.
> Also, what do you think should happen if the connection fails while
> unpickling?
> 
Actually that's just what I was asking: when __getstate__ is called, 
it's upto getstate to return the object to be pickled - it could be an 
IP passed in by the user or pretty much anything 'hello world' even.

Anyway, i think the point of that example (from the book) is that he's 
not saving TCP state info. Instead he provides a seamless iface so the 
user won't even realize the connection had failed (meaning he'll reopen 
the link using the pickled IP and pretend the link never went down).

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

Re: Pyhon 2.x or 3.x, which is faster?

On Thu, Mar 10, 2016 at 11:58 AM, BartC  wrote:
>>> I'm not much interested in Unicode at the minute. I'll pass.
>
>
>> Your final comment sums up perfectly your knowledge of computing in
>> 2016.
>
>
> You're utterly determined to belittle everything I do aren't you!
>
> But, yeah, I was writing international applications decades ago. I'm not
> working for anyone now and don't need to bother.
>
> From what I've seen, a lot of software can't get it right anyway.

That would be because a lot of software is written by people who don't
understand Unicode. "But other people get it wrong too!" wasn't a
valid excuse when I was in grade school, and it still isn't in
real-world work. [1] If you are writing code in 2016 that assumes that
a byte is the same thing as a character, and speak as if this is
alright, then yes, we WILL belittle you for it. It's on par with
thinking that an integer is a 16-bit signed two's complement number.
Sure, back in the 1990s, you could probably get away with that (and
you'll find a lot of games that flip at 32,767 or 65,535 - or, in one
that I remember, at 3,276,700!), but nobody today would let you
pretend that those are identical. Neither is a list identical to a
coherent block of memory (the way a C array often is implemented) -
and neither is a text string identical to a stream of bytes. Even if
you're restricting your text to the ASCII set, there is still an
encoding involved; a typical C string's encoding is "one character per
byte, followed by 0x00", whereas a Pascal string's encoding might be
"one character per byte, preceded by the character count, represented
in a single byte". Every encoding has consequences, every encoding has
costs. You can't get away from this. You can't pretend that you don't
have an encoding.

ChrisA

[1] Except when you're specifically writing compatibility code, where
getting it identically wrong means your program successfully
interoperates with someone else's buggy code. But if you're doing
that, I pity you. That is not a fun job to have.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Pyhon 2.x or 3.x, which is faster?


On 09/03/2016 23:38, Chris Angelico wrote:

On Thu, Mar 10, 2016 at 10:14 AM, BartC  wrote:



program to be actually written in Python. Sometimes you want to understand
how code works or what it does or simply to learn from it. (Or sometimes, to
rip bits off.) Then it's frustrating when you come up against a dead-end so
quickly. Because the real meat isn't in Python at all.


What *is* the real meat of a program? Every action is defined in terms
of smaller actions - a Python program is built out of Python
primitives and function calls, a C program is built out of C
primitives and function calls, an 80x86 machine code program is built
out of 80x86 CPU instructions and calls to other code. Does my MUD
server need to have its own memory allocation code? No. Does it need
an algorithm for adding two integers together? Certainly not! And nor
does it need PNG encoding and decoding algorithms; I simply call on
Image.PNG.encode() and Image.PNG.decode() to do the work, passing
images around in my code as first-class objects. Does it detract from
my code? Not in the least. My code treats "load an image from a PNG
file" as a fundamental operation, and gets on with doing its stuff.


Yes we understand how libraries can be useful.

But, someone had to write that Image.PNG.encode() function at some time. 
What language did they use? If it wasn't Python, then why not?


Why is it OK to let some poor sod slave away in C++ or whatever (a 
ghastly language), while others then reap the benefits writing in an 
easy 'soft' language?


I've been interested for a while in broadening the scope of scripting 
languages so that less work has to be done in 'hard' ones. (Although I 
admit that taking over imaging functions is probably not going to be 
viable, except perhaps for rather small images.)


It seems other have the same idea with the advent of fast JIT systems.

But the attitude in this group has been very different; Python /is/ 
slow, but so what? Just a general shrug. So long as /someone else/ uses 
the hard language to created the needed libraries, the speed of pure 
Python is irrelevant. New version of Python is now half the speed? 
Another shrug!



Reinventing the wheel does NOT intrinsically make your code better.


But you might end up with a small, manageable wheel that does just what 
you want instead of the same 100' monster than everything else is using!


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

Re: Pyhon 2.x or 3.x, which is faster?

On Thu, 10 Mar 2016 10:35 am, Mark Lawrence wrote:

> On 09/03/2016 23:14, BartC wrote:

>> (The byte-code compiler for the current version is written in itself. It
>> can compile itself (some 25Kloc) in about 1 second (that's running
>> interpreted, dynamic byte-code on a not-very-fast PC).
> 
> Please answer my question, will it be tested against real world
> benchmarks or microbenchmarks?  The above paragraph, and several
> following paragraphs, are completely irrelevant.

Mark, Bart's answer is a very good answer. He has written a self-hosting
interpreter and compiler. That is a good (although not perfect) "real world
benchmark".

I get it that you're keen to jump into the fray and defend the honour of
Python, but Python doesn't need to be defended from Bart. He's just one
guy, he's retired, and he has an interesting little language as a hobby.
What's the threat? Don't go all Ranting Rick on us and think that the
entire computing community is going to abandon Python for Bart's private
and unpublished language.

I've said it before, and I'll say it again: I think that Bart's language
sounds interesting. I'm not sure exactly where it would sit in the
computing ecosystem, but if it works for him, good for him.

>> The interpreter for the byte-code is also written in another language of
>> mine, which statically typed. The compiler for the latter is written in
>> the interpreted language too.
>>
>> I'd quite like to port either of these compilers to Python, to see what
>> PyPy can do with them. (It would also be quite cool to have them in pure
>> Python). But I've find these difficult to optimise, because they have
>> diverse execution patterns, while PyPy likes loops. I'll see.
>>
>> A compiler is another good 'pure language' task because, apart from
>> input and output at each end, all the computation is self-contained.)
> 
> I've no idea what this is meant to mean.

Then you shouldn't criticise Bart for his lack of "knowledge of computing"
just because he lacks of interest in Unicode. As they say, people in glass
houses shouldn't throw stones.

I think Bart is very old-school, and probably a bit behind the times when it
comes to modern compiler and interpreter technologies. But that doesn't
matter: the old timers knew a thing or two, and in some ways the old days
were better:

http://prog21.dadgum.com/116.html

I fear that Bart still holds quite a few misapprehensions about Python. But
he seems happy to discuss the language, and (unless he is lying to us and
all his claims about his interpreter are pure Walter Mitty fantasy -- and I
have no reason to think this is true), there's no doubt that he is knows
what he is talking about in the areas of which he is qualified to speak.

Does he know Unicode? No. Does he know compiler design? It seems so, which
is more than can be said by either you or I.

-- 
Steven

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

Re: Pyhon 2.x or 3.x, which is faster?

BartC  writes:

> But, someone had to write that Image.PNG.encode() function at some
> time. What language did they use? If it wasn't Python, then why not?

Because some operations actually need to be very fast, even at the
expense of difficult-to-maintain code in a difficult-to-use language.

> Why is it OK to let some poor sod slave away in C++ or whatever (a
> ghastly language), while others then reap the benefits writing in an
> easy 'soft' language?

Because that's the whole point of writing a small re-usable library and
maintaining it: countless gobs of badly-written imitations thereby never
need to be written.

> I've been interested for a while in broadening the scope of scripting
> languages so that less work has to be done in 'hard' ones.

Yes, that's pretty much the answer to the question you asked above.

> But the attitude in this group has been very different; Python /is/
> slow, but so what? Just a general shrug.

I'm sorry you drew that inference. Comprehensive answers – not a
“general shrug” – have in fact been given to you.

The answer boils down to the fact that there are trade-offs to be made.
One that is easy to express is that Python trades preserving valuable
programmer time, at the expense of some non-critical operations being
slightly slower.

And no, of course it's not “Python is slow”. Such a broad statement is
erxactly what gets mocking scorn in response: you need to be *much* more
specific about what is slow, under what conditions. Python is plenty
fast enough at most of the things it is used for.

> So long as /someone else/ uses the hard language to created the needed
> libraries, the speed of pure Python is irrelevant. New version of
> Python is now half the speed? Another shrug!

Citation needed. I don't know of any released version of Python that was
ever “twice as slow” – no qualifiers – than the previous release.

Make such sweeping, hand-waving statements that are trivially
demonstrated false, and yes your statements will be dismissed. With
sneers by some, and with a shrug by most.

-- 
 \   “It's easy to play any musical instrument: all you have to do |
  `\   is touch the right key at the right time and the instrument |
_o__)will play itself.” —Johann Sebastian Bach |
Ben Finney

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

Re: Pyhon 2.x or 3.x, which is faster?

On 2016-03-10, Chris Angelico  wrote:
> On Thu, Mar 10, 2016 at 10:48 AM, Jon Ribbens
> wrote:
>> On 2016-03-09, Chris Angelico  wrote:
>>> Then *get interested*. Unicode is the only way that you'll ever not be
>>> parochially bound to a subset of English - or, worse, bound to an
>>> arbitrary eight-bit codepage that you don't even control the choice
>>> of, such that your program behaves differently on different systems.
>>> FIX YOUR LANGUAGE and support non-English text.
>>
>> You can't even support English text properly without Unicode.
>> Plenty of English words use non-ASCII characters:
>> café, crêpe, façade, naïve, dæmon, etc.
>
> Like I said, a subset of English.

I profusely apologise for so rudely agreeing with you.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Pyhon 2.x or 3.x, which is faster?

On Thu, 10 Mar 2016 12:30 pm, BartC wrote:

> But the attitude in this group has been very different; Python is
> slow, but so what? Just a general shrug.

I think that sometimes people here get a bit defensive because they've
experienced too many people making snap dismissals of Python due to some
completely artificial benchmark that doesn't relate to the work that their
actually doing. These are the people who would rather spend two weeks
writing a buggy C program to do a one-off processing task that takes 10
minutes to run that we could do correctly in half a day in Python because
their code is "100 times faster".

You might think I'm exaggerating, but I've seen people do that.

Anyway, the Python community as a whole is *very* aware that Python is not
the speediest language in the world (although it is faster than Ruby,
faster than at least some Javascript implementations, and neither of those
two are suffering in popularity due to slowness). Speed is not the number 1
priority, and possibly not even the number 2 priority, but it is a priority
somewhere in the top 10. Hence there is a whole range of
performance-related factors to be considered:

- speed.python.org allows the core developers (and anyone else) to monitor
Python's performance;

- PyPy is a self-hosted[1] powerful Just-In-Time compiler aimed especially
at long-running code in loops;

- the author of Nuitka is re-writing Python in C++ with the eventual aim of
making it a highly-optimized Ahead-Of-Time compiler;

- one of the core devs, Victor Stinner, is working on FAT Python, an
optimizing implementation;

- other projects include Pyston, Pyjion, HotPy, Cython, Numba, Parakeet.

Some discussion here:

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

So don't think that the community as a whole is dismissive of speed issues.
But they're more interested in speeding up Python where it matters.

[1] Well, sort of. PyPy is actually written in RPython, a restricted subset
of Python.

--
Steven

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

Re: turtle ??

On Thu, 10 Mar 2016 05:14 am, MRAB wrote:

> FYI, the uppercase of "ı" is "I" and the lowercase of "İ" is "i".

Very true. Does that tell us anything about the placement and ease of
getting I on a Turkish keyboard? 

I'm just giving the OP the benefit of the doubt. Maybe they have a good
reason for typing l instead of I. Probably not though.


-- 
Steven

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

Re: Pyhon 2.x or 3.x, which is faster?

On Thu, Mar 10, 2016 at 1:38 PM, Jon Ribbens
 wrote:
> On 2016-03-10, Chris Angelico  wrote:
>> On Thu, Mar 10, 2016 at 10:48 AM, Jon Ribbens
>> wrote:
>>> On 2016-03-09, Chris Angelico  wrote:
 Then *get interested*. Unicode is the only way that you'll ever not be
 parochially bound to a subset of English - or, worse, bound to an
 arbitrary eight-bit codepage that you don't even control the choice
 of, such that your program behaves differently on different systems.
 FIX YOUR LANGUAGE and support non-English text.
>>>
>>> You can't even support English text properly without Unicode.
>>> Plenty of English words use non-ASCII characters:
>>> café, crêpe, façade, naïve, dæmon, etc.
>>
>> Like I said, a subset of English.
>
> I profusely apologise for so rudely agreeing with you.

I snapped off a very quick response as I was about to meet with a
student, but let me assure you that I was not offended in any way by
your post. You basically gave examples of exactly the problem that I
alluded to with the words "a subset of", and it's an important enough
consideration that it's well worth having the examples there.

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

Re: turtle ??

On Thu, Mar 10, 2016 at 1:45 PM, Steven D'Aprano  wrote:
> On Thu, 10 Mar 2016 05:14 am, MRAB wrote:
>
>> FYI, the uppercase of "ı" is "I" and the lowercase of "İ" is "i".
>
> Very true. Does that tell us anything about the placement and ease of
> getting I on a Turkish keyboard?
>
> I'm just giving the OP the benefit of the doubt. Maybe they have a good
> reason for typing l instead of I. Probably not though.

A Turkish keyboard should have dotless and dotted, uppercase and
lowercase, all easily typed. Here's one example layout (I've no idea
how prevalent this is):

http://ascii-table.com/img/keyboard-179.png

But depending on the exact layout used, it might be very easy to typo
I as l, and it may well not be noticed. My guess is that there's no
good reason to mistype, but plenty of good reasons for mistyping to
happen. :)

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

Re: A mistake which almost went me mad

2016-03-09 Thread Rustom Mody

On Wednesday, March 9, 2016 at 10:04:35 PM UTC+5:30, Rick Johnson wrote:
> On Thursday, March 3, 2016 at 4:22:07 AM UTC-6, ast wrote:
> > Hello
> > 
> > This has to be told
> > 
> > I created a file pickle.py in order to test some files
> > read/write with objects and put it in a directory
> > which is on my python path. 
> > 
> > Then the nightmare began
> > 
> > - Idle no longer works, window no longer opens 
> > when double clicked, no errors messsages
> > 
> > - python -m pip list doesnt work, crash with an 
> > error message related to pickle
> > 
> > I uninstalled python34 and reinstalled it, same problem
> > I uninstalled python34 and instaled 3.5, same problem
> > 
> > ...
> > 
> > I finally understood that pickle.py is the name of the file
> > containing the official pickle module.
> > 
> > This module is probably used by various python programs,
> > IDLE, pip ...
> > 
> > Instead of reading official pickle, python read my file ...
> 
> This is a design flaw of the python language. If all standard library modules 
> would have been protected from the global namespace by a single symbol -- say 
> "stdlib" or "py" or whatever -- we would only need to avoid *ONE* symbol, 
> instead of hundreds of them!!! Third party modules should have their own 
> namespace as well. 
> 
>  from stdlib import re
>  from stdlib.re import search
>  from extlib import PIL
>  from extlib.PIL import Image, ImageTk
> 
> Since those responsible for this flaw are unable, or unwilling, to fix it, 
> the only solution for *YOU* is to (1) memorize every module name that exists 
> in the python standard library, and also those that exist in your 
> "site-packages" directory, or (2) hide all your personal modules behind a 
> single symbol by utilizing a package.
>  
>  +mylib
>__init__.py
>pickle.py
> 
> import mylib.pickle as mypickle
> mypickle.do_something()

As usual Rick I find myself agreeing with your direction [also it seems
Random832's direction] though not with the ranty tone.

Ive been collecting factoids about how programming pedagogy and professional
programming practice cannot be conflated under one roof

[See 
http://blog.languager.org/2015/06/functional-programming-moving-target.html ]

One argument against that is -- in some guise or other -- to use namespaces.
eg If you dont need a language-feature dont use it
  If you dont need a library dont use it

These arguments neglect that the namespacing -- semantics, intricacies, 
headaches, etc -- ITSELF may be significantly noob-unfriendly.

For cars one needs: 
- the hood securely fastened when teaching driving
- easily openable when teaching automobile engineering
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: turtle ??

2016-03-09 Thread Marko Rauhamaa

Chris Angelico :

> A Turkish keyboard should have dotless and dotted, uppercase and
> lowercase, all easily typed.

BTW, typing any useful Unicode character is a major unsolved problem. I
have created this text file that contains a lot of unicode characters
with their code points. Every once in a while I have to open the file
and copy and paste a character to, say, a Usenet posting. Cumbersome but
necessary.


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

Re: turtle ??

2016-03-09 Thread Jussi Piitulainen

Marko Rauhamaa writes:

> Chris Angelico :
>
>> A Turkish keyboard should have dotless and dotted, uppercase and
>> lowercase, all easily typed.
>
> BTW, typing any useful Unicode character is a major unsolved
> problem. I have created this text file that contains a lot of unicode
> characters with their code points. Every once in a while I have to
> open the file and copy and paste a character to, say, a Usenet
> posting. Cumbersome but necessary.

C-u M-x python3 -c 'print("\N{TURTLE}", end = "")' RET :)

🐢

Though I only see this character as an over-wide box containing the
numeric code 01F422.

Usually I go to the web and search for the character code. Python
unicodedata module does not seem to help if one doesn't know or guess
the exact name, but if one does, unicodedata.lookup("TURTLE") works.

Aha! http://unicode-search.net/unicode-namesearch.pl?term=TURTLE

python3 -c 'print("\N{KANGXI RADICAL TURTLE}")'

⿔

That one shows as a glyph for me, both in Emacs in a terminal and in
Firefox.
-- 
https://mail.python.org/mailman/listinfo/python-list

Text input with keyboard, via input methods (was: turtle ??)

Marko Rauhamaa  writes:

> BTW, typing any useful Unicode character is a major unsolved problem.

You typed a good number of Unicode characters in that sentence alone.
ASCII is a simple subset of Unicode.

I suppose you meant to refer to typing some character not mapped to a
single keystroke on a US-English keyboard kayout.

You're right, that is a major problem.

As for how solved it is, that depends on what you're hoping for as a
solution.

The conventional solution, which I find to be quite useful for typing
characters from a great many different writing systems, is an
https://en.wikipedia.org/wiki/Input_method> customised to
particular writing systems.

My primary input method is one which lets me type typical English text
and also easily input a broad range of useful characters with a few
mnenonic two- or three-key sequences.

> I have created this text file that contains a lot of unicode
> characters with their code points. Every once in a while I have to
> open the file and copy and paste a character to, say, a Usenet
> posting. Cumbersome but necessary.

Hopefully your operating system has a good input method system, with
many input methods available to choose from. May you find a decent
default there.

-- 
 \  “It is … incumbent upon us to recognize that it is |
  `\inappropriate for religion to play any role in issues of state |
_o__)[of] a modern democracy.” —Lawrence M. Krauss, 2012-05-28 |
Ben Finney

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

Re: Pyhon 2.x or 3.x, which is faster?


On 10/03/2016 00:58, BartC wrote:

On 09/03/2016 23:35, Mark Lawrence wrote:

On 09/03/2016 23:14, BartC wrote:



(The byte-code compiler for the current version is written in itself. It
can compile itself (some 25Kloc) in about 1 second (that's running
interpreted, dynamic byte-code on a not-very-fast PC).


Please answer my question, will it be tested against real world
benchmarks or microbenchmarks?  The above paragraph, and several
following paragraphs, are completely irrelevant.


You think a bloody great compiler is a microbenchmark?!


I have no interest in the speed of the compiler, I am interested in the 
run time speed of the applications that it produces which is what has 
been discussed thus far.





A compiler is another good 'pure language' task because, apart from
input and output at each end, all the computation is self-contained.)


I've no idea what this is meant to mean.


It means the task doesn't do any function calls to external libraries.


Meaning that in this dreadful place called the real world it's less than 
useless in many cases.  Why do you think there are the better part of 
50,000 entries on pypi alone, some pure Python, some C extensions, 
presumably some a combinaton of both?




If you're benchmarking, that's usually what you want.


I'm not much interested in Unicode at the minute. I'll pass.



Your final comment sums up perfectly your knowledge of computing in
2016.


You're utterly determined to belittle everything I do aren't you!


Yes I am, as you appear to know squat.



But, yeah, I was writing international applications decades ago. I'm not
working for anyone now and don't need to bother.


So your new language doesn't bother with unicode then?



 From what I've seen, a lot of software can't get it right anyway.



Are you referring to PEP393 having taken notice of the RUE?

--
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: turtle ??

On Thu, Mar 10, 2016 at 5:14 PM, Marko Rauhamaa  wrote:
> Chris Angelico :
>
>> A Turkish keyboard should have dotless and dotted, uppercase and
>> lowercase, all easily typed.
>
> BTW, typing any useful Unicode character is a major unsolved problem. I
> have created this text file that contains a lot of unicode characters
> with their code points. Every once in a while I have to open the file
> and copy and paste a character to, say, a Usenet posting. Cumbersome but
> necessary.

Part of the reason it's unsolved is that there are many different ways
you might want to identify the character. Are you looking for a glyph
by name? Grab the unicodedata module (or the \N escape) and print
something out. (Works only if you know the exact name. A fuzzy match
tool would be handy, and would be reasonably easy to build on top of
unicodedata. Someone's probably done that already, but if not, it
wouldn't be a particularly long script.) Are you trying to type text
in a different script? Transliteration from/to Latin letters is
probably the best way - either as an input method (I can right-click
an entry field and select Cyrillic, and then "stop" comes out as
"стоп" - hey look, it translated it into Russian as well!), or as a
dedicated transliteration script. Trying to type Latin letters with
diacriticals? Dead key support is most likely to be the simplest -
type the diacritical, then the base letter, and it enters the combined
form. Or maybe set your keyboard so that Alt-` emits U+0300 COMBINING
GRAVE ACCENT, and then type the base letter followed by Alt-` to add
an accent. Not 100% sure what you want? Have a text file with all the
characters you can't type and often want to use. Cumbersome, maybe,
but not as bad as some other options. :)

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

Re: Pyhon 2.x or 3.x, which is faster?

Mark Lawrence  writes:

> Yes I am, as you appear to know squat.

Cut it out, please. This is now bullying.

Bart is interested in things that don't interest you; if you can't
engage him cordially, please desist.

-- 
 \ “Pinky, are you pondering what I'm pondering?” “I think so, |
  `\ Brain, but what kind of rides do they have in Fabioland?” |
_o__)   —_Pinky and The Brain_ |
Ben Finney

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

Installing ibm_db package on Windows 7, 64-bit problem

2016-03-09 Thread Alexander Shmugliakov

Hello, has anybody successfully installed ibm_db package in the 32-bit Python 
3.5.0 environment? This is the error messages I'm receiving:
I know that the message about vcvarsall.bat is related to the Visual Studio 
configuration -- I don't have it on my computer. I have no 64-bit IBM Data 
Server Driver installed on my machine. Any help will be *greatly* appreciated.

'--'
C:\Program Files (x86)\Python 3.5>easy_install ibm_db
Searching for ibm-db
Reading https://pypi.python.org/simple/ibm_db/
Best match: ibm-db 2.0.6
Downloading 
https://pypi.python.org/packages/source/i/ibm_db/ibm_db-2.0.6.tar.gz#md5=f6b80e1489167a141ebf8978c37ca398
Processing ibm_db-2.0.6.tar.gz
Writing 
C:\Users\shmuglak\AppData\Local\Temp\easy_install-yijpttuo\ibm_db-2.0.6\setup.cfg
Running ibm_db-2.0.6\setup.py -q bdist_egg --dist-dir 
C:\Users\shmuglak\AppData\Local\Temp\easy_install-yijpttuo\ibm_db-
2.0.6\egg-dist-tmp-np3lk_6i
Detected 32-bit Python
C:\Users\shmuglak\AppData\Local\Temp\easy_install-yijpttuo\ibm_db-2.0.6\setup.py:204:
 UserWarning: Detected usage of IBM
 Data Server Driver package. Ensure you have downloaded 32-bit package of 
IBM_Data_Server_Driver and retry the ibm_db module install

  warnings.warn(notifyString)
warning: no files found matching 'README'
warning: no files found matching '*' under directory 'clidriver'
warning: no files found matching '*' under directory 'ibm_db_dlls'
error: Setup script exited with error: Unable to find vcvarsall.bat
'--'

My environment:
Windows 7 Professional, SP1
Python:
Python 3.5.0 (v3.5.0:374f501f4567, Sep 13 2015, 02:16:59) [MSC v.1900 32 bit 
(Intel)] on win32 

IBM IBM Data Server Driver Package:
Client Package Type   : IBM Data Server Driver Package
Client Version (level/bit): DB2 v10.5.0.420 (s130528/32-bit)
Client Platform   : NT
Install/Instance Path : C:\PROGRA~2\IBM\IBMDAT~1

Common App Data Path  : C:\ProgramData\IBM\DB2\IBMDBCL1
DB2DSDRIVER_CFG_PATH value: C:\ProgramData\IBM\DB2\IBMDBCL1\cfg
db2dsdriver.cfg Path  : \cfg\db2dsdriver.cfg
DB2CLIINIPATH value   : C:\ProgramData\IBM\DB2\IBMDBCL1\cfg
db2cli.ini Path   : \cfg\db2cli.ini
db2diag.log Path  : \db2diag.log

==
List of all IBM Data Server client packages on the current workstation:


Copyname  Version Package Language Installed-Location

IBMDBCL1[C,D] 10.5.00 DSD ALL_LANG C:\Program Files (x86)\IBM\IBM DATA 
SERVER DRIVER

 DSD: IBM Data Server Driver Package

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

Re: Text input with keyboard, via input methods (was: turtle ??)

2016-03-09 Thread Rustom Mody

On Thursday, March 10, 2016 at 12:59:10 PM UTC+5:30, Ben Finney wrote:
> Marko Rauhamaa  writes:
> 
> > BTW, typing any useful Unicode character is a major unsolved problem.
> 
> You typed a good number of Unicode characters in that sentence alone.
> ASCII is a simple subset of Unicode.
> 
> I suppose you meant to refer to typing some character not mapped to a
> single keystroke on a US-English keyboard kayout.
> 
> You're right, that is a major problem.
> 
> As for how solved it is, that depends on what you're hoping for as a
> solution.
> 
> The conventional solution, which I find to be quite useful for typing
> characters from a great many different writing systems, is an
> https://en.wikipedia.org/wiki/Input_method> customised to
> particular writing systems.
> 
> My primary input method is one which lets me type typical English text
> and also easily input a broad range of useful characters with a few
> mnenonic two- or three-key sequences.
> 
> > I have created this text file that contains a lot of unicode
> > characters with their code points. Every once in a while I have to
> > open the file and copy and paste a character to, say, a Usenet
> > posting. Cumbersome but necessary.
> 
> Hopefully your operating system has a good input method system, with
> many input methods available to choose from. May you find a decent
> default there.

I believe that these discussions would be useful (and the current state
of input methods better-ed if we distinguish different levels of input-methods.

Basically ranging from low-setup, hi-perchar cost to hi-setup low-perchar cost

At the one extreme we have
use google, hunt around, cut-paste

At the other use a special hardware keyboard
[I believe Steven had sometime showed something like this
https://plus.google.com/102786751626732213960/posts/2uJzHw1JHeN?pid=5802841322291932386&oid=102786751626732213960
]

In between these two extremes we have many possibilities
- ibus/gchar etc
- compose key
- alternate keyboard layouts

Using all these levels judiciously seems to me a good idea...
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Pyhon 2.x or 3.x, which is faster?