[issue37909] Thread pool return ref hold memory
Anders added the comment:
Note: due to a change in Python 3.8 this example would be a lot less noticeable
if tested. The problem remains the same though.
If you run this snippet with Python 3.7, which is before the thread reuse was
introduced into the ThreadPoolExecutor, each thread will keep around 600mb of
memory in use.
This can be solved by shutting down the ThreadPoolExecutor which this example
does.
Now, the big problem is that asyncio uses a long-running ThreadPoolExecutor,
per default, for run_in_executor. Those threads will stay around forever and
consume memory until the application is shut down.
If you have a job that consumes a lot of memory for a short period of time and
use any long-running ThreadPoolExecutor then the memory will just keep growing
as the job hits various threads that are never cleaned up.
--
import asyncio
import concurrent
import threading
def prepare_a_giant_list():
d = {}
for i in range(1000):
d[i] = {}
for j in range(1000):
d[i][j] = {}
for k in range(30):
d[i][j][k] = 'a' * 1000
del d
th_num = threading.active_count()
print("Thread number is {}".format(th_num))
async def main():
loop = asyncio.get_running_loop()
with concurrent.futures.ThreadPoolExecutor(max_workers=20) as
async_executor:
await loop.run_in_executor(async_executor, prepare_a_giant_list)
await asyncio.sleep(5)
await loop.run_in_executor(async_executor, prepare_a_giant_list)
await asyncio.sleep(5)
await loop.run_in_executor(async_executor, prepare_a_giant_list)
await asyncio.sleep(5)
await loop.run_in_executor(async_executor, prepare_a_giant_list)
await asyncio.sleep(5)
print('Done!')
await asyncio.sleep(15)
if __name__ == "__main__":
asyncio.run(main())
--
--
nosy: +johndoee
versions: +Python 3.6, Python 3.7
___
Python tracker
<https://bugs.python.org/issue37909>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)
Anders Kaseorg added the comment: If argparse will not be developed further to fix this bug, then we should undo the deprecation of optparse in the documentation (https://bugs.python.org/issue37103), since the stated justification for that deprecation was that optparse will not be developed further. The documentation should encourage programmers to use correct libraries, and optparse is correct here where argparse is not. People who need the extra features of argparse and aren’t bothered by its incorrectness are welcome to decide to use it, but this is not the right default decision for the documentation to promote. -- ___ Python tracker <https://bugs.python.org/issue9334> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)
Anders Kaseorg added the comment: > While optparse that it isn't being developed further, therebut will not > be taken away. IIRC the reason for this was that it too had become > difficult to build out and that is what necessitated the creation of > argparse -- there wasn't clean way to add the desired features > (subparsers, actions, etc). My concern is not that optparse will be taken away. My concern is that the documentation incorrectly discourages its use. https://docs.python.org/3/library/optparse.html “Deprecated since version 3.2: The optparse module is deprecated and will not be developed further; development will continue with the argparse module.” Given that the apparent conclusion of this bug is that argparse has also become too difficult to fix, either argparse should be deprecated for exactly the same reason, or optparse should be un-deprecated. Most programs don’t need the extra features of argparse, and optparse doesn’t have this bug, so optparse is a better default choice; the documentation should not be encouraging argparse over it. -- ___ Python tracker <https://bugs.python.org/issue9334> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46637] Incorrect error message: "missing 1 required positional argument"
New submission from Anders Hovmöller : >>> def foo(a): ... pass ... >>> foo() Traceback (most recent call last): File "", line 1, in TypeError: foo() missing 1 required positional argument: 'a' This error is incorrect. It says "positional argument", but it's just "argument". The proof is that if you call it with foo(a=3) it works fine. -- components: Interpreter Core messages: 412510 nosy: Anders.Hovmöller priority: normal severity: normal status: open title: Incorrect error message: "missing 1 required positional argument" type: enhancement versions: Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue46637> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46637] Incorrect error message: "missing 1 required positional argument"
Anders Hovmöller added the comment: Just dropping the word "positional" is very good. That word is a lie, and just removing it makes it true. -- ___ Python tracker <https://bugs.python.org/issue46637> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46637] Incorrect error message: "missing 1 required positional argument"
Anders Hovmöller added the comment: For `foo(a, /, b)`, it could be: "TypeError: foo() missing 1 required argument 'a', and one required positional argument 'b'. If we start on this road there are some more, like for `def foo(a, *, b)` you get the error "TypeError: foo() missing 1 required positional argument: 'a'" which leaves out that the keyword only argument is also required. Another solution would be something like: TypeError: foo() missing 3 required arguments: 'a' (positional only), 'b', 'c' (keyword only) This solution scales to the worst complex cases, and is a lot clearer imo. Could even be further improved with some nicer formatting: TypeError: foo() missing 3 required arguments: 'a' (positional only) 'b' 'c' (keyword only) But that might be a bit overkill :) -- ___ Python tracker <https://bugs.python.org/issue46637> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1084] ''.find() gives wrong result in Python built with ICC
Changes by Simon Anders: -- components: Build, Interpreter Core severity: normal status: open title: ''.find() gives wrong result in Python built with ICC versions: Python 2.5 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1084> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1084] ''.find() gives wrong result in Python built with ICC
New submission from Simon Anders:
I have just encountered a strange bug affecting Python 2.5.1 on an
x86_64 Linux, but only when compiled with the Intel C Compiler (ICC)
10.0, not a GCC-compiled Python. On my Intel-compiled one, which
otherwise seems to work fine, ''.find() works incorrectly.
I have narrowed down the issue to the simple test case
"foo2/**bar**/".find ("/**bar**/")
Observe: On a GCC-compiled Python 2.5.1, the command works as
expected by returning 4:
[EMAIL PROTECTED] tmp]$ /usr/site/hc-2.6/python/gnu/2.5.1/bin/python2.5
Python 2.5.1 (r251:54863, Aug 30 2007, 16:21:23)
[GCC 3.4.6 20060404 (Red Hat 3.4.6-8)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> print "foo2/**bar**/".find ("/**bar**/")
4
On my Python 2.5.1 installation which was compiled from source with the
Intel C Compiler (ICC) for Linux, version 10.0, '-1' is returned:
[EMAIL PROTECTED] tmp]$ /usr/site/hc-2.6/python/intel/2.5.1/bin/python2.5
Python 2.5.1 (r251:54863, Aug 30 2007, 16:20:06)
[GCC Intel(R) C++ gcc 3.4 mode] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> print "foo2/**bar**/".find ("/**bar**/")
-1
What could have possibly gone wrong here? Admittedly, this smacks more
of a bug in icc than in Python, but I report it here, as I feel at loss
of what else to do with it.
Obvious first question: Does anyone else out here have an ICC-compiled
Python handy to check whether the bug reproduces elsewhere?
Any idea what kind of oddity I have stumbled over here? Obviously, it
could simply be that something went wrong when compiling Python from
source with ICC, but it should not happen that the interpreter
nebertheless starts up and fails only silently.
Additional information:
- I have stumbled over the problem when trying to install Numpy 1.0.3.1,
as the built failed at the point where a script 'conv_template.py',
which is part of NumPy's installtion system, is started to do some
pattern replacements in a file called 'scalartypes.inc.src'. My test
case is reduced from this script.
- The system is the master node of a compute cluster with AMD Opteron
CPUs. The cluster is not involved, all was done on the master node. The
box runs RedHat Enterprise Linux 4.0 Advanced Server. It replies to
'uname -a' with:
Linux hc-ma.uibk.ac.at 2.6.9-42.0.10.ELsmp #1 SMP Fri Feb 16 17:13:42
EST 2007 x86_64 x86_64 x86_64 GNU/Linux
- The dynamic dependencies of the GCC-compiled and the ICC-compiled
Python binaries are:
[EMAIL PROTECTED] tmp]$ ldd /usr/site/hc-2.6/python/gnu/2.5.1/bin/python2.5
libpthread.so.0 => /lib64/tls/libpthread.so.0 (0x00370290)
libdl.so.2 => /lib64/libdl.so.2 (0x003701d0)
libutil.so.1 => /lib64/libutil.so.1 (0x00370390)
libm.so.6 => /lib64/tls/libm.so.6 (0x003701b0)
libc.so.6 => /lib64/tls/libc.so.6 (0x00370180)
/lib64/ld-linux-x86-64.so.2 (0x00370160)
[EMAIL PROTECTED] tmp]$ ldd /usr/site/hc-2.6/python/intel/2.5.1/bin/python2.5
libpthread.so.0 => /lib64/tls/libpthread.so.0 (0x00370290)
libdl.so.2 => /lib64/libdl.so.2 (0x003701d0)
libutil.so.1 => /lib64/libutil.so.1 (0x00370390)
libimf.so => /usr/site/hc-2.6/intel/10.0/cc/lib/libimf.so
(0x002a95579000)
libm.so.6 => /lib64/tls/libm.so.6 (0x003701b0)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00370580)
libc.so.6 => /lib64/tls/libc.so.6 (0x00370180)
/lib64/ld-linux-x86-64.so.2 (0x00370160)
- The precise revision of Python is "Python 2.5.1 (r251:54863)".
- The test case ceases to show failure if the string is only slightly
altered, e.g. if the word 'foo', the word 'bar' or the one of the
asterisks or one of the slashes is cut out in both search and target string.
--
nosy: +sanders_muc
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1084>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1084] ''.find() gives wrong result in Python built with ICC
Simon Anders added the comment:
Martin, you are right: is is related to compiler optimization. I have
boiled it down to a call of stringlib_find (defined in
Python-2.5.1/Objects/stringlib/find.h) and this runs fine with 'icc -O2'
but incorrectly for 'icc -O3'. (The test code is attached.)
So, it seems that the lesson is simply once again: Do not use '-O3' with
Intel's C compiler. (At least, for me, it is not the first time that
this caused trouble.)
On the other hand, Python's ./configure script is quite clear in its
preference of GCC, anyway: It more or less ignores with option
'--without-gcc' and uses the content of the CC environment variable only
very occasionally.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1084>
__#define STRINGLIB_CHAR char
#define STRINGLIB_CMP memcmp
#define STRINGLIB_LEN PyString_GET_SIZE
#define STRINGLIB_NEW PyString_FromStringAndSize
#define STRINGLIB_STR PyString_AS_STRING
#define STRINGLIB_EMPTY nullstring
#include "/usr/site/hc-2.6/python/gnu/2.5.1/include/python2.5/Python.h"
#include "../Python-2.5.1/Objects/stringlib/fastsearch.h"
#include "../Python-2.5.1/Objects/stringlib/find.h"
int main ()
{
STRINGLIB_CHAR* str = "foo2/**bar**/";
Py_ssize_t str_len = strlen (str);
STRINGLIB_CHAR* sub = "/**bar**/";
Py_ssize_t sub_len = strlen (sub);
Py_ssize_t offset = 0;
Py_ssize_t res;
res = stringlib_find(str, str_len, sub, sub_len, offset);
printf ("%d\n", res);
return 0;
}
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1084] ''.find() gives wrong result in Python built with ICC
Simon Anders added the comment:
Martin: I've boiled down the test case a bit more and removed all
Python-specific types and macros, so that it can now be compiled
stand-alone. (Updated test case 'findtest.c' attached.) I didn't feel
like diving into the code much deeper, and so I have sent it to Intel
Premier Support as Issue #448807. Let's see if they bother to
investigate it further.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1084>
__/*
Testcase for problem with 'icc -O3':
The function 'fastsearch' is taken from the source code of Python 2.5
and looks for the substring 'p' (of length 'm') within the string 's'
(of length 'n'). If 'mode' is 'FAST_COUNT' the number of occurences of
p in s is returned, and for 'FAST_SEARCH', the position of the first
occurence.
For the specific values used in main() below, the function returns
correctly '4', if compiled with at most optimization '-O2', but '-1'
for optimization level '-O3'.
I have just changed the Python-specific types to standard ones, otherwise
fastsearc() is as defined in file Objects/stringlib/fastsearch.h of
the Python 2.5.1 source code. It has been written by Fredrik Lundh and
is described in his blog here: http://effbot.org/zone/stringlib.htm
Simon Anders, [EMAIL PROTECTED], 2007-09-02
*/
#include
#include
#define FAST_COUNT 0
#define FAST_SEARCH 1
inline int
fastsearch(const char* s, int n,
const char* p, int m,
int mode)
{
long mask;
int skip, count = 0;
int i, j, mlast, w;
w = n - m;
if (w < 0)
return -1;
/* look for special cases */
if (m <= 1) {
if (m <= 0)
return -1;
/* use special case for 1-character strings */
if (mode == FAST_COUNT) {
for (i = 0; i < n; i++)
if (s[i] == p[0])
count++;
return count;
} else {
for (i = 0; i < n; i++)
if (s[i] == p[0])
return i;
}
return -1;
}
mlast = m - 1;
/* create compressed boyer-moore delta 1 table */
skip = mlast - 1;
/* process pattern[:-1] */
for (mask = i = 0; i < mlast; i++) {
mask |= (1 << (p[i] & 0x1F));
if (p[i] == p[mlast])
skip = mlast - i - 1;
}
/* process pattern[-1] outside the loop */
mask |= (1 << (p[mlast] & 0x1F));
for (i = 0; i <= w; i++) {
/* note: using mlast in the skip path slows things down on x86 */
if (s[i+m-1] == p[m-1]) {
/* candidate match */
for (j = 0; j < mlast; j++)
if (s[i+j] != p[j])
break;
if (j == mlast) {
/* got a match! */
if (mode != FAST_COUNT)
return i;
count++;
i = i + mlast;
continue;
}
/* miss: check if next character is part of pattern */
if (!(mask & (1 << (s[i+m] & 0x1F
i = i + m;
else
i = i + skip;
} else {
/* skip: check if next character is part of pattern */
if (!(mask & (1 << (s[i+m] & 0x1F
i = i + m;
}
}
if (mode != FAST_COUNT)
return -1;
return count;
}
int main ()
{
char* str = "foo2/**bar**/";
int str_len = strlen (str);
char* sub = "/**bar**/";
int sub_len = strlen (sub);
int offset = 0;
int res;
res = fastsearch (str, str_len, sub, sub_len, FAST_SEARCH);
printf ("%d\n", res);
return 0;
}
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)
Anders Kaseorg added the comment: James: That’s not related to this issue. This issue is about options taking arguments beginning with dash (such as a2x --asciidoc-opts --safe, where --safe is the argument to --asciidoc-opts), not positional arguments beginning with dash. Your observation isn’t a bug. In all getopt-like parsers, -- is the only way to pass positional arguments beginning with -. (Whether you shell-quoted the argument is irrelevant; the - is interpreted by the program, not the shell, after the shell has already stripped off the shell quoting.) If your program doesn’t take any options and you’d like to parse positional arguments without requiring --, don’t use a getopt-like parser; use sys.argv directly. If you still think your example is a bug, please file a separate report. -- ___ Python tracker <http://bugs.python.org/issue9334> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12844] Support more than 255 arguments
New submission from Anders Kaseorg :
This feels like an arbitrary restriction (obvious sequences have been replaced
with ‘…’ to save space in this report):
>>> zip([0], [1], [2], …, [1999])
File "", line 1
SyntaxError: more than 255 arguments
especially when this works:
>>> zip(*[[0], [1], [2], …, [1999]])
[(0, 1, 2, …, 1999)]
Apparently that limit bites some people:
https://docs.djangoproject.com/en/1.3/topics/http/urls/#module-django.conf.urls.defaults
The bytecode format doesn’t support directly calling a function with more than
255 arguments. But, it should still be pretty easy to compile such function
calls by desugaring
f(arg0, …, arg999, k0=v0, …, k999=v999)
into
f(*(arg0, …, arg999), **{'k0': 'v0', …, 'k999': 'v999'})
--
components: Interpreter Core
messages: 142995
nosy: andersk
priority: normal
severity: normal
status: open
title: Support more than 255 arguments
type: feature request
___
Python tracker
<http://bugs.python.org/issue12844>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12844] Support more than 255 arguments
Anders Kaseorg added the comment:
I guess the desugaring is slightly more complicated in the case where the
original function call already used *args or **kwargs:
f(arg0, …, arg999, *args, k0=v0, …, k999=v999, **kwargs)
becomes something like
f(*((arg0, …, arg999) + args),
**dict({'k0': 'v0', …, 'k999': 'v999'}, **kwargs))
--
___
Python tracker
<http://bugs.python.org/issue12844>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8595] Explain the default timeout in http-client-related libraries
Changes by Anders Sandvig : -- nosy: +anders.sandvig ___ Python tracker <http://bugs.python.org/issue8595> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9641] httplib/ftplib: timeout parameter not applied correctly
New submission from Anders Sandvig :
>From <http://mail.python.org/pipermail/python-dev/2010-July/101266.html>:
Consider the following code for retreieving a web page using httplib:
def get_url(hostname, port, url, timeout=5):
con = httplib.HTTPConnection(hostname, port, timeout)
con.request("GET", url)
res = con.getresponse()
data = res.read()
return res, data
As expected, this will raise a socket.error if the client is unable to
connect before the timeout has expired. However, once the connection
has been made, the timeout parameter no longer has any effect and
con.getresponse() will block forever if the server does not send any
data.
I think the reason for this is that the socket object created in
HTTPConnection.connect() has a default timeout of 0 (i.e. it is never
set explicitly):
def connect(self):
"""Connect to the host and port specified in __init__."""
self.sock = socket.create_connection((self.host,self.port),
self.timeout)
For now I have been able to work around this by manually setting the
timeout of the (private) socket object after calling con.request(),
like this:
...
con.request("GET", url)
con.sock.settimeout(timeout)
res = con.getresponse()
...
However, I don't think this is a very good solution as it relies on
knowledge about the inner workings of httplib (and I had to read the
library source code to come up with it).
>From the top of my head, I can come up with three (four) ways of
properly solving the issue:
1) Documenting the timeout behavior and describing the above hack in
the httplib documentation.
2) Modify HTTPConnection.connect() to set the timeout on the socket
object after it has been created (using the same timeout as given on
the HTTPConnection constructor).
3) Adding (optional) timeout parameters to
HTTPConnection.getresponse() and HTTPResponse.read() (and possibly
other functions with the same problem).
4) A combination of 2) and 3).
[...]
--
components: Library (Lib)
messages: 114343
nosy: anders.sandvig
priority: normal
severity: normal
status: open
title: httplib/ftplib: timeout parameter not applied correctly
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3
___
Python tracker
<http://bugs.python.org/issue9641>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9641] httplib/ftplib: timeout parameter not applied correctly
Anders Sandvig added the comment: The best (and simplest) solution seems to be option 2). Affected methods are found to be HTTPConnection.connect() and HTTPSConnection.connect() in Lib/httplib.py (Lib/http/client.py for 3.x) and FTP.connect() and FTP.ntransfercmd() in Lib/ftplib.py. It appears the issue can be fixed by simply adding a call to settimeout() on socket objects returned by socket.create_connection(), but this should of course be verified by appropriate tests. -- ___ Python tracker <http://bugs.python.org/issue9641> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9641] httplib/ftplib: timeout parameter not applied correctly
Anders Sandvig added the comment: socket.create_connection() does in fact set the timeout of the resulting socket object, so the issue is not an issue after all. The problems I experienced was a result of sending the timeout as the third parameter to the HTTPConnection() constructor instead of a named parameter, i.e.: con = httplib.HTTPConnection(hostname, port, timeout) should have been: con = httplib.HTTPConnection(hostname, port, timeout=timeout) -- status: open -> closed ___ Python tracker <http://bugs.python.org/issue9641> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue979407] urllib2 digest auth totally broken
Changes by Anders Sandvig : -- nosy: +anders.sandvig ___ Python tracker <http://bugs.python.org/issue979407> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue809163] Can't add files with spaces
Changes by Anders Sandvig : -- nosy: +asandvig ___ Python tracker <http://bugs.python.org/issue809163> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)
Anders Kaseorg added the comment: > @andersk: Would the restriction to only having flags with a fixed > number of arguments be acceptable for your use case? I think that’s fine. Anyone coming from optparse won’t need options with optional arguments. However, FWIW, GNU getopt_long() supports options with an optional argument under the restrictions that: • the option must be a long option, • the optional argument must be the only argument for the option, and • the argument, if present, must be supplied using the ‘--option=argument’ form, not the ‘--option argument’ form. This avoids all parsing ambiguity. It would be useful to have feature parity with getopt_long(), to facilitate writing Python wrapper scripts for C programs. -- ___ Python tracker <http://bugs.python.org/issue9334> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10513] sqlite3.InterfaceError after commit
New submission from Anders Blomdell :
With version 2.7 (and 2.7.1rc1), the following sequence (see attached test):
c = cursor.execute(' select k from t where k == ?;', (1,))
conn.commit()
r = c.fetchone()
Traceback (most recent call last):
File "/bugs/sqlite_bug.py", line 22, in
c = cursor.execute(' select k from t where k == ?;', (2,))
sqlite3.InterfaceError: Error binding parameter 0 - probably unsupported type.
The program works with 2.6.2
--
components: Extension Modules
files: sqlite_bug.py
messages: 122213
nosy: [email protected]
priority: normal
severity: normal
status: open
title: sqlite3.InterfaceError after commit
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file19784/sqlite_bug.py
___
Python tracker
<http://bugs.python.org/issue10513>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10513] sqlite3.InterfaceError after commit
Anders Blomdell added the comment:
The culprit seems to be 'pysqlite_do_all_statements(self, ACTION_RESET, 0)' in
pysqlite_connection_commit, which resets all active statements, but subsequent
fetch/fetchall seems to trash the sqlite3 state in the statements. Removing the
ACTION_RESET seems to bring back old behaviour (if it's the correct fix is,
however, beyond me).
Slightly modified testprogram that shows more wierdness; output from:
c = cursor.execute(' select k from t where k == ?;', (0,))
conn.commit()
print c.fetchall()
is:
[(0,), (0,)]
which is not what I would expect with a primary key...
--
Added file: http://bugs.python.org/file19794/sqlite_bug.py
___
Python tracker
<http://bugs.python.org/issue10513>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1571170] Some numeric characters are still not recognized
Anders Chrigström added the comment: This is indeed a duplicate of #1571184 -- resolution: -> duplicate status: open -> closed ___ Python tracker <http://bugs.python.org/issue1571170> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)
Anders Kaseorg added the comment:
There are some problems that ‘=’ can’t solve, such as options with nargs ≥ 2.
optparse has no trouble with this:
>>> parser = optparse.OptionParser()
>>> parser.add_option('-a', nargs=2)
>>> parser.parse_args(['-a', '-first', '-second'])
(, [])
But inputting those arguments is _not possible_ with argparse.
>>> parser = argparse.ArgumentParser()
>>> parser.add_argument('-a', nargs=2)
>>> parser.parse_args(['-a', '-first', '-second'])
usage: [-h] [-a A A]
: error: argument -a: expected 2 argument(s)
--
___
Python tracker
<http://bugs.python.org/issue9334>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)
Anders Kaseorg added the comment: That would be a good first step. I continue to advocate making that mode the default, because it’s consistent with how every other command line program works[1], and backwards compatible with the current argparse behavior. As far as documentation for older versions, would it be reasonable to un-deprecate optparse until argparse becomes a suitable replacement? There are still lots of programmers working in Python 2.7. [1] bethard’s msg128047 is confusing positional arguments with option arguments. All UNIX commands that accept option arguments have no trouble accepting option arguments that begin with -. For example, ‘grep -e -pattern file’ is commonly used to search for patterns beginning with -. -- ___ Python tracker <http://bugs.python.org/issue9334> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)
Anders Kaseorg added the comment: > (1) It's only deprecated in the documentation Which is why I suggested un-deprecating it in the documentation. (I want to avoid encouraging programmers to switch away from optparse until this bug is fixed.) > # proposed behavior > parser = ArgumentParser(error_on_unknown_options=False) Perhaps you weren’t literally proposing “error_on_unknown_options=False” as the name of the new flag, but note that neither the current nor proposed behaviors have nothing to do with whether arguments look like known or unknown options. Under the proposed behavior, anything in argument position (--asciidoc-opts ___) is parsed as an argument, no matter what it looks like. So a more accurate name might be “refuse_dashed_args=False”, or more generally (in case prefix_chars != '-'), “refuse_prefixed_args=False”? -- ___ Python tracker <http://bugs.python.org/issue9334> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11202] Win32: shutil.move does not inherit permissions
New submission from Anders Østhus : Hi I'm running Python 2.7.1 (r271:86832, Nov 27 2010, 17:19:03) [MSC v.1500 64 bit (AMD64)] on win32 (Server 2008 R2). I've discovered that when moving files with shutil.move, the file won't inherit the security settings as it should. When using shutil.copy, it does get the right permissions. -- components: IO messages: 128452 nosy: Anders.Østhus priority: normal severity: normal status: open title: Win32: shutil.move does not inherit permissions versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue11202> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11202] Win32: shutil.move does not inherit permissions
Anders Østhus added the comment: Ok, but the whole page you linked to (http://docs.python.org/library/shutil) confuses me then. It states at the top: "Warning Even the higher-level file copying functions (copy(), copy2()) can’t copy all file metadata. On POSIX platforms, this means that file owner and group are lost as well as ACLs. On Mac OS, the resource fork and other metadata are not used. This means that resources will be lost and file type and creator codes will not be correct. On Windows, file owners, ACLs and alternate data streams are not copied." Then, under shutil.copy: "Permission bits are copied". I'm assuming this is UGO permissions on POSIX systems, and thus correct according to the top text. shutil.copy2 says: Similar to shutil.copy, but with metadata. Files copied with both shutil.copy and shutil.copy2 both inherits the permissions from their destination, but shutil.move does not. According to the shutil doc page, neither copy or copy2 should do this. And since they do, and you say shutil.move is implemented using shutil.copy2, shouldn't files moved with shutil.move also then inherit the permissions? -- status: closed -> open ___ Python tracker <http://bugs.python.org/issue11202> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11202] Win32: shutil.move does not inherit permissions
Anders Østhus added the comment: Ok. But that makes the whole method inconsistent. Basically, if it's on the same filesystem, rename the file, and thus not inheriting ACL. If it's on another use copy2, and inherit ACL. That makes no sense, atleast not to me :) -- ___ Python tracker <http://bugs.python.org/issue11202> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11202] Win32: shutil.move does not inherit permissions
Anders Østhus added the comment: On my system (Win Server 2008 R2 64-Bit, Python 2.7.1), when I use copy, copy2 or move(to another filesystem), the file _will_ get the ACL of the DST folder, and remove any ACL in SRC file that the DST folder does not have. Thus, it doesn't copy it from the source file, but inherits from the DST folder. -- ___ Python tracker <http://bugs.python.org/issue11202> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11202] Win32: shutil.move does not inherit permissions
Anders Østhus added the comment: Thank you for taking the time to explain it to me, but it still seems inconsistent to me. I did a test with the functions copy, copy2, move, os.rename, copyfile, both on the same filesystem and another filesystem, and the result is: Same filesystem: shutil.copy:Inherit shutil.copy2: Inherit shutil.move:Original os.rename: Original shutil.copyfile:Inherit Different filesystem: shutil.copy:Inherit shutil.copy2: Inherit shutil.move:Inherit os.rename: Inherit shutil.copyfile:Inherit On the same system, the result will differ if you move the file to a different location on the same filesystem, or if you move it to another filesystem. But still, I'm happy. I'll just use copy/copy2 and then delete the original file afterwards :) -- ___ Python tracker <http://bugs.python.org/issue11202> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3545] Python turning off assertions (Windows)
New submission from Anders Bensryd <[EMAIL PROTECTED]>: We are using Windows XP SP2, Visual Studio 2005 & Python 2.5.2. In Objects/exceptions.c the following code turns off all assertions. #if defined _MSC_VER && _MSC_VER >= 1400 && defined(__STDC_SECURE_LIB__) /* Set CRT argument error handler */ prevCrtHandler = _set_invalid_parameter_handler (InvalidParameterHandler); /* turn off assertions in debug mode */ prevCrtReportMode = _CrtSetReportMode(_CRT_ASSERT, 0); #endif As far as I understand, this is to make sure that no assertion dialogs pop up during the internal Python tests. For ordinary users, this is not an issue. However, we are using the Python DLL in our product and when developing we always use the debug version of the Python DLL (as recommended). When we do Py_Initialize() all assertions are turned off, even our assertions, and this is not what we want. The current workaround is as follows (this is in our code): prevCrtReportMode=_CrtSetReportMode(_CRT_ASSERT,_CRTDBG_REPORT_MODE); Py_Initialize(); prevCrtReportMode=_CrtSetReportMode(_CRT_ASSERT,prevCrtReportMode); I am not certain if this is a bug or a feature and I really do not have a suggested solution since I do not know the real reasons for turning off assertions. Perhaps there already is a way to avoid this problem that I have not found? All comments are appreciated. -- components: Windows messages: 71049 nosy: abe severity: normal status: open title: Python turning off assertions (Windows) type: behavior versions: Python 2.5 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3545> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3545] Python turning off assertions (Windows)
Anders Bensryd <[EMAIL PROTECTED]> added the comment: Yes, we could do that. However, my concerns are: 1) We cannot be the only Python user that experience this issue? I would prefer one of these solutions (in this order): a) A parameter to Py_Initialize (structure) that controls its behaviour. b) A #define in pyconfig.h controls whether this should be done or not. However, since I am not a Python developer myself, I cannot judge how much this would affect other things. I also realize that this involves some work and that it has very low priority. 2) We have to remember to do this change every time we upgrade to a newer version of Python. In earlier releases of Python where PyImport_AppendInittab did not exist, we had to do changes to the Python code every time we upgraded which was a hazzle. This is why I prefer the current workaround we are using where we reset the CRT report mode after Py_Initialize(). Your efforts are much appreciated and I realize that the current workaround we are using will probably be the final solution. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3545> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3545] Python turning off assertions (Windows)
Anders Bensryd <[EMAIL PROTECTED]> added the comment: We started using Python 2.5.2 recently and a few developers have complained that they do not get any assertions anymore so yes, we do use _ASSERT() and _ASSERTE(), but after a brief look it seems as if we mainly use assert(). The developer using _ASSERT() cannot remember why this was necessary and the tests I have made today shows that we could probably move to assert() everywhere. A more interesting aspect is that we have recently moved the the more secure CRT routines (strcpy_s etc) and tests have shown issues with these if we turn off assertions: int prevCrtReportMode=_CrtSetReportMode(_CRT_ASSERT,0); char str[8]; strcpy_s(str,"123456789"); With assertions turned on, I get an assertion dialog saying "Buffer is too small" which is what I expect and want. With assertions turned off (as in the example above), I get a dialog saying "Microsoft Visual Studio C Runtime Library has detected a fatal error in crt.exe.". The stack is still useful and we can find the cause of the error so it is not a serious problem for us since we will continue to turn on assertions after Py_Initialize(). I have not yet seen any examples where the are erroneous assertions. Anyway, you have made your point and I really do not want to take up anymore of your time. I respect your opinion and at least I have forced you to think about this. We have a workaround that works for us so I am OK with closing this issue. Many thanks! ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3545> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8158] documentation of 'optparse' module incomplete
New submission from Simon Anders : The class optparse.OptionParser supports a number of useful keyword arguments to the initializer, which are not documented in the Python Standard Library documentation, here: http://docs.python.org/library/optparse.html This is a bit unfortunate. For example, I wanted to add a description to the top of my script's help page and a copyright notice to the foot, and was already about to subclass OptionParser in order to override the format_help method, when I noticed that optional keyword arguments 'description' and 'epilog' are provided for precisely this purpose. The 'epilog' attribute is at least mentioned in the class's docstring, while the 'description' argument is completely undocumented. I doubt that this was done on purpose. I'd suggest to go over the documentation page for optparse and fill in the missing bits; at minimum, list all keyword arguments to optparse.OptionParser.__init__. -- assignee: georg.brandl components: Documentation messages: 101177 nosy: georg.brandl, sanders severity: normal status: open title: documentation of 'optparse' module incomplete versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue8158> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8376] Tutorial offers dangerous advice about iterator s: “__iter__() can just return self”
New submission from Anders Kaseorg : The Python tutorial offers some dangerous advice about adding iterator behavior to a class: http://docs.python.org/tutorial/classes.html#iterators “By now you have probably noticed that most container objects can be looped over using a for statement: … Having seen the mechanics behind the iterator protocol, it is easy to add iterator behavior to your classes. Define a __iter__() method which returns an object with a next() method. If the class defines next(), then __iter__() can just return self:” This is reasonable advice for writing an iterator class, but terrible advice for writing a container class, because it encourages you to associate a single iterator with the container, which breaks nested iteration and leads to hard-to-find bugs. (One of those bugs recently made its way into the code handout for a problem set in MIT’s introductory CS course, 6.00.) A container class’s __iter__() should return a generator or an instance of a separate iterator class, not self. The tutorial should make this clearer. -- assignee: georg.brandl components: Documentation messages: 102918 nosy: andersk, georg.brandl severity: normal status: open title: Tutorial offers dangerous advice about iterators: “__iter__() can just return self” ___ Python tracker <http://bugs.python.org/issue8376> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8376] Tutorial offers dangerous advice about iterator s: “__iter__() can just return self”
Anders Kaseorg added the comment:
As an experienced Python programmer I am obviously aware that the tutorial is
trying to teach how to make an iterator class, not how to make a container
class.
But the tutorial doesn’t make that *clear*. It should be much more explicit
about what it is explaining to avoid confusing those concepts in the minds of
beginners. (Or even the staff of the MIT introductory CS course.)
One way to fix this confusion would be to explain what one should do for both
container classes and iterator classes:
"""
Having seen the mechanics behind the iterator protocol, it is easy to add
iterator behavior to your container classes. Define a :meth:`__iter__` method
which returns an object of a separate iterator class. The iterator class
should have a :meth:`next` method and an :meth:`__iter__` method (the
:meth:`__iter__` method of the iterator class should just return ``self``)::
class ReverseList(object):
"Container that lets you iterate over the items backwards"
def __init__(self, data):
self.data = data
def __iter__(self):
return ReverseIterator(self.data)
class ReverseIterator(object):
"Iterator for looping over a sequence backwards"
def __init__(self, data):
self.data = data
self.index = len(data)
def __iter__(self):
return self
def next(self):
if self.index == 0:
raise StopIteration
self.index = self.index - 1
return self.data[self.index]
>>> for char in ReverseIterator('spam'):
... print char
...
m
a
p
s
>>> for char in ReverseList([1,2,3]):
... print char
...
3
2
1
"""
--
___
Python tracker
<http://bugs.python.org/issue8376>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1084] ''.find() gives wrong result in Python built with ICC
Simon Anders added the comment: Update to the story: After I submitted the bug report to Intel, they investigated and quickly confirmed it to be a compiler bug, whcih they then managed to fix. I have just got an e-mail from Intel that the newest available version of ICC, namely version l_cc_c_10.1.008, contains the fix. In principle the problem should vanish now, but I have not found the time to verify that. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1084> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2138] Factorial
Anders Valind added the comment: IMHO, The best place to put functions such as xgcd, factorial, etc, would be a new imath module, an integer equivalent of cmath. Not only would it keep the standard math module clean, it would also make clear that these functions are for integers only. -- nosy: +avalind __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2138> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2138] Factorial
Anders Valind added the comment: Yeah, I like the idea of a third party module and letting the popularity and quality decide when/if it will be included. This would also make it easier to see what kind of functionality people would want. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2138> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43323] UnicodeEncodeError: surrogates not allowed when parsing invalid charset
Anders Kaseorg added the comment: It could and does, as quoted in my original report. Content-Type: text/plain; charset*=utf-8”''utf-8%E2%80%9D That’s a U+201D right double quotation mark. This is not a valid charset for the charset of course, but it seems like the code was intended to handle an invalid charset value without crashing, so it should also handle an invalid charset charset (despite the absurdity of the entire concept of a charset charset). -- ___ Python tracker <https://bugs.python.org/issue43323> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31956] Add start and stop parameters to the array.index()
Anders Lorentsen added the comment: As far as I can recall, the patch is generally speaking good to go. A number of discussions arose on various details, however. In any event, I'll take a look at it during the next few days. -- ___ Python tracker <https://bugs.python.org/issue31956> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31956] Add start and stop parameters to the array.index()
Anders Lorentsen added the comment: I have actually managed to lost my local branch of this fix, though I assume I can just start another one, manually copy over the changes, somehow mark this current PR as cancelled, aborted, or in my option the best: "replaced/superseeded by: [new PR]". In any case, there were discussions that seem to be unresolved, allow me to summarize: * Document that index() raises ValueError when *value* is not found? > vstinner: We don't do this, remove this addition. > serhiy: Other index() methods does this. ---> My patch current does this. Who has final saying here? * 'start' and 'stop' arguments are not keyword arguments, and also not shown in the signature as '.. start=0 ..' for this very reason (it may make them look as keyword arguments). Also, this lines up with list.index() for consistency. Wishes about changing this for all index()-methods has been expressed, but it seems to be consensus on doing this in unison for all index()-methods at once, in a bigger change... So, what is currently in the PR is good enough for now, or? * Wording in documentation: Clarify that "the returned index is still relative to the start of the array, not the searched sub sequence" or not? * Comment in the code about checking the length of the array on each iteration? There were comments about it being "confusing" - and while I agree, the other index()-code for lists, does not comment on this. Again I followed the path of most consistency, but I did receive comments about this. Yes to descriptive comments, or not? Generally speaking: In the end, all I really did was mimic how list.index() is both written and documented, and that's when discussions about issues related to that started occurring, and so I now remember that I halted my PR, waiting for these issues to be resolved. -- ___ Python tracker <https://bugs.python.org/issue31956> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38673] REPL shows continuation prompt (...) when comment or space entered
Anders Lorentsen added the comment: As a person without much experience, it sounded like a simple enough task, but having dug a bit, I found it quite complicated. It seems to me that the interpreter loop (in the standard REPL, that you get when you start ./python, blocks for input somewhere inside a massive function called 'parsetok' (in Parser/parsetok.c). Now, I could maybe investigate further, to have it return to the interpreter loop if it reads a comment (or empty line), but I'm afraid to mess up something. >From my understanding, there aren't that many other choices, because >parsetok() doesn't return before you finish the statement (in other words, it >does not return if you type a comment line or a blank line - it instead waits >for more input, as indicated by the '... '). Am I way off in concluding that this would be a change to the parser? -- nosy: +Phaqui ___ Python tracker <https://bugs.python.org/issue38673> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44283] Add jump table for certain safe match-case statements
Anders Munch added the comment: Are you sure you want to do this? This optimisation is not applicable if the matched values are given symbolic names. You would be encouraging people to write bad code with lots of literals, for speed. -- nosy: +AndersMunch ___ Python tracker <https://bugs.python.org/issue44283> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44680] Reference cycles from a WeakKeyDictionary value to its key aren’t collected
New submission from Anders Kaseorg :
Because WeakKeyDictionary unconditionally maintains strong references to its
values, the garbage collector fails to collect a reference cycle from a
WeakKeyDictionary value to its key. For example, the following program
unexpectedly leaks memory:
from weakref import WeakKeyDictionary
class C: pass
d = WeakKeyDictionary()
while True:
c = C()
d[c] = [c]
I would expect a WeakKeyDictionary value to be marked live _if_ its key is
marked live, not unconditionally. This could be implemented with garbage
collector support for ephemerons
(https://www.researchgate.net/publication/221320677_Ephemerons_A_New_Finalization_Mechanism).
To motivate this issue, a typical use of WeakKeyDictionary is as a hygienic
replacement for patching extra properties into third-party objects:
# before:
obj._extra_state = ExtraState(obj)
# after:
extra_states = WeakKeyDictionary()
extra_states[o] = ExtraState(obj)
However, such a conversion will introduce this memory leak if ExtraState(obj)
has any transitive references to obj.
This leak does not occur in JavaScript:
class C {}
const d = new WeakMap();
while (true) {
const c = new C();
d[c] = [c];
}
--
components: Library (Lib)
messages: 397841
nosy: andersk
priority: normal
severity: normal
status: open
title: Reference cycles from a WeakKeyDictionary value to its key aren’t
collected
type: resource usage
versions: Python 3.9
___
Python tracker
<https://bugs.python.org/issue44680>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44680] Reference cycles from a WeakKeyDictionary value to its key aren’t collected
Anders Kaseorg added the comment: > extra_states[o] = ExtraState(obj) (Typo for extra_states[obj] = ExtraState(obj), obviously.) -- ___ Python tracker <https://bugs.python.org/issue44680> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44967] pydoc should return non-zero exit code when a query is not found
New submission from Gregory Anders : Currently pydoc returns an exit code of zero no matter what, even with e.g. pydoc lsjdfkdfj However, the ability to know whether or not pydoc successfully found a result is useful in tools that embed pydoc in some way. Here's one use case: Vim and Neovim have a feature that allows a user to run an external command for the keyword under the cursor (keywordprg). In Python files, this defaults to pydoc. In Neovim, we would like to automatically close the PTY buffers that we create for these processes when they finish without any errors, but if it returns a non-zero exit code we want to keep the PTY buffer open so the user can see what went wrong. Because pydoc returns immediately when it fails to find a match and does not indicate that it failed via a return code, the PTY buffer is closed immediately with no indication to the user that anything went wrong. I have a patch prepared for this that I will link to the issue. -- components: Demos and Tools messages: 400012 nosy: gpanders priority: normal severity: normal status: open title: pydoc should return non-zero exit code when a query is not found type: enhancement ___ Python tracker <https://bugs.python.org/issue44967> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44967] pydoc should return non-zero exit code when a query is not found
Change by Gregory Anders : -- keywords: +patch pull_requests: +26323 stage: -> patch review pull_request: https://github.com/python/cpython/pull/27868 ___ Python tracker <https://bugs.python.org/issue44967> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32308] Replace empty matches adjacent to a previous non-empty match in re.sub()
Anders Hovmöller added the comment: We were also bitten by this. In fact we still run a compatibility shim in production where we log if the new and old behavior are different. We also didn't think this "bug fix" made sense or was treated with the appropriate gravity in the release notes. I understand the logic in the bug tracker and they it matches other languages is good. But the bahvior also makes no sense for the .* case unfortunately. > On 21 Jan 2020, at 05:56, David Barnett wrote: > > > David Barnett added the comment: > > We were also bitten by this behavior change in > https://github.com/google/vroom/issues/110. I'm kinda baffled by the new > behavior and assumed it had to be an accidental regression, but I guess not. > If you have any other context on the BDFL conversation and reasoning for > calling this behavior correct, I'd love to see additional info. > > -- > nosy: +mu_mind > > ___ > Python tracker > <https://bugs.python.org/issue32308> > ___ -- ___ Python tracker <https://bugs.python.org/issue32308> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43115] locale.getlocale fails if locale is set
New submission from Anders Munch :
getlocale fails with an exception when the string returned by _setlocale is
already an RFC 1766 language tag.
Example:
Python 3.10.0a4 (tags/v3.10.0a4:445f7f5, Jan 4 2021, 19:55:53) [MSC v.1928 64
bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
>>> locale.setlocale(locale.LC_ALL, 'en-US')
'en-US'
>>> locale.getlocale()
Traceback (most recent call last):
File "", line 1, in
File "C:\flonidan\env\Python310\lib\locale.py", line 593, in getlocale
return _parse_localename(localename)
File "C:\flonidan\env\Python310\lib\locale.py", line 501, in _parse_localename
raise ValueError('unknown locale: %s' % localename)
ValueError: unknown locale: en-US
Expected result:
('en-US', None)
See https://github.com/wxWidgets/Phoenix/issues/1637 for an example of the
ensuing problems. wx.Locale calls C setlocale directly, but, as far as I can
see, correctly, using dashes in the language code which is consistent with not
only RFC 1766 but also the examples in Microsoft's documentation
(https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/setlocale-wsetlocale?view=msvc-160).
CPython seems to assume underscored names such as 'en_US' instead, as shown
by getdefaultlocale inserting an underscore.
--
components: Library (Lib), Windows
messages: 386203
nosy: AndersMunch, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: locale.getlocale fails if locale is set
versions: Python 3.10, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue43115>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43115] locale.getlocale fails if locale is set
Anders Munch added the comment:
I discovered that this can happen with underscores as well:
Python 3.8.7 (tags/v3.8.7:6503f05, Dec 21 2020, 17:59:51) [MSC v.1928 64 bit
(AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
>>> locale.setlocale(locale.LC_ALL, 'en_DE')
'en_DE'
>>> locale.getlocale()
Traceback (most recent call last):
File "", line 1, in
File "C:\flonidan\env\Python38-64\lib\locale.py", line 591, in getlocale
return _parse_localename(localename)
File "C:\flonidan\env\Python38-64\lib\locale.py", line 499, in
_parse_localename
raise ValueError('unknown locale: %s' % localename)
ValueError: unknown locale: en_DE
locale.setlocale does validate input - if you write nonsense in the second
argument then you get an exception, "locale.Error: unsupported locale setting".
So I'm guessing the en_DE locale is actually being set here, and the problem
is solely about getlocale making unfounded assumptions about the format.
Same thing happens in 3.10.0a4.
--
___
Python tracker
<https://bugs.python.org/issue43115>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43115] locale.getlocale fails if locale is set
Anders Munch added the comment: getlocale is documented to return None for the encoding if no encoding can be determined. There's no need to guess. I can't change the locale.setlocale call, because where I'm actually having the problem, I'm not even calling locale.setlocale: wxWidgets is calling C setlocale, that's where it comes from. wxWidgets aside, it doesn't seem right that getlocale fails when setlocale succeeded. -- ___ Python tracker <https://bugs.python.org/issue43115> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43115] locale.getlocale fails if locale is set
Anders Munch added the comment: > BTW: What is wxWidgets doing with the returned values ? wxWidgets doesn't call getlocale, it's a C++ library (wrapped by wxPython) that uses C setlocale. What does use getlocale is time.strptime and datetime.datetime.strptime, so when getlocale fails, strptime fails. > We could enhance this to return None for the encoding instead > of raising an exception, but would this really help ? Very much so. Frankly, I don't get the impression that the current locale preferred encoding is used for *anything*. Other than possibly having a role in implementing getpreferredencoding. > Alternatively, we could add "en_DE" to the alias table and set > a default encoding to use. Where would you get a complete list of all the new aliases that would need be to be added? As the "en_DE" example shows, you'd need all combinations of languages and regions. That's going to be a very long list. -- ___ Python tracker <https://bugs.python.org/issue43115> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43115] locale.getlocale fails if locale is set
Anders Munch added the comment: >> What does use getlocale is time.strptime and datetime.datetime.strptime, so >> when getlocale fails, strptime fails. > Would they work with getlocale() returning None for the encoding ? Yes. All getlocale is used for in _strptime.py is comparing the value returned to the previous value returned. I expect changing _strptime._getlang to return the unnormalized value locale._setlocale(locale.LC_TIME, None) would work as well and more robustly. -- ___ Python tracker <https://bugs.python.org/issue43115> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43323] UnicodeEncodeError: surrogates not allowed when parsing invalid charset
New submission from Anders Kaseorg :
We ran into a UnicodeEncodeError exception using email.parser to parse this
email
<https://lists.cam.ac.uk/pipermail/cl-isabelle-users/2021-February/msg00135.html>,
with full headers available in the raw archive
<https://lists.cam.ac.uk/pipermail/cl-isabelle-users/2021-February.txt>. The
offending header is hilariously invalid:
Content-Type: text/plain; charset*=utf-8”''utf-8%E2%80%9D
but I’m filing an issue since the parser is intended to be robust against
invalid input. Minimal reproduction:
>>> import email, email.policy
>>> email.message_from_bytes(b"Content-Type: text/plain;
>>> charset*=utf-8\xE2\x80\x9D''utf-8%E2%80%9D", policy=email.policy.default)
Traceback (most recent call last):
File "", line 1, in
File "/usr/local/lib/python3.10/email/__init__.py", line 46, in
message_from_bytes
return BytesParser(*args, **kws).parsebytes(s)
File "/usr/local/lib/python3.10/email/parser.py", line 123, in parsebytes
return self.parser.parsestr(text, headersonly)
File "/usr/local/lib/python3.10/email/parser.py", line 67, in parsestr
return self.parse(StringIO(text), headersonly=headersonly)
File "/usr/local/lib/python3.10/email/parser.py", line 57, in parse
return feedparser.close()
File "/usr/local/lib/python3.10/email/feedparser.py", line 187, in close
self._call_parse()
File "/usr/local/lib/python3.10/email/feedparser.py", line 180, in _call_parse
self._parse()
File "/usr/local/lib/python3.10/email/feedparser.py", line 256, in _parsegen
if self._cur.get_content_type() == 'message/delivery-status':
File "/usr/local/lib/python3.10/email/message.py", line 578, in
get_content_type
value = self.get('content-type', missing)
File "/usr/local/lib/python3.10/email/message.py", line 471, in get
return self.policy.header_fetch_parse(k, v)
File "/usr/local/lib/python3.10/email/policy.py", line 163, in
header_fetch_parse
return self.header_factory(name, value)
File "/usr/local/lib/python3.10/email/headerregistry.py", line 608, in
__call__
return self[name](name, value)
File "/usr/local/lib/python3.10/email/headerregistry.py", line 196, in __new__
cls.parse(value, kwds)
File "/usr/local/lib/python3.10/email/headerregistry.py", line 453, in parse
kwds['decoded'] = str(parse_tree)
File "/usr/local/lib/python3.10/email/_header_value_parser.py", line 126, in
__str__
return ''.join(str(x) for x in self)
File "/usr/local/lib/python3.10/email/_header_value_parser.py", line 126, in
return ''.join(str(x) for x in self)
File "/usr/local/lib/python3.10/email/_header_value_parser.py", line 798, in
__str__
for name, value in self.params:
File "/usr/local/lib/python3.10/email/_header_value_parser.py", line 783, in
params
value = value.decode(charset, 'surrogateescape')
UnicodeEncodeError: 'utf-8' codec can't encode characters in position 5-7:
surrogates not allowed
--
components: email
messages: 387685
nosy: andersk, barry, r.david.murray
priority: normal
severity: normal
status: open
title: UnicodeEncodeError: surrogates not allowed when parsing invalid charset
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue43323>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10513] sqlite3.InterfaceError after commit
Anders Blomdell added the comment: > So my suggestion is to remove in "pysql_connection_commit" the call to : > pysqlite_do_all_statements(self, ACTION_RESET, 0); > to bring back the correct old behavior. That's what I have been running for years, now... > And also eventually to remove in "pysqlite_connection_rollback" the > call to : > pysqlite_do_all_statements(self, ACTION_RESET, 1); Have no opinion on this Would be really nice to not have to fix this in ech new release :-) -- ___ Python tracker <http://bugs.python.org/issue10513> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37103] Undo deprecation of optparse
New submission from Anders Kaseorg : The optparse library is currently marked in the documentation as deprecated in favor of argparse. However, argparse uses a nonstandard reinterpretation of Unix command line grammars that makes certain arguments impossible to express, and causes scripts to break when ported from optparse to argparse. See the bug report I filed nine years ago: https://bugs.python.org/issue9334 argparse does not accept options taking arguments beginning with dash (regression from optparse) The conclusion of the core developers (e.g. msg309691) seems to have been that although it’s a valid bug, it can’t or won’t be fixed with the current argparse architecture. I was asked by another core developer to file a bug report for the de-deprecation of optparse (https://discuss.python.org/t/pep-594-removing-dead-batteries-from-the-standard-library/1704/20), so here it is. -- assignee: docs@python components: Documentation, Library (Lib) messages: 343997 nosy: andersk, docs@python priority: normal severity: normal status: open title: Undo deprecation of optparse versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue37103> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)
Anders Kaseorg added the comment: porton: Please don’t steal someone else’s issue to report a different bug. Open a new issue instead. -- title: argparse: add a full fledged parser as a subparser -> argparse does not accept options taking arguments beginning with dash (regression from optparse) ___ Python tracker <https://bugs.python.org/issue9334> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15873] datetime: add ability to parse RFC 3339 dates and times
Anders Hovmöller added the comment: @larsonreever That lib is pretty limited, in that it doesn't handle dates or deltas. Again: my lib that is linked above does and has comprehensive tests. -- ___ Python tracker <http://bugs.python.org/issue15873> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22490] Using realpath for __PYVENV_LAUNCHER__ makes Homebrew installs fragile
Anders Hovmöller added the comment: I just discovered this ticket again and see that it's stuck! I have read through the thread but it's still a bit unclear what would be required to test this with homebrew like Guido says is needed for this to go forward. Is there anyone who can explain or better yet test? -- ___ Python tracker <https://bugs.python.org/issue22490> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36485] Add a way to clear all caches
Anders Hovmöller added the comment: I think this is a great idea. We would have needed this many times for tests over the years. -- nosy: +Anders.Hovmöller ___ Python tracker <https://bugs.python.org/issue36485> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32308] Replace empty matches adjacent to a previous non-empty match in re.sub()
Anders Hovmöller added the comment:
This was a really bad idea in my opinion. We just found this and we have no way
to know how this will impact production. It's really absurd that
re.sub('(.*)', r'foo', 'asd')
is "foo" in python 1 to 3.6 but 'foofoo' in python 3.7.
--
nosy: +Anders.Hovmöller
___
Python tracker
<https://bugs.python.org/issue32308>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32308] Replace empty matches adjacent to a previous non-empty match in re.sub()
Anders Hovmöller added the comment: Just as a comparison, sed does the 3.6 thing: > echo foo | sed 's/\(.*\)/x\1y/g' xfooy -- ___ Python tracker <https://bugs.python.org/issue32308> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32308] Replace empty matches adjacent to a previous non-empty match in re.sub()
Anders Hovmöller added the comment: That might be true, but that seems like a weak argument. If anything, it means those others are broken. What is the logic behind "(.*)" returning the entire string (which is what you asked for) and exactly one empty string? Why not two empty strings? 3? 4? 5? Why not an empty string at the beginning? It makes no practical sense. We will have to spend considerable effort to work around this change and adapt our code to 3.7. The lack of a discussion about backwards compatibility in this, and the other, thread before making this change is also a problem I think. -- ___ Python tracker <https://bugs.python.org/issue32308> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32601] PosixPathTest.test_expanduser fails in NixOS build sandbox
New submission from Anders Kaseorg :
PosixPathTest.test_expanduser fails in the NixOS build sandbox, where every
user has home directory /, so it falls off the end of the for pwdent in
pwd.getpwall() loop.
nixbld:x:30001:3:Nix build user:/:/noshell
nobody:x:65534:65534:Nobody:/:/noshell
==
FAIL: test_expanduser (__main__.PosixPathTest)
--
Traceback (most recent call last):
File "/nix/store/mdak9gcy16dc536ws08rshyakd1l7srj-test_pathlib.py", line
2162, in test_expanduser
self.assertEqual(p3.expanduser(), P(otherhome) / 'Documents')
AssertionError: PosixPath('/Documents') != PosixPath('Documents')
--
components: Tests
messages: 310282
nosy: andersk
priority: normal
pull_requests: 5091
severity: normal
status: open
title: PosixPathTest.test_expanduser fails in NixOS build sandbox
type: behavior
versions: Python 3.7
___
Python tracker
<https://bugs.python.org/issue32601>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32764] Popen doesn't work on Windows when args is a list
Anders Lorentsen added the comment: This is strange, because _execute_child calls os.fsdecode with `args` as the argument, which may be a list. os.fsdecode calls fspath. Now, the python docstring of _fspath, as defined in Lib/os.py on line 1031, clearly states that it will raise a TypeError if the argument is not of type bytes, str or is a os.PathLike object, and that's probably why I wrote the initial code the way I did (catching TypeError from os.fsdecode). Doesn't the try-except block actually catch this TypeError? I don't understand off the top of my head why my code doesn't catch this exception.. -- ___ Python tracker <https://bugs.python.org/issue32764> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32764] Popen doesn't work on Windows when args is a list
Anders Lorentsen added the comment: Also, isn't there continuous integration testing? Everything passed on the PR, so where does this come from? -- ___ Python tracker <https://bugs.python.org/issue32764> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32764] Popen doesn't work on Windows when args is a list
Anders Lorentsen added the comment: Wait a minute. The failing test is test_nonexisting_with_pipes, and it fails because args[0] is a tuple - how can that be? Nobody is supposed to pass cmd=sequence-where-first-element-is-a-tuple! Is everything all right with the test itself? -- ___ Python tracker <https://bugs.python.org/issue32764> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31961] subprocess._execute_child doesn't accept a single PathLike argument for args
Anders Lorentsen added the comment: > # runs this weird file > subprocess.run([bin]) > # Currently an error; if this is implemented, would run > # /bin/ls, and pass it the -l argument. Refers to something > # completely different than our .exists() call above. I do not understand where it is stated that this is the behavior. My understanding was that if run() is passed a single argument, it will interpret the string "/bin/ls -l" to mean "run the `/bin/ls` program, and pass it one argument `-l`, whereas if instead run() is given a list, it will literally treat the first element as the program to run, regardless of how many spaces or whatever else it contains ... And as such, if `bin` is a Path-like object, this issue tries to resolve that run([bin]) works as excepted, but run(bin) fails horribly. Sure, I can understand that for strings it may not feel natural how these two things are interpreted differently, but if `bin` is a Path-like object, it at least feels very natural to me that then it should be run as the program name itself (as "paths" does not have arguments). -- ___ Python tracker <https://bugs.python.org/issue31961> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31961] subprocess._execute_child doesn't accept a single PathLike argument for args
Anders Lorentsen added the comment: What do you mean "is a bug", and "the PR would encourage this"? Can't it be fixed? Are you saying that just because it is a bug now, we should be discouraged from making it work in the way you'd expect it to work? If `exe` is a path, these two lines of code should do exactly the same, right? It seems unintuitive to me if they produce different results. run(exe) run([exe]) -- ___ Python tracker <https://bugs.python.org/issue31961> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33143] encode UTF-16 generates unexpected results
New submission from Anders Rundgren :
Python 3.5.1 (v3.5.1:37a07cee5969, Dec 6 2015, 01:54:25) [MSC v.1900 64 bit
(AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> v = '\u20ac'
>>> print (v)
€
>>> v.encode('utf-16')
b'\xff\xfe\xac '
>>> v.encode('utf-16_be')
b' \xac'
I had expected to get pair of bytes with 20 AC for the € symbol
--
components: Unicode
messages: 314443
nosy: [email protected], ezio.melotti, vstinner
priority: normal
severity: normal
status: open
title: encode UTF-16 generates unexpected results
type: behavior
versions: Python 3.5
___
Python tracker
<https://bugs.python.org/issue33143>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33143] encode UTF-16 generates unexpected results
Anders Rundgren added the comment: Thanx for the superquick response! I really appreciate it. I'm obviously a Python n00b Anders -- ___ Python tracker <https://bugs.python.org/issue33143> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31843] sqlite3.connect() should accept PathLike objects
Anders Lorentsen added the comment: Had my first go at a python patch. Added a test case for it, and all tests passing when I test with `./python -bb -E -Wd -m test -v test.test_sqlite -r -w -uall -R 3:2` -- nosy: +Phaqui ___ Python tracker <https://bugs.python.org/issue31843> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31961] subprocess._execute_child doesn't accept a single PathLike argument for args
Anders Lorentsen added the comment: I was able to make a test that reproduces your code, and expectedly fails. Also implemented a fix for it. See a temporary diff here: https://pastebin.com/C9JWkg0i However, there is also a specific MS Windows version of _execute_child() (a phrase only computer-folks can say out loud without feeling very...wrong...). It uses a different method to extract and parse arguments, and it should be corrected and tested under windows, before I submit a PR for this. Also, my test messes up the formatting. Instead of saying "ok", they both say "... total 0\nok". I have no idea why. -- nosy: +Phaqui ___ Python tracker <https://bugs.python.org/issue31961> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31961] subprocess._execute_child doesn't accept a single PathLike argument for args
Anders Lorentsen added the comment: While researching this, I discovered that on MS Windows >>> subprocess.run([pathlike_object, additional_arguments]) did not run like it did on Posix. My PR includes this problem and it's fix. -- ___ Python tracker <https://bugs.python.org/issue31961> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31956] Add start and stop parameters to the array.index()
Anders Lorentsen added the comment: I decided to work on this, and I would like some review, as this would be my second contribution to cpython. Also, a general question: As I defined the start and end arguments Py_ssize_t, bigger indexes (more negative or more positive) than what can fit in Py_ssize_t will trigger an overflow error. This should be OK, though, as other functions with index arguments has them as Py_ssize_t - and getarrayitem() itself accepts a Py_ssize_t. Or? -- nosy: +Phaqui Added file: https://bugs.python.org/file47261/WIP-issue-31956 ___ Python tracker <https://bugs.python.org/issue31956> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31956] Add start and stop parameters to the array.index()
Anders Lorentsen added the comment: Writing my tests, I originally looked at Lib/test/seq_tests.py. One test case uses indexes that are (+-)4*sys.maxsize. This does not fit in Py_ssize_t, and so these tests cause my array implementation to raise an overflow exception. A solution is of course to have the function take general objects instead, and then truncate them down to a number that can fit in Py_ssize_t if it's too negative or positive). But I concur. It seems more reasonable to stay consistent with the rest of the module, too. I'll look over the test code to make sure I test for every given scenario (or as many as I can think of), and prepare a PR for this, then :) -- ___ Python tracker <https://bugs.python.org/issue31956> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22490] Using realpath for __PYVENV_LAUNCHER__ makes Homebrew installs fragile
Change by Anders Hovmöller : -- versions: +Python 3.6 ___ Python tracker <https://bugs.python.org/issue22490> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22490] Using realpath for __PYVENV_LAUNCHER__ makes Homebrew installs fragile
Change by Anders Hovmöller : -- nosy: +Anders.Hovmöller ___ Python tracker <https://bugs.python.org/issue22490> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34861] Improve cProfile standard output
New submission from Anders Hovmöller : The standard output for cProfile when run from a command line is not very useful. It has two main flaws: - Default sort order is by name of function - It strips the full path of source files The first makes it very hard to look at the output. The second is very annoying when you get a bunch of __init__.py in the output. Suggested solution: - Default cumulative time sort order - Show one additional folder level when filename is __main__ or __init__ -- components: Library (Lib) messages: 326793 nosy: Anders.Hovmöller priority: normal severity: normal status: open title: Improve cProfile standard output type: enhancement versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue34861> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34861] Improve cProfile standard output
Change by Anders Hovmöller : -- keywords: +patch pull_requests: +9046 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue34861> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34861] Improve cProfile standard output
Anders Hovmöller added the comment: There is an example output on github. Should I paste it here too? I can do it once I get home if you want. -- ___ Python tracker <https://bugs.python.org/issue34861> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34861] Improve cProfile standard output
Anders Hovmöller added the comment: Output before this patch: 3666 function calls (3556 primitive calls) in 0.005 seconds Ordered by: standard name ncalls tottime percall cumtime percall filename:lineno(function) 20.0000.0000.0020.001 :1009(_handle_fromlist) 70.0000.0000.0000.000 :103(release) 50.0000.0000.0000.000 :143(__init__) 50.0000.0000.0000.000 :147(__enter__) 50.0000.0000.0000.000 :151(__exit__) 70.0000.0000.0000.000 :157(_get_module_lock) 50.0000.0000.0000.000 :176(cb) 20.0000.0000.0000.000 :194(_lock_unlock_module) 7/10.0000.0000.0030.003 :211(_call_with_frames_removed) 530.0000.0000.0000.000 :222(_verbose_message) 50.0000.0000.0000.000 :307(__init__) 50.0000.0000.0000.000 :311(__enter__) 50.0000.0000.0000.000 :318(__exit__) 200.0000.0000.0000.000 :321() 40.0000.0000.0000.000 :35(_new_module) 50.0000.0000.0000.000 :369(__init__) 90.0000.0000.0000.000 :403(cached) 70.0000.0000.0000.000 :416(parent) 50.0000.0000.0000.000 :424(has_location) 50.0000.0000.0000.000 :504(_init_module_attrs) 50.0000.0000.0000.000 :576(module_from_spec) 50.0000.0000.0000.000 :58(__init__) 5/10.0000.0000.0040.004 :663(_load_unlocked) 50.0000.0000.0000.000 :719(find_spec) 70.0000.0000.0000.000 :78(acquire) 50.0000.0000.0000.000 :792(find_spec) 150.0000.0000.0000.000 :855(__enter__) 150.0000.0000.0000.000 :859(__exit__) 50.0000.0000.0010.000 :882(_find_spec) 5/10.0000.0000.0040.004 :948(_find_and_load_unlocked) 5/10.0000.0000.0040.004 :978(_find_and_load) 10.0000.0000.0000.000 :1072(__init__) 10.0000.0000.0000.000 :1083(create_module) 10.0000.0000.0000.000 :1091(exec_module) 10.0000.0000.0000.000 :1233(_path_hooks) 120.0000.0000.0000.000 :1246(_path_importer_cache) 50.0000.0000.0010.000 :1283(_get_spec) 50.0000.0000.0010.000 :1315(find_spec) 10.0000.0000.0000.000 :1362(__init__) 80.0000.0000.0000.000 :1368() 50.0000.0000.0000.000 :1394(_get_spec) 100.0000.0000.0010.000 :1399(find_spec) 10.0000.0000.0000.000 :1447(_fill_cache) 10.0000.0000.0000.000 :1476() 10.0000.0000.0000.000 :1488(path_hook_for_FileFinder) 80.0000.0000.0000.000 :282(cache_from_source) 100.0000.0000.0000.000 :36(_relax_case) 50.0000.0000.0000.000 :412(_get_cached) 40.0000.0000.0000.000 :444(_check_name_wrapper) 40.0000.0000.0000.000 :481(_classify_pyc) 120.0000.0000.0000.000 :51(_r_long) 40.0000.0000.0000.000 :514(_validate_timestamp_pyc) 510.0000.0000.0000.000 :56(_path_join) 40.0000.0000.0000.000 :566(_compile_bytecode) 510.0000.0000.0000.000 :58() 50.0000.0000.0000.000 :617(spec_from_file_location) 80.0000.0000.0000.000 :62(_path_split) 230.0000.0000.0000.000 :74(_path_stat) 40.0000.0000.0000.000 :762(create_module) 4/10.0000.0000.0040.004 :765(exec_module) 40.0000.0000.0010.000 :836(get_code) 90.0000.0000.0000.000 :84(_path_is_mode_type) 40.0000.0000.0000.000 :927(__init__) 80.0000.0000.0000.000 :93(_path_isfile) 40.0000.0000.0000.000 :952(get_filename) 40.0000.0000.0000.000 :957(get_data) 10.0000.0000.0000.000 :98(_path_isdir) 40.0000.0000.0000.000 :994(path_stats) 1000.0000.0000.0010.000 __init__.py:183(dumps) 10.0000.0000.0030.003 __init__.py:97() 10.0000.0000.0020.002 decoder.py:2() 10.0000.0000.0000.000 decoder.py:20(JSONDecodeError) 10.0000.0000.0000.000 decoder.py:254(JSONDecoder) 10.0000.0000.0000.000
[issue15292] import hook behavior documentation improvement
New submission from Anders Hammarquist : When testing Eutaxia on PyPy (1.9) I discovered a discrepancy in the path_hooks import hook implementation. In CPython (2.7), if the find_module() method raises ImportError (as imp.find_module() does when it does not find a module in the given path), will cause the search to continue, whereas PyPy would propagate the ImportError. PyPy has now been changed to behave like CPython. The documentation is not entirely clear, but it does not explicitly document the import hook mechanism as eating an ImportError in find_module(). It should probably be made explicit, which ever way it should be. It is not obvious what is the correct behaviour, given the implicit relative imports, where the ImportError simply means that the import hook cannot find the module. Quick testing on CPython 3.3 indicates that it behaves like PyPy did, but as it doesn't do implicit relative imports my test case didn't work as it was. For 3.3, without implicit relative imports, propagating the ImportError feels like the correct behaviour. The attached demonstration needs a file /tmp/test/foo.py that does a top-level import, e.g. "import errno" to demonstrate the discrepancy. -- assignee: docs@python components: Documentation files: testimport.py messages: 164998 nosy: docs@python, iko priority: normal severity: normal status: open title: import hook behavior documentation improvement type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file26315/testimport.py ___ Python tracker <http://bugs.python.org/issue15292> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15429] types.NoneType missing
Changes by Anders Kaseorg : -- assignee: docs@python components: Documentation nosy: andersk, docs@python priority: normal severity: normal status: open title: types.NoneType missing type: behavior versions: Python 3.2 ___ Python tracker <http://bugs.python.org/issue15429> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15429] types.NoneType missing
New submission from Anders Kaseorg : http://docs.python.org/py3k/library/constants.html#None says that None is the sole value type types.NoneType. However, NoneType was removed from the types module with Python 3. -- ___ Python tracker <http://bugs.python.org/issue15429> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20288] HTMLParse handing of non-numeric charrefs broken
New submission from Anders Hammarquist:
Python 2.7 HTMLParse.py lines 185-199 (similar lines still exist in Python 3.4)
match = charref.match(rawdata, i)
if match:
...
else:
if ";" in rawdata[i:]: #bail by consuming &#
self.handle_data(rawdata[0:2])
i = self.updatepos(i, 2)
break
if you feed a broken charref, that is non-numeric, it will pass whatever random
string that happened to be at the start of rawdata to handle_data(). Eg:
p = HTMLParser()
p.handle_data = lambda x: sys.stdout.write(x)
p.feed('&#foo;')
will print '
<http://bugs.python.org/issue20288>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6682] Default traceback does not handle PEP302 loaded modules
New submission from Anders Blomdell :
While trying to get a PEP302 import hook to function properly, I found
that the default traceback picks up the wrong sourcecode for PEP302
loaded modules.
The testcase pep302_traceback.py tries to emulate the behavior of the
files in ordinary, which generates the following output when run:
(cd ordinary ; python2.6.2 main.py )
A.__name__= a
B.__name__ a.b
Traceback (most recent call last):
File "main.py", line 6, in
a.A()
File "/tmp/ordinary/a/__init__.py", line 6, in __init__
b.B()
File "/tmp/ordinary/a/b/__init__.py", line 4, in __init__
raise Exception()
Exception
But when i run the testcase, I get the following:
python2.6.2 pep302_traceback.py
### Show possible bug in default linecache (works in 2.6.2)
A.__name__= a
B.__name__= a.b
Traceback (most recent call last):
File "pep302_traceback.py", line 82, in
i.load_module("__main__")
File "pep302_traceback.py", line 58, in load_module
exec(code, mod.__dict__)
File "<__main__.Importer>/main.py", line 6, in
a.A()
File "<__main__.Importer>/a/__init__.py", line 6, in __init__
b.B()
File "<__main__.Importer>/a/b/__init__.py", line 4, in __init__
raise Exception()
Exception
### Show possible bug in default traceback (does not work in 2.6.2)
A.__name__= a
B.__name__= a.b
Traceback (most recent call last):
File "pep302_traceback.py", line 88, in
i.load_module("__main__")
File "pep302_traceback.py", line 58, in load_module
exec(code, mod.__dict__)
File "<__main__.Importer>/main.py", line 6, in
# main.py picked up from somewhere in sys.path
File "<__main__.Importer>/a/__init__.py", line 6, in __init__
# __init__.py picked up from somewhere in sys.path
File "<__main__.Importer>/a/b/__init__.py", line 4, in __init__
# __init__.py picked up from somewhere in sys.path
Exception
I.e. in python 2.6 the linecache module correctly picks up PEP302 loaded
code, while the default traceback picks up any source file from sys.path
that happens to match the name of the file that generated the exception.
When run with python2.5.2, the linecache module also locates the wrong
file from sys.path.
--
components: Interpreter Core
files: bug.tar
messages: 91475
nosy: [email protected]
severity: normal
status: open
title: Default traceback does not handle PEP302 loaded modules
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file14692/bug.tar
___
Python tracker
<http://bugs.python.org/issue6682>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1759169] clean up Solaris port and allow C99 extension modules
anders musikka added the comment: Just wanted to chip in my $.02: Defining _XOPEN_SOURCE in the python headers causes problems for Solaris. It also causes problems for Ubuntu Linux. Because _XOPEN_SOURCE is defined, Python.h must included first in any program under Ubuntu. Perhaps the right fix is to just not define _XOPEN_SOURCE at all? Which platforms disable important features when you don't define _XOPEN_SOURCE? Sometimes there are standards which nobody follows. In such cases it can be advantageous to "just do what everyone expects". -- nosy: +avl ___ Python tracker <http://bugs.python.org/issue1759169> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5704] Command line option '-3' should imply '-t'
New submission from Simon Anders : The '-3' command line option in Python 2.6 is supposed to warn whenever encountering something that would throw an error in Python 3. Mixing of tabs and spaces has become illegal in Python 3. However, Python 2.6, called with '-3', passes silently over this unless '-t' was given, too. Would it not be more consistent to let '-3' imply '-t'? -- components: Interpreter Core messages: 85581 nosy: sanders_muc severity: normal status: open title: Command line option '-3' should imply '-t' type: behavior versions: Python 2.6, Python 2.7 ___ Python tracker <http://bugs.python.org/issue5704> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8376] Tutorial offers dangerous advice about iterator s: “__iter__() can just return self”
Anders Kaseorg added the comment:
I don’t think that small change is good enough, if it is still the case that
the only provided example is the dangerous one.
It would be easy to clarify the differences between the classes:
>>> rl = test.ReverseList('spam')
>>> [c for c in rl]
['m', 'a', 'p', 's']
>>> [c for c in rl]
['m', 'a', 'p', 's']
>>> ri = iter(rl)
>>> ri
>>> [c for c in ri]
['m', 'a', 'p', 's']
>>> [c for c in ri]
[]
--
___
Python tracker
<http://bugs.python.org/issue8376>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8376] Tutorial offers dangerous advice about iterator s: “__iter__() can just return self”
Anders Kaseorg added the comment: Antoine: That’s true. Amaury: See my original bug description (“This is reasonable advice for writing an iterator class, but terrible advice for writing a container class…”), and my other comments. There is nothing wrong with explaining how to write an iterator, but the explanation needs to make clear that this is _not_ how you write a container. Currently the section opens with a misleading motivation (“By now you have probably noticed that most container objects can be looped over using a for statement”), but it does actually not explain how to write a container at all. So I proposed some language and an example to fix that. -- ___ Python tracker <http://bugs.python.org/issue8376> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)
New submission from Anders Kaseorg :
Porting the a2x program to argparse from the now-deprecated optparse subtly
breaks it when certain options are passed:
$ a2x --asciidoc-opts --safe gitcli.txt
$ ./a2x.argparse --asciidoc-opts --safe gitcli.txt
usage: a2x [-h] [--version] [-a ATTRIBUTE] [--asciidoc-opts ASCIIDOC_OPTS]
[--copy] [--conf-file CONF_FILE] [-D PATH] [-d DOCTYPE]
[--epubcheck] [-f FORMAT] [--icons] [--icons-dir PATH] [-k]
[--lynx] [-L] [-n] [-r PATH] [-s] [--stylesheet STYLESHEET]
[--safe] [--dblatex-opts DBLATEX_OPTS] [--fop]
[--fop-opts FOP_OPTS] [--xsltproc-opts XSLTPROC_OPTS] [-v]
a2x: error: argument --asciidoc-opts: expected one argument
Apparently argparse uses a heuristic to try to guess whether an argument looks
like an argument or an option, going so far as to check whether it looks like a
negative number (!). It should _never_ guess: the option was specified to take
an argument, so the following argument should always be parsed as an argument.
Small test case:
>>> import optparse
>>> parser = optparse.OptionParser(prog='a2x')
>>> parser.add_option('--asciidoc-opts',
... action='store', dest='asciidoc_opts', default='',
... metavar='ASCIIDOC_OPTS', help='asciidoc options')
>>> parser.parse_args(['--asciidoc-opts', '--safe'])
(, [])
>>> import argparse
>>> parser = argparse.ArgumentParser(prog='a2x')
>>> parser.add_argument('--asciidoc-opts',
... action='store', dest='asciidoc_opts', default='',
... metavar='ASCIIDOC_OPTS', help='asciidoc options')
>>> parser.parse_args(['--asciidoc-opts', '--safe'])
usage: a2x [-h] [--asciidoc-opts ASCIIDOC_OPTS]
a2x: error: argument --asciidoc-opts: expected one argument
--
components: Library (Lib)
messages: 111221
nosy: andersk
priority: normal
severity: normal
status: open
title: argparse does not accept options taking arguments beginning with dash
(regression from optparse)
versions: Python 2.7, Python 3.2, Python 3.3
___
Python tracker
<http://bugs.python.org/issue9334>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)
Anders Kaseorg added the comment: > Though in general I find argparse's default behavior more useful. I’m not sure I understand. Why is it useful for an option parsing library to heuristically decide, by default, that I didn’t actually want to pass in the valid option that I passed in? Shouldn’t that be up to the caller (or up to the program, if it explicitly decides to reject such arguments)? Keep in mind that the caller might be another script instead of a user. -- ___ Python tracker <http://bugs.python.org/issue9334> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)
Anders Kaseorg added the comment:
> Note that the negative number heuristic you're complaining about
> doesn't actually affect your code below.
Yes it does:
>>> import argparse
>>> parser = argparse.ArgumentParser(prog='a2x')
>>> parser.add_argument('--asciidoc-opts',
... action='store', dest='asciidoc_opts', default='',
... metavar='ASCIIDOC_OPTS', help='asciidoc options')
>>> parser.parse_args(['--asciidoc-opts', '-1'])
Namespace(asciidoc_opts='-1')
>>> parser.parse_args(['--asciidoc-opts', '-one'])
usage: a2x [-h] [--asciidoc-opts ASCIIDOC_OPTS]
a2x: error: argument --asciidoc-opts: expected one argument
> Your problem is that you want "--safe" to be treated as a positional
> argument even though you've declared it as an option.
No, it doesn’t matter whether --safe was declared as an option: argparse
rejected it on the basis of beginning with a dash (as I demonstrated in my
small test case, which did not declare --safe as an option, and again in the
example above with -one).
> Either the user wants a conf file named "--safe", or the user
> accidentally forgot to type the name of the conf file.
But it’s not argparse’s job to decide that the valid option I passed was
actually a typo for something invalid. This would be like Python rejecting the
valid call
shell = "bash"
p = subprocess.Popen(shell)
just because shell happens to also be a valid keyword argument for the Popen
constructor and I might have forgotten to specify its value.
Including these special heuristics by default, that (1) are different from the
standard behavior of all other option parsing libraries and (2) interfere with
the ability to pass certain valid options, only leads to strange
inconsistencies between command line programs written in different languages,
and ultimately makes the command line harder to use for everyone. The default
behavior should be the standard one.
--
___
Python tracker
<http://bugs.python.org/issue9334>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)
Anders Kaseorg added the comment: > I still disagree. You're giving the parser ambiguous input. If a > parser sees "--foo --bar", and "--foo" is a valid option, but "--bar" > is not, this is a legitimately ambiguous situation. There is no ambiguity. According to the way that every standard option parsing library has worked for decades, the parser knows that --foo takes an argument, so the string after --foo is in a different grammatical context than options are, and is automatically interpreted as an argument to --foo. (It doesn’t matter whether that string begins with a dash, is a valid argument, might become a valid argument in some future version, looks like a negative number, or any other such condition.) arguments = *(positional-argument / option) [-- *(positional-argument)] positional-argument = string option = foo-option / bar-option foo-option = "--foo" string bar-option = "--bar" This is just like how variable names in Python are in a different grammatical position than keyword argument names, so that Popen(shell) is not confused with Popen(shell=True). This is not ambiguity; it simply follows from the standard definition of the grammar. argparse’s alternative interpretation of that string as another option does not make sense because it violates the requirement that --foo has been defined to take an argument. The only justification for considering that input ambiguous is if you start assuming that argparse knows better than the user (“the user accidentally forgot to type the name of the conf file”) and try to guess what they meant. This violates the user’s expectations of how the command line should work. It also creates subtle bugs in scripts that call argparse-based programs (think about call(["program", "--foo", foo_argument]) where foo_argument comes from some complex computation or even untrusted network input). > Changing the default behavior is really a non-starter unless you can > propose a sensible transition strategy (as is always necessary for > changing APIs in backwards incompatible ways). This would not be a backwards incompatible change, since every option that previously parsed successfully would also parse in the same way after the fix. -- ___ Python tracker <http://bugs.python.org/issue9334> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)
Anders Kaseorg added the comment: > arguments = *(positional-argument / option) [-- *(positional-argument)] > positional-argument = string > option = foo-option / bar-option > foo-option = "--foo" string > bar-option = "--bar" Er, obviously positional arguments before the first ‘--’ can’t begin with a dash (I don’t think there’s any confusion over how those should work). arguments = *(non-dash-positional-argument / option) ["--" *(positional-argument)] non-dash-positional-argument = positional-argument = string The point was just that the grammar unambiguously allows the argument of --foo to be any string. -- ___ Python tracker <http://bugs.python.org/issue9334> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15873] datetime: add ability to parse RFC 3339 dates and times
Anders Hovmöller added the comment: > > By the way, I just discovered, that the way we treat microseconds differs > from the strptime one : we are smarter read every digits and smartly round to > six, strptime doesn't go that far and just *truncate* to this. Should go that > way, for consistency with what strptime does, maybe ? I'm strongly against silently throwing away data and calling it even. If we want compatibility with strptime then it should be a separate flag like silent_truncate_milliseconds=True. On another matter: does the latest proposed code pass the tests in my ISO8601 implementation that I mentioned 2013 (! time flies)? -- ___ Python tracker <http://bugs.python.org/issue15873> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24954] No way to generate or parse timezone as produced by datetime.isoformat()
Anders Hovmöller added the comment: > The `arrow` library depends on the supposed "strict" behaviour of strptime > that has never been guaranteed, which often results in very buggy behaviour > under some conditions. Well… the arrow library accepts all sorts of broken input and gives you a date back. I think they even think that’s a feature and not a bug so no use in trying to help people who are adamant that they don’t want to be helped :/ -- ___ Python tracker <http://bugs.python.org/issue24954> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
