[issue24185] Add Function for Sending File to Trash (or Recycling Bin)
Virgil Dupras added the comment: For further references, there's also https://mail.python.org/pipermail/python-ideas/2014-December/030547.html which is a deeper discussion and brings even more arguments against it. Even though I'd love to have some of my code integrated into the core, arguments against its inclusion are pretty strong. -- nosy: +vdupras ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24185 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21643] File exists error during venv --upgrade
Virgil Dupras added the comment: I could reproduce the bug on the v3.4.1 tag, on the 3.4 branch and on the default branch. I think that one of the conditions for the bug to arise is to have the lib64 symlink created (as described in #21197). I reproduced the bug on Gentoo and Arch environments. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21643 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21643] File exists error during venv --upgrade
New submission from Virgil Dupras: There seems to have been a regression in Python 3.4.1 with pyvenv --upgrade, and this regression seems to be caused by #21197. It now seems impossible to use the --upgrade flag without getting a File exists error. Steps to reproduce: $ pyvenv env $ pyvenv --upgrade env Error: [Errno 17] File exists: '/pwd/env/lib' - '/pwd/env/lib64' -- components: Library (Lib) keywords: 3.4regression messages: 219617 nosy: vdupras, vinay.sajip priority: normal severity: normal status: open title: File exists error during venv --upgrade versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21643 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15051] Can't compile Python 3.3a4 on OS X
New submission from Virgil Dupras hs...@hardcoded.net: I try to compile Pyhton 3.3a4 on a OS X 10.7 with XCode 4.3.3 and it fails. I tried a few configuration options, but even with a basic ./configure make, I get this: ./python.exe -SE -m sysconfig --generate-posix-vars Could not find platform dependent libraries exec_prefix Consider setting $PYTHONHOME to prefix[:exec_prefix] python.exe(11771) malloc: *** mmap(size=7310873954244194304) failed (error code=12) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug Could not import runpy module make: *** [Lib/_sysconfigdata.py] Segmentation fault: 11 I tried setting PYTHONHOME to `pwd`, to no avail. Am I doing something wrong? The same thing happens with v3.3a3. If I go back to v3.2.3, it compiles fine on the same system. I also tried on the repo's tip, same error. -- components: Build messages: 162683 nosy: vdupras priority: normal severity: normal status: open title: Can't compile Python 3.3a4 on OS X type: compile error versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15051 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11076] Iterable argparse Namespace
Virgil Dupras hs...@hardcoded.net added the comment: Here's a documentation-only patch which adds a section about using vars() to convert a namespace to a dict. If this becomes a documentation issue, can we target Python 3.2.1 instead of Python 3.3? -- Added file: http://bugs.python.org/file20734/issue11076_doc_only.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11076 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11076] Iterable argparse Namespace
Virgil Dupras hs...@hardcoded.net added the comment: I didn't know about vars() (well, I knew it existed, but never was quite sure what it did). Given that I'm not a Python newbie, I'm guessing I'm not alone in this situation. Maybe that instead of making the Namespace iterable, we should just add an example usage of vars() in argparse's documentation? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11076 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11076] Iterable argparse Namespace
Virgil Dupras hs...@hardcoded.net added the comment: I went ahead and created a patch (with test and doc) making argparse.Namespace iterable. -- keywords: +patch -easy Added file: http://bugs.python.org/file20648/issue11076.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11076 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11076] Iterable argparse Namespace
New submission from Virgil Dupras hs...@hardcoded.net: Currently, there is no (documented) way to easily extract arguments in an argparse Namespace as a dictionary. This way, it would me easy to interface a function taking a lot of kwargs like this: args = parser.parse_args() my_function(**dict(args)) There's _get_kwargs() but it's a private undocumented method. I guess that making it public would be problematic because of the namespace pollution that would occur. That's why I'm proposing to make it iterable. If it isn't rejected, I'd gladly work on the required patch. -- components: Library (Lib) keywords: easy messages: 127582 nosy: vdupras priority: normal severity: normal status: open title: Iterable argparse Namespace type: feature request versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11076 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10418] test_io hangs on 3.1.3rc1
New submission from Virgil Dupras hs...@hardcoded.net: I downloaded Python 3.1.3rc1 this morning to do my civic duty of testing it. I don't know what I'm doing wrong, but for me, test_io hangs and never completed. I'm on OS X 10.6.5. I ran it with: $ ./python.exe Lib/test/regrtest.py test_io And I got: test_io Testing large file ops skipped on darwin. It requires 2147483648 bytes and a long time. Use 'regrtest.py -u largefile test_io' to run it. Testing large file ops skipped on darwin. It requires 2147483648 bytes and a long time. Use 'regrtest.py -u largefile test_io' to run it. python.exe(12242) malloc: *** mmap(size=9223372036854775808) failed (error code=12) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug python.exe(12242) malloc: *** mmap(size=9223372036854775808) failed (error code=12) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug python.exe(12242) malloc: *** mmap(size=9223372036854775808) failed (error code=12) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug hangs at this point I build Python with this configuration: $ ./configure --enable-universalsdk=/ --enable-framework --with-universal-archs=intel Oh, and it's being run as 64-bit. By looking at the size being allocated, by guess that it's some kind of overflow thing or something. -- components: Tests messages: 121194 nosy: vdupras priority: release blocker severity: normal status: open title: test_io hangs on 3.1.3rc1 type: crash versions: Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10418 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10418] test_io hangs on 3.1.3rc1
Virgil Dupras hs...@hardcoded.net added the comment: I ran the test with the -v option flag. The malloc error don't happen at the same place the hang up happens. The first one happens at: test_readline (test.test_io.PyIOTest) ... ok test_unbounded_file (test.test_io.PyIOTest) ... skipped 'test can only run in a 32-bit address space' test_with_open (test.test_io.PyIOTest) ... ok test_buffering (test.test_io.CBufferedReaderTest) ... ok test_constructor (test.test_io.CBufferedReaderTest) ... python.exe(24083) malloc: *** mmap(size=9223372036854775808) failed (error code=12) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug ok test_context_manager (test.test_io.CBufferedReaderTest) ... ok test_detach (test.test_io.CBufferedReaderTest) ... ok And the second one happens at: test_readlines (test.test_io.PyBufferedReaderTest) ... ok test_repr (test.test_io.PyBufferedReaderTest) ... ok test_threads (test.test_io.PyBufferedReaderTest) ... skipped resource 'cpu' is not enabled test_constructor (test.test_io.CBufferedWriterTest) ... python.exe(24083) malloc: *** mmap(size=9223372036854775808) failed (error code=12) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug ok test_context_manager (test.test_io.CBufferedWriterTest) ... ok test_destructor (test.test_io.CBufferedWriterTest) ... ok And finally, the hang: test_io_after_close (test.test_io.CMiscIOTest) ... ok test___all__ (test.test_io.PyMiscIOTest) ... ok test_abc_inheritance (test.test_io.PyMiscIOTest) ... ok test_abc_inheritance_official (test.test_io.PyMiscIOTest) ... ok test_abcs (test.test_io.PyMiscIOTest) ... ok test_attributes (test.test_io.PyMiscIOTest) ... ok test_blockingioerror (test.test_io.PyMiscIOTest) ... ok test_io_after_close (test.test_io.PyMiscIOTest) ... ok test_interrupted_write_buffered (test.test_io.CSignalsTest) ... hang -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10418 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10418] test_io hangs on 3.1.3rc1
Virgil Dupras hs...@hardcoded.net added the comment: Nobody else can reproduce the bug? I'm not sure I can fix this (although I can try). I tried to re-compile 3.1.2 with the same flags and run test_io and it passes, so something happened between 3.1.2 and 3.1.3rc1. So, I'll give it a look, but if someone more experienced can reproduce it... -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10418 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10418] test_io hangs on 3.1.3rc1
Virgil Dupras hs...@hardcoded.net added the comment: Ooh, darn, that was it. I installed it and afterwards, the tests passed. Sorry for the fuss, I'll keep that gotcha in mind next time. -- resolution: - invalid status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10418 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue839159] iterators broken for weak dicts
Virgil Dupras hs...@hardcoded.net added the comment: It looks like this issue has been fixed in issue7105 already. Can we close this ticket? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue839159 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue839159] iterators broken for weak dicts
Virgil Dupras hs...@hardcoded.net added the comment: We might as well backport Antoine's patch rather than take this one (even if mine for 2.x already). It would be weird to have 2 wildly different patches to solve the same problem. Maybe close this ticket and flag issue7105 for backporting? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue839159 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8392] unit tests rather light on testing __import__(..., level)
Virgil Dupras hs...@hardcoded.net added the comment: If I understand the patch correctly, this patch basically add a test for relative imports. I'm pretty sure this is already testes in importlib.test. Brett, am I right? If yes, there's no point in applying this patch. -- nosy: +vdupras ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8392 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8392] unit tests rather light on testing __import__(..., level)
Virgil Dupras hs...@hardcoded.net added the comment: Because importlib is already well tested and that it already has the machinery to test __import__ instead of the importlib code, I suggest that we re-use importlib's relative tests instead. Attached is a patch that does this. I made sure that __import__ was actually called. -- Added file: http://bugs.python.org/file18138/issue8392.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8392 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7830] Flatten nested functools.partial
Virgil Dupras hs...@hardcoded.net added the comment: Applies cleanly on the py3k branch at r83069, the tests work correctly (fail before applying the patch, success afterwards), and, to the best of my C-API knowledge, the C code is alright. Oh, and it behaves as described... Python 3.2a0 (py3k:83069M, Jul 23 2010, 12:40:49) [GCC 4.2.1 (Apple Inc. build 5659)] on darwin Type help, copyright, credits or license for more information. def foo(a, b, c): pass ... from functools import partial p1 = partial(foo, 1) p1.func, p1.args (function foo at 0x1004531e8, (1,)) p2 = partial(foo, 2) p2.func, p2.args (function foo at 0x1004531e8, (2,)) -- nosy: +vdupras ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7830 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7830] Flatten nested functools.partial
Virgil Dupras hs...@hardcoded.net added the comment: Oops, used it wrong (but it still works correctly). p2 = partial(p1, 2) p2.func, p2.args (function foo at 0x10051da68, (1, 2)) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7830 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8392] unit tests rather light on testing __import__(..., level)
Virgil Dupras hs...@hardcoded.net added the comment: Brett, I think there's a problem with the tweak you made to the patch. There was already a testcase called RelativeImportTests and you've hidden it (that I why I called it ImportlibRelativeImportTests initially). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8392 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9043] 2to3 doesn't handle byte comparison well
New submission from Virgil Dupras hs...@hardcoded.net: If we run 2to3 on the following code: s = b' ' print s[0] == s we end up with this: s = b' ' print(s[0] == s) However, the first code, under python2 prints True while the converted code, under python3 prints False. Shouldn't 2to3 convert this code to: s = b' ' print s[0:1] == s instead? -- components: 2to3 (2.x to 3.0 conversion tool) messages: 108272 nosy: vdupras priority: normal severity: normal status: open title: 2to3 doesn't handle byte comparison well type: behavior versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9043 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6095] os.curdir as the default argument for os.listdir
Virgil Dupras hs...@hardcoded.net added the comment: Here's another one. I hadn't realized that it was useless to target the 2.x codebase. So I re-worked this on py3k. The change is non-trivial, since the non-windows/non-os2 part of the code has significantly changed in 3k. This time, since oname is released later and used in error conditions, I thought it was worth it to allocate a new PyBytes for the default value. I also modified the documentation so that it tells about path's default value. -- Added file: http://bugs.python.org/file16984/t6095_py3k.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6095 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6095] os.curdir as the default argument for os.listdir
Virgil Dupras hs...@hardcoded.net added the comment: Since I last submitted this patch, my leet C skills have improved. I'm submitting another patch, without the needless PyUnicode creation this time. (Moreover, I think the previous patch was wrong to insert code before variable declaration of the block) -- Added file: http://bugs.python.org/file16978/t6095_2.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6095 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7350] csv doesn't handle escaped characters properly
Virgil Dupras hs...@hardcoded.net added the comment: You have to tell the reader how to handle escaping. In your case, you should send escapechar=\\ in reader()'s kwargs. -- nosy: +vdupras ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7350 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6095] os.curdir as the default argument for os.listdir
Virgil Dupras hs...@hardcoded.net added the comment: 1. Yeah, I know. At first, that's what I wanted to do, but it resulted in a lot of code duplication (alloc, memerror, copy), which I didn't much like. But then again, what I ended up writing (because I realized I had to decref the new po) uses up more lines anyway... 2. oops 3. I did it because all other tests do it. I thought there had to be a reason (but then again, that old broken lsdir test had been there for a while...). Even if there's no reason. the new test would really stand out compared to the rest... -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6095 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6095] os.curdir as the default argument for os.listdir
Virgil Dupras hs...@hardcoded.net added the comment: I saw this ticket as a good way to get my feet wet (I almost never touched C) with Python's C API, so I went ahead and did the part for OS X. I also did the Windows part, but I'm not setup to compile Python on Windows, so I don't even know if it remotely works. It would be nice if someone could review this patch and tell me about mistakes (such as memory management ones, probably). Thanks! -- keywords: +patch nosy: +vdupras Added file: http://bugs.python.org/file14296/t6095.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6095 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5679] cleanUp stack for unittest
Virgil Dupras hs...@hardcoded.net added the comment: So, we are talking about adding a feature that could cause problem whether cleanup is performed before tearDown or after tearDown. Don't we risk confusing developers who are not familiar with the cleanup order? Do we really want to add this feature? The added functionality doesn't seem so attractive compared to the risk of confusion. We might as well continue to let the developers implement this feature in their own TestCase subclasses (for example, my own subclass already implement a TestCase.create_tmpdir(name) (which does cleanup, of course), which is easier to use than the rmtree example that was given as a use case). At least, when they do, they know about the cleanup order. -- nosy: +vdupras ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5679 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1741130] struct.pack(I, foo); struct.pack(L, foo) should fail
Virgil Dupras hs...@hardcoded.net added the comment:
While the behavior cannot be reproduced in the trunk, in can be
reproduced in the 2.6 release:
$ python -W ignore
Python 2.6.1 (r261:67515, Dec 6 2008, 16:42:21)
[GCC 4.0.1 (Apple Computer, Inc. build 5370)] on darwin
Type help, copyright, credits or license for more information.
import struct
struct.pack('L', 'foobar')
'\x00\x00\x00\x00'
struct.pack('I', 'foobar')
'\x00\x00\x00\x00'
struct.pack('i', 'foobar')
Traceback (most recent call last):
File stdin, line 1, in module
struct.error: required argument is not an integer
--
nosy: +vdupras
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1741130
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5345] cStringIO class name typo
Virgil Dupras hs...@hardcoded.net added the comment: The documentation says: Another difference from the StringIO module is that calling StringIO() with a string parameter creates a read-only object. Unlike an object created without a string parameter, it does not have write methods. These objects are not generally visible. They turn up in tracebacks as StringI and StringO. And there seem to have been some activity about this around r33834. -- nosy: +vdupras ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5345 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue839159] iterators broken for weak dicts
Virgil Dupras hs...@hardcoded.net added the comment: About duplicated code and performance: When I look at the duplicated code, I don't see anything that remotely looks like a performance tweak. Just to make sure, I made a bench: #!/usr/bin/env python import sys sys.path.insert(0, 'Lib') import timeit import weakref class Foo(object): pass def setup(): L = [Foo() for i in range(1000)] global d d = weakref.WeakValueDictionary(enumerate(L)) del L[:500] # have some dead weakrefs def do(): d.values() print timeit.timeit(do, setup, number=10) Results without the patch: ./python.exe weakref_bench.py 0.804216861725 Results with the patch: $ ./python.exe weakref_bench.py 0.813000202179 I think the small difference in performance is more attributable to the extra processing the weakref dict does than the deduplication of the code itself. About the test_weak_*_dict_flushed_dead_items_when_iters_go_out: If a weakref dict keeps its weak reference alive, it's not an implementation detail, it's a bug. The whole point of using such dicts is to not keep keys or values alive when they go out. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue839159 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue839159] iterators broken for weak dicts
Virgil Dupras hs...@hardcoded.net added the comment: Oh, that's me again not correctly reading my own tests. It's the *_are_not_held_* tests that test that no reference is kept. I agree about the *_flushed_dead_items_* being an implementation detail. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue839159 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1117601] os.path.exists returns false negatives in MAC environments.
Virgil Dupras [EMAIL PROTECTED] added the comment:
hsoft-dev:~ hsoft$ mkdir foobar
hsoft-dev:~ hsoft$ echo baz foobar/baz
hsoft-dev:~ hsoft$ chmod 000 foobar/baz
hsoft-dev:~ hsoft$ python
Python 2.5.2 (r252:60911, Feb 22 2008, 07:57:53)
[GCC 4.0.1 (Apple Computer, Inc. build 5363)] on darwin
Type help, copyright, credits or license for more information.
import os.path
os.path.exists('foobar/baz')
True
hsoft-dev:~ hsoft$ chmod 000 foobar
hsoft-dev:~ hsoft$ python
Python 2.5.2 (r252:60911, Feb 22 2008, 07:57:53)
[GCC 4.0.1 (Apple Computer, Inc. build 5363)] on darwin
Type help, copyright, credits or license for more information.
import os.path
os.path.exists('foobar/baz')
False
os.path.exists('foobar')
True
This seems like the correct behavior to me.
--
nosy: +vdupras
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1117601
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2153] unittest.py modernization
Virgil Dupras [EMAIL PROTECTED] added the comment: This patch has gone invalid due to some recent conflicting changes. I remade it and I'm resubmitting it hoping that it will get applied. Added file: http://bugs.python.org/file11086/unittest_modern2.diff ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2153 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3189] Py3k DeprecationWarning in difflib
New submission from Virgil Dupras [EMAIL PROTECTED]: When running with the -3 flag, difflib creates DeprecationWarnings. I attach a patch fixing them. There was a note in the code saying DOES NOT WORK for x in a. However, after my changes, tests still pass, so I removed these notices. If someone knows what this was all about, let me know. -- components: Library (Lib) files: difflib_py3k_deprecation.diff keywords: patch messages: 68677 nosy: vdupras severity: normal status: open title: Py3k DeprecationWarning in difflib type: behavior versions: Python 2.6 Added file: http://bugs.python.org/file10717/difflib_py3k_deprecation.diff ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3189 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3189] Py3k DeprecationWarning in difflib
Virgil Dupras [EMAIL PROTECTED] added the comment: It slipped out of my mind that performance was probably important for this module, so I ditched that nested get call and went if an if..else. Added file: http://bugs.python.org/file10718/difflib_py3k_deprecation2.diff ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3189 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2162] unittest.findTestCases undocumented
Virgil Dupras [EMAIL PROTECTED] added the comment: Can't we close this ticket? __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2162 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2387] cStringIO and unicode
New submission from Virgil Dupras [EMAIL PROTECTED]: hsoft-dev:python hsoft$ python Python 2.5.1 (r251:54869, Apr 18 2007, 22:08:04) [GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin Type help, copyright, credits or license for more information. from cStringIO import StringIO StringIO(u'foo').read() 'foo' hsoft-dev:python hsoft$ ./python.exe Python 2.6a1+ (trunk:61515, Mar 18 2008, 13:38:47) [GCC 4.0.1 (Apple Inc. build 5465)] on darwin Type help, copyright, credits or license for more information. from cStringIO import StringIO StringIO(u'foo').read() 'f\x00o\x00o\x00' The documentation says: Unlike the memory files implemented by the StringIO module, those provided by this module are not able to accept Unicode strings that cannot be encoded as plain ASCII strings. Attached a patch to test_StringIO. -- components: Library (Lib) files: cStringIO_unicode_test.diff keywords: patch messages: 63911 nosy: vdupras severity: normal status: open title: cStringIO and unicode type: behavior versions: Python 2.6 Added file: http://bugs.python.org/file9726/cStringIO_unicode_test.diff __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2387 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue984219] hotspot.stats.load is very slow
Virgil Dupras [EMAIL PROTECTED] added the comment: I had a 54 mb hotshot profile lying around, and it is indeed very long to load, so I ran a profiling session of hotshot.stats.load(MY_BIG_FILE) with python and stdlib of r61515, and here are the results (the resulting prof file is 27 mb): 96541166 function calls in 299.936 CPU seconds Ordered by: cumulative time List reduced from 30 to 15 due to restriction 15 ncalls tottime percall cumtime percall filename:lineno(function) 10.0000.000 299.936 299.936 stats.py:11(load) 1 95.089 95.089 299.936 299.936 stats.py:22(load) 27583167 51.1830.000 61.8150.000 log.py:95(next) 13791583 59.3140.000 59.3140.000 profile.py:328(trace_dispatch_return) 13791583 35.0140.000 42.9100.000 stats.py:54(new_frame) 13791584 40.8070.000 40.8070.000 profile.py:295(trace_dispatch_call) 13791583 10.6320.000 10.6320.000 log.py:138(_decode_location) 137915837.8970.0007.8970.000 stats.py:87(__init__) 10.0000.0000.0000.000 pstats.py:73(__init__) 10.0000.0000.0000.000 pstats.py:95(init) 10.0000.0000.0000.000 pstats.py:138(get_top_level_stats) 10.0000.0000.0000.000 log.py:24(__init__) 10.0000.0000.0000.000 pstats.py:117(load_stats) 10.0000.0000.0000.000 profile.py:436(create_stats) 10.0000.0000.0000.000 profile.py:440(snapshot_stats) 96541166 function calls in 299.936 CPU seconds Ordered by: internal time List reduced from 30 to 20 due to restriction 20 ncalls tottime percall cumtime percall filename:lineno(function) 1 95.089 95.089 299.936 299.936 stats.py:22(load) 13791583 59.3140.000 59.3140.000 profile.py:328(trace_dispatch_return) 27583167 51.1830.000 61.8150.000 log.py:95(next) 13791584 40.8070.000 40.8070.000 profile.py:295(trace_dispatch_call) 13791583 35.0140.000 42.9100.000 stats.py:54(new_frame) 13791583 10.6320.000 10.6320.000 log.py:138(_decode_location) 137915837.8970.0007.8970.000 stats.py:87(__init__) 10.0000.0000.0000.000 log.py:24(__init__) 10.0000.0000.0000.000 profile.py:440(snapshot_stats) 10.0000.0000.0000.000 pstats.py:138(get_top_level_stats) 300.0000.0000.0000.000 pstats.py:484(func_std_string) 50.0000.0000.0000.000 posixpath.py:306(normpath) 10.0000.000 299.936 299.936 stats.py:11(load) 240.0000.0000.0000.000 stats.py:80(__init__) 10.0000.0000.0000.000 pstats.py:117(load_stats) 10.0000.0000.0000.000 profile.py:402(simulate_call) 10.0000.0000.0000.000 profile.py:118(_get_time_resource) 10.0000.0000.0000.000 pstats.py:73(__init__) 10.0000.0000.0000.000 pstats.py:95(init) 10.0000.0000.0000.000 profile.py:166(__init__) So the bulk of the time seems to be taken by the sheer number of trace_dispatch_return and trace_dispatch_call calls. I took a quick look, but I'm not sure I can do anything to make it faster. If no one else has any idea, I suggest just closing the ticket. -- nosy: +vdupras Tracker [EMAIL PROTECTED] http://bugs.python.org/issue984219 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2127] sqlite3 docs should mention utf8 requirement
Virgil Dupras added the comment: Ok then, we need a test for this. Patch attached. However, I don't know if I applied Amaury's patch wrong or if I miss a ./configure option or something, but even with the patch, the test fails. Another thing: Why isn't the sqlite3 test suite a part of python's regression test suite? Or is it and I didn't notice? -- keywords: +patch Added file: http://bugs.python.org/file9566/sqlite_connect_test.diff __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2127 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2127] sqlite3 docs should mention utf8 requirement
Virgil Dupras added the comment: u':memory:'? That already worked before the patch because the implicit encoding with 'ascii' does not bump into any non-ascii character. Nope, one has to call connect with a filename containing non-ascii characters. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2127 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1738] filecmp.dircmp does exact match only
Virgil Dupras added the comment: The documentation doesn't say anything about dircmp being supposed to support pattern matching. This ticket is a feature request rather than a bug. -- components: +Library (Lib) -None nosy: +vdupras type: behavior - feature request __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1738 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue839159] iterators broken for weak dicts
Virgil Dupras added the comment: I made a patch to fix the problem. The cleaning up of they weakref keys or values will be held until all references to iterators created by the weakdict are dead. I also couldn't resist removing code duplication of code in items(), keys() and values(). At first, I couldn't understand why this whole remove(), _remove() and selfref() mechanism was in place. I had removed them and replaced them with methods, and the tests still passed. Then I realized it was to make sure keys and values didn't prevent the weak dicts from being freed. I added tests for this. -- keywords: +patch nosy: +vdupras type: - behavior versions: +Python 2.6 Added file: http://bugs.python.org/file9537/weakref_dict_iter.diff Tracker [EMAIL PROTECTED] http://bugs.python.org/issue839159 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2162] unittest.findTestCases undocumented
Virgil Dupras added the comment: findTestCases is an obsolete function. From the code: # Expose obsolete functions for backwards compatibility __all__.extend(['getTestCaseNames', 'makeSuite', 'findTestCases']) -- nosy: +vdupras __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2162 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2153] unittest.py modernization
New submission from Virgil Dupras: What prompted me to do these changes is that Backward compatibility section for 2.1 and earlier. How long are we going to keep this? According to svn, no commit has been made on the 2.1 branch since 2003. Is it safe to assume no unittest change is ever going to be backported to 2.1? Then, while I was in it, I made other changes: - dict.has_key(key) -- key in dict - raise Exception, args -- raise Exception(args) - try..except KeyboardInterrupt: raise except: do_stuff() -- try..except Exception: do_stuff() - __metaclass__ = type -- all classes are now object subclasses I'm not sure about the last one. Are those 2 equivalent? Is there a reason to keep is as __metaclass__ = type? regrtest passed for me. -- components: Tests files: unittest_modern.diff messages: 62622 nosy: vdupras severity: minor status: open title: unittest.py modernization type: feature request versions: Python 2.6 Added file: http://bugs.python.org/file9479/unittest_modern.diff __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2153 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2156] TestCase.tmpdir(), TestCase.mock()
New submission from Virgil Dupras: I've been using unittest for quite a while. One thing I got tired with is the code duplication for file management and mocking. A few months ago I created this nifty little TestCase subclass and I've been using it ever since. It works quite well. Am I the only one to extensively use temporary files and mocking in my tests? If not, I would suggest integrating my little subclass to unittest.Testcase, or if people think these functionalities out-scope unittest.TestCase, maybe we could put it in a separate unit. Here's the unit I have here. -- components: Tests files: testcase.py messages: 62627 nosy: vdupras severity: minor status: open title: TestCase.tmpdir(), TestCase.mock() type: feature request versions: Python 2.6 Added file: http://bugs.python.org/file9481/testcase.py __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2156 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2127] sqlite3 docs should mention utf8 requirement
Virgil Dupras added the comment: Shouldn't we apply this patch directly on pysqlite? Any change made to the sqlite3 module will be overwritten in the next refresh, right? Anyway, I'm not 100% sure, but it might already be fixed: http://www.initd.org/tracker/pysqlite/changeset/452 So, maybe create a ticket to use the latest version of pysqlite? __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2127 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2153] unittest.py modernization
Virgil Dupras added the comment: Isn't it why KeyboardInterrupt is a subclass of BaseException instead of Exception (along with SystemExit)? so that except Exception: doesn't catch it? __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2153 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2156] TestCase.tmpdir(), TestCase.mock()
Virgil Dupras added the comment: Oh, you meant hs.path? ah yeah, it's just for tmppath(), which is of no use except in my own stuff. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2156 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2156] TestCase.tmpdir(), TestCase.mock()
Virgil Dupras added the comment: Well, yeah, but I'm the owner, it's not like if the copyright was a problem. I'd gladly release it (and the test unit that goes with it) under BSD. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2156 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2144] os.environ should inherit dict
Virgil Dupras added the comment: The performance gain is rather good: hsoft-dev:python hsoft$ ./python.exe -m timeit -s import os os.environ['HOME'] 100 loops, best of 3: 1.16 usec per loop hsoft-dev:python hsoft$ patch -p0 environ-modern.diff patching file Lib/os.py hsoft-dev:python hsoft$ ./python.exe -m timeit -s import os os.environ['HOME'] 100 loops, best of 3: 0.428 usec per loop The regression tests still pass, and modernization of the code is a nice thing. +1 -- nosy: +vdupras __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2144 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2127] sqlite3 docs should mention utf8 requirement
Virgil Dupras added the comment:
+1 I've been pulling my hair off over this one too. Try this on win32:
Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on
win32
Type help, copyright, credits or license for more information.
import os
os.mkdir(u'foo\xe9')
import sqlite3
con = sqlite3.connect(u'foo\xe9\\my.db')
Traceback (most recent call last):
File stdin, line 1, in module
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe9' in position 3:
ordinal not in range(128)
import sys
sys.getfilesystemencoding()
'mbcs'
con = sqlite3.connect(u'foo\xe9\\my.db'.encode(sys.getfilesystemencoding()))
Traceback (most recent call last):
File stdin, line 1, in module
sqlite3.OperationalError: unable to open database file
con = sqlite3.connect(u'foo\xe9\\my.db'.encode('utf-8'))
--
nosy: +vdupras
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2127
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1149798] hotshot.runctx: builtins missing
Virgil Dupras added the comment:
Python 2.5.1 (r251:54869, Apr 18 2007, 22:08:04)
[GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin
Type help, copyright, credits or license for more information.
import hotshot
hotshot.Profile('/tmp/hs').runctx('print len',{'__builtins__':
... __builtins__},{})
built-in function len
hotshot.Profile instance at 0x6a940
Can we close this now?
--
nosy: +vdupras
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1149798
_
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1149798] hotshot.runctx: builtins missing
Virgil Dupras added the comment: oh crap here goes my ego... pasted the wrong line. _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1149798 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1149798] hotshot.runctx: builtins missing
Virgil Dupras added the comment: Well, since I brought that issue back, I might as well supply a patch. So if indeed it is decided that hotshot.Profile.runctx() should have __builtins__ in its globals by default, here is it. Added file: http://bugs.python.org/file9462/hotshot_builtins_globals.diff _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1149798 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2124] xml.sax and xml.dom fetch DTDs by default
Virgil Dupras added the comment: -1 on the systematic warnings too, but what I was talking about is a warning that would say The server you are trying to fetch your resource from is refusing the connection. Don't cha think you misbehave? only on 5xx and 4xx responses, not on every remote resource fetching. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2124 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2124] xml.sax and xml.dom fetch DTDs by default
Virgil Dupras added the comment: The blog page talked about 503 responses. What about issuing a warning on these responses? Maybe it would be enough to make developers aware of the problem? Or what about in-memory caching of the DTDs? Sure, it wouldn't be as good as a catalog or anything, but it might help for the worst cases? -- nosy: +vdupras __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2124 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1734234] Fast path for unicodedata.normalize()
Virgil Dupras added the comment:
It's a very interesting patch. I wonder why it fell into oblivion. stuff
like unicode.normalize('NFC', u'\xe9') was more than twice as fast for
me.
Making sure that all unicode is normalized can be a bottleneck in a lot
of applications (it somewhat is in my apps).
The downside is that it makes test_codecs and test_unicode_file fail.
--
nosy: +vdupras
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1734234
_
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1777134] minidom pretty xml output improvement
Virgil Dupras added the comment: If the patch would have better styling (if(onetextnode == True):), correct the test it breaks, and even better, add new ones, I guess it would be an acceptable one. -- nosy: +vdupras _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1777134 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1390] toxml generates output that is not well formed
Virgil Dupras added the comment: I wanted to start contributing to python for quite a while, so here's my very first try (cleaning out old patchless open tickets). So, whatever is the final decision on this, here's a patch. CDATASection.writexml() already raises ValueError when finding invalid data, so it seems consistent to me to extend the behavior to Comment.writexml() note: I can't add the patch keyword myself? -- nosy: +vdupras Added file: http://bugs.python.org/file9418/minidom_comment.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1390 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
