[issue17696] lookup fails for renamed functions
New submission from Ulrich Eckhardt: When you rename a test function, you can't explicitly specify it on the commandline any more. During normal test runs, it is automatically discovered though. The error is that the old name was not found, even though the new name was specified. The attached example changes the name attached to the function (its __name__ attribute) for demonstration. The same problem occurs if you auto-generate test functions and attach them to the class, using post-processing or a metaclass. The cases all have in common that the name in the class' dict is not the same as the function's __name__, so cls.foo.__name__ is not foo. See http://mail.python.org/pipermail/python-list/2013-April/644863.html for the initial discussion on the mailinglist. While I only tested Python 2.7 there, it also fails for 3.2 and 3.3. -- components: Tests files: name_mod.py messages: 186549 nosy: eckhardt priority: normal severity: normal status: open title: lookup fails for renamed functions type: behavior versions: Python 2.7, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file29775/name_mod.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17696 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4331] Can't use _functools.partial() created function as method
Ulrich Eckhardt added the comment: There is at least one thing that is missing in the patch, it lacks the necessary tests. The partialbug.py demonstrates the issue, it could be used as a base. However, even then, there is still one thing that is problematic: The fact that partial() returns something that behaves like a static method is documented and changing that is not backward compatible. I still think that something like this should become part of Python though. Jack Diederich argues that you can use lambda to achieve the same, but that is not always true. If you want to bind an argument to the current value of a variable instead of a constant, lambda fails. You need the closure created by a function call to bind those variables inside a local function. Having a dedicated function for that is IMHO preferable to people copying the Python-only equivalent of partial() to achieve the same effect or even inventing their own. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4331 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11470] Flag inappropriate uses of callable class attributes
Changes by Ulrich Eckhardt ulrich.eckha...@dominolaser.com: -- nosy: +eckhardt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11470 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4331] Can't use _functools.partial() created function as method
Ulrich Eckhardt added the comment: Just for the record, the behaviour is documented, unfortunately in the very last line of the functools documentation: Also, partial objects defined in classes behave like static methods and do not transform into bound methods during instance attribute look-up. Concerning how exactly they should behave during that lookup, I'd use the least surprising variant, namely that they are not treated differently from other functions: The first parameter is implicitly self. -- nosy: +eckhardt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4331 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12459] time.sleep(-1.0) behaviour
New submission from Ulrich Eckhardt eckha...@satorlaser.com: For reference, see the thread on the users' mailinglist/newsgroup from 2011-06-29 how to call a function for evry 10 seconds and the thread on the developers' mailinglist from 2011-06-30 time.sleep(-1) behaviour. The problem is how negative arguments to time.sleep() are handled. Python 2.x (tested 2.5 and 2.7) implementations on MS Windows seems to have a 32-bit underflow while converting the given argument to the DWORD that is passed to win32's Sleep() function. This causes a small negative value to sleep for a long time. On Linux, using Python 2.6, you get an IOError instead. While an error is better than blocking effectively forever, the use of an IOError to signal the wrong argument is at least confusing. I guess it is an artifact of the implementation, but that shouldn't be visible prominently. IMHH, both versions should raise a ValueError to signal invalid arguments. However, there was also the suggestion to simply treat negative values as zero, after all time.sleep() is already documented to possibly sleep longer than specified. -- messages: 139548 nosy: eckhardt priority: normal severity: normal status: open title: time.sleep(-1.0) behaviour type: behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12459 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1669539] Change (fix!) os.path.isabs() semantics on Win32
Changes by Ulrich Eckhardt eckha...@satorlaser.com: -- nosy: +eckhardt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1669539 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1669539] Change (fix!) os.path.isabs() semantics on Win32
Ulrich Eckhardt eckha...@satorlaser.com added the comment: I just stumbled across the issue with isabs(). I'd also say that Mark Hammond already provided the typical use case for this, i.e. that you allow relative paths for convenience when storing them or putting them on the commandline, but for actual use you first convert them so that their meaning doesn't change under your feet, e.g. because they depend on volatile things like the current working directory or drive. If you assume that is the intention or typical use case, then calling isabs() to determine if the path is stable doesn't work. Of course, the wording of the documentation then needs to change, too, as it explicitly says after chopping off a potential drive letter. Concerning the behaviour of path.join() and support for \\server\share paths, I'm not sure, but I think that these are issues that can be discussed/changed separately. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1669539 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5117] os.path.relpath problem with root directory
Changes by Ulrich Eckhardt eckha...@satorlaser.com: -- nosy: +eckhardt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5117 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4829] confusing error for file(foo, w++)
Ulrich Eckhardt eckha...@satorlaser.com added the comment:
Good catch, it just took me a while to actually figure out myself where
the bug is. Try the following instead:
import io
io.FileIO('foo.text', 'w++')
This will yield ValueError: Must have exactly one of read/write/append
mode with 2.6 on win32. I haven't tested on the latest 2.x or 3.x
branches, but looking at the 2.7 branch, I see the faulty code is still
there.
BTW:
Using io.open('foo.text', 'w++') yields ValueError: invalid mode:
'w++', I would have expected the same error as for io.FileIO() above.
Using open('foo.text', 'w++') works.
Using open('foo.text', 'ww++') yields IOError: [Errno 22] invalid mode
('ww++') or filename: 'foo.text').
In other words, Python 2.6 is behaving a bit inconsistent here. The
patch only fixes one of those issues, the others and the necessary unit
tests remain.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4829
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5134] Compiler warnings in sqlite module
Ulrich Eckhardt eckha...@satorlaser.com added the comment: What specific file would you put these pragmas into? Are you perhaps proposing to change upstream code? I would put it into the only sourcefile there is, and yes, I would change upstream code. Obviously, it would be better to get upstream to incorporate those changes... Other than that, I'm +1 for your solution using the vsprops file, which looks clean to me. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5134 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5134] Compiler warnings in sqlite module
Ulrich Eckhardt eckha...@satorlaser.com added the comment: Technically, both changes (or neither of them) generate the same output binaries, so I Don't Care(tm). My approach for disabling the warnings in the code has (to me) two advantages: 1. You immediately see that warnings are disabled. I would otherwise never expect that to happen in any serious project, because warnings are valuable. 2. You only have to do it once for the single source file, not in every VC project file. Happy weekend! ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5134 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5134] Compiler warnings in sqlite module
Ulrich Eckhardt eckha...@satorlaser.com added the comment: The syntax would be this: #if defined(_MSC_VER) # pragma warning(push) /* Disable warnings for this file, see http://www.sqlite.org/faq.html#q17 why we don't care for them. */ # pragma warning(disable: 4244) # pragma warning(disable: 4018) #endif ...// code that produces warnings #if defined(_MSC_VER) # pragma warning(pop) #endif For SQLite, I think the push/pop can be removed, as it is only a single file and not just a section of code. Otherwise, they are good style, in particular in header files, because they then don't affect other code. -- nosy: +eckhardt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5134 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5078] Avoid redundant call to FormatError()
New submission from Ulrich Eckhardt eckha...@satorlaser.com: For a background, see the developers' mailing list from 2009-01-26, subject FormatError() in callproc.c under win32. The attached patch removes the redundant call to FormatError(). It also makes SetException() a static function, since it is only used locally. -- assignee: theller components: ctypes files: Python-redundant-FormatError-call.0.patch keywords: patch messages: 80641 nosy: eckhardt, theller severity: normal status: open title: Avoid redundant call to FormatError() type: resource usage versions: Python 2.7 Added file: http://bugs.python.org/file12876/Python-redundant-FormatError-call.0.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5078 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1754] WindowsError messages are not properly encoded
Changes by Ulrich Eckhardt eckha...@satorlaser.com: -- nosy: +eckhardt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1754 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4949] Constness in PyErr_NewException
Ulrich Eckhardt eckha...@satorlaser.com added the comment: It's not just that function, at least not in trunk. There are also PyErr_SetFromErrnoWithFilename, PyErr_SetFromErrnoWithUnicodeFilename and _PyErr_BadInternalCall which should be made const correct, see attached patch for trunk. This patch also fixes some inconsistencies between the documentation and warning support functions. -- keywords: +patch nosy: +eckhardt Added file: http://bugs.python.org/file12745/python-2.7-const-error.1.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4949 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4893] Use separate thread support code under MS Windows CE
Ulrich Eckhardt eckha...@satorlaser.com added the comment: Okay, the changes necessary to the NT thread code are rather minimal, see attached patch. The file thread_wince.c could then be removed, too. I also removed a comment which was left over from the version before but doesn't apply any more. Added file: http://bugs.python.org/file12683/python-2.7-wince-threads.1.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4893 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4915] Port sysmodule.c to MS Windows CE
New submission from Ulrich Eckhardt eckha...@satorlaser.com: The attached patch is for sysmodule.c, it contains two changes: 1. The check whether stdin is a directory is rewritten without using fstat(), which doesn't exist under CE. 2. Replacing sys.argv[0] with the full path is skipped, CE doesn't have a current working dir or paths relative to it, so it must already be an absolute path. -- components: Interpreter Core files: python-2.7-wince-sysmodule.0.patch keywords: patch messages: 79600 nosy: eckhardt severity: normal status: open title: Port sysmodule.c to MS Windows CE type: feature request versions: Python 2.7 Added file: http://bugs.python.org/file12685/python-2.7-wince-sysmodule.0.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4915 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4893] Use separate thread support code under MS Windows CE
Ulrich Eckhardt eckha...@satorlaser.com added the comment: Okay, hopefully this patch is final. The last one was using 'errno' in debug mode, but under CE using CreateThread() it should use GetLastError(). I also took the liberty of saving that error information for both variants directly after creating the thread fails, so intermediate calls don't clobber that value. Added file: http://bugs.python.org/file12686/python-2.7-wince-threads.2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4893 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4893] Use separate thread support code under MS Windows CE
Ulrich Eckhardt eckha...@satorlaser.com added the comment: Actually, I made the distinction between the 'int e' and the 'unsigned e' consciously. When using 'errno', using an 'int' is correct. When using GetLastError(), I would have used a win32 DWORD if there was a format sequence that correctly and portably formats it, so I chose 'unsigned' as one that IMHO most likely matches it. That is also the reason for the two different error messages, otherwise I don't think it makes a big difference. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4893 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4915] Port sysmodule.c to MS Windows CE
Ulrich Eckhardt eckha...@satorlaser.com added the comment: I don't really know what happens when you try to read()/fread() from stdin that is a directory, but I guess it will fail quickly even without an explicit check by Python. A directory can be opened under win32 just like a file, so I guess that you could also set one as stdin for a process. All in all, I don't care whether the check is made or not, but it doesn't hurt to be there either. I'll submit a changed patch that has the opening curly brackets outside the conditional code. Thanks for the review, Martin, I appreciate your support on this. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4915 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4915] Port sysmodule.c to MS Windows CE
Ulrich Eckhardt eckha...@satorlaser.com added the comment: Changed patch with curly brackets outside the conditional code. Added file: http://bugs.python.org/file12689/python-2.7-wince-sysmodule.1.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4915 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4893] Use separate thread support code under MS Windows CE
Ulrich Eckhardt eckha...@satorlaser.com added the comment: That's all fine, but why do you need a variable named e in the first place? Can't you leave the code as it was before? There is an intermediate call to a function that retrieves the thread's ID. That function may or may not change the output of GetLastError(). It probably won't change errno, since it is just implemented as a call to the win32 API GetCurrentThreadId(). Still, when I have a function that fails and provides additional info through errno or GetLastError(), I personally prefer to save that value ASAP instead of relying on the fact that some call in between doesn't touch it. I don't really care too much about this piece of code, since it's just debug output, but in other cases (like #4906) making such distinction is crucial. Since people might read and copy the code, I prefer to give them a good example. If you feel differently, just drop me a note and I'll change it. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4893 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4915] Port sysmodule.c to MS Windows CE
Ulrich Eckhardt eckha...@satorlaser.com added the comment: The CE documentation mentions directories, too, but is silent on the FILE_FLAG_BACKUP_SEMANTICS use for them. Also, even using that flag, I can't open a directory under CE. It seems that this check is superfluous there. I can also confirm that you get an error if you try to redirect stdin via the commandline to a dir even before the executable is even launched. The only way to still have a dir as stdin could be to use CreateProcess(), but I'm neither sure nor do I care about such abuses. Do you want to remove the whole check for MS Windows then? Are you otherwise comfortable with the second part of the patch, the one about resolving argv[0]? ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4915 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4915] Port sysmodule.c to MS Windows CE
Ulrich Eckhardt eckha...@satorlaser.com added the comment: Next attempt, exclude all win variants from check. Added file: http://bugs.python.org/file12690/python-2.7-wince-sysmodule.2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4915 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4893] Use separate thread support code under MS Windows CE
Ulrich Eckhardt eckha...@satorlaser.com added the comment: The thread code is unaffected by the Unicode/ANSI issues, but CE doesn't have _beginthread[ex], which are mandatory for the desktop variants. I have checkin 68455 and I will try to compile the new NT code under CE to estimate how large the changes are. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4893 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4905] Use INVALID_FILE_ATTRIBUTES instead of magic numbers
New submission from Ulrich Eckhardt eckha...@satorlaser.com: GetFileAttributes[W|A] returns a DWORD with this value when it couldn't determine the file's attributes. In the Python codebase, there are basically three values this is compared with, the above macro, 0x and (DWORD)-1, it should only be the macro. However, this macro isn't defined in some SDKs (I don't remember if those were early MSVC versions or some MS Windows CE SDKs), so we also need to work around that. I'm currently preparing a patch that resolves those including the workaround when the macro isn't defined. -- components: Interpreter Core messages: 79535 nosy: eckhardt severity: normal status: open title: Use INVALID_FILE_ATTRIBUTES instead of magic numbers versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4905 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4905] Use INVALID_FILE_ATTRIBUTES instead of magic numbers
Ulrich Eckhardt eckha...@satorlaser.com added the comment: The patch replaces remaining magic numbers with INVALID_FILE_ATTRIBUTES. -- keywords: +patch Added file: http://bugs.python.org/file12673/python-2.7-fileattrib-magic.0.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4905 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4893] Use separate thread support code under MS Windows CE
New submission from Ulrich Eckhardt eckha...@satorlaser.com: There is a separate file thread_wince.h for use with CE, but that is firstly not used due to a missing macro definition and secondly it doesn't compile as it is. The attached patch defines WINCE_THREADS for CE and makes the file at least compile. Note that this doesn't touch any working code, because the CE port is currently broken anyway. Further, the changes compile, but since there are various other bits and pieces still missing, it is impossible to test it yet. -- components: Interpreter Core files: python-2.7-wince-threads.0.patch keywords: patch messages: 79466 nosy: eckhardt severity: normal status: open title: Use separate thread support code under MS Windows CE versions: Python 2.7 Added file: http://bugs.python.org/file12663/python-2.7-wince-threads.0.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4893 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4895] Missing strdup() under MS Windows CE
New submission from Ulrich Eckhardt eckha...@satorlaser.com: CE6 doesn't provide strdup() but provides an equivalent _strdup() in stdlib.h. The attached patch simply #defines strdup _strdup after including said header file. -- components: Interpreter Core files: python-2.7-wince-strdup.0.patch keywords: patch messages: 79469 nosy: eckhardt severity: normal status: open title: Missing strdup() under MS Windows CE type: compile error versions: Python 2.7 Added file: http://bugs.python.org/file12666/python-2.7-wince-strdup.0.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4895 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4841] io's close() not handling errors correctly
Ulrich Eckhardt eckha...@satorlaser.com added the comment: 4. I wonder if internal_close() should reset only the 'fd' field or if it should also reset 'readable', 'writable', 'seekable' seekable(), readable() and writable() raise an error if the file is closed. I think it's fine to leave the internal attributes unchanged. That's not what I'm concerned about. What I'm concerned about is this: f = _FileIO(open(some text file)) print f.seekable() f.__init__(open(some pipe)) print f.seekable() The cached value whether the file was seekable survives the __init__ call but is actually wrong then. Of course, one could also reset the value in __init__. Whether the file is readable or writable is different, since those values are supplied via the mode string and the code by the user and not determined automatically. I think that I just found another buglet, too: when supplying a file descriptor, dircheck() isn't actually called. os.open() under 2.5 on Debian/Linux at least allows opening '.', trunk under MS Windows fails with permission denied. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4841 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3582] thread_nt.c update
Ulrich Eckhardt eckha...@satorlaser.com added the comment: I do have an issue with the patch's startup code. The prototype for the thread entry should be DWORD WINAPI function(PVOID);. The important distinction is the WINAPI part, which resolves to __stdcall but doesn't have to. I know that some CE targets actually #define __cdecl __stdcall or vice versa, but using WINAPI always works. I'd then also change the comment to ...to adapt between our function signature and the one used by _createthreadex, as the internally used one doesn't mention __cdecl. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3582 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4856] Remove checks for win NT
New submission from Ulrich Eckhardt eckha...@satorlaser.com: There are several checks like GetVersion() 0x8000 that try to determine whether there is support for the WCHAR versions of the win32 API. Since all support for MS Windows 95, 98 and ME has been dropped, all supported systems support those APIs. Also, I need that cleanup as preparation for porting Python to MS Windows CE, so that I don't have to clone/port code for obsolete systems there. I'll be providing patches here. -- components: Interpreter Core messages: 79237 nosy: eckhardt severity: normal status: open title: Remove checks for win NT type: feature request versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4856 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3582] thread_nt.c update
Ulrich Eckhardt eckha...@satorlaser.com added the comment: You're right, Kristján, sorry for the noise. Shouldn't make claims before being fully awake ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3582 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4856] Remove checks for win NT
Ulrich Eckhardt eckha...@satorlaser.com added the comment: This patch removes all calls to win32's GetVersion() where they are used to detect NT. In posixmodule.c it was used by a wrapper function that cached the result, which then also became obsolete. -- keywords: +patch Added file: http://bugs.python.org/file12618/python-2.7-win9x-wchar-checks.0.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4856 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4841] io's close() not handling errors correctly
Ulrich Eckhardt eckha...@satorlaser.com added the comment: I have a patch here which passes the proposed change to the tests in trunk. A few notes up front though, since the patch isn't good yet: 1. The handling of the error in internal_close() isn't really good. What I'm also not sure about is whether it is correct to set the error there, the old code sometimes did set an error as reaction to internal_close() failing and sometimes not. 2. There is one place in dircheck() where I think that the error should be ignored, but I'm not sure about that. 3. This patch fixes another issue, and that is that internal_close() would call close() even if 'closefd' was not set. This e.g. happens when __init__ is called explicitly. This case is missing a test though. 4. I wonder if internal_close() should reset only the 'fd' field or if it should also reset 'readable', 'writable', 'seekable', too, i.e. apart from 'weakreflist' do the same as fileio_new() does. Added file: http://bugs.python.org/file12595/python-2.7-fileio-close-fix.0.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4841 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4846] Py_UNICODE_ISSPACE causes linker error
Ulrich Eckhardt eckha...@satorlaser.com added the comment: You beat me by 10 minutes, Alexander, otherwise I'd have had a similar patch, except moving the declaration. I agree with your rationale though, so yours is even better. Concerning including the extern C in the PyAPI_* macros, I had the same idea and think that that it would unclutter code a bit. -- nosy: +eckhardt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4846 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3582] thread_nt.c update
Ulrich Eckhardt eckha...@satorlaser.com added the comment: No, CreateThread() is not a suitable replacement, because it lacks some initialisations of the C library, as explained in the MSDN: http://msdn.microsoft.com/en-us/library/ms682453(VS.85).aspx -- nosy: +eckhardt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3582 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4841] io's close() not handling errors correctly
New submission from Ulrich Eckhardt eckha...@satorlaser.com: In _fileio.c, there is the following comment: Returns 0 on success, errno (which is 0) on failure. The problem here is the claim that errno ever was less than zero, which is simply wrong. You can see this being a problem with the following few lines: import os, io fd = os.open( some existing file, os.O_RDONLY) s1 = os.fdopen(fd) s2 = io.open(fd) os.close(fd) s1.close() s2.close() The call to close() pulls the file from under the feet of the two stream objects, but only the one opened with os.fdopen() actually detects that. For the second one, errno is set, but to a positive value which isn't detected correctly. -- components: Interpreter Core messages: 79120 nosy: eckhardt severity: normal status: open title: io's close() not handling errors correctly type: behavior versions: Python 2.6, Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4841 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4841] io's close() not handling errors correctly
Ulrich Eckhardt eckha...@satorlaser.com added the comment: This adds a test that the close() correctly fails with an IOError. -- keywords: +patch Added file: http://bugs.python.org/file12593/python-2.7-fileio-close-test.0.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4841 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4846] Py_UNICODE_ISSPACE causes linker error
Ulrich Eckhardt eckha...@satorlaser.com added the comment: Actually, providing the patch for PyAPI_Data/PyAPI_Func wouldn't be so hard, but there are lots of headers that need to be changed, i.e. all their existing extern C clauses removed. What I would do is build the Python shared library as it is and then use e.g. depends.exe (www.dependencywalker.com) to make sure the symbols before and after are the same. That's a different issue though and it's not pressing. Is it possible to clone this issue and make it a feature request (Include externC in PyAPI_* macros)? ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4846 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4829] confusing error for file(foo, w++)
New submission from Ulrich Eckhardt eckha...@satorlaser.com: Specifying the '+' more than once while opening a file results in the error Must have exactly one of read/write/append mode. The attached patch extends that with .. and at most one optional plus. Further, the patch checks these after the loop that parses the mode string, avoiding some unnecessary gotos and saving a few lines of code overall. -- components: Interpreter Core files: python-2.7-fopen-mode-parsing.0.patch keywords: patch messages: 79043 nosy: eckhardt severity: normal status: open title: confusing error for file(foo, w++) type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file12581/python-2.7-fopen-mode-parsing.0.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4829 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4817] PyOS_GetLastModificationTime is unused
New submission from Ulrich Eckhardt eckha...@satorlaser.com: This is just to record that the above function is wrongly documented, inconsistently implemented, but fortunately unused, so it can be removed. In addition to the patch attached, there are two files that can be removed: Python/getmtime.c RISCOS/Python/getmtime_riscos.c -- components: Interpreter Core files: python-2.7-eradicate-getmtime.0.patch keywords: patch messages: 78945 nosy: eckhardt severity: normal status: open title: PyOS_GetLastModificationTime is unused type: resource usage versions: Python 2.7 Added file: http://bugs.python.org/file12564/python-2.7-eradicate-getmtime.0.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4817 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4807] wrong wsprintf usage
New submission from Ulrich Eckhardt eckha...@satorlaser.com: Note up front: there is a win32 function wsprintf() and an ISO C function swprintf(), these are different things in case you wonder. In _winreg.c, there are two functions that use wsprintf on a char buffer, while the function takes a TCHAR buffer instead. This leads to compile warning and runtime errors when _UNICODE is defined, like e.g. under MS Windows CE. The attached patch replaces the two calls to that function with calls to fprintf() and PyString_FromFormat(). -- components: Windows files: python-2.7-no-wsprint.0.patch keywords: patch messages: 78790 nosy: eckhardt severity: normal status: open title: wrong wsprintf usage type: compile error versions: Python 2.7 Added file: http://bugs.python.org/file12538/python-2.7-no-wsprint.0.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4807 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4681] mmap offset should be off_t instead of ssize_t, and size calculation needs corrected
Changes by Ulrich Eckhardt eckha...@satorlaser.com: -- nosy: +eckhardt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4681 ___ ___ 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
Ulrich Eckhardt eckha...@satorlaser.com added the comment: Concerning the SetArgv( int, char**), that one will have to be changed to a SetArgv( int, char const* const*), i.e. applying the const on both levels. Otherwise, there is no implicit conversion between the two. The reason is a bit complicated: if the function stored a pointer-to-const in the array, it would become a pointer-to-nonconst outside. Only if modification of the array is forbidden, changing the element type to pointer-to-const is allowed. Otherwise, I'm +1 on this kind of changes, because it makes immediately obvious which functions modify a passed buffer and which don't. -- nosy: +eckhardt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1699259 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4075] Use WCHAR variant of OutputDebugString
Ulrich Eckhardt [EMAIL PROTECTED] added the comment: If this patch required for CE 5.0? The patch I created is required for all CEs that I know of. I have personally worked with 4.20, 5 and now 6, and had some exchange with others who worked on 3.x variants to get STLport (C++ stdlibrary implementation) to run. AFAIK, none of them support the *A functions, so this patch or something similar is required for every CE flavor out there. Roumen, you mentioned the way that the PythonCE project did it, which also works, but I'd say that that code is obsolete, because the emulated functions actually create a win9x-like environment, while Python has officially dropped support for that. The problem is that the *W functions are badly supported on win9x while the *A functions are unsupported on CE. The NT variants (NT, win2000..) support both APIs, but the *A functions are wrappers around the *W functions and don't provide the whole functionality that the OS actually supports. So, what this path does is to help phase out the *A functions, gaining more thorough Unicode support while at the same time easing porting to CE. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4075 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4075] Use WCHAR variant of OutputDebugString
Ulrich Eckhardt [EMAIL PROTECTED] added the comment: PythonCE project use xxxA functions for CE .NET 4.20 platform. Look again. The PythonCE project adds a header and sourcefile (wince_compatibility.h/c) which adds these functions. In other words, it doesn't use the xxxA functions of the win32 API (which don't exist under CE) but its own replacements. I was thinking of going that way too, but in the end decided against it unless absolutely necessary. The point is that this approach allowed minimal changes to the Python code which still had to support the xxxA variants for win9x. However, since IIRC 2.6 support for win9x has been dropped, so now it makes much more sense to use the WCHAR APIs which is what all supported MS Windows versions use internally anyway. This allows code to work under CE unchanged, avoids unnecessary conversions and provides better Unicode support. BTW: in case somebody actually wants to resurrect the win9x support, there is a library from Microsoft that provides the xxxW functions for that platform. Of course that's not a cure but just a band-aid with reduced functionality, but at least it's possible. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4075 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4098] surprised by default list parameter
Ulrich Eckhardt [EMAIL PROTECTED] added the comment: http://effbot.org/pyfaq/why-are-default-values-shared-between-objects.htm The same recently cropped up on the users mailinglist under the topic default value in __init__. -- nosy: +eckhardt ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4098 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4075] Use WCHAR variant of OutputDebugString
Ulrich Eckhardt [EMAIL PROTECTED] added the comment: Roumen, just and explanation on the TCHAR/WCHAR/CHAR issue under win32... In the old days, DOS/Windows was built with 8-bit characters using codepages. So functions like CreateFile() took a char string that used the current local codepage as encoding. Now, since NT 4 (maybe even 3) the internally used char type is a 16-bit type. In order to ease conversion, the function CreateFile() was removed (it still exists in oldnames.lib) and replaced with CreateFileW() and CreateFileA(), which explicitly take either a codepage-encoded 8-bit string or a UCS2/UTF-16 16-bit string. Under win9x, CreateFileW() actually tried to convert to the internally used 8-bit character type, while under NT, CreateFileA() converted from the codepage to the UTF-16 character type. Now, under CE, which is an embedded OS, neither the (legacy/obsolete/deprecated) codepages nor the according CreateFileA() functions exist. They simply have been removed to save space and because they are of limited functionality anyway. Which CE version? All of them, since at least CE3 (CE6 is current). Why not treat all strings as wide string? Because that would actually change the existing meaning of them and make it harder to impossible to create code that is portable. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4075 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4075] Use WCHAR variant of OutputDebugString
Ulrich Eckhardt [EMAIL PROTECTED] added the comment: Actually, even _Py_NegativeRefcount() passes a statically sized buffer with 300 chars. Other than that, there is get_ref_type() which uses one with 350 chars, but AFAICT, that's the largest one. Attached accordingly modified patch. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4075 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4075] Use WCHAR variant of OutputDebugString
New submission from Ulrich Eckhardt [EMAIL PROTECTED]: The attached patch converts the call to OutputDebugString() with a 'TCHAR' parameter (which boils down to a 'char') to one using a 'WCHAR' parameter, allowing the code to be compiled under MS Windows CE, which doesn't have the 'char' version. -- components: Windows files: Python-OutputDebugStringW.0.patch keywords: patch messages: 74527 nosy: eckhardt severity: normal status: open title: Use WCHAR variant of OutputDebugString type: feature request versions: Python 2.7 Added file: http://bugs.python.org/file11749/Python-OutputDebugStringW.0.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4075 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4077] Py_FatalError cleanup patch
New submission from Ulrich Eckhardt [EMAIL PROTECTED]: This patch does two things: * It removes trailing newlines from the arguments given to Py_FatalError() because a trailing newline is already added automatically. * It fixes the declaration in ffi.c to take a 'const char*'. -- components: None files: Python-FatalError-no-newline.0.patch keywords: patch messages: 74531 nosy: eckhardt severity: normal status: open title: Py_FatalError cleanup patch type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file11750/Python-FatalError-no-newline.0.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4077 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4051] use of TCHAR under win32
Ulrich Eckhardt [EMAIL PROTECTED] added the comment: Add a patch that fixes a warning. -- keywords: +patch Added file: http://bugs.python.org/file11708/Python-unicode-redefine-warning.0.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4051 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
