Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #66074 > unrolled thread

Wait... WHAT?

Back to article view | Back to comp.lang.python

Contents

  Wait... WHAT? eneskristo@gmail.com - 2014-02-12 11:43 -0800
    Re: Wait... WHAT? Ian Kelly <ian.g.kelly@gmail.com> - 2014-02-12 13:13 -0700
    Re: Wait... WHAT? eneskristo@gmail.com - 2014-02-12 12:21 -0800
      Re: Wait... WHAT? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-02-12 20:38 +0000
      Re: Wait... WHAT? Ian Kelly <ian.g.kelly@gmail.com> - 2014-02-12 14:35 -0700
      Re: Wait... WHAT? Michael Torrie <torriem@gmail.com> - 2014-02-12 14:39 -0700
      Re: Wait... WHAT? Tim Chase <python.list@tim.thechases.com> - 2014-02-12 16:14 -0600
      Re: Wait... WHAT? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-02-12 23:36 +0000
      Re: Wait... WHAT? Ian Kelly <ian.g.kelly@gmail.com> - 2014-02-12 17:01 -0700
      Re: Wait... WHAT? Tim Chase <python.list@tim.thechases.com> - 2014-02-12 18:44 -0600
      Re: Wait... WHAT? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-02-13 00:59 +0000
      Re: Wait... WHAT? Chris Angelico <rosuav@gmail.com> - 2014-02-13 12:10 +1100
      Re: Wait... WHAT? Tim Chase <python.list@tim.thechases.com> - 2014-02-12 21:29 -0600
      Re: Wait... WHAT? Chris Angelico <rosuav@gmail.com> - 2014-02-13 14:47 +1100
        Re: Wait... WHAT? eneskristo@gmail.com - 2014-02-13 09:46 -0800
          Re: Wait... WHAT? MRAB <python@mrabarnett.plus.com> - 2014-02-13 18:25 +0000
          Re: Wait... WHAT? Michael Torrie <torriem@gmail.com> - 2014-02-13 15:22 -0700
    Re: Wait... WHAT? eneskristo@gmail.com - 2014-02-12 12:43 -0800
      Re: Wait... WHAT? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-02-12 20:56 +0000
        Re: Wait... WHAT? eneskristo@gmail.com - 2014-02-12 12:59 -0800
          Re: Wait... WHAT? Chris Angelico <rosuav@gmail.com> - 2014-02-13 08:17 +1100
          Re: Wait... WHAT? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-02-12 21:23 +0000
      Re: Wait... WHAT? Grant Edwards <invalid@invalid.invalid> - 2014-02-12 23:09 +0000

Page 1 of 2  [1] 2  Next page →

#66074 — Wait... WHAT?

http://postimg.org/image/rkm9lhj8n/

So, I was doing some cx freeze stuff. If you cant understand everything from the pic, I'll give extra info. Please help me.

[toc] | [next] | [standalone]

#66075

On Wed, Feb 12, 2014 at 12:43 PM,  <eneskristo@gmail.com> wrote:
> http://postimg.org/image/rkm9lhj8n/
>
> So, I was doing some cx freeze stuff. If you cant understand everything from the pic, I'll give extra info. Please help me.

It would be preferable if you would please copy and paste the
exception along with the code being run into your post, rather than
linking to a (probably transient) image on some random hosting site.

It appears that tkinter is trying to write an exception directly to
stderr and failing because sys.stderr is None.  This is probably
because you're running the program in console-less mode, where
sys.stderr (along with stdin and stdout) does not exist.  You'll need
to either run your program in console mode or set up a file-like
object yourself in place of sys.stderr to capture these messages.

It might also be considered a bug in tkinter that it attempts to write
to stderr without first ensuring that stderr exists.

[toc] | [prev] | [next] | [standalone]

#66077

