This is a somehow an update to the thread on pydoc started by Ron.
Since the last entry we took the bull by the horns (so to speak), and
are seriously aiming at delivering something that can qualify as:
- a revision of the module pydoc
- something that will facilitate the inclusion of ideas explored in efforts
like the nice epydoc
- something that is in general easily extensible to answer most of the
need (both regarding the output that is returned, and what are the
capabilities regarding the exploration of the documentation).
We are probably setting the bar a little high, but we hope to get somewhere
at least with the first point thanks to a number of advices on this
list, some of which by pydoc's or ipython's original authors
(beside that, the bar could not be elsewhere since I am not a very
good limbo dancer ;-) ).
There is a sourceforge page for that project, since it lets us work with SVN
without risking to disturb a larger project, but we are ready to have that moved
to the sandbox in the python tree (although it would be neat to wait a
there are more tests).
svn co https://pydoc-r.svn.sourceforge.net/svnroot/pydoc-r pydoc-r
Still, the thought process is not over and we were thinking of having
recorded either in the form of posts on python-dev, or say using the
on the sourceforge page. An example of discussions we had are about
whether we should already name the module pydoc or an other name,
Posting on python-dev would give exposure to what is discussed, but at
the same could be perceived as off-topic until the module is in the
Posting on the sourceforge page would have pretty much opposite points
(no exposure, but no one would feel annoyed)
Any suggestion ?
I've been tracking down an issue with some code sporadically raising
IOError with errno=514 on "time.sleep(1)". time.sleep() is implemented
with the select() system call, and on Linux this is sporadically returning
This is on 2.6.9, though I've heard reports of it happening through 2.6.17,
and my review of the code indicates that 18.104.22.168 (the latest kernel) is
probably also going to act the same.
Now, the header file where ERESTARTNOHAND is defined says that user-space
should never see this errno. Clearly, that's not as true as it could be.
I'm going to ask the LKML for more information about whether this should
make it to user-space, but thought I'd bring it up here as well.
Some options we have:
Do nothing. (I like this one :-)
Catch and ignore 514. (Only on Linux? Far-reaching implications, I
don't like this one).
Use the libc sleep() call for integer time.sleep() values? No guarantee
that libc sleep() doesn't use select, though I've seen indications that
it might use alarm. I haven't looked at the libc source.
Try to make time.sleep() smarter in the face of errnos. Maybe try the
sleep multiple times, check time.time() before and after the sleep to do
multiple sleeps. Could possibly even fail over to using /dev/rtc if
In general I'm reluctant to suggest a Python fix to this, but it's fairly
unexpected for time.sleep() to raise an exception...
I think the net needs some Viagra today. It's just not performing...
-- Mike Loseke, 2000
Sean Reifschneider, Member of Technical Staff <jafo(a)tummy.com>
tummy.com, ltd. - Linux Consulting since 1995: Ask me about High Availability
The other night i was watching a google techtalk about python 3000 and
Guido mentioned some problems with the C standard io library.
In particular he highlighted an issue with switching between reading
and writing without flushing and the fact that it caused serious
errors. Not that i dont think its a good idea to write a new io
library, but I wondered if it was the same problem ive encounted.
It only happens on windows that i know off, but the fix is simple...
Assuming you have a hanlde to the file called "Handle" and a Flush()
method, the following logic for read and write will allow you to
detect and prevent the problem.
Add this to the Read() method before reading takes place:
if ( Handle && (Handle->_flag & _IORW) && (Handle->_flag & (_IOREAD |
_IOWRT)) == _IOWRT )
Handle->_flag |= _IOREAD;
Add this to the Write() method before writing takes place:
if ( Handle && (Handle->_flag & _IORW) && (Handle->_flag & (_IOREAD |
_IOWRT)) == _IOREAD )
Handle->_flag |= _IOWRT;
I've noticed a bunch of changes recently without corresponding items
added to Misc/NEWS. Can everyone update NEWS especially when fixing
bugs or adding new features? If you have made recent checkins, it
would be great if you could go back and update Misc/NEWS if you missed
it the first time.
Forwarded for discussion from http://www.python.org/sf/1633665.
[forwarded from http://bugs.debian.org/327060]
Many types in Python are idempotent, so that int(1) works
as expected, float(2.34)==2.34, ''.join('hello')=='hello'
Why not file()? Currently, file(open(something, 'r')) fails
with "TypeError: coercing to Unicode: need string or buffer, file found."
Semantically, file(fd) should be equivalent to os.fdopen(fd.fileno())
or the proposed file.fromfd() (Jp Calderone, Python-dev, 2003).
You should get another independent
file object that accesses the same file.
What would be gained?
Primarily, it would allow you to derive classes from file more easily.
At present, if you want to derive like so, you're class can only work
when passed a file name or buffer.
def __init__(self, something):
For instance, you have no way of creating a file_with_caching()
object from the file descriptors returned from os.fork().
Also, you have no way of taking a file that is already open,
and creating a file_with_caching() object from it. So,
you can't use classes derived from file() on the standard input
or standard output.
This breaks the nice Linux OS-level definition of a file descriptor.
At the Linux level, you have a nice uniform interface where all
file descriptors are equally good. At the python level, some
are better than others. It's a case where Python unnecessarily
restricts what you can do.
On 11 Jan, 08:22 pm, sluggoster(a)gmail.com wrote:
>On 1/11/07, James Y Knight <foom(a)fuhm.net> wrote:
>> If the goal is really to have Py 3.0 be released later this year,
>There will certainly be demand for an asynchronous server in 3.0,
To flip the question around: there might be a demand for Twisted in 3.0, but will there be a demand for 3.0 in Twisted? It might just be easier for everyone concerned to just continue maintaining 2.x forever. I have yet to see a reason why, other than continued maintenance, 3.0 would be a preferable development platform.
>So the two projects will operate independently, and the 3.0 one may be
>smaller and less ambitious than Twisted. But if the need is there it
>will be written.
It is quite likely that someone else will write some completely different code for python 3.0 that calls select(). I hadn't considered that the goal of 3.0 was to *discover* these people by alienating existing Python developers - that's crafty! If so, though, you'll have to figure out a way to stop Anthony from providing all this compatibility stuff. He might make it too attractive for us to continue development on future versions :).
>How did Perl 4 and Perl 5 handle the situation? I basically waited
>2-3 years after Perl 5 came out, then started programming the new way.
> If it mattered (it didn't), I would have tied my applications
>specifically to Perl 4.
I handled the Perl 4 to 5 transition by dropping Perl and moving to Python, because if I was going to port all my code to another language I wanted to at least port to a better language.
On 10:12 am, mwh(a)python.net wrote:
>For practical reasons (we have enough work to be getting on with) PyPy
>is more-or-less ignoring Python 2.5 at the moment. After funding and
>so on, when there's less pressure, maybe it will seem worth it. Not
I think I know what you mean from previous conversations, but the context of the question makes the answer ambiguous. Are you ignoring 2.5 in favor of 2.4, or 3.0?
On 02:42 am, brett(a)python.org wrote:
>Wrapper around open() that does proper checking of its arguments. I
>will be discussing my security stuff at PyCon if you are attending and
I am both, so I guess I'll see you there :).
On 12:37 am, brett(a)python.org wrote:
>For security reasons I might be asking for file's constructor to be
>removed from the type for Python source code at some point (it can be
>relocated to an extension module if desired). By forcing people to go
>through open() to create a file object you can more easily control
>read/write access to the file system (assuming the proper importation
>of extension modules has been blocked). Not removing the constructor
>allows any code that has been explicitly given a file object but not
>open() to just get the class and call the constructor to open a new
This is a general problem with type access. Secure versions of any type should not allow access to the type period. It is hardly unique to files, and is not limited to constructors either. How do you, e.g., allow a restricted piece of code write access to only a specified area of the filesystem?
More importantly, given the random behavior that open() will be growing (opening sockets? dynamic dispatch on URL scheme???) file() will likely remain a popular way to be sure you are accessing the filesystem.