Re: [Tutor] slashes in paths
On 22 July 2013 03:51, eryksun wrote: > On Sun, Jul 21, 2013 at 9:18 PM, Marc Tompkins > wrote: > > CP/M itself didn't use '/' switches in its internal CCP commands, even > if some 3rd party programs did. Neither did COMMAND.COM in Tim > Paterson's 86-DOS. Microsoft added the switches (but Paterson was > there in 81-82). By the time PC-DOS 2.0 shipped there were switches > for FORMAT, COPY, DIR, DISKCOMP, DISKCOPY, BACKUP, CHKDSK, PRINT, > RESTORE, and TREE (is that ironic?). > I forgot about TREE. But figured piping C:\Python27>tree /f > pytree.txt might be illuminating. I piped since it took forever to print because I have python(x,y). Unfortunately, I got tiny numbers and A with umlauts instead of the nice path outlines in the dos box: ³ ³ ³ ³ ÀÄÄÄtests Jim ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
[Tutor] unichr not working as expected
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() arg not in range(0x1) (narrow Python build) -- Jim ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] slashes in paths
On 22 July 2013 11:26, Marc Tompkins wrote: > > > > If you haven't already read it, may I suggest Joel's intro to Unicode? > http://www.joelonsoftware.com/articles/Unicode.html > I had a bad feeling I'd end up learning Unicode ;') -- Jim ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] slashes in paths
On Mon, Jul 22, 2013 at 10:47 AM, Jim Mooney wrote: I forgot about TREE. But figured piping C:\Python27>tree /f > pytree.txt > might be illuminating. I piped since it took forever to print because I > have python(x,y). Unfortunately, I got tiny numbers and A with umlauts > instead of the nice path outlines in the dos box: > > ³ ³ ³ ³ ÀÄÄÄtests > > That's an encoding problem; TREE is apparently not Unicode-aware, and uses the old ASCII-US code page for values above 127. I suspect that bringing ancient command-line utilities into the Notepad++ is my default text editor; I was able to see the line-drawing characters properly after I selected Encoding/Character sets/Western European/OEM-US. No idea what you'd need to do in other text editors... TREE /? displays the following: Graphically displays the folder structure of a drive or path. TREE [drive:][path] [/F] [/A] /F Display the names of the files in each folder. /A Use ASCII instead of extended characters. Using /f /a will give you a readable file, no matter which text editor you use. I suspect that it hasn't been updated for Unicode for two reasons: 1) updating TREE to use Unicode for line-drawing would break compatibility for people who pipe its output into other CLI programs in the *nix style 2) although Microsoft could get around that by adding another command-line switch, there probably isn't an awful lot of demand - who uses TREE anymore, except in the context of discussions like this? If you haven't already read it, may I suggest Joel's intro to Unicode? http://www.joelonsoftware.com/articles/Unicode.html ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] slashes in paths
On Mon, Jul 22, 2013 at 11:30 AM, Jim Mooney wrote: > On 22 July 2013 11:26, Marc Tompkins wrote: > >> >> >> >> If you haven't already read it, may I suggest Joel's intro to Unicode? >> http://www.joelonsoftware.com/articles/Unicode.html >> > > I had a bad feeling I'd end up learning Unicode ;') > It's not as painful as you might think! Try it - you'll like it! Actually, once you start getting used to working in Unicode by default, having to deal with programs that are non-Unicode-aware feels extremely irritating. ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] unichr not working as expected
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 http://www.alan-g.me.uk/ ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] slashes in paths
I had a bad feeling I'd end up learning Unicode ;') > > > It's not as painful as you might think! Try it - you'll like it! > Actually, once you start getting used to working in Unicode by default, > having to deal with programs that are non-Unicode-aware feels extremely > irritating. > I'll have to, to write a python program to translate the tree output. I tried More, but since I have Python(x,y) I gave up after holding down the enter key for five minutes. I tried piping More but that didn't work right. I probably forgot DOS. but since DOS isn't commonly used, a python program would be better anyway. -- Jim ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
[Tutor] close, but no cigar
Okay, I'm getting there, but this should be translating A umlaut to an old DOS box character, according to my ASCII table, but instead it's print small 'u': def main(): zark = '' for x in "ÀÄÄÄ": print(unichr(ord(u'x')-3), end=' ') result: u u u u -- Jim What the Nations of the World Fail to Realize, is That we are Living in a Closed System: In March 2013, researchers from the Stanford University Hopkins Marine Station issued a report on Bluefin tuna caught off the California coast and tested for radioactive cesium. The report found that Bluefin tuna were 100 per cent contaminated, that not one was cesium-free. The report did not address such questions as whether cesium would continue to accumulate in tuna or whether it was appearing in other fish species. ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] 3 Dimensional Dictionaries
THANK YOU ALL for your time.
The first format which I pasted was from the DB
The second format(exactly the same), is to be sent to the view.
If the logic can be fitted in One or two methods it'll help me to easily
understand & to apply.
so I request you to help...
On Sunday, July 21, 2013, Alan Gauld wrote:
> On 20/07/13 11:17, Sunil Tech wrote:
>>
>> Hi Everyone,
>>
>> I have a list of dictionaries like
>>
>> world =
>>
[{'continent':'Asia','continent_code':1,'ocean':'Pacific','country':'India','country_code':1,'state':'Kerala',
>> 'state_pin':51},
>
>>
>> i am trying to to make it in this format
>>
>> world = [{'continent':'Asia', 'ocean':'Pacific',
>> 'countries':[{'country':'India',
>> 'states':[{'state':'Kerala', 'state_pin':51},
>> {'state':'Karnataka', 'state_pin':52}]
>> }]
>> },
>
>> Please help me in this regard.
>
> In what regard? Where do you need the help?
> You seem to know the data format you want?
>
> The only thing I'd suggest is to consider using classes if you are
familiar with them.
>
> world => list of continents
> continent => class containing countries
> country => class containing states
> state => class containing data
>
> It then becomes easier to build helper methods to extract/manipulate the
data you are interested in.
>
> Alternatively, if you have a large amount of data a database may be
another option. Swap table for class above and use SQL to manage the data.
>
> But other than those suggestions I don't know what kind of
> help you want?
>
> --
> Alan G
> Author of the Learn to Program web site
> http://www.alan-g.me.uk/
>
> ___
> Tutor maillist - Tutor@python.org
> To unsubscribe or change subscription options:
> http://mail.python.org/mailman/listinfo/tutor
>
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Cannot understand what this means
CCing the list. Please always use ReplyAll to include the list. Alan Gauld Author of the Learn To Program website http://www.alan-g.me.uk/ > > From: #PATHANGI JANARDHANAN JATINSHRAVAN# >To: Alan Gauld >Sent: Monday, 22 July 2013, 17:14 >Subject: RE: [Tutor] Cannot understand what this means > > >Hi >I have doubts only on the arguments part. > >OK, But what about them? Do you understand what command line arguments are? > def main(): > >> # This command-line parsing code is provided. >> # Make a list of command line arguments, omitting the [0] element >> # which is the script itself. >> args = sys.argv[1:] This fetches the command line arguments missing the first which is the program name. Do you understand slicing? Do you understand how sys.argv works - its similar to the argc, argv mechanism of C++ which you've maybe seen before. >> if not args: >> print 'usage: [--summaryfile] file [file ...]' >> sys.exit(1) The logic here says that if args is empty then print the message and exit >> # Notice the summary flag and remove it from args if it is present. >> summary = False >> if args[0] == '--summaryfile': >> summary = True >> del args[0] I have no idea why this is here but for whatever reason he is setting the summary flag to True if the first argument was --summaryfile Now, is there anything else you don't understand? The more specific you make your questions the better we can answer them. Alan G. ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] unichr not working as expected
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?>
>
> Just a guess...
>
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')
gives me the error:
AttributeError: 'module' object has no attribute 'setdefaultencoding'
Jim
>
> --
> Alan G
> Author of the Learn to Program web site
> http://www.alan-g.me.uk/
>
> __**_
> Tutor maillist - Tutor@python.org
> To unsubscribe or change subscription options:
> http://mail.python.org/**mailman/listinfo/tutor
>
--
Jim
What the Nations of the World Fail to Realize, is That we are Living in a
Closed System:
In March 2013, researchers from the Stanford University Hopkins Marine
Station issued a report on Bluefin tuna caught off the California coast and
tested for radioactive cesium. The report found that Bluefin tuna were 100
per cent contaminated, that not one was cesium-free. The report did not
address such questions as whether cesium would continue to accumulate in
tuna or whether it was appearing in other fish species.
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] slashes in paths
On Mon, Jul 22, 2013 at 11:57 AM, Jim Mooney wrote: > I had a bad feeling I'd end up learning Unicode ;') > >> >> >> It's not as painful as you might think! Try it - you'll like it! >> Actually, once you start getting used to working in Unicode by default, >> having to deal with programs that are non-Unicode-aware feels extremely >> irritating. >> > > I'll have to, to write a python program to translate the tree output. I > tried More, but since I have Python(x,y) I gave up after holding down the > enter key for five minutes. I tried piping More but that didn't work right. > I probably forgot DOS. but since DOS isn't commonly used, a python program > would be better anyway. > You'd be better off skipping TREE entirely and going pure-Python. TREE - being Unicode-naive - can't deal with any foreign-alphabet characters beyond the few baked in alongside the box-drawing characters; they all get turned into question marks. I'm guessing that's not an issue on your own computer, but if you ever want to deal with files from other people... ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] close, but no cigar
On Mon, Jul 22, 2013 at 11:27 AM, Jim Mooney wrote:
> Okay, I'm getting there, but this should be translating A umlaut to an old
> DOS box character, according to my ASCII table, but instead it's print
> small 'u':
>
> def main():
> zark = ''
> for x in "ÀÄÄÄ":
> print(unichr(ord(u'x')-3), end=' ')
>
> result: u u u u
>
When you type "Ä" in a Python string (without specifying which encoding
you're trying to represent), it doesn't necessarily have the same ordinal
value as the line-drawing character that gets mistakenly displayed as "Ä"
in your text editor. Depending on which Python version you happen to be
using at the moment (and therefor depending on the default encoding), "Ä"
might be a Unicode Latin Capital Letter A With Diaeresis (U+00C4), or it
might be character code 0x8E, or it might be 0xC4...
For a quick visualization of what I'm talking about, just fire up the
Character Map program and find "Ä" in the following fonts: Arial, Terminal,
and Roman. Float your mouse cursor over it each time to see the character
code associated with it.
If you insist on parsing the output of TREE (instead of letter Python do
things in a modern, Unicode-aware way), here's how I would do it:
inFileName = "/Users/Marc/Desktop/rsp/tree.txt"
with open(inFileName, 'r') as inFile:
inString = inFile.read().decode('cp437')
print inString
This printed out the line-drawing characters just fine; my test Cyrillic
filename remained a string of question marks, because TREE itself had
trashed that filename and there wasn't anything for .decode() to decode.
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] close, but no cigar
On 22 July 2013 13:45, Marc Tompkins wrote:
>
> inFileName = "/Users/Marc/Desktop/rsp/tree.txt"
> with open(inFileName, 'r') as inFile:
> inString = inFile.read().decode('cp437')
> print inString
>
> I already tried something similar and got an error:
with open('../pytree.txt') as pytree, open('newpytree.txt','w') as pyout:
for line in pytree:
for char in line:
newchar = char.decode('cp437')
pyout.write(newchar)
UnicodeEncodeError: 'ascii' codec can't encode character u'\u2502' in
position 0: ordinal not in range(128)
What's my error here, since I want to write to a file. I have python(x,y)
so printing that is kind of time-taking and not too illuminating ;')
Jim
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] slashes in paths
On 22 July 2013 12:48, Marc Tompkins wrote: > > > You'd be better off skipping TREE entirely and going pure-Python. TREE - > being Unicode-naive - can't deal with any foreign-alphabet characters > beyond the few baked in alongside the box-drawing characters; they all get > turned into question marks. I'm guessing that's not an issue on your own > computer, but if you ever want to deal with files from other people... > so I should just walk the python27 tree and write my own box drawing chars? Or is there a more global alternative to DOS box-drawing chars to illustrate a tree structure, other than graphic processing? -- Jim ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] close, but no cigar
On Mon, Jul 22, 2013 at 1:55 PM, Jim Mooney wrote:
> On 22 July 2013 13:45, Marc Tompkins wrote:
>
>>
>> inFileName = "/Users/Marc/Desktop/rsp/tree.txt"
>> with open(inFileName, 'r') as inFile:
>> inString = inFile.read().decode('cp437')
>> print inString
>>
>> I already tried something similar and got an error:
>
> with open('../pytree.txt') as pytree, open('newpytree.txt','w') as pyout:
> for line in pytree:
> for char in line:
> newchar = char.decode('cp437')
> pyout.write(newchar)
>
> UnicodeEncodeError: 'ascii' codec can't encode character u'\u2502' in
> position 0: ordinal not in range(128)
>
> What's my error here, since I want to write to a file. I have python(x,y)
> so printing that is kind of time-taking and not too illuminating ;')
>
The error's in your error message: Python has decoded the string properly,
but (since you haven't specified an encoding) is trying to encode to the
default, which in Python < 3 is 'ascii'... which has a great big blank
space where all characters over 128 should be.
One way to deal with this is to specify an encoding:
newchar = char.decode('cp437').encode('utf-8')
which works just fine for me.
Another way is to tell Python what it should do in case of encoding errors:
- ignore (just drop the offending characters from the output):
newchar = char.decode('cp437').encode('ascii', 'ignore')
- replace (all offending characters get replaced with something
non-offending - like TREE did with my Cyrillic filename):
newchar = char.decode('cp437').encode('ascii', 'replace')
- xmlcharrefreplace (replace offending characters with their XML
encodings):
newchar = char.decode('cp437').encode('ascii', 'xmlcharrefreplace')
This page is your friend: http://docs.python.org/2/howto/unicode.html
and so is this one:
http://docs.python.org/2/library/codecs.html#standard-encodings
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] slashes in paths
On Mon, Jul 22, 2013 at 2:00 PM, Jim Mooney wrote: > so I should just walk the python27 tree and write my own box drawing > chars? Or is there a more global alternative to DOS box-drawing chars to > illustrate a tree structure, other than graphic processing? > You could do worse... Again, my issue with TREE is that it willfully throws away information (non-ASCII characters in filenames) before passing it on to you. As a result, the tree you print out may not correspond to the actual filesystem structure, and there's nothing you can do about it. If that's not a problem for you, go for it. ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] close, but no cigar
On 22 July 2013 14:11, Marc Tompkins wrote: The error's in your error message: Python has decoded the string properly, > but (since you haven't specified an encoding) is trying to encode to the > default, which in Python < 3 is 'ascii'... which has a great big blank > space where all characters over 128 should be. > Thanks. I now have the full tree, with nice little DOS graphics, visible in Notepad++. That's useful. Besides having learned a bit of unicode. Win 7 doesn't show the full tree and if you expand it, it's kind of tiny. Why, in an aging population, is everyone assuming you can see spidery light grey text on websites and tiny symbols and offsets in a file explorer ;') Since I have python(x,y) which makes for an enormous tree, this makes it easier to go through and see what I've got and where it is ;') -- Jim What the Nations of the World Fail to Realize, is That we are Living in a Closed System: In March 2013, researchers from the Stanford University Hopkins Marine Station issued a report on Bluefin tuna caught off the California coast and tested for radioactive cesium. The report found that Bluefin tuna were 100 per cent contaminated, that not one was cesium-free. The report did not address such questions as whether cesium would continue to accumulate in tuna or whether it was appearing in other fish species. ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] slashes in paths
On 22 July 2013 14:15, Marc Tompkins wrote: > > > You could do worse... Again, my issue with TREE is that it willfully > throws away information (non-ASCII characters in filenames) before passing > it on to you. As a result, the tree you print out may not correspond to > the actual filesystem structure, and there's nothing you can do about it. > If that's not a problem for you, go for it. > Oh, I meant walk the tree in python, not using DOS at all. Not everyone has it so it's a good habit to get into not using it. I was just wondering the best way to print the tree. I'll probably have to resort to graphics if I don't like the DOS box characters. Jim > > > -- Jim What the Nations of the World Fail to Realize, is That we are Living in a Closed System: In March 2013, researchers from the Stanford University Hopkins Marine Station issued a report on Bluefin tuna caught off the California coast and tested for radioactive cesium. The report found that Bluefin tuna were 100 per cent contaminated, that not one was cesium-free. The report did not address such questions as whether cesium would continue to accumulate in tuna or whether it was appearing in other fish species. ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] slashes in paths
On Mon, Jul 22, 2013 at 2:34 PM, eryksun wrote: > > Just to clarify, tree isn't completely Unicode naive. It writes > Unicode to the console, presuming you're using a font that supports > it, such as Consolas. > Interesting! Indeed - I just moved my test Cyrillic file to a different folder (so TREE wouldn't scroll off the page) and sho 'nuff there it is - Мама, я хочу домой.RSP. The problem is that it doesn't configure ULIB to use the current > console code page when streaming to a pipe or file. It leaves it at > the default setting, which is to encode Unicode to the OEM code page > (e.g. 437). If it would use the current code page instead, you could > try setting it to 65001 (a somewhat-buggy UTF-8 code page). Streaming > the UTF-16 directly (like cmd's /U option) would be even better, but > that would require modifying ULIB. > > That said, I doubt anyone at Microsoft cares. It's a dinky utility > written back in the early 90s. Probably no one has even looked at the > code in years. > So it does the job correctly, as long as everything fits on one screen. Good to know... ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] slashes in paths
> Just to clarify, tree isn't completely Unicode naive. It writes > Unicode to the console, presuming you're using a font that supports > it, such as Consolas. > I'm sticking to 20 pt Lucida Console on a big, full screen DOS box with navy letters and cyan background. If you have a big screen might as well use it. Why the DOS box defaults to being so tiny is beyond me. To heck with this nutty new design idea of black backgrounds and tiny greyish letters. I didn't like it in DOS and I don't like it on the web. It's like being in the Negative Zone. Must be some Goth thing. Jim ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] slashes in paths
On 22/07/13 22:50, Jim Mooney wrote: I'm sticking to 20 pt Lucida Console on a big, full screen DOS box with navy letters and cyan background. If you have a big screen might as well use it. Why the DOS box defaults to being so tiny is beyond me. Depends what you mean by tiny. On a 1024x768 display its not that small, and with a multi-tasking OS you want to be able to do more than one thing at a time don't you? Single window display is a throwback to the stone age of computing . err, or maybe forward to Windows 8? Go figure letters. I didn't like it in DOS and I don't like it on the web. It's like being in the Negative Zone. When I used an old VT220 on a VAX I always used to reverse the display to show black characters on a light (green or amber) screen. It used to freak out my colleagues who were traditionalist green on black men... When I got upgraded to a VT340(!) I also set it to display 132 chars wide. Now that was really heretical! :-) -- Alan G Author of the Learn to Program web site http://www.alan-g.me.uk/ ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] close, but no cigar
On 22 July 2013 14:11, Marc Tompkins wrote:
>
> One way to deal with this is to specify an encoding:
> newchar = char.decode('cp437').encode('utf-8')
>
Works fine, but I decided to add a dos graphics dash to the existing dash
to expand the tree
visually. Except I got a complaint from IDLE that I should add this:
# -*- coding: utf-8 -*-
Will that always work? Setting coding in a comment? Or am I looking at a
Linux hash line?
Jim
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] slashes in paths
On 22 July 2013 15:12, Alan Gauld wrote: When I used an old VT220 on a VAX I always used to reverse the display to > show black characters on a light (green or amber) screen. It used to freak > out my colleagues who were traditionalist green on black men... > I think a lot of old sonar guys went to computer school on the WWII GI bill. Thought they were still in a submarine ;') -- Jim ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] close, but no cigar
On 22/07/13 23:22, Jim Mooney wrote: # -*- coding: utf-8 -*- Will that always work? Setting coding in a comment? Or am I looking at a Linux hash line? Same concept. It's a special comment that will only take effect when at the top of a file. Actually, I'm not sure how it plays with the hash-bang line - I assume being the second line is OK too... -- Alan G Author of the Learn to Program web site http://www.alan-g.me.uk/ ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] close, but no cigar
On Mon, Jul 22, 2013 at 3:22 PM, Jim Mooney wrote:
> On 22 July 2013 14:11, Marc Tompkins wrote:
>
>>
>> One way to deal with this is to specify an encoding:
>> newchar = char.decode('cp437').encode('utf-8')
>>
>
> Works fine, but I decided to add a dos graphics dash to the existing dash
> to expand the tree
> visually. Except I got a complaint from IDLE that I should add this:
>
> # -*- coding: utf-8 -*-
>
> Will that always work? Setting coding in a comment? Or am I looking at a
> Linux hash line?
>
>
I speak under correction here, but: what you're setting there is the
encoding for the script file itself (and - the real point here - any
strings you specify, without explicit encoding, inside the script), NOT the
default encoding that Python is going to use while executing your script.
Unless I'm very much mistaken, Python will still use the default encoding
('ascii' in your case) when reading strings from external files.
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] close, but no cigar
On 07/22/2013 02:27 PM, Jim Mooney wrote: Okay, I'm getting there, but this should be translating A umlaut to an old DOS box character, according to my ASCII table, but instead it's print small 'u': def main(): zark = '' for x in "ÀÄÄÄ": print(unichr(ord(u'x')-3), end=' ') result: u u u u You're not using any of the A-umlaut characters in that code. You're repeatedly taking ord of the literal u'x' And naturally, u is 3 characters less than x. -- DaveA ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] 3 Dimensional Dictionaries
On Tuesday, July 23, 2013, Sunil Tech wrote:
> THANK YOU ALL for your time.
>
> The first format which I pasted was from the DB
>
> The second format(exactly the same), is to be sent to the view.
>
> If the logic can be fitted in One or two methods it'll help me to easily
understand & to apply.
>
> so I request you to help...
>
>
> On Sunday, July 21, 2013, Alan Gauld wrote:
>> On 20/07/13 11:17, Sunil Tech wrote:
>>>
>>> Hi Everyone,
>>>
>>> I have a list of dictionaries like
>>>
>>> world =
>>>
[{'continent':'Asia','continent_code':1,'ocean':'Pacific','country':'India','country_code':1,'state':'Kerala',
>>> 'state_pin':51},
>>
>>>
>>> i am trying to to make it in this format
>>>
>>> world = [{'continent':'Asia', 'ocean':'Pacific',
>>> 'countries':[{'country':'India',
>>> 'states':[{'state':'Kerala', 'state_pin':51},
>>> {'state':'Karnataka', 'state_pin':52}]
>>> }]
>>> },
>>
>>> Please help me in this regard.
>>
>> In what regard? Where do you need the help?
>> You seem to know the data format you want?
>>
>> The only thing I'd suggest is to consider using classes if you are
familiar with them.
>>
>> world => list of continents
>> continent => class containing countries
>> country => class containing states
>> state => class containing data
>>
>> It then becomes easier to build helper methods to extract/manipulate the
data you are interested in.
>>
>> Alternatively, if you have a large amount of data a database may be
another option. Swap table for class above and use SQL to manage the data.
>>
>> But other than those suggestions I don't know what kind of
>> help you want?
>>
>> --
>> Alan G
>> Author of the Learn to Program web site
>> http://www.alan-g.me.uk/
>>
>> ___
>> Tutor maillist - Tutor@python.org
>> To unsubscribe or change subscription options:
>> http://mail.python.org/mailman/listinfo/tutor
>>
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] close, but no cigar
On Mon, Jul 22, 2013 at 6:13 PM, Dave Angel wrote: > On 07/22/2013 02:27 PM, Jim Mooney wrote: > >> Okay, I'm getting there, but this should be translating A umlaut to an old >> DOS box character, according to my ASCII table, but instead it's print >> small 'u': >> >> def main(): >> zark = '' >> for x in "ÀÄÄÄ": >> print(unichr(ord(u'x')-3), end=' ') >> >> result: u u u u >> >> > You're not using any of the A-umlaut characters in that code. You're > repeatedly taking ord of the literal u'x' > > And naturally, u is 3 characters less than x. > Oooh - I missed that... ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] unichr not working as expected
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')
gives me the error:
AttributeError: 'module' object has no attribute 'setdefaultencoding'
Don't touch setdefaultencoding. It is hidden for a reason. And if you insist on
living dangerously, don't set it to weird legacy encodings like cp437.
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.
The documentation is clear that there are no user-serviceable parts here:
http://docs.python.org/2/library/sys.html#sys.setdefaultencoding
And in Python 3 it became a no-op, then finally deleted for good, gone forever,
and thanks be to feck. http://bugs.python.org/issue9549
Apparently it only exists because when Unicode was first introduced to Python,
the developers couldn't decide whether to use ASCII, Latin1 or UTF-8 as the
internal encoding, which just goes to show that even the top Python devs can be
foolish when it comes to Unicode. So they put in an experimental function to
set the default encoding, and *literally forgot to remove it* for the public
release.
(That's according to the Effbot, Fredrik Lundh, one of the early Python
luminaries.)
--
Steven
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] unichr not working as expected
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 += unichr(ord(x)-45) This is broken in three ways that I can see. Firstly, assuming you are using Python 2.7 (as you have said in the past), "ÀÄÄÄ" does not mean what you think it means. In Python 3, this is a Unicode string containing four individual characters: LATIN CAPITAL LETTER A WITH GRAVE LATIN CAPITAL LETTER A WITH DIAERESIS LATIN CAPITAL LETTER A WITH DIAERESIS LATIN CAPITAL LETTER A WITH DIAERESIS Why you have duplicates, I do not know :-) But in Python 2, that's not what you will get. What you get depends on your environment, and is unpredictable. For example, on my system, using a Linux terminal interactively with the terminal set to UTF-8, I get: py> for c in "ÀÄ": # removing duplicates ... print c, ord(c) ... � 195 � 128 � 195 � 132 Yes, that's right, I get FOUR (not two) "characters" (actually bytes). But if I change the terminal settings to, say, ISO-8859-7: py> for c in "ΓΓ": ... print c, ord(c) ... Γ 195 128 Γ 195 132 the bytes stay the same (195, 128, 195, 132) but the *meaning* of those bytes change completely. So, the point is, if you are running Python 2.7, what you get from a byte string like "ÀÄ" is unpredictable. What you need is a Unicode string u"ÀÄ", which will exactly what it looks like. That's the first issue. Second issue, you build up a string using this idiom: zark = '' for c in something: zark += c Even though this works, this is a bad habit to get into and you should avoid it: it risks being unpredictably slower than continental drift, and in a way that is *really* hard to diagnose. I've seen a case of this fool the finest Python core developers for *weeks*, regarding a reported bug where Python was painfully slow but only for SOME but not all Windows users. The reason why accumulating strings using + can be slow when there are a lot of strings is because it is a Shlemiel the painter's algorithm: http://www.joelonsoftware.com/articles/fog000319.html The reason why sometimes it is *not* slow is that CPython 2.3 and beyond includes a clever optimization trick which can *sometimes* fix this issue, but it depends on details for the operating system's memory handling, and of course it doesn't apply to other implementations like Jython, IronPython, PyPy and Nuitka. So do yourself a favour and get out of the habit of accumulating strings in a for loop using + since it will bite you one day. (Adding one or two strings is fine.) Problem number three: you generate characters using this: unichr(ord(x)-45) but that gives you a negative number if ord(x) is less than 45, which gives you exactly the result you see: py> unichr(-1) Traceback (most recent call last): File "", line 1, in ValueError: unichr() arg not in range(0x1) (narrow Python build) (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 don't understand what the ord(x)-45 is intended to do. The effect is to give the 45th previous character, e.g. the 45th character before 'n' is 'A'. But characters below chr(45) don't have anything 45 characters previous, so you need to rethink what you are trying to do. -- Steven ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] unichr not working as expected
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. > Oh, I found that out already. I found a trick to set it anyway, using reload, then discovered python wasn't printing Anything, even "Hello, world", even after restarting the interpreter ;') I had awful visions of reinstalling python and re downloading python(x,y) on my Really slow connection, but the problem went away after awhile. So I will have to concur in not messing with it. Jim ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] unichr not working as expected
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 track. The worst is when I got something working, but was moving so fast, I forgot how ;') But I have my tree diagram. The next step is to walk the Py27 directory so I can make my own tree diagram, without DOS Tree and it's dumb graphics. Walking a directory seems to be a fave assignment of professors, judging by questions I see, but I don't want to look at anyone else's.solution. I'll just see what the walk generator puts out and try to figure it. That's the fun part. -- Jim When I was young dad told me if a moth fluttered onto my sleeping lips at night it would suck out my soul. Dad was such a kidder. But I still flee from moths. ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
