Re: [Python-Dev] [Python-checkins] cpython: Mention OSError instead of IOError in the docs.

[Andrew Svetlov]

Done in #e5958a4e52ef

On Wed, Dec 19, 2012 at 9:24 AM, Nick Coghlan  wrote:
> On Wed, Dec 19, 2012 at 7:16 AM, andrew.svetlov 
> wrote:
>>
>> http://hg.python.org/cpython/rev/a6ea6f803017
>> changeset:   80934:a6ea6f803017
>> user:Andrew Svetlov 
>> date:Tue Dec 18 23:16:44 2012 +0200
>> summary:
>>   Mention OSError instead of IOError in the docs.
>>
>> files:
>>   Doc/faq/library.rst |  4 ++--
>>   1 files changed, 2 insertions(+), 2 deletions(-)
>>
>>
>> diff --git a/Doc/faq/library.rst b/Doc/faq/library.rst
>> --- a/Doc/faq/library.rst
>> +++ b/Doc/faq/library.rst
>> @@ -209,7 +209,7 @@
>> try:
>> c = sys.stdin.read(1)
>> print("Got character", repr(c))
>> -   except IOError:
>> +   except OSError:
>> pass
>> finally:
>> termios.tcsetattr(fd, termios.TCSAFLUSH, oldterm)
>> @@ -222,7 +222,7 @@
>> :func:`termios.tcsetattr` turns off stdin's echoing and disables
>> canonical
>> mode.  :func:`fcntl.fnctl` is used to obtain stdin's file descriptor
>> flags
>> and modify them for non-blocking mode.  Since reading stdin when it is
>> empty
>> -   results in an :exc:`IOError`, this error is caught and ignored.
>> +   results in an :exc:`OSError`, this error is caught and ignored.
>
>
> With any of these changes in the docs, please don't forget to include
> appropriate "versionchanged" directives. Many people using the Python 3 docs
> at "docs.python.org/3/" will still be on Python 3.2, and thus relying on the
> presence of such directives to let them know that while the various
> OS-related exception names are now just aliases for OSError in 3.3+, the
> distinctions still matter in 3.2.
>
> Cheers,
> Nick.
>
>
> --
> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
> ___
> Python-checkins mailing list
> python-check...@python.org
> http://mail.python.org/mailman/listinfo/python-checkins
>



-- 
Thanks,
Andrew Svetlov
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] hg annotate is broken on hg.python.org

[anatoly techtonik]

On Mon, Dec 10, 2012 at 4:39 AM, Chris Jerdonek wrote:

> On Sun, Dec 9, 2012 at 3:30 PM, anatoly techtonik 
> wrote:
> > Just to let you know that annotate in hgweb is broken for Python sources.
> >
> >
> http://hg.python.org/cpython/annotate/692be1f9fa1d/Lib/distutils/tests/test_register.py
>
> Maybe I'm missing something, but what's broken about it?


There was broken html markup for some revisions. Everything is ok now. Next
time I'll try to post a screenshot.

Also, in my
> experience it's okay to file issues about hg.python.org on the main
> tracker if you suspect something isn't right or you think should be
> improved.
>

I bet such issues will be closed as 'invalid', so there is no place for
them there as explained in this request:
http://psf.upfronthosting.co.za/roundup/meta/issue340
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3145 (With Contents)

[anatoly techtonik]

On Sun, Dec 9, 2012 at 7:14 AM, Glyph  wrote:

> On Dec 7, 2012, at 5:10 PM, anatoly techtonik  wrote:
>
> What about reading from other file descriptors?  subprocess.Popen allows
>> arbitrary file descriptors to be used.  Is there any provision here for
>> reading and writing non-blocking from or to those?
>
>
> On Windows it is WriteFile/ReadFile and PeekNamedPipe. On Linux it is
> select. Of course a test is needed, but why it should not just work?
>
>
> This is exactly why the provision needs to be made explicitly.
>
> On Windows it is WriteFile and ReadFile and PeekNamedPipe - unless the
> handle is a socket in which case it needs to be WSARecv.  Or maybe it's
> some other weird thing - like, maybe a mailslot - and you need to call a
> different API.
>

IIRC on Windows there is no socket descriptor that can be used as a file
descriptor. Seems reasonable to limit the implementation to standard file
descriptors in this platform.

On *nix it really shouldn't be select.  select cannot wait upon a file
> descriptor whose *value* is greater than FD_SETSIZE, which means it sets
> a hard (and small) limit on the number of things that a process which wants
> to use this facility can be doing.
>