I think of it as a bit strange. Should I report it as a bug? I was trying to incorporate a save/load, and this happened. 
    def save():
        target = open ("save.swroc", 'w')
        target.write([counter, loop, number_of_competitors, competitors])
    def load():
        target = open("save.swroc", 'r')
        the_array = target
        counter = the_array[0]
        loop = the_array[1]
        number_of_competitors = the_array[2]
        competitors = the_array[3]
Swroc is an nonexisting file format that i just made up, an acronym of the program

[toc] | [prev] | [next] | [standalone]

#66080

On 12/02/2014 20:21, eneskristo@gmail.com wrote:
> I think of it as a bit strange. Should I report it as a bug? I was trying to incorporate a save/load, and this happened.
>      def save():
>          target = open ("save.swroc", 'w')
>          target.write([counter, loop, number_of_competitors, competitors])
>      def load():
>          target = open("save.swroc", 'r')
>          the_array = target
>          counter = the_array[0]
>          loop = the_array[1]
>          number_of_competitors = the_array[2]
>          competitors = the_array[3]
> Swroc is an nonexisting file format that i just made up, an acronym of the program
>

What is it, trying to write a Python list to a file or trying to access 
offsets into a file handle?

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

Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

[toc] | [prev] | [next] | [standalone]

#66096

On Wed, Feb 12, 2014 at 1:21 PM,  <eneskristo@gmail.com> wrote:
> I think of it as a bit strange. Should I report it as a bug? I was trying to incorporate a save/load, and this happened.
>     def save():
>         target = open ("save.swroc", 'w')
>         target.write([counter, loop, number_of_competitors, competitors])
>     def load():
>         target = open("save.swroc", 'r')
>         the_array = target
>         counter = the_array[0]
>         loop = the_array[1]
>         number_of_competitors = the_array[2]
>         competitors = the_array[3]
> Swroc is an nonexisting file format that i just made up, an acronym of the program

You can't write lists directly to files.  You can only write strings
to files.  To write and read a list, you'll need to first serialize it
and later deserialize it.  Your needs appear simple enough that I
suggest the json module for this.

    json.dump([counter, loop, number_of_competitors, competitors], target)

    [counter, loop, number_of_competitors, competitors] = json.load(target)

It sounds like this may be the source of the exception that tkinter
was trying unsuccessfully to report in your first post.  You should
still fix your sys.stderr so that tkinter can report exceptions.

[toc] | [prev] | [next] | [standalone]

#66098

On 02/12/2014 01:21 PM, eneskristo@gmail.com wrote:
> I think of it as a bit strange. Should I report it as a bug? I was
trying to incorporate a save/load, and this happened.

What happened?  I'm not seeing any exception information.  I do see code
that doesn't quite make sense.

>     def save():
>         target = open ("save.swroc", 'w')
>         target.write([counter, loop, number_of_competitors, competitors])

Do you know what actually gets written? IE do you know what the
resulting text file looks like?

>     def load():
>         target = open("save.swroc", 'r')
>         the_array = target
>         counter = the_array[0]
>         loop = the_array[1]
>         number_of_competitors = the_array[2]
>         competitors = the_array[3]

This function isn't right.  Question for you, what does open() return?
And if you assign that to "the_array," what makes you think you can
dereference open() as it it were an array?  open() does not provide a
__getitem__() dunder method.

Python is pretty good at doing what you want usually, but you're missing
a step.  Python's not bug-free, but the first suspect in a case like
this is your code.

There's an outside chance you want to explore the "pickle" module.

[toc] | [prev] | [next] | [standalone]

#66106

On 2014-02-12 14:35, Ian Kelly wrote:
> You can't write lists directly to files.  You can only write strings
> to files.  To write and read a list, you'll need to first serialize
> it and later deserialize it. 

To be pedantic, you can only write *bytes* to files, so you need to
serialize your lists (or other objects) to strings and then encode
those to bytes; or skip the string and encode your list/object
directly to bytes.

