Re: [Tutor] unichr not working as expected

2013-07-23 Thread Marc Tompkins
On Tue, Jul 23, 2013 at 12:31 PM, Dave Angel wrote: > The three distributed version control systems I know of are: >git, mercurial, and bazaar > Not to overplay my Joel Spolsky fanboiism, but are you aware of Kiln from Fog Creek? It started out as an enterprise-friendly wrapper around Mercu

Re: [Tutor] unichr not working as expected

2013-07-23 Thread Dave Angel
On 07/23/2013 03:20 PM, Alan Gauld wrote: On 23/07/13 18:41, wolfrage8...@gmail.com wrote: Although I can not say for sure. It appears to me, they are trying to do a better job at merging from distributed branches Thanks for the memory jog. Yes i remember reading an interview with linus when

Re: [Tutor] unichr not working as expected

2013-07-23 Thread Alan Gauld
On 23/07/13 18:41, wolfrage8...@gmail.com wrote: Although I can not say for sure. It appears to me, they are trying to do a better job at merging from distributed branches Thanks for the memory jog. Yes i remember reading an interview with linus when he referred to the difficulty of using CVS

Re: [Tutor] unichr not working as expected

2013-07-23 Thread Jim Mooney
On 23 July 2013 07:28, Steven D'Aprano wrote: > > (I trust that everyone remembers enough high school chemistry to > understand why Mercurial is called hg? Hg is the chemical symbol for > Mercury.) > And I recall my high school chemistry teacher claiming the noble gases could never combine, unti

Re: [Tutor] unichr not working as expected

2013-07-23 Thread Alan Gauld
On 23/07/13 16:08, Dave Angel wrote: git is free, and is usually installed on individual machines. It's also easy to set up and use for a single user. I prefer Mercurial (also known as hg). And I've used SVN in recent years and found it... OK. But my question is: Why is there such a rash

Re: [Tutor] unichr not working as expected

2013-07-23 Thread Dave Angel
On 07/23/2013 10:28 AM, Steven D'Aprano wrote: On 24/07/13 00:14, Dave Angel wrote: On 07/23/2013 02:10 AM, Jim Mooney wrote: On 22 July 2013 21:00, Steven D'Aprano wrote: (By the way, you're very naughty. The code you show *cannot possibly generate the error you claim it generates*. Bad Ji

Re: [Tutor] unichr not working as expected

2013-07-23 Thread Steven D'Aprano
On 24/07/13 00:14, Dave Angel wrote: On 07/23/2013 02:10 AM, Jim Mooney wrote: On 22 July 2013 21:00, Steven D'Aprano wrote: (By the way, you're very naughty. The code you show *cannot possibly generate the error you claim it generates*. Bad Jim, no biscuit!) I know. I need a personal git

Re: [Tutor] unichr not working as expected

2013-07-23 Thread Dave Angel
On 07/23/2013 02:10 AM, Jim Mooney wrote: On 22 July 2013 21:00, Steven D'Aprano wrote: (By the way, you're very naughty. The code you show *cannot possibly generate the error you claim it generates*. Bad Jim, no biscuit!) I know. I need a personal github. git is free, and is usually ins

Re: [Tutor] unichr not working as expected

2013-07-22 Thread Jim Mooney
On 22 July 2013 21:00, Steven D'Aprano wrote: > > (By the way, you're very naughty. The code you show *cannot possibly > generate the error you claim it generates*. Bad Jim, no biscuit!) > I know. I need a personal github. When I get frustrated I try so many things in quick succession I lose tra

Re: [Tutor] unichr not working as expected

2013-07-22 Thread Jim Mooney
Steven D'Aprano When Python starts up, it needs to set the encoding used, but you *cannot* > set it to arbitrary encodings. Setting it to arbitrary encodings can cause > all sorts of weird, hard to diagnose bugs, so to prevent that, Python > deletes the setdefaultencoding function after using it.

Re: [Tutor] unichr not working as expected

2013-07-22 Thread Steven D'Aprano
On 23/07/13 04:14, Jim Mooney wrote: I tried translating the odd chars I found in my dos tree /f listing to symbols, but I'm getting this error. The chars certainly aren't over 1, The ord is only 13 - so what's wrong here? def main(): zark = '' for x in "ÀÄÄÄ": zark +=

Re: [Tutor] unichr not working as expected

2013-07-22 Thread Steven D'Aprano
On 23/07/13 05:22, Jim Mooney wrote: I already changed to u for the char, so I got a bigger number, and only subtracted 3 from umlaut, which should have given me the dos line-drawing dash, but now my problem is I can't seem to set encoding for that: import sys sys.setdefaultencoding('cp437') g

Re: [Tutor] unichr not working as expected

2013-07-22 Thread Jim Mooney
On 22 July 2013 11:52, Alan Gauld wrote: > On 22/07/13 19:14, Jim Mooney wrote: > > zark += unichr(ord(x)-45) >> >> >> unichr() arg not in range(0x1) (narrow Python build) >> > > > What if ord() is returning a value less than 45? > What does unichr() do with negative vales?> > > Jus

Re: [Tutor] unichr not working as expected

2013-07-22 Thread Alan Gauld
On 22/07/13 19:14, Jim Mooney wrote: zark += unichr(ord(x)-45) unichr() arg not in range(0x1) (narrow Python build) What if ord() is returning a value less than 45? What does unichr() do with negative vales?> Just a guess... -- Alan G Author of the Learn to Program web site h

[Tutor] unichr not working as expected

2013-07-22 Thread Jim Mooney
I tried translating the odd chars I found in my dos tree /f listing to symbols, but I'm getting this error. The chars certainly aren't over 1, The ord is only 13 - so what's wrong here? def main(): zark = '' for x in "ÀÄÄÄ": zark += unichr(ord(x)-45) print(zark) unichr(