[issue1436] logging.config.fileConfig, NameError: name 'RotatingFileHandler' is not defined
sebastian added the comment: thank you very much... but: [...] the class and arguments are evaluated using the logging package's namespace. [...] does this mean, it is not possible to use user-defined handlers, naturally residing outside python's class library (and logging package), when applying fileConfig()? __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1436> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8787] PySys_Get
New submission from Sebastian : Hi all, I found a bug in the exception handler. When I start the app without any arguments I get an output I expect: __main__:2:DeprecationWarning: Deprecated function. When I run the app with arguments, the arguments are printed somehow in the exception output: -test=HALLO:1:DeprecationWarning: Deprecated function Can anyone please confirm? Bye, Seb [code] #include "Python/Python.h" static PyObject *testfunc(PyObject *self, PyObject *args, PyObject *keywords) { PyErr_Warn(PyExc_DeprecationWarning, "Deprecated function."); Py_RETURN_NONE; } static PyMethodDef testmod[] = { {"testfunc", (PyCFunction)testfunc, METH_NOARGS, "Prints out a text to stdout."}, {NULL} }; int main (int argc, char **argv) { Py_Initialize(); PySys_SetArgv(argc, argv); PyObject *mod = Py_InitModule4("testmod", testmod, "", NULL, PYTHON_API_VERSION); if(mod == NULL) return -1; PyRun_SimpleString( "import testmod\n" "testmod.testfunc()"); Py_Finalize(); return 0; } [/code] -- components: None messages: 106306 nosy: Sebastian priority: normal severity: normal status: open title: PySys_Get type: behavior versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue8787> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8787] PySys_Get
Sebastian added the comment: Could anyone please correct the title? Thx :) -- ___ Python tracker <http://bugs.python.org/issue8787> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8787] warnings inside PyRun_SimpleString() display argv[1]
Sebastian added the comment: Oh, damn. I really forgot the argv filename thing. Nevermind :) But back to topic. __file__ might be not the best solution for that. What does Python when embedded, and __file__ is not set? That can happen when the source of your code is not a file (multiline textbox, ...) I would simply follow the way how the traceback solves this. Just print out the filename passed to: Py_CompileStringFlags(const char *str, const char *filename, int start, PyCompilerFlags *flags) PyRun_SimpleFileExFlags(FILE *fp, const char *filename, int closeit, PyCompilerFlags *flags) [...] -- ___ Python tracker <http://bugs.python.org/issue8787> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8787] warnings inside PyRun_SimpleString() display argv[1]
Sebastian added the comment: attached a patch for this issue now. Now it first uses the name of the script, instead of __file__. -- keywords: +patch Added file: http://bugs.python.org/file17461/_warnings.c.patch ___ Python tracker <http://bugs.python.org/issue8787> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8787] warnings inside PyRun_SimpleString() display argv[1]
Sebastian added the comment: any news on this? -- ___ Python tracker <http://bugs.python.org/issue8787> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4028] Problem compiling the multiprocessing module on sunos5
Sebastian added the comment: Yes, it is. I encountered it at Solaris9 with python 2.7.1. -- nosy: +SebaM6 ___ Python tracker <http://bugs.python.org/issue4028> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2736] datetime needs an "epoch" method
Changes by Sebastian Rittau : -- nosy: -srittau ___ Python tracker <http://bugs.python.org/issue2736> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1699259] replacing char* with const char* in sysmodule.c/.h
Sebastian Ramacher added the comment: Any news on that? -- ___ Python tracker <http://bugs.python.org/issue1699259> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1699259] replacing char* with const char* in sysmodule.c/.h
Sebastian Ramacher added the comment: Since the patches are not applicable to Py 3.x and Py 2.7 is stable I'm closing this bug. -- resolution: -> out of date status: open -> closed ___ Python tracker <http://bugs.python.org/issue1699259> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12505] python interpreter not handle wildards properly
Sebastian Ramacher added the comment: That is definitely not python's job. That is the duty of your shell and python should never expand that. And it would lead to platform specific behavior as one can see with the following script: import sys import subprocess if __name__ == "__main__": if len(sys.argv) == 1: subprocess.Popen([sys.executable, __file__, "foo", "*"]) else: print sys.argv[1:] With setargv.obj the argument would be expanded on Windows whereas on any other platform it just prints [foo, *]. -- nosy: +sebastinas ___ Python tracker <http://bugs.python.org/issue12505> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4028] Problem compiling the multiprocessing module on sunos5
Sebastian M added the comment: One more thing, as I tried to rebuild whole python I've encountered on following problem: building '_multiprocessing' extension gcc -fPIC -fno-strict-aliasing -g -O2 -DNDEBUG -DHAVE_SEM_OPEN=1 -DHAVE_FD_TRANSFER=1 -DHAVE_SEM_TIMEDWAIT=0 -IModules/_multiprocessing -I. -IInclude -I./Include -I/usr/local/include -I/home/malyska/bld/python_sol10/Python-2.7.1/Include -I/home/malyska/bld/python_sol10/Python-2.7.1 -c /home/malyska/bld/python_sol10/Python-2.7.1/Modules/_multiprocessing/multiprocessing.c -o build/temp.solaris-2.9-sun4u-2.7/home/malyska/bld/python_sol10/Python-2.7.1/Modules/_multiprocessing/multiprocessing.o gcc -fPIC -fno-strict-aliasing -g -O2 -DNDEBUG -DHAVE_SEM_OPEN=1 -DHAVE_FD_TRANSFER=1 -DHAVE_SEM_TIMEDWAIT=0 -IModules/_multiprocessing -I. -IInclude -I./Include -I/usr/local/include -I/home/malyska/bld/python_sol10/Python-2.7.1/Include -I/home/malyska/bld/python_sol10/Python-2.7.1 -c /home/malyska/bld/python_sol10/Python-2.7.1/Modules/_multiprocessing/socket_connection.c -o build/temp.solaris-2.9-sun4u-2.7/home/malyska/bld/python_sol10/Python-2.7.1/Modules/_multiprocessing/socket_connection.o gcc -fPIC -fno-strict-aliasing -g -O2 -DNDEBUG -DHAVE_SEM_OPEN=1 -DHAVE_FD_TRANSFER=1 -DHAVE_SEM_TIMEDWAIT=0 -IModules/_multiprocessing -I. -IInclude -I./Include -I/usr/local/include -I/home/malyska/bld/python_sol10/Python-2.7.1/Include -I/home/malyska/bld/python_sol10/Python-2.7.1 -c /home/malyska/bld/python_sol10/Python-2.7.1/Modules/_multiprocessing/semaphore.c -o build/temp.solaris-2.9-sun4u-2.7/home/malyska/bld/python_sol10/Python-2.7.1/Modules/_multiprocessing/semaphore.o gcc -shared build/temp.solaris-2.9-sun4u-2.7/home/malyska/bld/python_sol10/Python-2.7.1/Modules/_multiprocessing/multiprocessing.o build/temp.solaris-2.9-sun4u-2.7/home/malyska/bld/python_sol10/Python-2.7.1/Modules/_multiprocessing/socket_connection.o build/temp.solaris-2.9-sun4u-2.7/home/malyska/bld/python_sol10/Python-2.7.1/Modules/_multiprocessing/semaphore.o -L/home/malyska/bld/python_sol10/install/lib -L/usr/local/lib -o build/lib.solaris-2.9-sun4u-2.7/_multiprocessing.so *** WARNING: renaming "_multiprocessing" since importing it failed: ld.so.1: python: fatal: relocation error: file build/lib.solaris-2.9-sun4u-2.7/_multiprocessing.so: symbol sem_timedwait: referenced symbol not found so I had to commented out HAVE_SEM_TIMEDWAIT from setup.py, see: elif platform.startswith('sunos5'): macros = dict( HAVE_SEM_OPEN=1, HAVE_FD_TRANSFER=1 ) #HAVE_SEM_TIMEDWAIT=0, libraries = ['rt'] thanks -- ___ Python tracker <http://bugs.python.org/issue4028> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10467] io.BytesIO.readinto() segfaults when used on BytesIO object seeked beyond end.
New submission from Sebastian Hagen : io.BytesIO().readinto() does not correctly handle the case of being called on a BytesIO object that has been seeked past the end of its data. It consequently ends up reading into unallocated memory, and (typically?) segfaulting if used in this manner. I've confirmed that this bug exists in the same fashion in 2.6, 2.7, 3.0, 3.1 and 3.2; the following demonstration code works on all of these. Demonstration: >>> import io; b = io.BytesIO(b'bytes'); b.seek(42); b.readinto(bytearray(1)) 42 Segmentation fault I'm attaching a simple patch against r32a3:85355 that fixes this problem. -- components: IO files: bio_readinto_1.patch keywords: patch messages: 121618 nosy: sh priority: normal severity: normal status: open title: io.BytesIO.readinto() segfaults when used on BytesIO object seeked beyond end. type: crash versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2 Added file: http://bugs.python.org/file19656/bio_readinto_1.patch ___ Python tracker <http://bugs.python.org/issue10467> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11024] imaplib: Time2Internaldate() returns localized strings
New submission from Sebastian Spaeth : imaplib's Time2Internaldate returns invalid (as localized) INTERNALDATE strings. Appending a message with such a time string leads to a: 19 BAD Command Argument Error. 11 (for MS Exchange IMAP servers) it returned "26-led-2011 18:23:44 +0100", however: http://tools.ietf.org/html/rfc2060.html defines: date_month ::= "Jan" / "Feb" / "Mar" / "Apr" / "May" / "Jun" / "Jul" / "Aug" / "Sep" / "Oct" / "Nov" / "Dec" so it expects an English date format. imaplib's Time2Internaldate uses time.strftime() to create the final string which uses the current locale, returning things such as: "26-led-2011 18:23:44 +0100" rather than "26-Jan-2011 18:23:44 +0100". For the right thing to do, we would need to set locale.setlocale(locale.LC_TIME, '') to get English formatting or we would need to use some home-grown parser that hardcodes the proper terms. -- components: Library (Lib) messages: 127186 nosy: spaetz priority: normal severity: normal status: open title: imaplib: Time2Internaldate() returns localized strings type: behavior versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue11024> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11024] imaplib: Time2Internaldate() returns localized strings
Sebastian Spaeth added the comment: P.S. To replicate this in ipython: import locale, imaplib locale.setlocale(locale.LC_ALL,'de_CH.utf8') imaplib.Time2Internaldate(220254431) Out[1]: '"24-Dez-1976 06:47:11 +0100"' (Note the German 'Dez' rather than 'Dec') -- ___ Python tracker <http://bugs.python.org/issue11024> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11024] imaplib: Time2Internaldate() returns localized strings
Sebastian Spaeth added the comment: CC'ing lavajoe as he seemed to be busy with some of imaplib's Date stuff the last couple of days. -- nosy: +lavajoe ___ Python tracker <http://bugs.python.org/issue11024> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11024] imaplib: Time2Internaldate() returns localized strings
Sebastian Spaeth added the comment: I think I found the issue he mentioned, however it was about the functions taking the local time (rather than UTC), which is fine. The problem is that Time2Internaldate is used for every .append() operation internally, producing invalid dates which are handed to the IMAP server. So in most cases, the IMAP server will silently ignore the time and use the current time (as per IMAP RFC) or it will complain and barf out (as the MS Exchange server rightly does. So this is more than just an inconvenience, it outright prevents intenational users from APPENDing new messages to a server (or silently bodges the message date) as there is no way around using that function... Sorry if this sounds like whining :-) I don't even have a patch handy... -- ___ Python tracker <http://bugs.python.org/issue11024> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11024] imaplib: Time2Internaldate() returns localized strings
Sebastian Spaeth added the comment: > Added file: imaplib_Time2Internaldate_locale_fix.patch The patch looks very good to me and works. I agree that we should be returning a bytearray but this is should not be part of this issue. For all that it's worth: Signed-off-by: Sebastian Spaeth -- ___ Python tracker <http://bugs.python.org/issue11024> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15566] tarfile.TarInfo.frombuf documentation is out of date
New submission from Sebastian Ramacher: tarfile.TarInfo.frombuf has gained two more parameters: encoding and errors. The documentation of frombuf claims that the only parameter is buf, which is not true anymore. -- assignee: docs@python components: Documentation messages: 167553 nosy: docs@python, sebastinas priority: normal severity: normal status: open title: tarfile.TarInfo.frombuf documentation is out of date versions: Python 3.2, Python 3.3 ___ Python tracker <http://bugs.python.org/issue15566> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8800] add threading.RWLock
Sebastian Noack added the comment: I would love to see a reader/writer lock implementation shipped with Python's threading (and multiprocessing) module. But I have some issues with the patch: 1. I would avoid the terms 'read' and 'write' as those terms are referring just to one of many use cases. A better and more generic name would be shared and exclusive lock. 2. If we add a new synchronization primitive to the threading module we really should add it also to the multiprocessing module, for consistency and to keep switching between threading and multiprocessing as easy as it is right now. 3. The methods rdlock() and wrlock() might even block if you call them with blocking=False. That's because of they acquire the internal lock in a blocking fashion before they would return False. 4. As Antoine already pointed out, it is a bad idea to make acquiring the exclusive (write) lock, the default behavior. That clearly violates the Zen of Python, since explicit is better than implicit. 5. The issue above only raises from the idea that the RWLock should provide the same API as the Lock and RLock primitives. So everywhere where a lock primitive is expected, you can pass either a Lock, RLock or RWLock. That is actually a good idea, but in that case you should explicitly specify, whether to pass the shared (read) or the exclusive (write) lock. Both issues 4. and 5. only raise from the idea that a shared/exclusive lock should be implemented as a single class. But having two different lock primitives, one for the shared lock and one for the exclusive lock and a function returning a pair of those, would be much more flexible, pythonic and compatible with existing lock primitives. def ShrdExclLock() class _ShrdLock(object): def acquire(self, blocking=True): ... def release(self, blocking=True): ... def __enter__(self): self.acquire() retrun self def __exit__(self, exc_value, exc_type, tb): self.release() class _ExclLock(object): def acquire(self, blocking=True): ... def release(self, blocking=True): ... def __enter__(self): self.acquire() retrun self def __exit__(self, exc_value, exc_type, tb): self.release() return _ShrdLock(), _ExclLock() # create a shared/exclusive lock shrd_lock, excl_lock = ShrdExclLock() -- nosy: +Sebastian.Noack ___ Python tracker <http://bugs.python.org/issue8800> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8800] add threading.RWLock
Sebastian Noack added the comment: Using a lock as context manager is the same as calling lock.acquire(blocking=True) and it will in fact block while waiting for an other thread to release the lock. In your code, the internal lock is indeed just hold for a very short period of time while acquiring or releasing a shared or exclusive lock, but it might add up to a notable amount of time dependent on how much concurrent threads are using the same RWLock and how slow/busy your computer is. But what made me reconsider my point are following facts: 1. For example, when you acquire a shared (read) lock in non-blocking mode and False is returned, you assume that an other thread is holding an exclusive (write) lock. But that isn't necessarily the case, if it also returns False, when the internal lock is acquired by an other thread for example in order to acquire or release another shared (read) lock. 2. The internal lock must be acquired also in order to release a shared/exclusive lock. And the 'release' method (at least if implemented as for Lock and RLock) don't have a 'blocking' argument, anyway. For that reasons, I think it is ok to block while waiting for the internal lock, even if the shared/exclusive lock was acquired in non-blocking mode. At least it seems to lead to less unexpected side effects, than returning False in case the internal lock is acquired. -- ___ Python tracker <http://bugs.python.org/issue8800> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8800] add threading.RWLock
Sebastian Noack added the comment: I've added a new patch, that implements a shared/exclusive lock as described in my comments above, for the threading and multiprocessing module. -- Added file: http://bugs.python.org/file27350/Added-ShrdExclLock-to-threading-and-multiprocessing.patch ___ Python tracker <http://bugs.python.org/issue8800> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8800] add threading.RWLock
Sebastian Noack added the comment: I was just waiting for a comment pointing out, that my patch comes without tests. :) Note that we are still discussing the implementation and this patch is just a proof of concept. And since the way it is implemented and the API it provides could still change, its quite pointless to write tests, until we at least agreed on the API. I have uploaded a new patch. The way it is implemented now, is more like the Barrier is implemented. The common code is shared in the threading module and the shared/exclusive lock objects can be pickled now. I have also fixed a bug related to acquiring locks in non-blocking mode. However the code still uses c_uint, but ctypes (and multiprocessing.sharedtypes) is only imported when ShrdExclLock is called. So it is just a lazy dependency, now. However the reason why I am using ctypes instead of python integers for threading and a BufferWrapper for multiprocessing (as the Barrier does) is, because of 2 of the 4 counters need to be continuously incremented, and c_uint has the nice feature that it can overflow, in contrast to python integers and integers in arrays. Also that way the implementation is simpler and it seems that there isn't much difference under the hood between using BufferWrapper() and RawValue(). A shared/exclusive lock isn't one lock but two locks, which are synchronized, but must be acquired separately. Similar to a pipe, which isn't one file, but one file connected to another file that reads whatever you have written into the first file. So it isn't strange to create two lock objects, as it also isn't strange that os.pipe() returns two file descriptors. Also having a separate lock object for the shared and exclusive lock, each providing the same API (as Lock and RLock), gives you huge flexibility. You can acquire both locks using the with statement or pass them separately around. So for example when you have a function, thread or child process, that should only be able to acquire either the shared or the exclusive lock, you don't have to pass both locks. That also means that existing code that expects a lock-like object will be compatible with both the shared and exclusive lock. -- Added file: http://bugs.python.org/file27363/Added-ShrdExclLock-to-threading-and-multiprocessing-2.patch ___ Python tracker <http://bugs.python.org/issue8800> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8800] add threading.RWLock
Sebastian Noack added the comment: Yes, you could also look at the shared/exclusive lock as one lock with different states. But this approach is neither more common, have a look at Java's ReadWriteLock [1] for example, which works just like my patch does, except that a factory is returned instead of a tuple. Nor does it provide any of the benefits, I have mentioned before (same API as Lock and RLock, better compatibility with existing code an with statement, ability to pass the shared or exclusive lock separetly around). But maybe we could satisfy anybody, by following Richard's and Antoine's suggestion of returning a named tuple. So you could use the ShrdExclLock both ways: # use a single object lock = ShrdExclLock() with lock.shared: ... with lock.exclusive: ... # unpack the the object into two variables and pass them separately around shrd_lock, excl_lock = ShrdExclLock() Thread(target=reader, args=(shrd_lock,)).start() Thread(target=writer, args=(excl_lock,)).start) The majority of us seems to prefer the terms shared and exclusive. However I can't deny that the terms read and write are more common, even though there are also notable exmples where the terms shared and exclusive are used [2] [3]. But let us ignore how other call it for now, and get to the origin of both set of terms, in order to figure out which fits best into Python: shared/exclusive -> abstract description of what it is read/write -> best known use case The reason why I prefer the terms shared and exculsive, is that it is more distinct and less likely to get misunderstand. Also naming a generic implementation after a specific use case is bad API design and I don't know any other case where that was done, in the Python core library. [1] http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/locks/ReadWriteLock.html [2] http://www.postgresql.org/docs/9.2/static/explicit-locking.html [3] http://www.unix.com/man-page/freebsd/9/SX/ -- ___ Python tracker <http://bugs.python.org/issue8800> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8800] add threading.RWLock
Sebastian Noack added the comment: @richard: I'm sorry, but both of my patches contain changes to 'Lib/threading.py' and can be applied on top of Python 3.3.0. So can you explain what do you mean, by missing the changes to threading.py? -- ___ Python tracker <http://bugs.python.org/issue8800> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8800] add threading.RWLock
Sebastian Noack added the comment: > If you want to argue it this way, I counter that the attributes > "shared" and "exclusive" apply to the type of "access to the > protected object" you are talking about, and yet, the name suggest > that they are attributes of the lock itself. A lock's sole purpose is to synchronize access to a protected object or context. So naming a lock after its type of protection absolutely makes sense. Those names are also not supposed to be attributes of the lock, rather two locks (a shared and an exclusive lock) should be created, that might be returned as a namedtuple for convenience. > In that sense, "reader lock" and "writer lock", describe attributes > of the user of the lock, and the verbs "readlock" and "writelock" > describe the operation being requested. The user of the lock isn't necessarily a reader or writer. This is just one of many possible use cases. For example in a server application a shared/exclusive lock might be used to protect a connection to the client. So every time a thread wants to use the connection, a shared lock must be acquired and when a thread wants to shutdown the connection, the exclusive lock must be acquired, in order to ensure that it doesn't interrupt any thread still processing a request for that connection. In that case you clearly wouldn't call the users reader and writer. > The patch looks like it was produced using git rather than hg, so > perhaps Rietveld got confused by this. In that case it is a bug > in Rietveld that it produced a partial review instead of producing > no review. Yes, I have imported the Python 3.3.0 tree into a local git repository and created the patch that way. Since patches generated with git are still compatible with the 'patch' program in order to apply them, I hope that isn't a problem. > Although using namedtuple is probably a good idea, I don't think it > really adds much flexibility. This example could just as easily be > written > > selock = ShrdExclLock() > > Thread(target=reader, args=(selock.shared,)).start() > Thread(target=writer, args=(selock.exclusive,)).start() Yes, that is true, but in some cases it is more convenient to be able unpack the shared/exclusive lock into two variables, with a one-liner. And defining a namedtuple doesn't require any extra code compared to defining a class that holds both locks. In fact it needs less code to be implemented. However the flexibility comes from having two lock objects, doesn't matter how they are accessed, instead as suggested by Kristján to have a single lock object, which just provides proxies for use with the with statement. > I also think it is time to drop the "writer preference" model, since > it just adds complexity with doubtful benefits. Sebastian's model > also does that. I have implemented the simplest possible acquisition order. The lock acquired first will be granted first. Without that (or a more advanced policy) in applications with concurrent threads/processes that are heavily using the shared lock, the exclusive lock can never be acquired, because of there is always a shared lock acquired and before it is released the next shared lock will be acquired. -- ___ Python tracker <http://bugs.python.org/issue8800> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8800] add threading.RWLock
Sebastian Noack added the comment: I would love to see how other people would implement a shared/exclusive lock that can be acquired from different processes. However it really seems that nobody did it before. If you know a reference implementation I would be more than happy. There are plenty of implementations for threading only, but they won't work with multiprocessing, due to the limitations in the ways you can share data between processes. -- ___ Python tracker <http://bugs.python.org/issue8800> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8800] add threading.RWLock
Sebastian Noack added the comment: Thanks, but as I already said there are a lot of implementations for shared/exclusive lock that can be acquired from different threads. But we need with threading as well as with multiprocessing. And by the way POSIX is the standard for implementing UNIX-like systems and not an industry standard for implementing anything, including high-level languages like Python. -- ___ Python tracker <http://bugs.python.org/issue8800> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8800] add threading.RWLock
Sebastian Noack added the comment: Exactly, with my implemantation "the lock acquired first will be granted first". There is no way that either shared nor exclusive locks can starve, and therefore it should satisfy all use cases. Since you can only share simple datastructures like integers across processes, I also found that this seems to be the only policy (except ignoring the acquisition order at all), that can be implemented for multiprocessing. I have also looked at the seqlock algorithm, which seems to be great for use cases where the exclusive lock is acquired rather rarely and where your "reader" code is in fact read-only and therefore can be repeated. But in any other case a seqlock would break your code. However the algorithm is ultra simple and can't be implemented as lock-like object anyway. Though you could implement it as context manager, but that would hide the fact that the "reader" code will be repeated. So if you find yourself that a seqlock is that what you need for your specific use case, you can just use the algorithm like below: lock = multiprocessing.Value(0) count = multiprocessing.Value(0) def do_read(): while True: if count.value % 2: continue data = ... if count.value % 2: continue return data def do_write(data): with lock: count.value += 1 # write data count.value += 1 I have also experimented with implementing a shared/exclusive lock on top of a pipe and UNIX file locks (https://gist.github.com/3818148). However it works only on Unix and only with processes (not threads). Also it turned out that UNIX file locks don't implement an acquisition order. So exclusive locks can starve, which renders it useless for most use cases. -- ___ Python tracker <http://bugs.python.org/issue8800> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8800] add threading.RWLock
Sebastian Noack added the comment: @Kristján: Uhh, that is a huge amount of code, more than twice as much (don't counting tests) as my implementation, to accomplish the same. And it seems that there is not much code shared between the threading and multiprocessing implementation. And for what? Ah right, to make the API suck as much as the Windows API does. Please tell me more about good coding practice. ;) -- ___ Python tracker <http://bugs.python.org/issue8800> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12873] 2to3 incorrectly handles multi-line imports from __future__
Changes by Sebastian Wiesner : -- nosy: +lunar ___ Python tracker <http://bugs.python.org/issue12873> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12873] 2to3 incorrectly handles multi-line imports from __future__
Sebastian Wiesner added the comment: More precisely, the bug is, that 2to3 refactors the "print()" invocation in "test1.py" though it shouldn't because a "print_function" future import is present at the beginning of "test1.py". The cross-check with "test2.py" shows that this is due to the multi-line future import in "test1.py" because the line-break in the import statement is the only difference between both files. -- ___ Python tracker <http://bugs.python.org/issue12873> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12844] Support more than 255 arguments
Changes by Sebastian Ramacher : -- nosy: +sebastinas ___ Python tracker <http://bugs.python.org/issue12844> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12998] Memory leak with CTypes Structure
Sebastian Wiesner added the comment: Why should it? After all, you're sort of abusing ctypes by repeatedly creating Struture types over and over again. C structures that you might want to wrap with these types are fixed and known at the time of programming, so there is never a need to create the same Structure type twice. Thus the set of Structure subclasses created during the live-time of a program is both, fixed and small, so there is no need to limit the cache size. -- nosy: +lunar ___ Python tracker <http://bugs.python.org/issue12998> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16525] wave file module does not support 32bit float format
New submission from Sebastian Kraft: The wave module cannot read audio WAV files containing 32bit float values. This is a very common file type for professional audio! There has already been a patch some years ago which works fine but was finally not applied. I can confirm that it does not break anything and only adds support for a new number format. http://bugs.python.org/issue1144504 -- components: Extension Modules, IO messages: 176077 nosy: Sebastian.Kraft priority: normal severity: normal status: open title: wave file module does not support 32bit float format type: enhancement versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 ___ Python tracker <http://bugs.python.org/issue16525> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16525] wave file module does not support 32bit float format
Sebastian Kraft added the comment: Write support is no problem, I will add this. >From reading the spec in the link you provided I think the implementation in >general is OK. Everything apart WAVE_FORMAT_PCM should have an extension size cbSize, that's right. But only WAVE_FORMAT_EXTENSIBLE sets cbSize=22. So for read access it is not mandatory to check the value when WAVE_FORMAT_IEEE_FLOAT, but for writing files I would set this to zero. There are several other wave formats which also use float data, but most important is WAVE_FORMAT_IEEE_FLOAT, and that can be suppoted quite easily without many changes. -- ___ Python tracker <http://bugs.python.org/issue16525> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16525] wave file module does not support 32bit float format
Sebastian Kraft added the comment: I will create a patch together with a testset of example files and also fill out the agreement. BTW: readframes() returns bad data for 24bit PCM if big_endian==True. Furthermore IMO it doesn't make sense to return a byte stream in little endian order on a big endian system... What do you think? At least the waves doc doesn't mention or specify the endianess which will cause trouble. -- ___ Python tracker <http://bugs.python.org/issue16525> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16525] wave file module does not support 32bit float format
Sebastian Kraft added the comment: Attached to this mail you find my patch for the implementation of support for 8, 16, 24, 32 bit signed int PCM and 32, 64 bit float. 24bit on big endian systems is buggy, but this will be reported in another ticket. The modified test checks all number formats apart form 24bit int. If the patch is fine and will be accepted I will also update the doc and send a seperate patch for this. -- keywords: +patch Added file: http://bugs.python.org/file28122/wave_float_issue16525.patch ___ Python tracker <http://bugs.python.org/issue16525> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16525] wave file module does not support 32bit float format
Sebastian Kraft added the comment: Contribution agreement is now attached to my account. So the review can start ;) -- ___ Python tracker <http://bugs.python.org/issue16525> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16664] [PATCH] Test Glob: files starting with .
New submission from Sebastian Kreft: Please find attached a patch to improve the test cases for the glob module. It adds test cases for files starting with '.'. -- components: Tests files: python.patch keywords: patch messages: 177345 nosy: Sebastian.Kreft priority: normal severity: normal status: open title: [PATCH] Test Glob: files starting with . versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file28281/python.patch ___ Python tracker <http://bugs.python.org/issue16664> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16664] [PATCH] Test Glob: files starting with .
Sebastian Kreft added the comment: The docs don't say anything about it. However the code is there (docs bug probably). See the following lines in glob.py: 57 if pattern[0] != '.': 58 names = [x for x in names if x[0] != '.'] 59 return fnmatch.filter(names, pattern) The documentation is even harder to follow. The glob docs say: "The pattern may contain simple shell-style wildcards a la fnmatch." but the fnmatch docs say: "Similarly, filenames starting with a period are not special for this module, and are matched by the * and ? patterns." The posix standard states that "if a filename begins with a period ( '.' ), the period shall be explicitly matched" (http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_13_03). -- ___ Python tracker <http://bugs.python.org/issue16664> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16845] warnings.simplefilter should validate input
New submission from Sebastian Berg: `warnings.simplefilter` does not validate that the category passed in is actually a class. This means that an invalid category leads to a `TypeError` whenever a warning would otherwise occur due to `issubclass` check failing. It is a very small thing, but for usability it would be clearer if this was checked right away. -- messages: 178867 nosy: seberg priority: normal severity: normal status: open title: warnings.simplefilter should validate input type: enhancement ___ Python tracker <http://bugs.python.org/issue16845> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16525] wave file module does not support 32bit float format
Sebastian Kraft added the comment: Any news or feedback regarding my patch? -- ___ Python tracker <http://bugs.python.org/issue16525> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7279] decimal.py: == and != comparisons involving NaNs
Sebastian Berg added the comment: This is closed, and maybe I am missing something. But from a general point of view, why does hashing of NaN not raise an error as it did for decimals, i.e. why was this not resolved exactly the other way around? I am mostly just wondering about this it is not a problem for me. Hashing NaNs seems dangerous and surprising because it might work in dicts/sets, but normally doesn't. (The only thing for it to work right would be if NaN was a singleton, but that is impossible for subclasses, etc.). The thing is: In [16]: s = {float('nan'): 1, float('nan'): 2, float('nan'): 3} In [17]: s Out[17]: {nan: 1, nan: 2, nan: 3} In [18]: s[float('nan')] KeyError: nan In [19]: n = float('nan') In [20]: s = {n: 1, n: 2, n: 3} In [21]: s Out[21]: {nan: 3} This is because `n is n`, and PyObject_RichCompareBool assumes that if `a is b` then `a == b` which is simply wrong for NaNs and also makes comparisons of iterables including NaNs an impossible business. NaNs have their unavoidable weirdness, but at least for dictionaries/sets it would seem more clear to me if they raised an error. -- nosy: +seberg ___ Python tracker <http://bugs.python.org/issue7279> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7279] decimal.py: == and != comparisons involving NaNs
Sebastian Berg added the comment: Thanks, yes, you are right, should have googled a bit more anyway. Though I did not find much on the hashable vs unhashable itself, so if I ever stumble across it again, I will write a mail... -- ___ Python tracker <http://bugs.python.org/issue7279> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16525] wave file module does not support 32bit float format
Changes by Sebastian Kraft : Removed file: http://bugs.python.org/file28122/wave_float_issue16525.patch ___ Python tracker <http://bugs.python.org/issue16525> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16525] wave file module does not support 32bit float format
Sebastian Kraft added the comment: Thanks for the hint Harvey! I have updated my patch to include your changes, but only applied the second hunk for the following reasons: Wave_read should not assume any wave format, as it is expected to open a file during initialization. So actually the only missing thing was the assignment of the wave format during the reading of the format chunk. setparams() in Wave_write already sets the wavformat a few lines later together with the other parameters. So no need to set it twice... Can you please check if the updated patch works for you? -- Added file: http://bugs.python.org/file29085/patch ___ Python tracker <http://bugs.python.org/issue16525> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6243] getkey() can segfault in combination with curses.ungetch()
Changes by Sebastian Ramacher : -- nosy: +sebastinas ___ Python tracker <http://bugs.python.org/issue6243> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6952] deprecated conversion from string constant to char *
Changes by Sebastian Ramacher : -- nosy: +sebastinas ___ Python tracker <http://bugs.python.org/issue6952> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7036] Doc/reference/datamodel: Slots description needs update
New submission from Sebastian Thiel : The section starting with: "If a class defines a slot also defined in a base class, the instance variable defined by the base class slot is inaccessible rendering the meaning of the program undefined. [...]" would need to be revisited as it claims that a check for this issue might be added in future. As far as I can tell, it has been added in Python 2.4 or earlier as I get a TypeError in that case. The attached diff is my attempt to fix this issue. Kind Regards, Sebastian -- assignee: georg.brandl components: Documentation files: docfix.diff keywords: patch messages: 93447 nosy: Byron, georg.brandl severity: normal status: open title: Doc/reference/datamodel: Slots description needs update type: behavior versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2 Added file: http://bugs.python.org/file15020/docfix.diff ___ Python tracker <http://bugs.python.org/issue7036> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7036] Doc/reference/datamodel: Slots description needs update
Sebastian Thiel added the comment: Additional Information: "multiple bases have instance lay-out conflict" This happens only if I add __slots__ to the bases so that there is no dict. I can reproduce this easily by indirectly deriving a class from two bases that both define the same slot. It only happens if all classes define __slots__ so there is no dict. class ac( object ): __slots__ = "a" class bc( ac ): __slots__ = "b" class cc( ac ): __slots__ = "c" class cannotbecreated( bc,cc ): pass # raises an error. Actually I don't know whether this is intended or if it is related to the documentation section I pointed at. -- ___ Python tracker <http://bugs.python.org/issue7036> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7382] bytes.__getnewargs__ is broken; copy.copy() therefore doesn't work on bytes, and bytes subclasses can't be pickled by default
New submission from Sebastian Hagen : In either python 3.0, bytes instances cannot be copied, and (even trivial) bytes subclasses cannot be unpickled unless they explicitly override __getnewargs__() or __reduce_ex__(). Copy problem: >>> import copy; copy.copy(b'foo') Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3.1/copy.py", line 96, in copy return _reconstruct(x, rv, 0) File "/usr/lib/python3.1/copy.py", line 280, in _reconstruct y = callable(*args) File "/usr/lib/python3.1/copyreg.py", line 88, in __newobj__ return cls.__new__(cls, *args) TypeError: string argument without an encoding Bytes subclass unpickle problem: >>> class B(bytes): ... pass ... >>> import pickle; pickle.loads(pickle.dumps(B(b'foo'))) Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3.1/pickle.py", line 1373, in loads encoding=encoding, errors=errors).load() TypeError: string argument without an encoding AFAICT, the problem is that bytes.__getnewargs__() returns a tuple with a single argument - a string - and bytes.__new__() refuses to reconstruct the instance when called with in that manner. That is, "bytes.__new__(bytes, *b'foo'.__getnewargs__())" fails with a TypeError. This does not cause a problem for pickling bytes instances (as opposed to instances of a subclass of bytes), because both the Python and C versions of pickle shipped with Python 3.[01] have built-in magic (_Pickler.save_bytes() and save_bytes(), respectively) to deal with bytes instances, and therefore never call their __getnewargs__(). The pickle case, in particular, is highly irritating; the error message doesn't indicate which object is causing the problem, and until you actually try to load the pickle, there's nothing to indicate that there's anything problematic about pickling an instance of a subclass of bytes. -- components: Library (Lib) files: pickle_bytes_subclass.py messages: 95632 nosy: sh severity: normal status: open title: bytes.__getnewargs__ is broken; copy.copy() therefore doesn't work on bytes, and bytes subclasses can't be pickled by default type: behavior versions: Python 3.0, Python 3.1 Added file: http://bugs.python.org/file15387/pickle_bytes_subclass.py ___ Python tracker <http://bugs.python.org/issue7382> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7560] Various filename-taking posix methods don't like bytes / buffer objects.
New submission from Sebastian Hagen : Most of the functions in Python's stdlib that take filename parameters allow for those parameters to be buffer (such as bytes, bytearray, memoryview) objects. This is useful for various reasons, among them that on Posix-likes, file- and pathnames ultimately *are* sequences of bytes. A number of functions in the posix (and thus, os) module break this convention: mkfifo() mknod() statvfs() pathconf() E.g.: >>> os.statvfs(b'/') Traceback (most recent call last): File "", line 1, in TypeError: statvfs() argument 1 must be string, not bytes I'm attaching a patch that modifies the abovementioned functions to make them accept buffer-like objects in addition to string objects; I've never contributed code to the stdlib, so any general problems with that patch can be ascribed to my ignorance about established practice (or inability to program, in the case of downright bugs). I'm a bit off a loss as what to do about posix.system(). IMO, that one should also take bytes - at least on posix-like OSes - since it specifies a commandline, and both the name and the arguments in such lines are, on posix-likes, sequences of bytes. I'm not sure how to best reconcile that with the MS Windows version of that function, however; advice would be welcome. -- components: Library (Lib) files: posix_fn_bytes_01.patch keywords: patch messages: 96792 nosy: sh severity: normal status: open title: Various filename-taking posix methods don't like bytes / buffer objects. versions: Python 3.1, Python 3.2 Added file: http://bugs.python.org/file15659/posix_fn_bytes_01.patch ___ Python tracker <http://bugs.python.org/issue7560> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7560] Various filename-taking posix methods don't like bytes / buffer objects.
Changes by Sebastian Hagen : -- type: -> behavior ___ Python tracker <http://bugs.python.org/issue7560> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7560] Various filename-taking posix methods don't like bytes / buffer objects.
Changes by Sebastian Hagen : Removed file: http://bugs.python.org/file15659/posix_fn_bytes_01.patch ___ Python tracker <http://bugs.python.org/issue7560> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7560] Various filename-taking posix methods don't like bytes / buffer objects.
Sebastian Hagen added the comment: I'm taking that patch back. More testing would have been in order before posting; sorry for that, will repost once I've got the obvious problems worked out. -- ___ Python tracker <http://bugs.python.org/issue7560> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7560] Various filename-taking posix methods don't like bytes / buffer objects.
Sebastian Hagen added the comment: And further testing reveals that all of this has in fact already been fixed in trunk. I assumed it hadn't been, because the code for at least some of the relevant functions in Modules/_posixmodule.c is the same as in 3.1.1; I didn't know that the samentics for the "s" format parameter to PyArg_ParseTuple() had been modified. Apologies for the noise. -- ___ Python tracker <http://bugs.python.org/issue7560> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7560] Various filename-taking posix methods don't like bytes / buffer objects.
Changes by Sebastian Hagen : -- status: open -> closed versions: -Python 3.2 ___ Python tracker <http://bugs.python.org/issue7560> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7561] Filename-taking functions in posix segfault when called with a bytearray arg.
New submission from Sebastian Hagen : Various functions in the 'posix' module that take filename arguments accept bytearray values for those arguments, and mishandle those objects in a way that leads to segfaults. Python 3.1 (r31:73572, Jul 23 2009, 23:41:26) [GCC 4.3.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.mkdir(bytearray(b'/')) Segmentation fault There's at least two seperate problems with the way posixmodule handles these objects. The first is that the code isn't set up to handle NULL retvals from PyByteArray_AS_STRING(), which occur for zero-byte bytearray objects. This causes a NULL-pointer dereference in PyUnicode_FSConverter() if you pass a zero-length bytearray. The second issue is that release_bytes() calls bytearray_releasebuffer() with NULL for the first argument, which directly leads to a NULL-pointer dereference. I'm attaching a patch against SVN 77001 which should fix both of these issues. -- components: Library (Lib) files: posixmodule_fn_bytearray_fix_01.patch keywords: patch messages: 96795 nosy: sh severity: normal status: open title: Filename-taking functions in posix segfault when called with a bytearray arg. type: crash versions: Python 3.1, Python 3.2 Added file: http://bugs.python.org/file15660/posixmodule_fn_bytearray_fix_01.patch ___ Python tracker <http://bugs.python.org/issue7561> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7561] Filename-taking functions in posix segfault when called with a bytearray arg.
Sebastian Hagen added the comment: Not exactly. The last part fixes the second problem, which you get for non-zero-length bytearrays. But without the first fix, zero-length bytearrays still lead to a crash: Python 3.2a0 (py3k:77001M, Dec 22 2009, 18:17:08) [GCC 4.3.4] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import posix >>> posix.mkdir(bytearray(0)) Segmentation fault That's what the rest of the patch fixes. -- ___ Python tracker <http://bugs.python.org/issue7561> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7561] Filename-taking functions in posix segfault when called with a bytearray arg.
Sebastian Hagen added the comment: You're correct about PyUnicode_FSConverter(), which is why the very first part of my patch fixes that function. Only fixing that one will get rid of the segfaults, but also lead to incorrect error reporting for the zero-length bytearray case; the bytes2str() modification is to get the right exceptions. I don't know which precise semantics PyByteArray_AS_STRING() is *supposed* to have. I assumed it returning NULL was normal for 0-byte-length arrays, and based my patch off of that. -- ___ Python tracker <http://bugs.python.org/issue7561> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7561] Filename-taking functions in posix segfault when called with a bytearray arg.
Sebastian Hagen added the comment: Correction: "Only fixing that one will get rid of the segfaults" ... well, for mkdir() on GNU/Linux, anyway. POSIX.1-2008 doesn't specify what happens if you call mkdir() with a NULL pointer, so I guess other conforming implementations might in fact still segfault at that point - it just happens that the one I tested it on is too nice to do that. Either way, passing a NULL pointer to those functions is almost certainly not a good idea. -- ___ Python tracker <http://bugs.python.org/issue7561> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7561] Filename-taking functions in posix segfault when called with a bytearray arg.
Sebastian Hagen added the comment: I've glanced at some of the other PyByteArray_AS_STRING() (and PyByteArray_AsStr(), which inherits this behaviour) uses in the stdlib. By far the heaviest user is bytearrayobject.c; aside from that, there's by my count only 24 uses in current trunk. I haven't looked at all of them in detail, but the ones I have looked at all seem to ensure that the possible NULL retvals don't cause them problems. Given that, and considering that bytearray itself uses it for all kinds of operations, I'd be rather reluctant to add any additional overhead to this macro absent some authoritative statement that the current behaviour is bad. We'd definitely get better performance by just having posixmodule.c pay attention to the retval it gets. [Yes, this is probably premature optimization; but it's not as if fixing posixmodule.c takes any massive changes either, so I'm not too worried about additional code complexity in this particular case.] -- ___ Python tracker <http://bugs.python.org/issue7561> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7561] Filename-taking functions in posix segfault when called with a bytearray arg.
Sebastian Hagen added the comment: Well, it doesn't *need* to accept them ... but it would certainly be nice to have. If you've already got the filename in a bytearray object for some reason, being able to pass it through directly saves you both a copy and the explicit conversion code, which is a double-win. >From an interface POV, it'd be even better if memoryview was allowed, too ... is there a specific reason that it's not? If one kind of simple readable buffers work, I don't see any good reason not to support all such objects. -- ___ Python tracker <http://bugs.python.org/issue7561> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7561] Filename-taking functions in posix segfault when called with a bytearray arg.
Sebastian Hagen added the comment: Oh, and *forcing* use of the PEP 383 hack for such interfaces would really be the Wrong Thing. Byte sequences are the natural (and most efficient, and least prone to misunderstandings) way to store filenames on a posix-like. Storing them as unicode-except-not-really is an acceptable hack for interfaces that need to standardize on strings for some reasons, but that really doesn't apply to these functions, and I'd always store such filenames as bytes if I know I'm running on a posix-like. -- ___ Python tracker <http://bugs.python.org/issue7561> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3001] RLock's are SLOW
sebastian serrano <[EMAIL PROTECTED]> added the comment: Running with python -O the timing gets a little closer between Lock and RLock. This code won't be easy to improve in performance. The heaviest call is current_thread(), used at lines: 117:me = current_thread() 137:if self.__owner is not current_thread(): and only consist on: 788: def current_thread(): 789: try: 790: return _active[_get_ident()] 791: except KeyError: 792: ##print "current_thread(): no current thread for", _get_ident() 793: return _DummyThread() Simple profiler dump: $../python-trunk/python -O rlock.py time Lock 0.720541000366 time RLock 4.90231084824 44 function calls in 0.982 CPU seconds Ordered by: internal time, call count ncalls tottime percall cumtime percall filename:lineno(function) 100.3040.0000.3900.000 threading.py:116(acquire) 100.2780.0000.3600.000 threading.py:136(release) 10.2320.2320.9820.982 rlock.py:27(testRLock) 200.1680.0000.1680.000 threading.py:788(current_thread) 10.0000.0000.0000.000 threading.py:103(__init__) 10.0000.0000.0000.000 threading.py:98(RLock) 10.0000.0000.0000.000 threading.py:76(__init__) 00.000 0.000 profile:0(profiler) -- nosy: +sserrano ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3001> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4163] textwrap wordsep_re Unicode
New submission from Sebastian Kirsche <[EMAIL PROTECTED]>: The attached patch makes textwrap work with strings containing dashes and Unicode alphabetic characters. In addition, it fixes the test case for issue 1149508, which no longer failed after temporarily undoing the corresponding change. Example 1: print textwrap.fill(u'Die Empfänger-Auswahl', 13) Output without patch: Die Empf änger-Auswahl With patch: Die Empfänger- Auswahl Example 2: print textwrap.fill(u'aa ää-ää', 7) Output without patch: aa ää-ää With patch: aa ää- ää -- components: Library (Lib) files: textwrap-umlauts.patch keywords: patch messages: 75037 nosy: skirsche severity: normal status: open title: textwrap wordsep_re Unicode type: behavior versions: Python 2.5, Python 2.5.3, Python 2.6, Python 2.7 Added file: http://bugs.python.org/file11848/textwrap-umlauts.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4163> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1699259] replacing char* with const char* in sysmodule.c/.h
Sebastian Ramacher <[EMAIL PROTECTED]> added the comment: At least a response, finally. > * Any reason why PySys_SetPath(char *) is left out? I guess it I just missed it. > * Same for PySys_SetArgv(int, char **) That one is non-trivial and requires some rewriting of PySys_SetArgv. And I didn't have the time to look into it any further. I attached an updated patch. Added file: http://bugs.python.org/file11999/sysmodule_const_char_r67215.diff ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1699259> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4411] __mro__ documentation
New submission from Sebastian Wiesner <[EMAIL PROTECTED]>: The documentation of Python 2.6 and 2.7 only mentions the class attribute "__mro__" in ABC documentation and in Data model documentation when explaining description invocation (see search results: http://docs.python.org/dev/search.html?q=__mro__&check_keywords=yes&area=default) Imho __mro__ lacks documentation in "Standard Type Hierachy", where special attributes of fundamental data types are documented. -- assignee: georg.brandl components: Documentation messages: 76355 nosy: georg.brandl, lunar severity: normal status: open title: __mro__ documentation versions: Python 2.7 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4411> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4577] distutils: -3 warnings (apply)
New submission from Sebastian Rittau <[EMAIL PROTECTED]>: The attached patch removes all instances of the deprecated "apply" function from distutils and thereby fixes warnings when run with -3. -- components: Distutils files: distutils.diff keywords: patch messages: 77233 nosy: srittau severity: normal status: open title: distutils: -3 warnings (apply) versions: Python 2.6 Added file: http://bugs.python.org/file12263/distutils.diff ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4577> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4577] distutils: -3 warnings (apply)
Sebastian Rittau <[EMAIL PROTECTED]> added the comment: Oops, missed a closing parenthesis. Added file: http://bugs.python.org/file12264/distutils.diff ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4577> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4577] distutils: -3 warnings (apply)
Changes by Sebastian Rittau <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file12263/distutils.diff ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4577> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4578] compiler: -3 warnings
New submission from Sebastian Rittau <[EMAIL PROTECTED]>: The attached patch replaces all instances of "x.has_key(k)" method calls by "k in x". It also replaces one call to parser.ast2tuple by parser.st2tuple. This removes deprecation warnings when running in -3 mode. -- components: Library (Lib) files: compiler.diff keywords: patch messages: 77238 nosy: srittau severity: normal status: open title: compiler: -3 warnings versions: Python 2.6 Added file: http://bugs.python.org/file12266/compiler.diff ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4578> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4578] compiler: -3 warnings
Sebastian Rittau <[EMAIL PROTECTED]> added the comment: I'd like to see this fixed, just to decrease the amount of warning spam I get when testing my own packages. It seems that one of my dependecies that I have no control over is pulling this in. Adding a warning when this module is important seems like a good idea, though. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4578> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1673409] datetime module missing some important methods
Sebastian Rittau added the comment: A timedelta.toseconds method (or equivalent) makes no sense. The number of seconds in a day is not fixed (due to leap seconds) and relying on such a method would introduce subtle bugs. The only way to find out the number of seconds in a range of dates is if you have a concrete date range. -- nosy: +srittau ___ Python tracker <http://bugs.python.org/issue1673409> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2155] optparse.OptionGroup with_statement context handling
Sebastian Rittau added the comment: This API is too "magical" to my liking and doesn't really reflect what context manager's are supposed to do, i.e. handling resources. Also, I don't see much advantage over: group = OptionGroup(parser, "Group name") group.add_option(...) parser.add_option_group(group) Finally, the __exit__ handler adds the option group to the parser in any case, whether there was an exception raised inside the block or not. -- nosy: +srittau ___ Python tracker <http://bugs.python.org/issue2155> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1673409] datetime module missing some important methods
Sebastian Rittau added the comment: Leap second handling is usually configurable. Default on Debian Linux (but similar on RHEL and SuSE): >>> int(date(1994,1,1).strftime("%s")) - int(date(1993,1,1).strftime("%s")) 31536000 After doing "cp /usr/share/zoneinfo/right/Europe/Berlin /etc/localtime": >>> int(date(1994,1,1).strftime("%s")) - int(date(1993,1,1).strftime("%s")) 31536001 Also, NTP servers usually get this right. I don't think, Python should promote a wrong date handling by default, even if it's convenient. ___ Python tracker <http://bugs.python.org/issue1673409> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4949] Constness in PyErr_NewException
Changes by Sebastian Ramacher : -- nosy: +sebastinas ___ Python tracker <http://bugs.python.org/issue4949> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5322] Python 2.6 object.__new__ argument calling autodetection faulty
Changes by Sebastian Ramacher : -- nosy: +sebastinas ___ Python tracker <http://bugs.python.org/issue5322> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5589] Wrong dump of floats
New submission from Sebastian Billaudelle : Hi there, I just recognized a weird behaviour of the json module... Dumpig a float like 0.1 I get some crazy output. Here is an example: >>> import json >>> json.dumps([.1]) '[0.10001]' Very simple to reproduce;) - Sebastian -- components: Library (Lib) messages: 84323 nosy: stein severity: normal status: open title: Wrong dump of floats type: behavior versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue5589> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1470548] Bugfix for #1470540 (XMLGenerator cannot output UTF-16 or UTF-8)
Sebastian Ortiz Vasquez added the comment: I have been working with this in order to generate an RSS feed using web2py. I found, XMLGenerator method does not validate if is an unicode or string type, and it does not encode accord the encoding parameter of the XMLGenerator. I added changed the method to verify if is an unicode object or try to convert to it using the desired encoding. Recall that the _write UnbufferedTextIOWrapper receives an unicode object as parameter. def characters(self, content): if isinstance(content, unicode): self._write(escape(content)) else: self._write(escape(unicode(content,self._encoding))) -- nosy: +neoecos title: Bugfix for #1470540 (XMLGenerator cannot output UTF-16) -> Bugfix for #1470540 (XMLGenerator cannot output UTF-16 or UTF-8) versions: -Python 3.2, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file29623/saxutils.py ___ Python tracker <http://bugs.python.org/issue1470548> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17606] BUG: XMLGenerator cannot output with the correct encoding
New submission from Sebastian Ortiz Vasquez: The XMLGenerator character method is unable to detect and encode using the encoding defined in the constructor. This yields to an UnicodeEncode exception, because always tries to encode using 'ascii' as default in python 2 -- components: XML files: XMLGenerator.patch keywords: patch messages: 185684 nosy: Arfrever, BreamoreBoy, benjamin.peterson, doerwalter, georg.brandl, larry, loewis, neoecos, neoecos, ngrig, pitrou, python-dev, serhiy.storchaka priority: normal severity: normal status: open title: BUG: XMLGenerator cannot output with the correct encoding versions: Python 2.6, Python 2.7 Added file: http://bugs.python.org/file29640/XMLGenerator.patch ___ Python tracker <http://bugs.python.org/issue17606> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17606] xml.sax.saxutils.XMLGenerator cannot output with the correct encoding
Sebastian Ortiz Vasquez added the comment: Added new test and patch generated following the python development directions found on http://docs.python.org/devguide/patch.html -- type: -> crash Added file: http://bugs.python.org/file29655/XMLGenerator.patch ___ Python tracker <http://bugs.python.org/issue17606> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17606] xml.sax.saxutils.XMLGenerator cannot output with the correct encoding
Changes by Sebastian Ortiz Vasquez : Removed file: http://bugs.python.org/file29655/XMLGenerator.patch ___ Python tracker <http://bugs.python.org/issue17606> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17606] xml.sax.saxutils.XMLGenerator cannot output with the correct encoding
Changes by Sebastian Ortiz Vasquez : Added file: http://bugs.python.org/file29656/XMLGenerator.patch ___ Python tracker <http://bugs.python.org/issue17606> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com