Though unfortunately, I now have a tweaked version of that late-night
commercial¹:  "PICKLE: SERIALIZE DIRECTLY TO BYTES! PICKLE: SERIALIZE
DIRECTLY TO BYTES! PICKLE: SERIALIZE DIRECTLY TO BYTES!"

-tkc

¹ http://www.youtube.com/watch?v=f_SwD7RveNE

[toc] | [prev] | [next] | [standalone]

#66120

On 12/02/2014 22:14, Tim Chase wrote:
>
> To be pedantic, you can only write *bytes* to files, so you need to
> serialize your lists (or other objects) to strings and then encode
> those to bytes; or skip the string and encode your list/object
> directly to bytes.
>

Really?

 >>> f = open('test.txt', 'w')
 >>> f.write('a string')
8
 >>> f.close()
 >>>

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

Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

[toc] | [prev] | [next] | [standalone]

#66122

On Wed, Feb 12, 2014 at 3:14 PM, Tim Chase
<python.list@tim.thechases.com> wrote:
> On 2014-02-12 14:35, Ian Kelly wrote:
>> You can't write lists directly to files.  You can only write strings
>> to files.  To write and read a list, you'll need to first serialize
>> it and later deserialize it.
>
> To be pedantic, you can only write *bytes* to files, so you need to
> serialize your lists (or other objects) to strings and then encode
> those to bytes; or skip the string and encode your list/object
> directly to bytes.

The file was opened in text mode, not binary mode.

Python 3.3.0 (v3.3.0:bd8afb90ebf2, Sep 29 2012, 10:55:48) [MSC v.1600 32 bit (In
tel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> f = open('test.txt', 'w')
>>> f.write(b'hello world')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: must be str, not bytes

[toc] | [prev] | [next] | [standalone]

#66124

On 2014-02-12 23:36, Mark Lawrence wrote:
> On 12/02/2014 22:14, Tim Chase wrote:
> >
> > To be pedantic, you can only write *bytes* to files, so you need
> > to serialize your lists (or other objects) to strings and then
> > encode those to bytes; or skip the string and encode your
> > list/object directly to bytes.
> >
> 
> Really?
> 
>  >>> f = open('test.txt', 'w')
>  >>> f.write('a string')
> 8
>  >>> f.close()
>  >>>

Yep:

>>> s = "\u3141" # HANGUL LETTER MIEUM
>>> f = open('test.txt', 'w')
>>> f.write("\u3141")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeEncodeError: 'ascii' codec can't encode character '\u3141' in
position 0: ordinal not in range(128)

Just because the open() call hides the specification of how Python
should do that encoding doesn't prevent the required encoding from
happening. :-)

-tkc

[toc] | [prev] | [next] | [standalone]

#66125

On 13/02/2014 00:44, Tim Chase wrote:
> On 2014-02-12 23:36, Mark Lawrence wrote:
>> On 12/02/2014 22:14, Tim Chase wrote:
>>>
>>> To be pedantic, you can only write *bytes* to files, so you need
>>> to serialize your lists (or other objects) to strings and then
>>> encode those to bytes; or skip the string and encode your
>>> list/object directly to bytes.
>>>
>>
>> Really?
>>
>>   >>> f = open('test.txt', 'w')
>>   >>> f.write('a string')
>> 8
>>   >>> f.close()
>>   >>>
>
> Yep:
>
>>>> s = "\u3141" # HANGUL LETTER MIEUM
>>>> f = open('test.txt', 'w')
>>>> f.write("\u3141")
> Traceback (most recent call last):
>    File "<stdin>", line 1, in <module>
> UnicodeEncodeError: 'ascii' codec can't encode character '\u3141' in
> position 0: ordinal not in range(128)
>
> Just because the open() call hides the specification of how Python
> should do that encoding doesn't prevent the required encoding from
> happening. :-)
>
> -tkc
>
>

Which clearly reinforces the fact that what you originally said is 
incorrect, I don't have to do anything, Python very kindly does things 
for me under the covers.

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

Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

[toc] | [prev] | [next] | [standalone]

#66128

