with open('com1', 'r') as f:

[gert]

from subprocess import *

check_call(['mode', 'COM1:9600,N,8,1,P'],shell=True)
while True:
with open('com1', 'r') as f:
for line in f:
print('line')

This works very well except for one thing. After a reboot I have to
launch 1 time any windows serial exe application no mater with one,
that just opens an closes the com port, before i can launch this
script. The script keeps on working even after closing and reopening
it, until i reboot the pc. Then again I have to launch one time a
serial.exe and close it again. The exe does not run anything in the
background it just does something in windows python does not do when
it reads from the com port after a fresh reboot.

And i really appreciate it if somebody knew what it was.

 

[Kushal Kumaran]

from subprocess import *

check_call(['mode', 'COM1:9600,N,8,1,P'],shell=True)
while True:
with open('com1', 'r') as f:
for line in f:
print('line')

This works very well except for one thing. After a reboot I have to
launch 1 time any windows serial exe application no mater with one,
that just opens an closes the com port, before i can launch this
script. The script keeps on working even after closing and reopening
it, until i reboot the pc. Then again I have to launch one time a
serial.exe and close it again. The exe does not run anything in the
background it just does something in windows python does not do when
it reads from the com port after a fresh reboot.

And i really appreciate it if somebody knew what it was.

I don't know why you're getting this behaviour, but have you tried using
a python library for accessing the serial port? See
http://pyserial.wiki.sourceforge.net/pySerial.

 

[gert]

from subprocess import *

check_call(['mode', 'COM1:9600,N,8,1,P'],shell=True)
while True:
    with open('com1', 'r') as f:
        for line in f:
             print('line')

This works very well except for one thing. After a reboot I have to
launch 1 time any windows serial exe application no mater with one,
that just opens an closes the com port, before i can launch this
script. The script keeps on working even after closing and reopening
it, until i reboot the pc. Then again I have to launch one time a
serial.exe and close it again. The exe does not run anything in the
background it just does something in windows python does not do when
it reads from the com port after a fresh reboot.

And i really appreciate it if somebody knew what it was.

I don't know why you're getting this behaviour, but have you tried using
a python library for accessing the serial port? Seehttp://pyserial.wiki.sourceforge.net/pySerial.

I am sorry but I don't think pyserial will work on python3.x and I
also like to know whats going on before I consider it.
Maybe its a bug in open() on windows?

 

[Gabriel Genellina]

On Thu, 2 Apr 2009 10:01:02 -0700 (PDT)

from subprocess import *
check_call(['mode', 'COM1:9600,N,8,1,P'],shell=True)
while True:
    with open('com1', 'r') as f:
        for line in f:
             print('line')

This works very well except for one thing. After a reboot I have to
launch 1 time any windows serial exe application no mater with one,
that just opens an closes the com port, before i can launch this
script. The script keeps on working even after closing and reopening
it, until i reboot the pc. Then again I have to launch one time a
serial.exe and close it again. The exe does not run anything in the
background it just does something in windows python does not do when
it reads from the com port after a fresh reboot.

And i really appreciate it if somebody knew what it was.

I don't know why you're getting this behaviour, but have you tried using
a python library for accessing the serial port?
Seehttp://pyserial.wiki.sourceforge.net/pySerial.

I am sorry but I don't think pyserial will work on python3.x and I
also like to know whats going on before I consider it.

A real Windows program accessing the serial port is likely to use
SetupComm, SetCommState, and other functions in addition to CreateFile.
See http://msdn.microsoft.com/en-us/library/aa363196(VS.85).aspx

pySerial takes care of all those details, as suggested.

Maybe its a bug in open() on windows?

open() doesn't care about the file name; it's the OS that interprets
"com1" as a serial port.

 

[gert]

On Thu, 2 Apr 2009 10:01:02 -0700 (PDT)
from subprocess import *
check_call(['mode', 'COM1:9600,N,8,1,P'],shell=True)
while True:
    with open('com1', 'r') as f:
        for line in f:
             print(line)
This works very well except for one thing. After a reboot I have to
launch 1 time any windows serial exe application no mater with one,
that just opens an closes the com port, before i can launch this
script. The script keeps on working even after closing and reopening
it, until i reboot the pc. Then again I have to launch one time a
serial.exe and close it again. The exe does not run anything in the
background it just does something in windows python does not do when
it reads from the com port after a fresh reboot.
And i really appreciate it if somebody knew what it was.
I don't know why you're getting this behaviour, but have you tried using
a python library for accessing the serial port?  
Seehttp://pyserial.wiki.sourceforge.net/pySerial.

I am sorry but I don't think pyserial will work on python3.x and I
also like to know whats going on before I consider it.

A real Windows program accessing the serial port is likely to use  
SetupComm, SetCommState, and other functions in addition to CreateFile.
Seehttp://msdn.microsoft.com/en-us/library/aa363196(VS.85).aspx

pySerial takes care of all those details, as suggested.

Maybe its a bug in open() on windows?

open() doesn't care about the file name; it's the OS that interprets  
"com1" as a serial port.

