poq p...@gmx.com added the comment:
Now with proper skipping.
--
Added file: http://bugs.python.org/file25622/sqlite3-test-hooks.v2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13934
poq p...@gmx.com added the comment:
Just to confirm: curses SIGWINCH handling is still (2.7/3.2) broken after
importing readline.
Readline seems to set the LINES/COLUMNS environment vars, and this confuses
curses, even if curses is imported after readline.
Clearing the LINES/COLUMNS vars
poq p...@gmx.com added the comment:
Issue 3948 is almost certainly a duplicate.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2675
poq p...@gmx.com added the comment:
Sure, why not. Here you go.
--
Added file: http://bugs.python.org/file25616/sqlite3-version-doc.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13934
poq p...@gmx.com added the comment:
It is exposed as types.DictProxyType in Python 2...
--
nosy: +poq
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14386
poq p...@gmx.com added the comment:
Because the available space for command line switches is rather limited
Limited by what?
MYENVVAR=foo python ...
That does not work with hashbangs (and env is kludgey).
--
___
Python tracker rep
poq p...@gmx.com added the comment:
No, the point is that the exception may be caused by a real bug and having
the traceback is tremendously useful to debug such situations. [...]
KeyboardInterrupt is not different in this regard from, say,
ZeroDivisionError.
KeyboardInterrupt
poq p...@gmx.com added the comment:
It seems not even using -S fixes the problem
That's because you try to use re and os in your except block, and the
KeyboardInterrupt is raised before they are imported.
--
nosy: +poq
___
Python tracker rep
poq p...@gmx.com added the comment:
Martin,
I agree that wcswidth is incorrect with respect to Unicode. However I don't
think that's relevant at all. Python should only try to match the behaviour of
the terminal.
Since terminals do slightly different things, trying to match them exactly
poq p...@gmx.com added the comment:
Martin, I think you meant to write if w == 'A':.
Some very common characters have ambiguous widths though (e.g. the Greek
alphabet), so you can't just raise an error for them.
http://unicode.org/reports/tr11/ says:
Ambiguous characters occur in East Asian
poq p...@gmx.com added the comment:
It seems this is a bit of a minefield...
GNOME Terminal/libvte has an environment variable (VTE_CJK_WIDTH) to override
the handling of ambiguous width characters. It bases its default on the locale
(with the comment 'This is basically what GNU libc does
poq p...@gmx.com added the comment:
It is generally considered more correct to write floating-point number,
because floating-point is a compound adjective here. The hyphen clarifies
that it should be parsed as ((floating point) number) instead of (floating
(point number)).
However
poq p...@gmx.com added the comment:
FWIW, I was surprised by the return type of b64encode when I first used it in
Python 3. It seems to me that b64encode turns binary data into text and thus
intuitively should take bytes and return str.
Similarly it seems intuitive to me for b64decode to take
poq p...@gmx.com added the comment:
The Python docs should either list them (there aren’t much; pro: all the info
is here, con: maintenance) or link to them.
They've already added a new option ('psow') since I opened this report, so
linking is probably more future-proof.
I've added
New submission from poq p...@gmx.com:
The test CheckCollationIsUsed in Lib/sqlite3/test/hooks.py never runs because
it checks the wrong version tuple. Patch attached.
--
components: Tests
files: sqlite3-test-hooks.patch
keywords: patch
messages: 152548
nosy: poq
priority: normal
poq p...@gmx.com added the comment:
Can you open a bug report for that?
Opened #13934.
I think the doc could link to the sqlite.org doc about URIs.
I considered this, but the rest of the sqlite3 module documentation doesn't
link to the sqlite.org doc pages either. There is only a link
poq p...@gmx.com added the comment:
I've attached a patch for the _array_type change.
The long double fix is probably dependent on PEP3118 (#3132).
--
keywords: +patch
Added file: http://bugs.python.org/file24413/ctypes-leak.patch
___
Python tracker
poq p...@gmx.com added the comment:
This can be closed.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12993
___
___
Python-bugs-list mailing
New submission from poq p...@gmx.com:
URIs are an extensible way to pass options to SQLite. See:
http://www.sqlite.org/uri.html
Patch adds a keyword argument uri to sqlite3.connect which causes the
filename to be parsed as a URI if set to True.
--
components: Extension Modules
files
poq p...@gmx.com added the comment:
Thanks for your comments. You're right, I didn't consider positional arguments.
Here's a patch that addresses your comments.
Should I also rewrap modified lines that were already much too long?
I also noticed fixed an unrelated typo in Lib/sqlite3/test
poq p...@gmx.com added the comment:
sqlite3.version_info = (2, 6, 0)
sqlite3.sqlite_version_info = (3, 7, 4)
pysqlite2.version_info = (2, 6, 0)
pysqlite2.sqlite_version_info = (3, 7, 4)
--
___
Python tracker rep...@bugs.python.org
http
poq p...@gmx.com added the comment:
I don't think you even need the slice, if you use unpack_from.
--
nosy: +poq
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13031
poq p...@gmx.com added the comment:
Works for me?
$ python2.7 t.py
Traceback (most recent call last):
File t.py, line 13, in module
con.execute(insert into track (artist_id) values (1))
sqlite3.IntegrityError: foreign key constraint failed
$ python3.2 t.py
Traceback (most recent call last
poq p...@gmx.com added the comment:
The sqlite3 module already uses prepared statements. Quoting from the
documentation:
The sqlite3 module internally uses a statement cache to avoid SQL parsing
overhead. If you want to explicitly set the number of statements that are
cached
poq p...@gmx.com added the comment:
Nope.
$ sqlite3
SQLite version 3.7.4
Enter .help for instructions
Enter SQL statements terminated with a ;
sqlite pragma foreign_keys;
0
sqlite
$ python
Python 2.7.1+ (r271:86832, Apr 11 2011, 18:13:53)
[GCC 4.5.2] on linux2
Type help, copyright, credits
poq p...@gmx.com added the comment:
It would just need to call a given callable (fp.write) at regular intervals
and that would be enough to C-accelerate dump().
True, but that would just special case dump(), just like dumps() is
special-cased now. Ideally JSONEncoder.iterencode() would
poq p...@gmx.com added the comment:
Is iterencode() used much? I would think dump() and dumps() see the most use.
Of course. I'd just prefer an elegant complete solution. But I agree
accelerating just dump() would already be much better than the current
situation
poq p...@gmx.com added the comment:
I think this is because dumps() uses the C encoder. Making the C encoder
incremental (i.e. iterator-based) like the Python encoder would solve this.
I actually looked into doing this for issue #12134, but it didn't seem so
simple; Since C has no yield, I
poq p...@gmx.com added the comment:
dump() is not slower because it's incremental though. It's slower because it's
pure Python. I don't think there is necessarily a memory/speed trade-off; it
should be possible to write an incremental encoder in C as well
poq p...@gmx.com added the comment:
Tests succeed with this change.
There is only one use of _array_type, which is in the same module. This use is
presumably tested, because the test fails if I change the line to _array_type =
type(Structure).
In fact, everything must behave exactly the same
poq p...@gmx.com added the comment:
Alright.
I wouldn't mind a little note in the docs; I certainly did not expect that
these two functions would perform so differently.
Would it be very difficult though to add buffering support the C encoder
New submission from poq p...@gmx.com:
import json, timeit
obj = [[1,2,3]*10]*10
class writable(object):
def write(self, buf): pass
w = writable()
print('dumps: %.3f' % timeit.timeit(lambda: json.dumps(obj), number=1))
print('dump: %.3f' % timeit.timeit(lambda: json.dump(obj,w
New submission from poq p...@gmx.com:
When importing ctypes after gc.set_debug(gc.DEBUG_LEAK), the garbage collector
finds a 'c_int_Array_3' class and some related objects.
The class is created in ctypes/_endian.py:
_array_type = type(c_int * 3)
It seems that this could be avoided
Changes by poq p...@gmx.com:
--
title: Circular reference when importing ctypes - eference cycle when
importing ctypes
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12142
Changes by poq p...@gmx.com:
--
title: eference cycle when importing ctypes - Reference cycle when importing
ctypes
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12142
35 matches
Mail list logo