On Thu, Feb 13, 2014 at 11:44 AM, Tim Chase
<python.list@tim.thechases.com> wrote:
> Yep:
>
>>>> s = "\u3141" # HANGUL LETTER MIEUM
>>>> f = open('test.txt', 'w')
>>>> f.write("\u3141")
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> UnicodeEncodeError: 'ascii' codec can't encode character '\u3141' in
> position 0: ordinal not in range(128)
>
> Just because the open() call hides the specification of how Python
> should do that encoding doesn't prevent the required encoding from
> happening. :-)
>

All it's hiding is what the default encoding is.

Python 3.4.0rc1+ (default:2ba583191550, Feb 12 2014, 10:30:57)
[GCC 4.7.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> f = open('test.txt', 'w')
>>> f.write("\u3141")
1

Python 3.4.0b2 (v3.4.0b2:ba32913eb13e, Jan  5 2014, 16:23:43) [MSC
v.1600 32 bit (Intel)] on win32
Type "copyright", "credits" or "license()" for more information.
>>> f = open('test.txt', 'w')
>>> f.write("\u3141")
Traceback (most recent call last):
  File "<pyshell#1>", line 1, in <module>
    f.write("\u3141")
  File "C:\Python34\lib\encodings\cp1252.py", line 19, in encode
    return codecs.charmap_encode(input,self.errors,encoding_table)[0]
UnicodeEncodeError: 'charmap' codec can't encode character '\u3141' in
position 0: character maps to <undefined>
>>> f = open('test.txt', 'w', encoding='utf-8')
>>> f.write("\u3141")
1

Be explicit, and you can store Unicode strings reliably. That said,
though, you still can't store lists.

ChrisA

[toc] | [prev] | [next] | [standalone]

#66144

On 2014-02-13 00:59, Mark Lawrence wrote:
> >>>> s = "\u3141" # HANGUL LETTER MIEUM
> >>>> f = open('test.txt', 'w')
> >>>> f.write("\u3141")  
> > Traceback (most recent call last):
> >    File "<stdin>", line 1, in <module>
> > UnicodeEncodeError: 'ascii' codec can't encode character '\u3141'
> > in position 0: ordinal not in range(128)
> >
> > Just because the open() call hides the specification of how Python
> > should do that encoding doesn't prevent the required encoding from
> > happening. :-)
> 
> Which clearly reinforces the fact that what you originally said is 
> incorrect, I don't have to do anything, Python very kindly does
> things for me under the covers.

...and when they break, you get to keep both pieces. :)

If you don't know that encoding is being done, it's a lot harder to
trust the assumption that you can directly write strings to files
when exceptions like the above happen. My original point (though
perhaps not conveyed as well as I'd intended) was that only bytes get
written to the disk, and that some encoding must take place.  It can
be done implicitly using some defaults which may break (as demoed),
whereas one would be better off doing it explicitly such as Chris
shows:

  >>> f = open('test.txt', 'w', encoding='utf-8')
  >>> f.write("\u3141")  
  1

UTF-8'rs gonna 8. (or whatever memes the cool kids are riffing these
days)

-tkc

[toc] | [prev] | [next] | [standalone]

#66147

On Thu, Feb 13, 2014 at 2:29 PM, Tim Chase
<python.list@tim.thechases.com> wrote:
> My original point (though
> perhaps not conveyed as well as I'd intended) was that only bytes get
> written to the disk, and that some encoding must take place.  It can
> be done implicitly using some defaults which may break (as demoed),
> whereas one would be better off doing it explicitly such as Chris
> shows

And since the default encoding varies based on matters outside your
script (most notably platform - I tried this on Windows and Linux, and
got a default of UTF-8 on Linux and CP-1252 on Windows; but
environment variables and such can interfere too), I would say that
omitting the encoding= parameter should be done ONLY when you actually
have no idea what the encoding is, only that it's "probably something
from the rest of the system". And, well, if that's what you're looking
at, you definitely can't trust to reading or writing non-ASCII (you
can probably trust ASCII). When you create a file that you'll read
back yourself, specify an encoding.

