poq added the comment:
Issue 3948 is almost certainly a duplicate.
--
___
Python tracker
<http://bugs.python.org/issue2675>
___
___
Python-bugs-list mailin
poq 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 after import
poq added the comment:
Now with proper skipping.
--
Added file: http://bugs.python.org/file25622/sqlite3-test-hooks.v2.patch
___
Python tracker
<http://bugs.python.org/issue13
poq added the comment:
Sure, why not. Here you go.
--
Added file: http://bugs.python.org/file25616/sqlite3-version-doc.patch
___
Python tracker
<http://bugs.python.org/issue13
poq added the comment:
It is exposed as types.DictProxyType in Python 2...
--
nosy: +poq
___
Python tracker
<http://bugs.python.org/issue14386>
___
___
Python-bug
poq 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
<htt
poq 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 *i
poq 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 tracke
poq 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 - in
poq 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 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 charact
poq 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)).
poq 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 str as
poq 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'
poq added the comment:
This can be closed.
--
___
Python tracker
<http://bugs.python.org/issue12993>
___
___
Python-bugs-list mailing list
Unsubscribe:
poq 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 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 li
New submission from poq :
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
severity: normal
poq 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/sq
New submission from poq :
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
fil
poq 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
<http://bugs.python.org/issue12
poq added the comment:
I don't think you even need the slice, if you use unpack_from.
--
nosy: +poq
___
Python tracker
<http://bugs.python.org/is
poq 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 "h
poq 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 for the connection, yo
poq added the comment:
Works for me?
$ python2.7 t.py
Traceback (most recent call last):
File "t.py", line 13, in
con.execute("insert into track (artist_id) values (1)")
sqlite3.IntegrityError: foreign key constraint failed
$ python3.2 t.py
Traceback (most recen
poq 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 curren
poq 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 be accel
poq 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 thin
poq 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
poq 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 after this
poq 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?
--
___
P
Changes by poq :
--
title: eference cycle when importing ctypes -> Reference cycle when importing
ctypes
___
Python tracker
<http://bugs.python.org/issu
Changes by poq :
--
title: Circular reference when importing ctypes -> eference cycle when
importing ctypes
___
Python tracker
<http://bugs.python.org/issu
New submission from poq :
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 with:
_
New submission from poq :
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(
35 matches
Mail list logo