I didn't know that. Should a note be added to
http://docs.python.org/2/library/select ?
I also thought that poll acts like, well, a polling function - eating 100%
CPU while looping over inputs over and over checking if there is something
to react to.


> On the other hand, if you hard-code another arbitrary limit like this into
> the stdlib subprocess module, it will just be another great reason why
> Twisted's spawnProcess is the best and everyone should use it instead, so
> be my guest ;-).
>

spawnProcess requires a reactor. This PEP is an alternative for the
proponents of green energy. =)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3145 (With Contents)

[anatoly techtonik]

On Sun, Dec 9, 2012 at 7:17 AM, Gregory P. Smith  wrote:

> I'm really not sure what this PEP is trying to get at given that it
> contains no examples and sounds from the descriptions to be adding a
> complicated api on top of something that already, IMNSHO, has too much it
> (subprocess.Popen).
>
> Regardless, any user can use the stdout/err/in file objects with their own
> code that handles them asynchronously (yes that can be painful but that is
> what is required for _any_ socket or pipe I/O you don't want to block on).
>

And how to use stdout/stderr/in asynchronously in cross-platform manner?
IIUC the problem is that every read is blocking.


> It *sounds* to me like this entire PEP could be written and released as a
> third party module on PyPI that offers a subprocess.Popen subclass adding
> some more convenient non-blocking APIs.  That's where I'd start if I were
> interested in this as a future feature.
>

I've rewritten the PEP based on how do I understand the code. I don't know
how to update it and how to comply with open documentation license, so I
just attach it and add PEPs list to CC. Me too has a feeling that the PEP
should be stripped of additional high level API until low level
functionality is well understood and accepted.

-- 
anatoly t.


pep-3145.diff
Description: Binary data
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

[Ben Finney]

Terry Reedy  writes:

> On 12/12/2012 10:56 AM, Lennart Regebro wrote:
>
> >> It seems like calling get_timezone() with an unknown timezone
> >> should just throw ValueError, not necessarily some custom
> >> Exception?
> >
> > That could very well be. What are others opinions on this?
>
> ValueError. That is what it is. Nothing special here.

I think it's useful to have this raise a custom exception
UnknownTimeZoneError, subclassed from ValueError. That satisfies those
(including me!) who think it should be a ValueError, while also making
the exception more specific so it can be handled apart from other
possible ValueError causes.

In short: +1 to ‘class UnknownTimeZoneError(ValueError)’.

-- 
 \“Members of the general public commonly find copyright rules |
  `\implausible, and simply disbelieve them.” —Jessica Litman, |
_o__)  _Digital Copyright_ |
Ben Finney

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3145 (With Contents)

[Glyph]

On Dec 19, 2012, at 2:14 PM, anatoly techtonik  wrote:

> On Sun, Dec 9, 2012 at 7:14 AM, Glyph  wrote:
> On Dec 7, 2012, at 5:10 PM, anatoly techtonik  wrote:
> 
>> What about reading from other file descriptors?  subprocess.Popen allows 
>> arbitrary file descriptors to be used.  Is there any provision here for 
>> reading and writing non-blocking from or to those?
>> 
>> On Windows it is WriteFile/ReadFile and PeekNamedPipe. On Linux it is 
>> select. Of course a test is needed, but why it should not just work?
> 
> 
> This is exactly why the provision needs to be made explicitly.
> 
> On Windows it is WriteFile and ReadFile and PeekNamedPipe - unless the handle 
> is a socket in which case it needs to be WSARecv.  Or maybe it's some other 
> weird thing - like, maybe a mailslot - and you need to call a different API.
> 
> IIRC on Windows there is no socket descriptor that can be used as a file 
> descriptor. Seems reasonable to limit the implementation to standard file 
> descriptors in this platform.

Via the documentation of ReadFile: 


hFile [in]
A handle to the device (for example, a file, file stream, physical disk, 
volume, console buffer, tape drive, socket, communications resource, mailslot, 
or pipe). (...) For asynchronous read operations, hFile can be any handle that 
is opened with the FILE_FLAG_OVERLAPPED flag by the CreateFilefunction, or a 
socket handle returned by the socket or accept function.

(emphasis mine).

So, you can treat sockets as regular files in some contexts, and not in others. 
 Of course there are other reasons to use WSARecv instead of ReadFile 
sometimes, which is why there are multiple functions.

> On *nix it really shouldn't be select.  select cannot wait upon a file 
> descriptor whose value is greater than FD_SETSIZE, which means it sets a hard 
> (and small) limit on the number of things that a process which wants to use 
> this facility can be doing.
> 
> I didn't know that. Should a note be added to 
> http://docs.python.org/2/library/select ?

The note that should be added there is simply "you should know how the select 
system call works in C if you want to use this module".

> I also thought that poll acts like, well, a polling function - eating 100% 
> CPU while looping over inputs over and over checking if there is something to 
> react to.

Nope.  Admittedly, the naming is slightly misleading.

> On the other hand, if you hard-code another arbitrary limit like this into 
> the stdlib subprocess module, it will just be another great reason why 
> Twisted's spawnProcess is the best and everyone should use it instead, so be 
> my guest ;-).
> 
> spawnProcess requires a reactor. This PEP is an alternative for the 
> proponents of green energy. =)

Do you know what happens when you take something that is supposed to be 
happening inside a reactor, and then move it outside a reactor?  It's not 
called "green energy", it's called "a bomb" ;-).

-glyph

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3145 (With Contents)

[exarkun]

Please stop copying me on this thread.

Thanks,
Jean-Paul
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3145 (With Contents)

[anatoly techtonik]

On Thu, Dec 20, 2012 at 3:47 AM, Glyph  wrote:

>
> On Dec 19, 2012, at 2:14 PM, anatoly techtonik 
> wrote:
>
> On Sun, Dec 9, 2012 at 7:14 AM, Glyph  wrote:
>
>> On Dec 7, 2012, at 5:10 PM, anatoly techtonik 
>> wrote:
>>
>> What about reading from other file descriptors?  subprocess.Popen allows
>>> arbitrary file descriptors to be used.  Is there any provision here for
>>> reading and writing non-blocking from or to those?
>>
>>
>> On Windows it is WriteFile/ReadFile and PeekNamedPipe. On Linux it is
>> select. Of course a test is needed, but why it should not just work?
>>
>>
>> This is exactly why the provision needs to be made explicitly.
>>
>> On Windows it is WriteFile and ReadFile and PeekNamedPipe - unless the
>> handle is a socket in which case it needs to be WSARecv.  Or maybe it's
>> some other weird thing - like, maybe a mailslot - and you need to call a
>> different API.
>>
>
> IIRC on Windows there is no socket descriptor that can be used as a file
> descriptor. Seems reasonable to limit the implementation to standard file
> descriptors in this platform.
>
>
> Via the documentation of ReadFile: <
> http://msdn.microsoft.com/en-us/library/windows/desktop/aa365467(v=vs.85).aspx
> >
>
> hFile [in]
>
> A handle to the device (for example, a file, file stream, physical disk,
> volume, console buffer, tape drive, *socket*, communications resource,
> mailslot, or pipe). (...) For asynchronous read operations, hFile can be
> any handle that is opened with the FILE_FLAG_OVERLAPPED flag by
> the CreateFilefunction, or a *socket handle returned by
> the socket or accept function*.
>
>
> (emphasis mine).
>
> So, you can treat sockets as regular files in some contexts, and not in
> others.  Of course there are other reasons to use WSARecv instead of
> ReadFile sometimes, which is why there are multiple functions.
>

handle != descriptor, and Python documentation explicitly says that socket
descriptor is limited, so it's ok to continue not supporting socket
descriptors for pipes.
http://docs.python.org/2/library/socket.html#socket.socket.fileno


>  On *nix it really shouldn't be select.  select cannot wait upon a file
>> descriptor whose *value* is greater than FD_SETSIZE, which means it sets
>> a hard (and small) limit on the number of things that a process which wants
>> to use this facility can be doing.
>>
>
> I didn't know that. Should a note be added to
> http://docs.python.org/2/library/select ?
>
>
> The note that should be added there is simply "you should know how the
> select system call works in C if you want to use this module".
>

Why spreading FUD if it is possible to define a good entrypoint for those
who want to learn, but don't have enough time? Why not to say directly that
select interface is outdated?

>  On the other hand, if you hard-code another arbitrary limit like this
>> into the stdlib subprocess module, it will just be another great reason why
>> Twisted's spawnProcess is the best and everyone should use it instead, so
>> be my guest ;-).
>>
>
> spawnProcess requires a reactor. This PEP is an alternative for the
> proponents of green energy. =)
>
>
> Do you know what happens when you take something that is supposed to be
> happening *inside* a reactor, and then move it *outside* a reactor?  It's
> not called "green energy", it's called "a bomb" ;-).
>

The biggest complain about nuclear physics is that to understand what's
going on it should have been gone 3D long ago. =) I think Twisted needs to
organize competition on the best visualization of underlying concepts. It
will help people grasp the concepts behind and different problems much
faster (as well as gain an ability to compare different reactors).
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com