ChrisA

[toc] | [prev] | [next] | [standalone]

#66195

Can we please revert back to the original problem?
    def save():
        target = open ("save.swroc", 'w')
        target.write([counter, loop, number_of_competitors, competitors])
    def load():
        the_array = list(open("save.swroc", 'r'))
        the_array = target
        counter = the_array[0]
        loop = the_array[1]
        number_of_competitors = the_array[2]
        competitors = the_array[3]
Is this better?

[toc] | [prev] | [next] | [standalone]

#66199

On 2014-02-13 17:46, eneskristo@gmail.com wrote:
> Can we please revert back to the original problem?
>      def save():
 >          target = open ("save.swroc", 'w')

This opens the file for writing text (assuming you're using Python 3).

 >          target.write([counter, loop, number_of_competitors, 
competitors])

This tries to write a list to the file. You can't do that. A list isn't
text.

>      def load():
>          the_array = list(open("save.swroc", 'r'))

This open the file for reading text. Using 'list' will make it read
lines of text and return them as a list.

>          the_array = target

What's 'target'?

>          counter = the_array[0]

This will set 'counter' to the first line of text that was read.

>          loop = the_array[1]

This will set 'loop' to the second line of text.

>          number_of_competitors = the_array[2]

This will set 'number_of_competitors' to the third line of text.

>          competitors = the_array[3]

This will set 'number_of_competitors' to the fourth line of text.

> Is this better?
>
Not really! :-)

Have a look at the "pickle" module, or the "json" module.

[toc] | [prev] | [next] | [standalone]

#66264

On 02/13/2014 10:46 AM, eneskristo@gmail.com wrote:
> Can we please revert back to the original problem?
>     def save():
>         target = open ("save.swroc", 'w')
>         target.write([counter, loop, number_of_competitors, competitors])
                      ^^^^^^^^^
Have you tried to run this code?  Does it even produce a file?  On my
python it says that write() is expecting a string on Python 3, or a
character buffer object on Python 2.7.  Have you broken out the code
into a minimal, standalone file you can work on?

>     def load():
>         the_array = list(open("save.swroc", 'r'))
                  ^^^^^^^^^^^
That's better.  You know it reads in the text file one line at a time
into a list right?  This would work if your file was actually written
with one variable in text form on each line.

>         the_array = target
		    ^^^^^^^^^^
You have now reassigned the_array to an undefined object. If target is
defined somewhere (I can't see that it is here in your code snippet),
then you've now lost the array of lines you just read in.

>         counter = the_array[0]
>         loop = the_array[1]
>         number_of_competitors = the_array[2]
>         competitors = the_array[3]
> Is this better?

Well it doesn't run, so we can't say it's better.

A couple of points/questions/hints/suggestions:

1. make a minimal, complete, example of what you are trying to do.  Code
you can run without the rest of your program.

2. What are your variables, "counter," "loop," "number_of_competitors,"
"competitors?"

3. What format is the file supposed to be in?

4. If you pullup the file in an editor does it look right? (IE do you
know what the output from your save function actually looks like?)

5. If you're dealing with numbers, remember the text file has no concept
of numbers. You'll have to parse them from text when you read them.

6. Consider using the pickle module if you really want to store and load
python objects without encoding and decoding a text file.

Hope this helps.

[toc] | [prev] | [next] | [standalone]

#66081

One to write in the file, and one to read it.

[toc] | [prev] | [next] | [standalone]

#66083

On 12/02/2014 20:43, eneskristo@gmail.com wrote:
> One to write in the file, and one to read it.
>

Nice to know, but please place this in context.  Many people who partake 
in this group are smart, but we're not mind readers :)

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

Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

[toc] | [prev] | [next] | [standalone]

#66084

I am sorry then. So what's the problem, and if it is a bug, should I report it?

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.python

csiph-web