ascii to unicode line endings
The code:
import codecs
udlASCII = file("c:\\temp\\CSVDB.udl",'r')
udlUNI = codecs.open("c:\\temp\\CSVDB2.udl",'w',"utf_16")
udlUNI.write(udlASCII.read())
udlUNI.close()
udlASCII.close()
This doesn't seem to generate the correct line endings. Instead of
converting 0x0D/0x0A to 0x0D/0x00/0x0A/0x00, it leaves it as 0x0D/
0x0A
I have tried various 2 byte unicode encoding but it doesn't seem to
make a difference. I have also tried modifying the code to read and
convert a line at a time, but that didn't make any difference either.
I have tried to understand the unicode docs but nothing seems to
indicate why an seemingly incorrect conversion is being done.
Obviously I am missing something blindingly obvious here, any help
much appreciated.
Dom
--
http://mail.python.org/mailman/listinfo/python-list
Re: ascii to unicode line endings
On 2 May, 17:29, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote:
> On 2 May 2007 09:19:25 -0700, [EMAIL PROTECTED] wrote:
>
>
>
> >The code:
>
> >import codecs
>
> >udlASCII = file("c:\\temp\\CSVDB.udl",'r')
> >udlUNI = codecs.open("c:\\temp\\CSVDB2.udl",'w',"utf_16")
>
> >udlUNI.write(udlASCII.read())
>
> >udlUNI.close()
> >udlASCII.close()
>
> >This doesn't seem to generate the correct line endings. Instead of
> >converting 0x0D/0x0A to 0x0D/0x00/0x0A/0x00, it leaves it as 0x0D/
> >0x0A
>
> >I have tried various 2 byte unicode encoding but it doesn't seem to
> >make a difference. I have also tried modifying the code to read and
> >convert a line at a time, but that didn't make any difference either.
>
> >I have tried to understand the unicode docs but nothing seems to
> >indicate why an seemingly incorrect conversion is being done.
> >Obviously I am missing something blindingly obvious here, any help
> >much appreciated.
>
> Consider this simple example:
>
> >>> import codecs
> >>> f = codecs.open('test-newlines-file', 'w', 'utf16')
> >>> f.write('\r\n')
> >>> f.close()
> >>> f = file('test-newlines-file')
> >>> f.read()
> '\xff\xfe\r\x00\n\x00'
> >>>
>
> And how it differs from your example. Are you sure you're examining
> the resulting output properly?
>
> By the way, "\r\0\n\0" isn't a "unicode line ending", it's just the UTF-16
> encoding of "\r\n".
>
> Jean-Paul
I am not sure what you are driving at here, since I started with an
ascii file, whereas you just write a unicode file to start with. I
guess the direct question is "is there a simple way to convert my
ascii file to a utf16 file?". I thought either string.encode() or
writing to a utf16 file would do the trick but it probably isn't that
simple!
I used a binary file editor I have used a great deal for all sorts of
things to get the hex values.
Dom
--
http://mail.python.org/mailman/listinfo/python-list
Re: ascii to unicode line endings
On 3 May, 13:00, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote:
> On 3 May 2007 04:30:37 -0700, [EMAIL PROTECTED] wrote:
>
>
>
> >On 2 May, 17:29, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote:
> >> On 2 May 2007 09:19:25 -0700, [EMAIL PROTECTED] wrote:
>
> >> >The code:
>
> >> >import codecs
>
> >> >udlASCII = file("c:\\temp\\CSVDB.udl",'r')
> >> >udlUNI = codecs.open("c:\\temp\\CSVDB2.udl",'w',"utf_16")
>
> >> >udlUNI.write(udlASCII.read())
>
> >> >udlUNI.close()
> >> >udlASCII.close()
>
> >> >This doesn't seem to generate the correct line endings. Instead of
> >> >converting 0x0D/0x0A to 0x0D/0x00/0x0A/0x00, it leaves it as 0x0D/
> >> >0x0A
>
> >> >I have tried various 2 byte unicode encoding but it doesn't seem to
> >> >make a difference. I have also tried modifying the code to read and
> >> >convert a line at a time, but that didn't make any difference either.
>
> >> >I have tried to understand the unicode docs but nothing seems to
> >> >indicate why an seemingly incorrect conversion is being done.
> >> >Obviously I am missing something blindingly obvious here, any help
> >> >much appreciated.
>
> >> Consider this simple example:
>
> >> >>> import codecs
> >> >>> f = codecs.open('test-newlines-file', 'w', 'utf16')
> >> >>> f.write('\r\n')
> >> >>> f.close()
> >> >>> f = file('test-newlines-file')
> >> >>> f.read()
> >> '\xff\xfe\r\x00\n\x00'
>
> >> And how it differs from your example. Are you sure you're examining
> >> the resulting output properly?
>
> >> By the way, "\r\0\n\0" isn't a "unicode line ending", it's just the UTF-16
> >> encoding of "\r\n".
>
> >> Jean-Paul
>
> >I am not sure what you are driving at here, since I started with an
> >ascii file, whereas you just write a unicode file to start with. I
> >guess the direct question is "is there a simple way to convert my
> >ascii file to a utf16 file?". I thought either string.encode() or
> >writing to a utf16 file would do the trick but it probably isn't that
> >simple!
>
> There's no such thing as a unicode file. The only difference between
> the code you posted and the code I posted is that mine is self-contained
> and demonstrates that the functionality works as you expected it to work,
> whereas the code you posted is requires external resources which are not
> available to run and produces external results which are not available to
> be checked regarding their correctness.
>
> So what I'm driving at is that both your example and mine are doing it
> correctly (because they are doing the same thing), and mine demonstrates
> that it is correct, but we have to take your word on the fact that yours
> doesn't work. ;)
>
> Jean-Paul
Thanks for the advice. I cannot prove what is going on. The following
code seems to work fine as far as console output goes, but the actual
bit patterns of the files on disk are not what I am expecting (or
expected as input by the ultimate user of the converted file). Which I
can't prove of course.
>>> import codecs
>>> testASCII = file("c:\\temp\\test1.txt",'w')
>>> testASCII.write("\n")
>>> testASCII.close()
>>> testASCII = file("c:\\temp\\test1.txt",'r')
>>> testASCII.read()
'\n'
Bit pattern on disk : \0x0D\0x0A
>>> testASCII.seek(0)
>>> testUNI = codecs.open("c:\\temp\\test2.txt",'w','utf16')
>>> testUNI.write(testASCII.read())
>>> testUNI.close()
>>> testUNI = file("c:\\temp\\test2.txt",'r')
>>> testUNI.read()
'\xff\xfe\n\x00'
Bit pattern on disk:\0xff\0xfe\0x0a\0x00
Bit pattern I was expecting:\0xff\0xfe\0x0d\0x00\0x0a\0x00
>>> testUNI.close()
Dom
--
http://mail.python.org/mailman/listinfo/python-list
Re: ascii to unicode line endings
On 3 May, 13:39, "Jerry Hill" <[EMAIL PROTECTED]> wrote:
> On 2 May 2007 09:19:25 -0700, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> > The code:
>
> > import codecs
>
> > udlASCII = file("c:\\temp\\CSVDB.udl",'r')
> > udlUNI = codecs.open("c:\\temp\\CSVDB2.udl",'w',"utf_16")
> > udlUNI.write(udlASCII.read())
> > udlUNI.close()
> > udlASCII.close()
>
> > This doesn't seem to generate the correct line endings. Instead of
> > converting 0x0D/0x0A to 0x0D/0x00/0x0A/0x00, it leaves it as 0x0D/
> > 0x0A
>
> That code (using my own local files, of course) basically works for me.
>
> If I open my input file with mode 'r', as you did above, my '\r\n'
> pairs get transformed to '\n' when I read them in and are written to
> my output file as 0x00 0x0A. If I open the input file in binary mode
> 'rb' then my output file shows the expected sequence of 0x00 0x0D 0x00
> 0x0A.
>
> Perhaps there's a quirk of your version of python or your platform? I'm
> running
> Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit
> (Intel)] on win32
>
> --
> Jerry
Thanks very much! Not sure if you intended to fix my whole problem,
but changing the read mode to 'rb' has done the trick :)
Dom
--
http://mail.python.org/mailman/listinfo/python-list
A better way to split up a list
The code below works fine, but it is less than nice to look at and somewhat long winded. Is there a better way to do the docstring task? This is the first working version, and can proabably be "compacted" a bit (list comprehensions etc) but I am looking for a better basic approach. Any help much appreciated :) from itertools import islice def chopupmoves(movelist): '''creates a list of 3 lists from one list, that should all have (length of movelist)/3 length, with any remainder getting added to the third list''' outputlist = [[],[],[]] parlen = int(len(movelist)/3) if parlen < 3: parlen = 3 stoplist=[0];exit = 0 while exit < len(movelist): stoplist.append(exit+parlen) exit = exit + parlen while len(stoplist) > 4: stoplist.pop(len(stoplist)-1) stoplist[-1]=len(movelist) for x in range(len(stoplist)-1): for i in islice(movelist,stoplist[x],stoplist[x+1],1): outputlist[x].append(i) return outputlist movelist = [1,2,3,4,5,6,7,8,9,10,11] print chopupmoves(movelist) -- http://mail.python.org/mailman/listinfo/python-list
Re: A better way to split up a list
Argh, embarassment on my part due to incomplete spec. movelist is used to store a list of chess moves and splitting it up in this way is so it can be printed in a space that is 3 lines high but quite wide. Thus the way the list grows as it is appended to in chopupmoves is intended. -- http://mail.python.org/mailman/listinfo/python-list
Re: A better way to split up a list
Thanks very much, that is a far tidier solution!! -- http://mail.python.org/mailman/listinfo/python-list
Re: python recursive function
On 11 Jan, 08:30, Tom_chicollegeboy <[EMAIL PROTECTED]> wrote: > here is what I have to do: > > This question involves a game with teddy bears. The game starts when I > give you some bears. You then start giving me back some bears, but you > must follow these rules (where n is the number of bears that you > have): > > If n is even, then you may give back exactly n/2 bears. (Hint: To test > whether n is even, use the expression ((n % 2) == 0).) > If n is divisible by 3 or 4, then you may multiply the last two digits > of n and give back this many bears. (By the way, the last digit of n > is n%10, and the next-to-last digit is (n%100)/10; this rule may not > be used if either of the last two digits is 0.) > > If n is divisible by 5, then you may give back exactly 42 bears. > The goal of the game for you is to end up with EXACTLY 42 bears. > > For example, suppose that you start with 250 bears. Then you could > make these moves: > > Start with 250 bears. > Since 250 is divisible by 5, you may return 42 of the bears, leaving > you with 208 bears. > Since 208 is even, you may return half of the bears, leaving you with > 104 bears. > Since 104 is even, you may return half of the bears, leaving you with > 52 bears. > Since 52 is divisible by 4, you may multiply the last two digits > (resulting in 10) and return these 10 bears. This leaves you with 42 > bears. > You have reached the goal! > Now, you are to write a program that, if I give you n bears, returns > true if it is at all possible for you to win the game. Your program > must use recursion to check all possible ways in which you can apply > the rules. > > Usage: > > >>> bears(42) > True > >>> bears(250) > True > >>> bears(50) > False > >>> bears(84) > True > >>> bears(41) > > False > > As you see my program must use recursion. > > I came up with this idea but I am not sure if its right or are there > any minor errors that I can easily fix: > > def bears (n): > if n==42: > return True > if n%5==0: > bears(n-42) > if n%2==0: > bears(n/2) > if n%3==0 or n%4==0: > one = (n%10) > two = ((n%100)/10) > if one!=0 and two!=0: > bears(n-(one*two)) > return False > > If a game hits 42 it should return True, otherwise False. If program > never hits 42 and return True, then it returns False. I figured out > base case, but I still get False when I enter bears(250). Any help > would be very appreciated! May != Must and Could != Should -- http://mail.python.org/mailman/listinfo/python-list
