[issue40771] python3 fromtimestamp generates OSError
Jim Carroll added the comment: My bad. I read the docs, but mistakenly believed platform support meant OS. I figured since Windows maketh then Windows should taketh. I've spent the day studying the _datetimemodule.c code and now realize my error. Question -- it seems to me an unnecessary limitation. If someone were willing to submit a platform neutral version of localtime/gmtime that worked identically on all platforms, would this be met with eagerness? Or more of a shoulder shrug? It's a fair amount of effort, and I'm willing to commit to it, but if the issue only matters to me, I can work around it. -- ___ Python tracker <https://bugs.python.org/issue40771> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40771] python3 fromtimestamp generates OSError
New submission from Jim Carroll :
We encountered an interesting mtime problem in the field, that I believe
represents a bug in python's datetime timestamp handling.
A file stored on a windows server had the last-modified date '1/1/4501' (that's
the year 4501). os.path.getmtime() returns a valid timestamp, but when we try
to pass this back into datetime.datetime.fromtimestamp() we get an OSError.
I understand that generating an OSError when the date exceeds the epoch support
on Windows is consistent with the python docs. In our case, the date is clearly
supported by Windows as evidenced by it's storage in the filesystem. Further,
we can reproduce the situation using the cygwin touch utility.
>>> import os, datetime
>>> os.system('touch -d "4501-01-01" file.txt')
>>> t = os.path.getmtime('file.txt')
>>> datetime.datetime.fromtimestamp(t)
Traceback (most recent call last):
File "", line 1, in
OSError: [Errno 22] Invalid argument
What's interesting is we can manually convert it with reference to the epoch
>>> datetime.datetime(1970, 1, 1) + datetime.timedelta(seconds=t)
datetime.datetime(4501, 1, 1, 5, 0)
We used Windows 10-Pro for our tests running python 3.8.1.
--
components: Library (Lib)
messages: 369895
nosy: jamercee
priority: normal
severity: normal
status: open
title: python3 fromtimestamp generates OSError
versions: Python 3.8
___
Python tracker
<https://bugs.python.org/issue40771>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23407] os.walk always follows Windows junctions
Jim Carroll added the comment: I can confirm the os.walk() behavior still exists on 3.8. Just curious on the status of the patch? -- nosy: +jamercee ___ Python tracker <https://bugs.python.org/issue23407> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38611] ElementTree.ParseError does not implement SyntaxError interface as expected
Jim Carroll added the comment:
This patch solves the issue
diff --git a/Modules/_elementtree.c b/Modules/_elementtree.c
index c3f30c9339..d265021f75 100644
--- a/Modules/_elementtree.c
+++ b/Modules/_elementtree.c
@@ -2782,6 +2782,7 @@ treebuilder_handle_start(TreeBuilderObject* self,
PyObject* tag,
st->parseerror_obj,
"multiple elements on top level"
);
+ PyErr_SyntaxLocationEx("xml.etree.ElementTree", 0, 0);
goto error;
}
Py_INCREF(node);
@@ -3267,6 +3268,7 @@ expat_set_error(enum XML_Error error_code, Py_ssize_t
line, Py_ssize_t column,
Py_DECREF(position);
PyErr_SetObject(st->parseerror_obj, error);
+ PyErr_SyntaxLocationEx("xml.etree.ElementTree", (int)line, (int)column);
Py_DECREF(error);
}
--
___
Python tracker
<https://bugs.python.org/issue38611>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38611] Bug in traceback.py
New submission from Jim Carroll : _elementtree.c defines a custom exception 'xml.etree.ElementTree.ParseError' that inherits from SyntaxError. According to the docs https://docs.python.org/3/library/exceptions.html#SyntaxError ``Instances of this class have attributes filename, lineno, offset and text for easier access to the details.`` The ElementTree.Parser does not provide these extra attributes. While unittesting a badly formatted string passed to ET.fromstring(), the unittests/results.py module passes the exception to traceback.py, which attempts to extract the members causing it to raise a new exception. Either ElementTree.Parser should be raising something other than SyntaxErrors, or it should be providing the required attributes, or traceback.py needs to be more flexible and test for the extra attributes before accessing. I'm willing to submit a patch, but before diving in, wasn't sure which path people would prefer to see fixed? The code in traceback.py is from lines 516 - 521. -- components: Library (Lib) messages: 355518 nosy: jamercee priority: normal severity: normal status: open title: Bug in traceback.py versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue38611> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38482] BUG in codecs.BufferedIncrementalDecoder
Jim Carroll added the comment: I understand. btw; I did a deep dive on cpython codebase, and the only references to codecs.iterencode()/iterdecode() is in ./Lib/tests/test_codecs.py. I suspect functions are not used by many people. The patch I proposed was a three line change that would allow passing either an int or bytes...not sure if that sways any opinions on this topic. If we decide to just stick with existing functionality, a small clarification to the docs might be in order? -- ___ Python tracker <https://bugs.python.org/issue38482> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38485] BUG Modules/_io/texio.c
New submission from Jim Carroll :
The io.TextIOWrapper class initializes a codec.IncrementalEncoder and uses it
to encode str, but it never calls the encoder's encode('', final=True).
According to the docs
https://docs.python.org/3.5/library/codecs.html#codecs.IncrementalEncoder.encode:
``If this is the last call to encode() final must be true (the default is
false).``
Without a call to encode('', final=True), codecs cannot be created that use
codecs.BufferedIncrementalEncoder which depend on being called with final=True
to flush any internal buffers.
Platform: Python 3.7.4 (tags/v3.7.4:e09359112e, Jul 8 2019, 20:34:20) [MSC
v.1916 64 bit (AMD64)] on win32
--
messages: 354733
nosy: jamercee
priority: normal
severity: normal
status: open
title: BUG Modules/_io/texio.c
versions: Python 3.7
___
Python tracker
<https://bugs.python.org/issue38485>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38482] BUG in codecs.BufferedIncrementalDecoder
Jim Carroll added the comment: According to the documentation (https://docs.python.org/3.7/library/codecs.html#codecs.iterdecode), the first parameter is a bytes object to decode (not an iterable of bytes). Which is also consistent with it's companion iterencode() which accepts a str object, not an iterable of chars. Seems logical that one should be able to pass the output from iterencode() as the direct input to iterdecode() without having to convert, no? -- ___ Python tracker <https://bugs.python.org/issue38482> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38482] BUG in codecs.BufferedIncrementalDecoder
Change by Jim Carroll : Added file: https://bugs.python.org/file48662/codecs.patch ___ Python tracker <https://bugs.python.org/issue38482> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38482] BUG in codecs.BufferedIncrementalDecoder
Change by Jim Carroll : Removed file: https://bugs.python.org/file48661/codecs.patch ___ Python tracker <https://bugs.python.org/issue38482> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38482] BUG in codecs.BufferedIncrementalDecoder
New submission from Jim Carroll :
While working with codecs.iterdecode(), encountered "can't concat int to
bytes". The source of the problem is BufferedIncrementalDecoder stores it's
internal buffer as a bytes (ie: b""), but decode() can be passed either a byte
string or in the case of iterdecode() an int. The solution is to test for this
in the decode and if passed an int to coerce to bytes (see attach patch)
Platform: Python 3.7.4 (tags/v3.7.4:e09359112e, Jul 8 2019, 20:34:20) [MSC
v.1916 64 bit (AMD64)] on win32
Code to demonstrate the issue:
>>> import codecs
>>> source = ''.join([chr(x) for x in range(256)])
>>> enc = b''.join(codecs.iterencode(source, 'utf-8'))
>>> list(''.join(codecs.iterdecode(enc, 'utf-8')))
Traceback (most recent call last):
File "", line 1, in
File "C:\Python37\lib\codecs.py", line 1048, in iterdecode
output = decoder.decode(input)
File "C:\Python37\lib\codecs.py", line 321, in decode
data = self.buffer + input
TypeError: can't concat int to bytes
--
components: Library (Lib)
files: codecs.patch
keywords: patch
messages: 354707
nosy: jamercee
priority: normal
severity: normal
status: open
title: BUG in codecs.BufferedIncrementalDecoder
versions: Python 3.7
Added file: https://bugs.python.org/file48661/codecs.patch
___
Python tracker
<https://bugs.python.org/issue38482>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35789] Typo in unittest.mock docs
Jim Carroll added the comment: Never mindi see this issue has been reported previously and the typo is considered intentional. -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue35789> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35789] Typo in unittest.mock docs
New submission from Jim Carroll : There is a typo in the unittest.mock documentation found at https://docs.python.org/3/library/unittest.mock.html. There are seven(7) instances of the word assret, where the author clearly intended assert. -- assignee: docs@python components: Documentation messages: 334087 nosy: docs@python, jamercee priority: normal severity: normal status: open title: Typo in unittest.mock docs type: enhancement versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue35789> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23136] BUG in how _strptime() handles week 0
Jim Carroll added the comment: Thanks for all your work ! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23136 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23136] BUG in how _strptime() handles week 0
Jim Carroll added the comment: All the proposed patches are acceptable from my point of view, but it would be really great if we could get the fix in the 2.x line. It seems unlikely there could be any legacy code that would depend on the bug to exist (ie: to only be wrong when then date requested is exactly two days before the first date of the new year). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23136 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23136] BUG in how _strptime() handles week 0
Jim Carroll added the comment: I understand. Actually, raising an exception would be perfectly acceptable as well (possibly even more desirable). I too experimented with the c-lib strptime() and discovered the negative values of tm_mday. These results are good too -- as they clearly show the number of days before the new year. I don't think it's important for the python version to return the same values, but it would be better for it to at least be predictable. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23136 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23129] sqlite3 COMMIT nested in SELECT returns unexpected results
Jim Carroll added the comment:
Completely understood.
I recently found a workaround. Setting isolation_level to None seems to
mitigate the issue, ie:
db = sq.connect(':memory:', isolation_level=None)
I'm hoping to put some time in scrutinizing the c-api code later this week (as
SQLite bugs directly affect projects we work on) to see if we can get to the
bottom of the issue.
--
title: sqlite3 COMMIT nested in SELECT returns unexpected results -
sqlite3 COMMIT nested in SELECT returns unexpected results
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23129
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23136] BUG in how _strptime() handles week 0
New submission from Jim Carroll:
The following bit of code demonstrates a bug in how _strptime handles week 0.
The bug is an edge condition that specifically affects how it handles two days
before the first day of the new year
for i in range(7):
... datetime.strptime('%s %s %s' % (0, 2015, i), '%W %Y %w').date()
...
datetime.date(2015, 1, 4)
datetime.date(2014, 12, 29)
datetime.date(2015, 1, 1) # -- ERROR: should be '2014, 12, 30'
datetime.date(2014, 12, 31)
datetime.date(2015, 1, 1)
datetime.date(2015, 1, 2)
datetime.date(2015, 1, 3)
The issue stems from the fact that calls to _calc_julian_from_U_or_W() can
return a -1, which under normal circumstances is invalid. The strptime()
function tests and corrects when julian values are -1...but it should not do
this when the week_of_year is zero.
The fact that it tests for ONLY -1 is why we see the problem in 2015. The error
condition only exists when the first day of the year is exactly two days ahead
of the date being tested for.
Patch is attached
--
components: Library (Lib)
files: patch.txt
messages: 233219
nosy: jamercee
priority: normal
severity: normal
status: open
title: BUG in how _strptime() handles week 0
versions: Python 2.7
Added file: http://bugs.python.org/file37568/patch.txt
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23136
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23129] sqlite3 COMMIT nested in SELECT returns unexpected results
New submission from Jim Carroll:
I reported this to the sqlite mailing list, and the comments I received
suggested the problem may by the python sqlite connector issue, so I'm opening
this as a bug report.
I understand that performing a SELECT and nested COMMIT on the same table is
not supported in sqlite, but I would have expected a COMMIT on a separate table
would not be a problem. Some test code in python however reveals that
performing the COMMIT disrupts the SELECT statement, and causes duplicate data
to be returned.
If this is not a supported operation, would you mind pointing me to the docs so
I can understand it better?
Example
#!/usr/bin/env python
import sqlite3 as sq
db = sq.connect(':memory:')
db.execute('CREATE TABLE tbl (col INTEGER)')
db.execute('CREATE TABLE tbl2 (col INTEGER)')
db.executemany('INSERT INTO tbl (col) VALUES (?)', [(0,), (1,), (2,)])
db.commit()
print('count=' + str(db.execute('SELECT count(*) FROM tbl').fetchone()[0]))
# Read and print the values just inserted into tbl
for col in db.execute('SELECT col FROM tbl'):
print(col)
db.execute('INSERT INTO tbl2 VALUES (?)', col)
db.commit()
print('count=' + str(db.execute('SELECT count(*) FROM tbl').fetchone()[0]))
The output we see is:
count=3
(0,)
(1,)
(0,)
(1,)
(2,)
count=3
The expected output was:
count=3
(0,)
(1,)
(2,)
count=3
Tested on Linux:
sqlite version 3.7.13
sqlite3 connector version 2.6.0
# uname -a
Linux hostname 3.16-0.bpo.3-amd64 #1 SMP Debian
3.16.5-1~bpo70+1 (2014-11-02) x86_64 GNU/Linux
Also tested on Windows with identical results
Sqlite version 3.6.21
Windows 7 Professional, 64-bit
--
messages: 233178
nosy: jamercee
priority: normal
severity: normal
status: open
title: sqlite3 COMMIT nested in SELECT returns unexpected results
type: behavior
versions: Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23129
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23129] sqlite3 COMMIT nested in SELECT returns unexpected results
Jim Carroll added the comment: Hi David, One more data point. Although I demonstrated the bug using the .execute() method associated with a connection object -- you can also create the exact problem using the .execute() method associated with cursors. This leaves no means to COMMIT inside a nested SELECT. The members of the sqlite mailing list confirmed they had no problem executing the SQL statements using C and PHP. I think this is a bug, rather than just a problem with the docs. I've been digging around the pysqlite C source but can't quite figure out what's going on yet. Jim -Original Message- From: R. David Murray [mailto:rep...@bugs.python.org] Sent: Monday, December 29, 2014 1:08 PM To: j...@carroll.com Subject: [issue23129] sqlite3 COMMIT nested in SELECT returns unexpected results R. David Murray added the comment: I'd say you have a bug here of some sort, but I'm not sure if it is a doc bug or a code bug. Commit specifically does *not* reset the cursors, according to the code, but I'm not even sure what resetting a cursor means :) I've poked around the sqlite3 module's code a bit, but not enough to have an answer to this. I do note that a commit does a call to sqlite3_reset on all statements associated with the connection, and I suspect that's where the problem originates. Which probably makes it a doc bug. -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23129 ___ -- title: sqlite3 COMMIT nested in SELECT returns unexpected results - sqlite3 COMMIT nested in SELECT returns unexpected results ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23129 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22199] Embedding Python documentation error
New submission from Jim Carroll: On the page https://docs.python.org/2/extending/embedding.html#compiling-and-linking-under-unix-like-systems The documentation makes the following reference: ...(use sysconfig.get_makefile_filename() to find its location)... But this is incorrect. sysconfig was modified in 3.x (Issue 9877) to use this new name. In 2.x, the function has an underscore prefix: sysconfig._get_makefile_filename() -- assignee: docs@python components: Documentation messages: 225307 nosy: docs@python, jamercee priority: normal severity: normal status: open title: Embedding Python documentation error versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22199 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19998] Python 2.7.6 fails to build _ctypes on GCC 2.x toolchain
Jim Carroll added the comment: As requested, I've opened the issue with the libffi project: https://github.com/atgreen/libffi/issues/63 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19998 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19998] Python 2.7.6 fails to build _ctypes on GCC 2.x toolchain
New submission from Jim Carroll: When building Python 2.7.6 on older GCC 2.x, the _ctypes module fails to build. The failure is caused due to a header file reference to __builtin_expect (the author expected this to be available when the module was built with gcc, but did not take into account that this was not available in all versions of gcc). The solution is a simple modification to the test in ffi_common.h --- Modules/_ctypes/libffi/include/ffi_common.h Sun Nov 10 02:36:41 2013 +++ Modules/_ctypes/libffi/include/ffi_common.h.fix Mon Dec 16 08:23:56 2013 @@ -115,7 +115,7 @@ typedef float FLOAT32; -#ifndef __GNUC__ +#if !defined(__GNUC__) || __GNUC__==2 #define __builtin_expect(x, expected_value) (x) #endif #define LIKELY(x)__builtin_expect(!!(x),1) -- components: Build files: ffi_common.h.patch keywords: patch messages: 206307 nosy: jamercee priority: normal severity: normal status: open title: Python 2.7.6 fails to build _ctypes on GCC 2.x toolchain type: compile error versions: Python 2.7 Added file: http://bugs.python.org/file33165/ffi_common.h.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19998 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18341] enhancements zlib.compress/decompress to accept Py_buffer
New submission from Jim Carroll: We were looking to squeak maximum performance out of zlib.compress. We noticed in py3k, zlib.compress already accepts Py_buffer’s, but in 2.x, compress required strings. We’ve modified the compress (and decompress for orthogonal completeness), see the attached patch. -- components: Extension Modules files: zlibmodule.c.patch keywords: patch messages: 192135 nosy: jamercee priority: normal severity: normal status: open title: enhancements zlib.compress/decompress to accept Py_buffer type: enhancement versions: Python 2.7 Added file: http://bugs.python.org/file30742/zlibmodule.c.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18341 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