I do understand, and I went looking into pySerial, but it is a long
way from getting compatible with python3.x and involves other libs
that are big and non pyhton3.x compatible.

Also I can not imaging activating a com port wouldn't be possible with
a check_call dos instruction. I can already configure com with mode.

 

[Lawrence D'Oliveiro]

In message <8bc55c05-19da-41c4-

with open('com1', 'r') as f:
for line in f:
print('line')

Why bother, why not just

for line in open('com1', 'r') :
print line

 

[gert]

In message <8bc55c05-19da-41c4-



Why bother, why not just

    for line in open('com1', 'r') :
        print line

Interesting
So its does the same thing as with right ?
Automatic closing and finalizing stuff.

 

[gert]

So don't use Python 3.0. Most people are still using Python 2.5 or 2.6.

With all respect but why do people in general avoid the question when
they do not know something?
I appreciate the answer and its a valid solution, never the less
useless in the answer I seek.

I hope I did not offend anybody. When you want to do something about
the future, you have to take the hard way, so others can take the easy
way. If somebody is stuck going the hard way, to clear it for others,
you can not expect them to be satisfied with a easy answer.

Sorry.

 

[Kushal Kumaran]

So don't use Python 3.0. Most people are still using Python 2.5 or
2.6.

Alternatively, you could look into the pySerial source and find out
what it does.

 

[Gabriel Genellina]

Interesting
So its does the same thing as with right ?
Automatic closing and finalizing stuff.

No, it does not. Either use `with` o a `try...finally` block.

 

[Diez B. Roggisch]

With all respect but why do people in general avoid the question when
they do not know something?
I appreciate the answer and its a valid solution, never the less
useless in the answer I seek.

I hope I did not offend anybody. When you want to do something about
the future, you have to take the hard way, so others can take the easy
way. If somebody is stuck going the hard way, to clear it for others,
you can not expect them to be satisfied with a easy answer.

But your path is clearly *not* the future. It would be fixing win32 and
pyserial, if anything.

And the suggestion to change the set of tools if there is no reason to
stick to the ones you use now certainly is a valid answer. Especially if
they do know that these solutions work.

Diez

 

[Lawrence D'Oliveiro]

In message <91e09eaf-5a25-4a6b-b131-

So its does the same thing as with right ?

Why do you need a with?

Automatic closing and finalizing stuff.

All Python objects are reference-counted. Once the file object becomes
inaccessible, it is automatically closed. Simple.

Note: I wouldn't do this for files open for writing. I'd prefer to make sure
those were properly flushed and closed, if only to catch any I/O errors.

 

[Steven D'Aprano]

All Python objects are reference-counted. Once the file object becomes
inaccessible, it is automatically closed. Simple.

If only it were so simple.

Firstly, what you describe is an implementation detail of CPython, not
Python the language. Jython does not close files as soon as they become
inaccessible, and IronPython and CLPython may not.

Secondly, even in CPython things may not be so simple. Not all file-like
objects are built-in file objects.
.... pass
....Traceback (most recent call last):
File "<stdin>", line 1, in <module>
OSError: [Errno 9] Bad file descriptor

My file-like object works just like the built-in file object, but now I
can do this:
'hello'

And lo and behold, the file is *not* automatically closed when f becomes
inaccessible. I don't believe the garbage collector will free that file
descriptor, possibly not even when Python exists. But watch this:
.... n = f.fileno()
.... f.attr = f # make a reference cycle
....Traceback (most recent call last):
File "<stdin>", line 1, in <module>
OSError: [Errno 9] Bad file descriptor


The with statement guarantees[1] closing, even if there are other
references to the file object elsewhere.






[1] Guarantee void if the file system can't actually close the file for
some reason.

 

[Terry Reedy]

In message <91e09eaf-5a25-4a6b-b131-


Why do you need a with?


All Python objects are reference-counted.

Nope. Only in CPython, and even that could change.

Once the file object becomes
inaccessible, it is automatically closed. Simple.

Even in CPython, that would not be true now is the object became
involved in or became a dependent of a reference cycle.

Note: I wouldn't do this for files open for writing. I'd prefer to make sure
those were properly flushed and closed, if only to catch any I/O errors.

tjr

 

[Lawrence D'Oliveiro]

Firstly, what you describe is an implementation detail of CPython, not
Python the language. Jython does not close files as soon as they become
inaccessible, and IronPython and CLPython may not.

That's a limitation of Java-like virtual machines, which I have no intention
of condonig.

Secondly, even in CPython things may not be so simple. Not all file-like
objects are built-in file objects.

Why is this relevant?

 

[Steven D'Aprano]

That's a limitation of Java-like virtual machines, which I have no
intention of condonig.

You don't have to condone it, but you do have to live with it.

Why is this relevant?

File-like objects might not automatically close themselves.

 

[Lawrence D'Oliveiro]

Nope. Only in CPython, and even that could change.

Why should it?

Even in CPython, that would not be true now is the object became
involved in or became a dependent of a reference cycle.

And how exactly would that happen with a file object?