Re: [Python-Dev] Dealing with a desired change to warnings.showwarning()
Brett Cannon python.org> writes: > As http://bugs.python.org/issue2705 points out, though, since the > function has been documented as being allowed to be overridden, this > potentially breaks existing showwarning() implementations. That means > something needs to change. > > One option is to introduce a new function. But what to name it? > show_warning()? That small of a name change seems like asking for > trouble, but showwarning_ex() just seems wrong to use in Python code. But then what happens if a library overrides one of the callbacks and another library overrides the other one? Fixing the original "problem" seems to introduce other hairier ones. As a Benjamin pointed out in the bug comments, the sane solution would be to keep an unique callback and mention the small change in the release notes. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] enhanced ioctl?
IIUC, current ioctl is not capable of handling arbitrary argument types.
This code will allow any arg type (such as structures with pointers to
embedded structures).
The code for _IOC is taken from linux and might not be portable.
from ctypes import *
libc = CDLL ('/lib/libc.so.6')
#print libc.ioctl
def set_ioctl_argtype (arg_type):
libc.ioctl.argtypes = (c_int, c_int, arg_type)
_IOC_WRITE = 0x1
_IOC_NRBITS=8
_IOC_TYPEBITS= 8
_IOC_SIZEBITS= 14
_IOC_DIRBITS= 2
_IOC_NRSHIFT= 0
_IOC_TYPESHIFT= (_IOC_NRSHIFT+_IOC_NRBITS)
_IOC_SIZESHIFT= (_IOC_TYPESHIFT+_IOC_TYPEBITS)
_IOC_DIRSHIFT= (_IOC_SIZESHIFT+_IOC_SIZEBITS)
def _IOC (dir, type, nr, size):
return (((dir) << _IOC_DIRSHIFT) | \
((type) << _IOC_TYPESHIFT) | \
((nr) << _IOC_NRSHIFT) | \
((size) << _IOC_SIZESHIFT))
def ioctl (fd, request, args):
return libc.ioctl (fd, request, args)
---
Example usage:
from ioctl import *
set_ioctl_argtype (POINTER (eos_dl_args_t))
EOS_IOC_MAGIC = 0xF4
request = _IOC(_IOC_WRITE, EOS_IOC_MAGIC, 0x00, 0) # ignore size
err = ioctl (eos_file.fileno(), request, args)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] enhanced ioctl?
On Mon, Apr 28, 2008 at 7:02 AM, Neal Becker <[EMAIL PROTECTED]> wrote: > IIUC, current ioctl is not capable of handling arbitrary argument types. > This code will allow any arg type (such as structures with pointers to > embedded structures). Please submit this patch to the tracker. -- Cheers, Benjamin Peterson ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] enhanced ioctl?
Benjamin Peterson wrote: > On Mon, Apr 28, 2008 at 7:02 AM, Neal Becker <[EMAIL PROTECTED]> wrote: >> IIUC, current ioctl is not capable of handling arbitrary argument types. >> This code will allow any arg type (such as structures with pointers to >> embedded structures). > > Please submit this patch to the tracker. > > issue 2712 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Warn about mktemp once again?
Have we documented the alternatives well enough? In most cases NamedTemporaryFile will work, but sometimes you will have to create a directory and pick names therein. Doing that so that it will always be cleaned up properly is a bit of a trick, involving an isdir() check and a shutil.rmtree() call. On Sun, Apr 27, 2008 at 3:33 PM, <[EMAIL PROTECTED]> wrote: > Back in r29829, Guido commented out the security hole warning for > tempfile.mktemp: > > r29829 | gvanrossum | 2002-11-22 09:56:29 -0600 (Fri, 22 Nov 2002) | 3 > lines > > Comment out the warnings about mktemp(). These are too annoying, and > often unavoidable. > > Any thought about whether this warning should be restored? We're 5+ years > later. Hopefully many uses of mktemp have been removed. If we're not going > to restore the warning perhaps the commented code should just be deleted. > > Skip > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Warn about mktemp once again?
Guido> Have we documented the alternatives well enough? I suppose we could document explicitly how to use mkstemp() in place of mktemp(), but the difference in return value is fairly modest: >>> tempfile.mktemp() '/var/folders/5q/5qTPn6xq2RaWqk+1Ytw3-U+++TI/-Tmp-/tmpV_5OLi' >>> tempfile.mkstemp() (3, '/var/folders/5q/5qTPn6xq2RaWqk+1Ytw3-U+++TI/-Tmp-/tmpmS7K4T') and the argument list is quite similar as well: >>> help(tempfile.mktemp) Help on function mktemp in module tempfile: mktemp(suffix='', prefix='tmp', dir=None) ... >>> help(tempfile.mkstemp) Help on function mkstemp in module tempfile: mkstemp(suffix='', prefix='tmp', dir=None, text=False) ... Guido> In most cases NamedTemporaryFile will work, ... It's API seems to be a bit farther from the mktemp API than that of mkstemp. Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Warn about mktemp once again?
IMO mkstemp() is a major pain because you have to use raw file descriptors on the return value. I'd much rather recommend [Named]TemporaryFile which return streams. On Mon, Apr 28, 2008 at 4:17 PM, <[EMAIL PROTECTED]> wrote: > > Guido> Have we documented the alternatives well enough? > > I suppose we could document explicitly how to use mkstemp() in place of > mktemp(), but the difference in return value is fairly modest: > > >>> tempfile.mktemp() > '/var/folders/5q/5qTPn6xq2RaWqk+1Ytw3-U+++TI/-Tmp-/tmpV_5OLi' > >>> tempfile.mkstemp() > (3, '/var/folders/5q/5qTPn6xq2RaWqk+1Ytw3-U+++TI/-Tmp-/tmpmS7K4T') > > and the argument list is quite similar as well: > > >>> help(tempfile.mktemp) > Help on function mktemp in module tempfile: > > mktemp(suffix='', prefix='tmp', dir=None) > ... > >>> help(tempfile.mkstemp) > Help on function mkstemp in module tempfile: > > mkstemp(suffix='', prefix='tmp', dir=None, text=False) > ... > > Guido> In most cases NamedTemporaryFile will work, ... > > It's API seems to be a bit farther from the mktemp API than that of mkstemp. > > Skip > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Warn about mktemp once again?
Guido> IMO mkstemp() is a major pain because you have to use raw file Guido> descriptors on the return value. I'd much rather recommend Guido> [Named]TemporaryFile which return streams. Why not: fd, fname = tempfile.mkstemp() f = os.fdopen(fd) Seems fairly straightforward to me. Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Warn about mktemp once again?
I'd be much happier if there was a standard API in tempfile.py that did that for you, so you wouldn't have to understand fdopen(). (Your example is wrong BTW, the open mode would have to be something like 'rb+' or 'wb+'.) On Mon, Apr 28, 2008 at 4:35 PM, <[EMAIL PROTECTED]> wrote: > > Guido> IMO mkstemp() is a major pain because you have to use raw file > Guido> descriptors on the return value. I'd much rather recommend > Guido> [Named]TemporaryFile which return streams. > > Why not: > > fd, fname = tempfile.mkstemp() > f = os.fdopen(fd) > > Seems fairly straightforward to me. > > Skip > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Warn about mktemp once again?
Guido> I'd be much happier if there was a standard API in tempfile.py Guido> that did that for you, so you wouldn't have to understand Guido> fdopen(). That can be arranged: http://bugs.python.org/issue2717 Guido> (Your example is wrong BTW, the open mode would have to be Guido> something like 'rb+' or 'wb+'.) I'm not disagreeing with you, but it seems odd that os.fdopen doesn't simply obey the mode of the file descriptor it receives as its argument (e.g., normally opened with "w+b"). Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Warn about mktemp once again?
[EMAIL PROTECTED] wrote: Guido> Have we documented the alternatives well enough? I suppose we could document explicitly how to use mkstemp() in place of mktemp(), but the difference in return value is fairly modest: I'd like to see a variation of mkstemp() that returns a file object instead of a file descriptor, since that's what you really want most of the time. At least I always end up calling fdopen on it. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Warn about mktemp once again?
On Tue, 29 Apr 2008 17:15:11 +1200, Greg Ewing wrote: > [EMAIL PROTECTED] wrote: >> Guido> Have we documented the alternatives well enough? >> >> I suppose we could document explicitly how to use mkstemp() in place of >> mktemp(), but the difference in return value is fairly modest: > > I'd like to see a variation of mkstemp() that returns a file object > instead of a file descriptor, since that's what you really want most of > the time. At least I always end up calling fdopen on it. Same here. In fact, is there a good reason to have mkstemp() return the fd (except backward compatibility)? -- Giovanni Bajo Develer S.r.l. http://www.develer.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Warn about mktemp once again?
Guido van Rossum wrote: IMO mkstemp() is a major pain because you have to use raw file descriptors on the return value. I'd much rather recommend [Named]TemporaryFile which return streams. The problem with NamedTemporaryFile is that it deletes the file as soon as you close it, which makes the named-ness of it rather useless, as far as I can see. If you don't want that to happen, you have to use mkstemp. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Warn about mktemp once again?
[EMAIL PROTECTED] wrote: I'm not disagreeing with you, but it seems odd that os.fdopen doesn't simply obey the mode of the file descriptor it receives as its argument I'm not even sure if it's possible to find out the mode that a file descriptor was opened with -- is it? Certainly there's no way to tell whether you want it treated as binary, so at least that much of the mode needs to be specified. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Warn about mktemp once again?
Greg Ewing wrote:
[EMAIL PROTECTED] wrote:
I'm not disagreeing with you, but it seems odd that os.fdopen doesn't
simply
obey the mode of the file descriptor it receives as its argument
I'm not even sure if it's possible to find out the mode
that a file descriptor was opened with -- is it?
int mode = fcntl(fd, F_GETFL);
switch(mode) {
case O_RDONLY: ...
case O_WRONLY: ...
case O_RDWR: ...
}
Certainly there's no way to tell whether you want it
treated as binary, so at least that much of the mode
needs to be specified.
Agreed.
-Scott
--
Scott Dial
[EMAIL PROTECTED]
[EMAIL PROTECTED]
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Warn about mktemp once again?
> Same here. In fact, is there a good reason to have mkstemp() return the > fd (except backward compatibility)? Except for backwards compatibility: is there a good reason to keep os.mkstemp at all? The tradition is that all APIs in os expose the "system" calls as-is, i.e. they don't try to adjust the result values at all. This has the advantage that the caller can use their system's man page to find out all details, and trust that the Python wrapper does exactly the same. For mkstemp, there are two special issues: the C API modifies the string parameter, which cannot be exposed to Python as-is (hence the two result values), and it isn't a system call (at least not on POSIX), so it doesn't really need to be exposed, except perhaps to also provide this on non-POSIX systems where a regular POSIX implementation (in Python) would fail. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
