[issue14574] SocketServer doesn't handle client disconnects properly
New submission from Vlad :
When dealing with a new connection, SocketServer.BaseRequestHandler.__init__
first calls the request handler (self.handle below) and then calls cleanup code
which closes the connection (self.finish below).
class BaseRequestHandler:
def __init__(self, request, client_address, server):
< ... snip ... >
try:
self.handle()
finally:
self.finish()
The issue arises when a client disconnects suddenly during the self.handle()
call. The handler may attempt to write data to the disconnected socket. This
will cause an exception (which is correct), but somehow data will still be
added to the connection's buffer and self.wfile.closed will be False! As a
result, BaseRequestHandler.finish() will attempt to flush the connection's
buffer and this will raise another exception which can't be handled without
modifying the library code.
Exception happened during processing of request from ('127.0.0.1', 62718)
Traceback (most recent call last):
File "C:\Python27\lib\SocketServer.py", line 284, in _handle_request_noblock
self.process_request(request, client_address)
File "C:\Python27\lib\SocketServer.py", line 310, in process_request
self.finish_request(request, client_address)
File "C:\Python27\lib\SocketServer.py", line 323, in finish_request
self.RequestHandlerClass(request, client_address, self)
File "C:\Python27\lib\SocketServer.py", line 641, in __init__
self.finish()
File "C:\Python27\lib\SocketServer.py", line 694, in finish
self.wfile.flush()
File "C:\Python27\lib\socket.py", line 303, in flush
self._sock.sendall(view[write_offset:write_offset+buffer_size])
error: [Errno 10053] An established connection was aborted by the software in
your host machine
I've provided a toy server below, you can reproduce the issue by submitting a
request to it with curl and then immediately killing curl:
curl -d "test" http://127.0.0.1:8000/
Toy server code:
===
import BaseHTTPServer
import SocketServer
import time
class ThreadedHTTPServer(BaseHTTPServer.HTTPServer):
pass
class RequestHandler(BaseHTTPServer.BaseHTTPRequestHandler):
def do_POST(self):
try:
length = int(self.headers["Content-Length"])
request = self.rfile.read(length)
print "Sleeping. Kill the 'curl' command now."
time.sleep(10)
print "Woke up. You should see a stack trace from the problematic
exception below."
print "Received POST: " + request
self.send_response(200) # <--- This somehow adds to the connection's
buffer!
self.end_headers()
except Exception as e:
print "Exception: " + str(e) # <- This exception is expected
httpd = ThreadedHTTPServer(("127.0.0.1", 8000), RequestHandler)
httpd.serve_forever()
httpd.server_close()
--
components: Library (Lib)
messages: 158240
nosy: vdjeric
priority: normal
severity: normal
status: open
title: SocketServer doesn't handle client disconnects properly
versions: Python 2.7
___
Python tracker
<http://bugs.python.org/issue14574>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7254] Class members not properly initialized if declared outside of function
New submission from Vlad : If a class member is declared outside of a function, it's creation is _not_ repeated with every new instance of the class. Instead, the same member is created during the first instance and then shared by all the subsequent instances of that class. This is wrong, because a new member should be created for every instance. I have attached a sample code contrasting the incorrect behavior (on top) with the correct behavior (on bottom). Python behaves correctly if the member is declared in __init__ (that is, Python initializes a new member for every instance). The output of "print b.greet" and "print d.greet" should be the same and should read "['Howdy']". -- files: class_member_init_inconsistency.py messages: 94851 nosy: vladc6 severity: normal status: open title: Class members not properly initialized if declared outside of function type: behavior versions: Python 2.5 Added file: http://bugs.python.org/file15253/class_member_init_inconsistency.py ___ Python tracker <http://bugs.python.org/issue7254> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17408] second python execution fails when embedding
New submission from Vlad: This issue is for Python3.3 and doesn't exist in Python3.2 Detailed description with source code can be found here: http://stackoverflow.com/questions/15387035/second-python-execution-fails -- components: None messages: 184081 nosy: theDarkBrainer priority: normal severity: normal status: open title: second python execution fails when embedding type: crash versions: Python 3.3 ___ Python tracker <http://bugs.python.org/issue17408> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17408] second python execution fails when embedding
Vlad added the comment:
I'm trying to embed the python 3.3 engine for an app that need to run custom
scripts in python. Since the scripts might be completely different, and
sometimes user provided, I am trying to make each execution isolated and there
is not need to preserve any data between execution of the different scripts.
So, my solution is to wrap each execution between 'Py_Initialize' and
'Py_Finalize'. It looks something like that:
void ExecuteScript(const char* script)
{
Py_Initialize();
PyRun_SimpleString( script );
Py_Finalize();
}
However, this fails for a particular python script the second time a script is
executed with:
done!
Traceback (most recent call last):
File "", line 8, in
File "\Python33Test\Output\Debug\Python33\Lib\copy.py", line 89, in copy
rv = reductor(2)
TypeError: attribute of type 'NoneType' is not callable
The python script looks like this:
class Data:
value1 = 'hello'
value2 = 0
import copy
d = Data()
dd = copy.copy( d )
print ( 'done!' )
As you can see, the first time around the script was executed the 'done!' was
printed out. But the second time it rises an exception inside the copy function.
It looks like the python engine was left in some weird state after the first
initialize-finalize. Note, this is python 3.3.
Also, it is very interesting to note that Python 2.7 and Python 3.2 did not
have this problem.
I guess there might be other examples that could reveal better what's going,
but i haven't had the time to find yet.
I also put a copy of the project containing flag to switch between Python 3 and
Python 2.7 (the file is 31 MB):
https://docs.google.com/file/d/0B86-G0mwwxZvbWRldTd5b2NNMWM/edit?usp=sharing
Thanks, Vlad
--
Added file: http://bugs.python.org/file29398/Python33Test.zip
___
Python tracker
<http://bugs.python.org/issue17408>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12880] ctypes: clearly document how structure bit fields are allocated
Vlad Riscutia added the comment: Attached doc update against tip (though I still hope my patch for configurable allocation strategies will make it in). This is my first doc patch so let me know if I missed something. I am basically explaining that bit field allocation is compiler-specific and no assumptions should be made of how a bitfield is allocated. I believe this is the better thing to do rather than detailing how GCC and MSVC allocated their bitfields because that would just encourage people to use this feature incorrectly. Most bugs opened on bit fields are because people are toying with the underlying buffer and get other results than what they expect. IMO, when using bitfields one should only access the structure members at a high level and not go read/write the raw memory underneath. -- keywords: +patch Added file: http://bugs.python.org/file23275/bitfield_doc.diff ___ Python tracker <http://bugs.python.org/issue12880> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5001] Remove assertion-based checking in multiprocessing
Vlad Riscutia added the comment: I attached a patch which replaces all asserts with checks that raise exceptions. I used my judgement in determining exception types but I might have been off in some places. Also, this patch replaces ALL asserts. It is possible that some of the internal functions should be kept using asserts but I am not familiar enough with the module to say which. I figured I'd better do the whole thing than reviewers can say where lines should be reverted to asserts. -- keywords: +patch nosy: +vladris Added file: http://bugs.python.org/file23298/issue5001.diff ___ Python tracker <http://bugs.python.org/issue5001> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5001] Remove assertion-based checking in multiprocessing
Vlad Riscutia added the comment: Thanks for the quick review! I attached second iteration addressing feedback + changed all occurrences of checks like "type(x) is y" to "isinstance(x, y)". I would appreciate a second look because this patch has many small changes and even though I ran full test suit which passed, I'm afraid I made a typo somewhere :) -- Added file: http://bugs.python.org/file23302/issue5001_v2.diff ___ Python tracker <http://bugs.python.org/issue5001> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12880] ctypes: clearly document how structure bit fields are allocated
Vlad Riscutia added the comment: Thanks for the "make patchcheck" tip, I didn't know about that. I will update the patch soon. In the mean time, I want to point out a couple of things: First, I'm saying "toying with the underlying buffer" because none of the bugs are actual issues of the form "I created this bitfield structure with Python, passed it to C function but C structure was different". That would be a bitfield bug. All of these bugs are people setting raw memory to some bytes, then looking at bitfield members and not seeing what they expect. Since this is platform dependent, they shouldn't worry about the raw memory as long as C interop works fine. Bitfield layout is complex as it involves both allocation algorithm and structure packing and same Python code will work differently on Windows and Unix. My point is that documenting all this low-level stuff will encourage people to work with the raw memory which will open the door for other issues. I believe it would be better to encourage users to stick to declaring members and accessing them by name as raw memory WILL be different for the same code on different OSes. Second, one of your review comments is: "GCC is used for most Unix systems and Microsoft VC++ is used on Windows.". This is not how ctypes works. Ctypes implements the bitfield allocation algorithm itself, it doesn't use the compiler with which it is built. Basically it says #ifdef WIN32 - allocate like VC++ - #else - allocate like GCC. So it doesn't really matter with which compiler you are building Python. It will still do GCC style allocation on Solaris. -- ___ Python tracker <http://bugs.python.org/issue12880> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12880] ctypes: clearly document how structure bit fields are allocated
Vlad Riscutia added the comment: I agree compiler matters for alignment but if you look at PyCField_FromDesc, you will see the layout is pretty much #ifdef MS_WIN32 - #else. Sorry for generalizing, "all" indeed is not the right word. My point is that we should set expectation correctly - VC++-style on Windows, GCC-style everywhere else and encourage users to access structure members by name, not raw memory. Issues opened for bitfields *usually* are of the form I mentioned - setting raw memory to some bytes then seeing members are not what user expected, even if ctypes algorithm works correctly. As I said, I will revise the patch and maybe make it more clear that users should look up how bitfield allocation works for their compiler instead of trying to understand this via structure raw memory. -- ___ Python tracker <http://bugs.python.org/issue12880> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6068] ctypes is not correctly handling bitfields backed by 64 bit integers on Windows
Vlad Riscutia added the comment:
Changing title and type to better reflect issue.
On Windows MSVC build, ctypes is not correctly setting bitfields backed by 64
bit integers if specifying custom width. Simple repro:
from ctypes import *
class X(Structure):
_fields_ = [("a", c_ulonglong, 16),
("b", c_ulonglong, 32),
("c", c_ulonglong, 16)]
s = X()
s.b = 1
print(s.b) # this prints 0
Whenever field width goes over 32 bits, setting or getting value of the field
in cfield.c will only look at last ( - 32) bits of the field. So
if we have a field of 34 bits, only least significant 2 bits will be operated
on. The above repro results in an ( - 32) = 0 bits so nothing is
getting set with the assignement.
This is not caught in unit test package because we have only this in
test_bitfields.py:
def test_ulonglong(self):
class X(Structure):
_fields_ = [("a", c_ulonglong, 1),
("b", c_ulonglong, 62),
("c", c_ulonglong, 1)]
self.assertEqual(sizeof(X), sizeof(c_longlong))
x = X()
self.assertEqual((x.a, x.b, x.c), (0, 0, 0))
x.a, x.b, x.c = 7, 7, 7
self.assertEqual((x.a, x.b, x.c), (1, 7, 1))
For 62 bit width, we will actually operate on last 30 bits but this test passes
as 7 fits in those bits. If we would actually try to set it to
0x3FFF, result will be different than expected (0x3FFF).
I will look into extending UT package with some tests that set full range of
bits and check if they are actually being set correctly.
This issue reproes with latest bits but only on Windows. Root cause seems to be
BIT_MASK macro in cfield.c which is ifdef-ed to something different on Windows.
I patched on my machine by removing the special treatment:
@@ -429,12 +429,7 @@
#define LOW_BIT(x) ((x) & 0x)
#define NUM_BITS(x) ((x) >> 16)
-/* This seems nore a compiler issue than a Windows/non-Windows one */
-#ifdef MS_WIN32
-# define BIT_MASK(size) ((1 << NUM_BITS(size))-1)
-#else
-# define BIT_MASK(size) ((1LL << NUM_BITS(size))-1)
-#endif
+#define BIT_MASK(size) ((1LL << NUM_BITS(size))-1)
/* This macro CHANGES the first parameter IN PLACE. For proper sign handling,
we must first shift left, then right.
Unittests still pass with this in place and now fields are handled correctly
though I don't know why this was put in in the first place. Looking at file
history it seems it was there from the start (from 2006). Could it be that it
was addressing some MSVC bug which got fixed in the meantime? Things seem to be
building and working fine now when using 1LL for shift.
Also related to this I have doubts about the SWAP_8 macro which is similarly
changed for MSVC, also in cfield.c.
I am only able to build 32 bit version so I can't say whether this was put in
place due to some x64 issue, maybe someone can check behavior on x64 build. If
that's the case, maybe #ifdef should take that into account.
--
nosy: +vladris
title: support read/write c_ulonglong type bitfield structures -> ctypes is not
correctly handling bitfields backed by 64 bit integers on Windows
type: feature request -> behavior
versions: +Python 3.3 -Python 3.2
___
Python tracker
<http://bugs.python.org/issue6068>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6068] ctypes is not correctly handling bitfields backed by 64 bit integers on Windows
Vlad Riscutia added the comment: Terry, I am kind of new to this so I might not have marked header correctly. Please feel free to fix it. This is 100% bug not feature request. Initial message was confusing because highstar thought Python has such bitfields as readonly and was asking for a feature to make them read-write. That is not the case, behavior is caused by a bug. By UT I mean unittest. I reproed this on 64bit Windows 7 on latest sources with x32 build (as I said, I don't have x64 build). -- ___ Python tracker <http://bugs.python.org/issue6068> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6068] ctypes is not correctly handling bitfields backed by 64 bit integers on Windows
Vlad Riscutia added the comment: Attached is addition to unittests which repro the issue. They will currently pass on Linux but fail on Windows. -- keywords: +patch Added file: http://bugs.python.org/file22447/issue6068_unittest.diff ___ Python tracker <http://bugs.python.org/issue6068> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6069] casting error from ctypes array to structure
Vlad Riscutia added the comment:
I took a look at this and I believe behavior is correct on Windows, the issue
is with the test. For example this test is failing:
class closest_fit(ctypes.BigEndianStructure):
_pack_ = 1# aligned to 8 bits, not ctypes default of 32
_fields_= [
("Data0", ctypes.c_uint32, 32),
("Data1", ctypes.c_uint8, 3),
("Data2", ctypes.c_uint16, 12),
]
But you also have this assumption when generating the test data:
size_of_structures_in_bytes = 6
I verified and this does not hold with MSVC compiler. Using VC++ 2005, this code
typedef struct Test {
unsigned int x: 32; // uint_32 : 32
unsigned char y: 3; // uint_8 : 3
unsigned short int z: 12; // uint_16 : 12
} Test;
gives sizeof(Test) == 7. In Python, if you look at sizeof(closest_fit), it will
also be 7.
Looking at cfield.c, seems this was taken into account when creating bit fields:
if (bitsize /* this is a bitfield request */
&& *pfield_size /* we have a bitfield open */
#ifdef MS_WIN32
/* MSVC, GCC with -mms-bitfields */
&& dict->size * 8 == *pfield_size
#else
/* GCC */
&& dict->size * 8 <= *pfield_size
#endif
&& (*pbitofs + bitsize) <= *pfield_size) {
/* continue bit field */
fieldtype = CONT_BITFIELD;
#ifndef MS_WIN32
} else if (bitsize /* this is a bitfield request */
&& *pfield_size /* we have a bitfield open */
&& dict->size * 8 >= *pfield_size
&& (*pbitofs + bitsize) <= dict->size * 8) {
/* expand bit field */
fieldtype = EXPAND_BITFIELD;
#endif
} else if (bitsize) {
/* start new bitfield */
fieldtype = NEW_BITFIELD;
*pbitofs = 0;
*pfield_size = dict->size * 8;
Though I don't know this first-hand, above code plus sizeof experiment leads me
to believe that gcc packs bitfields differently than MSVC. Seems that gcc will
expand existing bitfield trying to pack structure more tightly so indeed on
Linux (or I assume Windows gcc build), size of this structure is 6 as gcc will
combine these seeing that an unsigned short can hold all 15 bits required but
with MSVC this won't work. MSVC will allocate both the c_uint8 and the c_uint16
once is sees that last 12 bits don't fit in remaining c_uint8.
As far as I can tell this is by design and Python matches expected MSVC
structure packing for this test case.
--
nosy: +vladris
___
Python tracker
<http://bugs.python.org/issue6069>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6068] ctypes is not correctly handling bitfields backed by 64 bit integers on Windows
Vlad Riscutia added the comment: Attaching patch as previous attachment is only unittest. I included change to SWAP_8 macro also as it looks like same issue and it will probably popup later. -- Added file: http://bugs.python.org/file22451/issue6068_patch.diff ___ Python tracker <http://bugs.python.org/issue6068> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12528] Implement configurable bitfield allocation strategy
New submission from Vlad Riscutia :
Opened this issue to track configurable bitfield allocation strategy. This will
address issues like http://bugs.python.org/issue6069,
http://bugs.python.org/issue11920.
Summary: the way bitfields are allocated is up to the compiler not defined by
standard. MSVC and GCC have different strategies to perform the allocation so
the size of bitfield structures can be different depending on compiler.
Currently we hardcode allocation strategy to be GCC-way on non-Windows and
MSVC-way on Windows which raises issues when trying to interop on Windows with
GCC binaries.
Short term this solution will enable interop between MSVC compiled Python with
GCC compiled binaries under Windows. It will also enable addressing other
possible compiler interop issues in the future, for compilers that don't use
GCC strategy.
Following is copied from thread discussing this:
On 6/25/2011 12:33 PM, Vlad Riscutia wrote:
I recently started looking at some ctypes issues. I dug a bit into
http://bugs.python.org/issue6069 and then I found
http://bugs.python.org/issue11920. They both boil down to the fact that
bitfield allocation is up to the compiler, which is different in GCC and
MSVC. Currently we have hard-coded allocation strategy based on paltform
in cfields.c:
if (bitsize /* this is a bitfield request */
&& *pfield_size /* we have a bitfield open */
#ifdef MS_WIN32
/* MSVC, GCC with -mms-bitfields */
&& dict->size * 8 == *pfield_size
#else
/* GCC */
&& dict->size * 8<= *pfield_size
#endif
&& (*pbitofs + bitsize)<= *pfield_size) {
/* continue bit field */
fieldtype = CONT_BITFIELD;
#ifndef MS_WIN32
} else if (bitsize /* this is a bitfield request */
&& *pfield_size /* we have a bitfield open */
&& dict->size * 8>= *pfield_size
&& (*pbitofs + bitsize)<= dict->size * 8) {
/* expand bit field */
fieldtype = EXPAND_BITFIELD;
#endif
So when creating a bitfield structure, it's size can be different on
Linux vs Windows.
class MyStructure(ctypes.BigEndianStructure):
_pack_ = 1# aligned to 8 bits, not ctypes default of 32
_fields_= [
("Data0", ctypes.c_uint32, 32),
("Data1", ctypes.c_uint8, 3),
("Data2", ctypes.c_uint16, 12),
]
sizeof for above structure is 6 on GCC build and 7 on MSVC build. This
leads to some confusion and issues, because we can't always interop
correctly with code compiled with different compiler than the one Python
is compiled with on the platform.
Just curious, are you saying that this is the 'cause' of the two bug reports,
or 'just' something you discovered while investigating them?
> Short term solution is to add a warning in the documentation about this.
For 2.7/3.2, yes.
> Longer term though, I think it
would be better to add a property on the Structure class for
configurable allocation strategy, for example Native (default), GCC,
MSVC and when allocating the bitfield, use given strategy. Native would
behave similar to what happens now, but we would also allow GCC-style
allocation on Windows for example and the ability to extend this if we
ever run into similar issues with other compilers. This shouldn't be too
difficult to implement, will be backwards compatible and it would
improve interop. I would like to hear some opinions on this.
If this would allow the MSVC-compilied Python to better access dlls compiled
with gcc (cygwin) on Windows, definitely -- in 3.3.
If the new feature is (currently) only useful on Windows, doc should say so.
--
Terry Jan Reedy
/copy
Attached is patch with initial refactoring of cfield.c to enable configurable
allocation. Next step is to provide a way to configure this through Python
library. I will also look at updating documentation to point out the known
issue.
--
components: ctypes
files: cfield_bitfield_refactoring.diff
keywords: patch
messages: 140088
nosy: terry.reedy, vladris
priority: normal
severity: normal
status: open
title: Implement configurable bitfield allocation strategy
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file22617/cfield_bitfield_refactoring.diff
___
Python tracker
<http://bugs.python.org/issue12528>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11920] ctypes: Strange bitfield structure sizing issue
Vlad Riscutia added the comment: Opened http://bugs.python.org/issue12528 to address this. -- nosy: +vladris ___ Python tracker <http://bugs.python.org/issue11920> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6069] casting error from ctypes array to structure
Vlad Riscutia added the comment: Opened http://bugs.python.org/issue12528 to address this. -- versions: +Python 3.3 ___ Python tracker <http://bugs.python.org/issue6069> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12528] Implement configurable bitfield allocation strategy
Vlad Riscutia added the comment: Removed previously attached partial patch, this is complete patch. Summary: Added following 3 constants in ctypes: ctypes.BITFIELD_ALLOCATION_NATIVE ctypes.BITFIELD_ALLOCATION_GCC ctypes.BITFIELD_ALLOCATION_MSVC Setting _bitfield_allocation_ attribute to one of these on a class declaration inheriting from Structure will force specified allocation of the bitfield. NATIVE is equivalent to not specifying anything. GCC will do GCC-style allocation (what Python does now on non-Windows) MSVC will do MSVC-style allocation (what Python does now on Windows) I added unittests to cover these and ran full suit on both Windows and Linux. Still have to update documentation to mention this. Will submit diff for that after this gets reviewed. -- Added file: http://bugs.python.org/file22618/configurable_bitfield_allocation.diff ___ Python tracker <http://bugs.python.org/issue12528> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12528] Implement configurable bitfield allocation strategy
Changes by Vlad Riscutia : Removed file: http://bugs.python.org/file22617/cfield_bitfield_refactoring.diff ___ Python tracker <http://bugs.python.org/issue12528> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8161] inconsistency behavior in ctypes.c_char_p dereferencing
Vlad Riscutia added the comment:
Looks like this was implemented by design at some point. In cfield.c, we have
specific code to treat character array fields as strings:
/* Field descriptors for 'c_char * n' are be scpecial cased to
return a Python string instead of an Array object instance...
*/
if (PyCArrayTypeObject_Check(proto)) {
StgDictObject *adict = PyType_stgdict(proto);
StgDictObject *idict;
if (adict && adict->proto) {
idict = PyType_stgdict(adict->proto);
if (!idict) {
PyErr_SetString(PyExc_TypeError,
"has no _stginfo_");
Py_DECREF(self);
return NULL;
}
if (idict->getfunc == _ctypes_get_fielddesc("c")->getfunc) {
struct fielddesc *fd = _ctypes_get_fielddesc("s");
getfunc = fd->getfunc;
setfunc = fd->setfunc;
}
#ifdef CTYPES_UNICODE
if (idict->getfunc == _ctypes_get_fielddesc("u")->getfunc) {
struct fielddesc *fd = _ctypes_get_fielddesc("U");
getfunc = fd->getfunc;
setfunc = fd->setfunc;
}
#endif
}
}
Simple fix would be to just remove this whole section though this might break
code which relied on string assignment to such fields. For example:
class T(ctypes.Structure):
_fields_ = (
('member', ctypes.c_char * 16),
)
x = T()
x.member = bytes('Spam', 'ascii')
Above works now but will fail if change is made. There is a high chance this
would break existing code as I imagine people using this due to convenience. An
alternative would be to keep string setfunc but don't change getfunc, though
that is also pretty inconsistent as you will be able to set a string but not
get one back.
If we are willing to take the risk, fix is easy.
--
nosy: +vladris
___
Python tracker
<http://bugs.python.org/issue8161>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6493] Can not set value for structure members larger than 32 bits
Vlad Riscutia added the comment: I have a similar patch for issue 6068. I wasn't aware of this issue when I looked into it. I believe both patches fix the same thing (please take a look and correct me if I'm wrong). My fix: we don't need to treat Windows differently, just remove #ifdef and #define BIT_MASK(size) ((1LL << NUM_BITS(size))-1) regardless of platform. Unittests for this patch pass for my patch too. I believe this is some old #ifdef that was put in place due to a compiler bug which got fixed since then. -- nosy: +vladris ___ Python tracker <http://bugs.python.org/issue6493> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12142] Reference cycle when importing ctypes
Vlad Riscutia added the comment:
I ran full test suit after making the _array_type = type(Array) change and
everything passes.
I also took a look at this and found additional leak. gc shows this as garbage:
[(,), , , , (, , , ), {'__dict__': , '_type_': 'g', '__module__': 'ctypes', '__weakref__': , '__doc__': None}]
This is all caused by these lines in ctypes __init__.py:
class c_longdouble(_SimpleCData):
_type_ = "g"
if sizeof(c_longdouble) == sizeof(c_double):
c_longdouble = c_double
For me sizeof(c_longdouble) == sizeof(c_double) (I believe MS compiler always
does this) but when we assign c_longdouble = c_double, there is a leak. I
removed the alias lines:
if sizeof(c_longdouble) == sizeof(c_double):
c_longdouble = c_double
And the leak was gone. Looks like changing c_longdouble after declaring it
causes a leak. Below for similar aliasing of longlong types, we have this:
if _calcsize("l") == _calcsize("q"):
# if long and long long have the same size, make c_longlong an alias for
c_long
c_longlong = c_long
c_ulonglong = c_ulong
else:
class c_longlong(_SimpleCData):
_type_ = "q"
_check_size(c_longlong)
class c_ulonglong(_SimpleCData):
_type_ = "Q"
This avoids declaring c_longlong and c_ulonglong as class if not needed to. The
problem is _calcsize("g") causes an error because "g" is used as long double
througout ctypes but _calcsize is function from _struct.c, where "g" (long
double) is not defined. Not sure why it isn't...
So in short:
As far as I can tell _array_type = type(Array) doesn't break anything
Looks like we have another leak in ctypes (which isn't a big deal)
We have elegant fix for the leak once _struct.c will support long double
--
nosy: +vladris
___
Python tracker
<http://bugs.python.org/issue12142>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4376] Nested ctypes 'BigEndianStructure' fails
Vlad Riscutia added the comment: Added unit test to reproduce the issue (covers both big endian and little endian structures so _other_endian function is hit on any machine). Test currently fails without fix and passes with proposed fix in place. -- keywords: +patch nosy: +vladris Added file: http://bugs.python.org/file22623/issue4376_test.diff ___ Python tracker <http://bugs.python.org/issue4376> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4376] Nested ctypes 'BigEndianStructure' fails
Vlad Riscutia added the comment: Also added diff for fix: - Implemented proposed issubclass(typ, Structure) solution - Refactored _other_endian function because we used to getattr, catch exception, then check if type is array/structure. I believe exception throwing should not be on normal code path so I replaced try-except with a check for hasattr - Removed a unittest which becomes deprecated with this fix (unittest asserts getting _other_endian for nested struct raises exception which is no longer the case) -- Added file: http://bugs.python.org/file22627/issue4376_fix.diff ___ Python tracker <http://bugs.python.org/issue4376> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4376] Nested ctypes 'BigEndianStructure' fails
Changes by Vlad Riscutia : Removed file: http://bugs.python.org/file22627/issue4376_fix.diff ___ Python tracker <http://bugs.python.org/issue4376> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4376] Nested ctypes 'BigEndianStructure' fails
Vlad Riscutia added the comment: New patch containing unittest that actually tests the feature. I would appreciate it if someone can try this on a bigendian machine. -- Added file: http://bugs.python.org/file22642/issue4376_fix.diff ___ Python tracker <http://bugs.python.org/issue4376> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4376] Nested ctypes 'BigEndianStructure' fails
Changes by Vlad Riscutia : Removed file: http://bugs.python.org/file22642/issue4376_fix.diff ___ Python tracker <http://bugs.python.org/issue4376> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4376] Nested ctypes 'BigEndianStructure' fails
Vlad Riscutia added the comment: Changed c_int in tests to c_int32 just to be on the safe side. -- Added file: http://bugs.python.org/file22643/issue4376_fix.diff ___ Python tracker <http://bugs.python.org/issue4376> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4376] Nested ctypes 'BigEndianStructure' fails
Vlad Riscutia added the comment: But if you set raw memory to let's say b'\0\0\0\1', when you look at the c_int value afterwards, won't it be different on little endian and big endian machines? -- ___ Python tracker <http://bugs.python.org/issue4376> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4376] Nested ctypes 'BigEndianStructure' fails
Changes by Vlad Riscutia : Removed file: http://bugs.python.org/file22643/issue4376_fix.diff ___ Python tracker <http://bugs.python.org/issue4376> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4376] Nested ctypes 'BigEndianStructure' fails
Vlad Riscutia added the comment: You're right. I was busy swapping bytes in my head and missed that :) -- Added file: http://bugs.python.org/file22644/issue4376_fix.diff ___ Python tracker <http://bugs.python.org/issue4376> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6068] ctypes is not correctly handling bitfields backed by 64 bit integers on Windows
Vlad Riscutia added the comment: Ping? This also fixes 6493 (I believe in a cleaner way) -- ___ Python tracker <http://bugs.python.org/issue6068> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12528] Implement configurable bitfield allocation strategy
Vlad Riscutia added the comment: Updated patch to reflect review feedback. Allocation strategy is now specified as string in Python code. I kept asserts in CanContinueField/CanExpandField because, as I said, default case should never be hit. Input is validated in stgdict and this should make it clear to whoever reads the code that something is very wrong if execution gets to default case. -- Added file: http://bugs.python.org/file22728/configurable_bitfield_allocation_v2.diff ___ Python tracker <http://bugs.python.org/issue12528> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12562] calling mmap twice fails on Windows
Vlad Riscutia added the comment: Reason you are seeing the failure for this is following change from 2.5 in mmapmodule.c (:1109): m_obj->data = (char *) MapViewOfFile(m_obj->map_handle, dwDesiredAccess, 0, 0, 0); changed to mmapmodule.c (:1414 in 3.3): m_obj->data = (char *) MapViewOfFile(m_obj->map_handle, dwDesiredAccess, off_hi, off_lo, m_obj->size); Previously size wasn't passed to MapViewOfFile. Passing new size to MapViewOfFile greater than the size of previous map causes an error. This seems to be by design. From MSDN: MapViewOfFile: dwNumberOfBytesToMap [in] The number of bytes of a file mapping to map to the view. All bytes must be within the maximum size specified by CreateFileMapping. If this parameter is 0 (zero), the mapping extends from the specified offset to the end of the file mapping. CreateFileMapping: lpName [in, optional] The name of the file mapping object. If this parameter matches the name of an existing mapping object, the function requests access to the object with the protection that flProtect specifies. So on second call, CreateFileMapping will get back the previous mapping object, which has 4096 bytes of memory mapped. MapViewOfFile will try to map beyond its limit and get an error. I am curious how "resizing" worked before. I tried passing size=0 to MapViewOfFile on second call (length=8192) then call VirtualQuery on the returned map, which can query the size of the buffer. Size is still 4096. So even if length=8192 and we call CreateFileMapping with this length, it will return the previous 4096 byte-buffer. This looks to me like an issue which existed until Python 2.5, namely this error was silenced and returned map was still 4096 bytes, just claiming to be 8192. The way it is behaving now seems to be the correct way. -- nosy: +vladris ___ Python tracker <http://bugs.python.org/issue12562> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12675] tokenize module happily tokenizes code with syntax errors
Vlad Riscutia added the comment: How come tokenizer module is not based on actual C tokenizer? Wouldn't that make more sense (and prevent this kind of issues)? -- nosy: +vladris ___ Python tracker <http://bugs.python.org/issue12675> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5149] syntactic sugar: type coercion on pointer assignment
Vlad Riscutia added the comment: The main reason for this issue is that internally ctypes doesn't consider c_char_p as a pointer type. This is a bit counter-intuitive, but c_char_p is treated as a simple type and has some other sugar built-in, like easier integration with Python strings. Alternative pointer type is POINTER(c_char), which allows assignment from array. I would make this clear in the documentation. Even now, documentation says following about c_char_p: Represents the C char * datatype when it points to a zero-terminated string. For a general character pointer that may also point to binary data, POINTER(c_char) must be used. The constructor accepts an integer address, or a string. So there already is a hint that c_char_p has limited use for convenience. We should maybe make documentation more clear. If you want equivalent of C char* behavior, POINTER(c_char) is the way to go. -- nosy: +vladris ___ Python tracker <http://bugs.python.org/issue5149> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12437] _ctypes.dlopen does not include errno in OSError
Vlad Riscutia added the comment: Not sure how this can be fixed actually. I don't think PyErr_SetFromErrno instead of PyErr_SetString would work because as far as I can tell, standard does not mention dlopen making use of errno. Unlike Windows, where LoadLibrary will change last-error, if dlopen fails, only way to retrieve error is to dlerror which returns a string, no error code. -- nosy: +vladris ___ Python tracker <http://bugs.python.org/issue12437> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11835] python (x64) ctypes incorrectly pass structures parameter
Vlad Riscutia added the comment:
Attached patch for this issue.
This only happens on MSVC x64 (I actually tired to repro on Arch Linux x64
before starting work on it and it didn't repro).
What happens is that MSVC on x64 always passes structures larger than 8 bytes
by reference. See here:
http://msdn.microsoft.com/en-us/library/ms235286(v=vs.90).aspx
Now this was accounted for in callproc.c, line 1143 in development branch with
this:
if (atypes[i]->type == FFI_TYPE_STRUCT
#ifdef _WIN64
&& atypes[i]->size <= sizeof(void *)
#endif
)
avalues[i] = (void *)args[i].value.p;
else
avalues[i] = (void *)&args[i].value;
This fix wasn't made in libffi_msvc/ffi.c though. Here, regardless of whether
we have x64 or x86 build, if z >= sizeof(int) we will hit else branch in
libffi_msvc/ffi.c at line 114 and do:
else
{
memcpy(argp, *p_argv, z);
}
p_argv++;
argp += z;
In our case, we copy 28 bytes as arguments (size of our structure) but in fact
for x64 we only need 8 as structure is passed by reference so argument is just
a pointer. My patch will adjust z before hitting if statement on x64 and it
will cause correct copy as pointer.
--
nosy: +vladris
Added file: http://bugs.python.org/file22899/issue11835_patch.diff
___
Python tracker
<http://bugs.python.org/issue11835>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11835] python (x64) ctypes incorrectly pass structures parameter
Vlad Riscutia added the comment: Changing type to behavior as it doesn't crash on 3.3. I believe issue was opened against 2.6 and Santoso changed it to 2.7 and up where there is no crash. Another data point: there is similar fix in current version of libffi here: https://github.com/atgreen/libffi/blob/master/.pc/win64-struct-args/src/x86/ffi.c Since at the moment we are not integrating new libffi, I believe my fix should do (libffi fix is slightly different but I'm matching what we have in callproc.c which is not part of libffi). -- type: crash -> behavior ___ Python tracker <http://bugs.python.org/issue11835> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12764] segfault in ctypes.Struct with bad _fields_
Vlad Riscutia added the comment: Attached patch for 3.3 with unittest -- keywords: +patch nosy: +vladris Added file: http://bugs.python.org/file22923/issue12764_patch3x.diff ___ Python tracker <http://bugs.python.org/issue12764> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12764] segfault in ctypes.Struct with bad _fields_
Vlad Riscutia added the comment: Also patch for 2.7 with unittest. BTW, b"x" works on 2.7. -- Added file: http://bugs.python.org/file22924/issue12764_patch2x.diff ___ Python tracker <http://bugs.python.org/issue12764> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12802] Windows error code 267 should be mapped to ENOTDIR, not EINVAL
Vlad Riscutia added the comment: Attached new mapping though I don't know where unit test for this should go... -- keywords: +patch nosy: +vladris Added file: http://bugs.python.org/file22969/issue12802.diff ___ Python tracker <http://bugs.python.org/issue12802> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12802] Windows error code 267 should be mapped to ENOTDIR, not EINVAL
Vlad Riscutia added the comment: Attached unit test. -- Added file: http://bugs.python.org/file23026/issue12802_unittest.diff ___ Python tracker <http://bugs.python.org/issue12802> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12802] Windows error code 267 should be mapped to ENOTDIR, not EINVAL
Vlad Riscutia added the comment:
I wasn't aware this is an auto-generated file. I can add a comment but looking
at it, it seems we auto-generate this file just to save a call to _dosmaperr. I
would refactor the whole function to call _dosmaperr first then if result is
still EINVAL, tweak with custom switch case. The way I see it, this looks like
premature optimization since OS error shouldn't be on a hot code path, meaning
an application should be able to live with an extra CRT function call on such
exceptions. I'm willing to implement this if there are no objections.
Something like:
errno = _dosmaperr(err)
if (EINVAL == errno)
{
switch (err)
{
// Our tweaks
}
}
--
___
Python tracker
<http://bugs.python.org/issue12802>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12802] Windows error code 267 should be mapped to ENOTDIR, not EINVAL
Vlad Riscutia added the comment: Oh, got it. Interesting. Then should I just add a comment somewhere or should we resolve this as Won't Fix? -- ___ Python tracker <http://bugs.python.org/issue12802> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12802] Windows error code 267 should be mapped to ENOTDIR, not EINVAL
Vlad Riscutia added the comment: Attached updated patch which extends generrmap.c to allow for easy addition of other error mappings. Also regenerated errmap.h and unittest. -- Added file: http://bugs.python.org/file23054/issue12802_2.diff ___ Python tracker <http://bugs.python.org/issue12802> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12802] Windows error code 267 should be mapped to ENOTDIR, not EINVAL
Vlad Riscutia added the comment: Ah, I see Antoine already attached a patch. I was 3 minutes late :) -- ___ Python tracker <http://bugs.python.org/issue12802> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6069] casting error from ctypes array to structure
Vlad Riscutia added the comment: Meador, I believe this was the first issue on the tracker that got me looking into bitfield allocation. I agree that big-endian on MSVC doesn't make too much sense but you can disregard that - using default endianess will still yield different sizes of bitfields when compiled with GCC and MSVC. Basically bitfield allocation is compiler specific and patch in issue12528 implements a way to select which allocation strategy to be used at runtime instead of hardcoding the one with which Python is compiled. This should improve cross-compiler interop. I wanted to hyperlink that patch to all other bitfield bugs, that's why I followed up with link to the patch. Feel free to close this, either as not an issue or as a duplicate of issue12528. And yes, this bit about bitfield allocation should be documented and I was planning to look into it at some point after 12528 gets committed. -- ___ Python tracker <http://bugs.python.org/issue6069> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6069] casting error from ctypes array to structure
Vlad Riscutia added the comment: Sounds good. Please nosy me in the doc bug. -- ___ Python tracker <http://bugs.python.org/issue6069> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12528] Implement configurable bitfield allocation strategy
Vlad Riscutia added the comment: Well currently we pack bitfields with an algorithm that uses #ifdefs for GCC and MSVC builds. This feature tries to remove the hardcoded behavior and implement it as a runtime option. This should improve interop with other compilers. Currently I provided these for MSVC-style and GCC-style bitfield allocations. These, of course, can be extended with other strategies. I am not sure that the fact that GCC has different types of bitfield allocations in different versions is a point against this feature. Consider that in our current code we don't use compiler bitfield allocation, we create the structure layout using our own algorithm, interop might be broken even if Python gets built with same version of GCC as the binary we want to interop with as long as algorithm is out of date. This patch should provide some flexibility in this matter. Wouldn't a GCC44 constant provided at API level be better than saying "you can't interop with anything build with GCC 4.4 and up"? Or vice-versa, anything built with GCC < 4.4. -- ___ Python tracker <http://bugs.python.org/issue12528> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5149] syntactic sugar: type coercion on pointer assignment
Vlad Riscutia added the comment: I believe there is a deeper issue here in ctypes design. Basically we provide both c_char_p and POINTER(c_char) which should behave exactly the same since both are the equivalent of char* in C but internally they have different implementations. c_char_p is considered a "simple type" and I believe supports some conversions to and from Python strings while POINTER(c_char) is considered a pointer type which supports assignment from array etc. I think a better fix would be to deprecate p_char_p or make it an equivalent of POINTER(c_char), otherwise we will have to do work on c_char_p to make it more like POINTER(c_char) when issues like this get opened and probably also make POINTER(c_char) more like c_char_p. Why not just have POINTER(c_char) which works as expected? I don't have all the historical context on why this pseudo-simple type was provided but I saw a couple of issues where people expect it to behave like a C char* but it won't because it is implemented as a convenience type with limited support. -- ___ Python tracker <http://bugs.python.org/issue5149> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35889] sqlite3.Row doesn't have useful repr
Vlad Shcherbina added the comment: 1. "This patch adds too many lines of code and not enough value." If the maintainers judge it so, I have nothing to say. You have the responsibility to keep the codebase relatively simple. 2a. "Existing programs made with the assumption that repr(row) is short (albeit useless) will break when it becomes not so short." I have no experience maintaining popular language implementations, so I defer to your judgement on what level of backward compatibility is warranted. 2b. "New users of new repr(row) will run into problems because its size is unbounded." I think this objection is invalid, as I explained in the comment: https://bugs.python.org/issue35889#msg336291 -- ___ Python tracker <https://bugs.python.org/issue35889> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38641] lib2to3 does not support py38 return/yield syntax with starred expressions
New submission from Vlad Emelianov : Lib2to3 does not support changes made in https://bugs.python.org/issue32117 ```python def test(): my_list = ["value2", "value3"] yield "value1", *my_list return "value1", *my_list ``` The idea is to use `testlist_star_expr` instead of `testlist`. This is a backwards compatible change, because testlist_star_expr supports test as well like testlist does. -- components: 2to3 (2.x to 3.x conversion tool) messages: 355713 nosy: Vlad Emelianov priority: normal pull_requests: 16521 severity: normal status: open title: lib2to3 does not support py38 return/yield syntax with starred expressions type: enhancement versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue38641> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38641] lib2to3 does not support py38 return/yield syntax with starred expressions
Change by Vlad Emelianov : -- versions: +Python 3.8 ___ Python tracker <https://bugs.python.org/issue38641> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43827] abc conflicts with __init_subclass__
New submission from Vlad Hoi : from abc import ABC class A: def __init_subclass__(self): pass class B(ABC, A, name="name"): pass After initialising class B, this exception occurs, because multiple "name" arguments where provided: Traceback (most recent call last): File "test_abc", line 9, in class B(ABC, A, name="name"): TypeError: __new__() got multiple values for argument 'name' -- components: Extension Modules messages: 390933 nosy: vladhoi priority: normal severity: normal status: open title: abc conflicts with __init_subclass__ type: crash versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue43827> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43827] abc conflicts with __init_subclass__
Change by Vlad Hoi : -- keywords: +patch pull_requests: +24117 stage: -> patch review pull_request: https://github.com/python/cpython/pull/25385 ___ Python tracker <https://bugs.python.org/issue43827> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39627] Fix TypedDict totalizy check for inherited keys
New submission from Vlad Emelianov : Add changes made in https://github.com/python/typing/pull/700 to upstream. -- components: Library (Lib) messages: 361957 nosy: Vlad Emelianov priority: normal severity: normal status: open title: Fix TypedDict totalizy check for inherited keys type: enhancement versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue39627> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39627] Fix TypedDict totalizy check for inherited keys
Change by Vlad Emelianov : -- keywords: +patch pull_requests: +17879 stage: -> patch review pull_request: https://github.com/python/cpython/pull/18503 ___ Python tracker <https://bugs.python.org/issue39627> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39627] Fix TypedDict totality check for inherited keys
Change by Vlad Emelianov : -- title: Fix TypedDict totalizy check for inherited keys -> Fix TypedDict totality check for inherited keys ___ Python tracker <https://bugs.python.org/issue39627> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37204] Scripts and binaries in PYTHON_PREFIX/Scripts contain unnecessarily lowercased path to Python location on Windows
New submission from Vlad Shcherbina : To reproduce: 1. Download and run Python installer (I used python-3.7.3-amd64-webinstall.exe). 2. Modify install settings: - Install for all users: yes - Customize install location: "C:\Python37" (don't know if it's relevant, mentioning it just in case) 3. Install. 4. Run the following commands: pip --version py -m pip --version Expected result: > pip --version pip 19.0.3 from C:\Python37\lib\site-packages\pip (python 3.7) > py -m pip --version pip 19.0.3 from C:\Python37\lib\site-packages\pip (python 3.7) Actual result: > pip --version pip 19.0.3 from c:\python37\lib\site-packages\pip (python 3.7) > py -m pip --version pip 19.0.3 from C:\Python37\lib\site-packages\pip (python 3.7) Same happens for all binaries and scripts in PYTHON_PREFIX/Scripts, not only for pip.exe. For example, if I install pytest (using "pip install pytest" or "py -m pip install pytest", doesn't matter), I get the following: > pytest -v test session starts platform win32 -- Python 3.7.3, pytest-4.6.2, py-1.8.0, pluggy-0.12.0 -- c:\python37\python.exe cachedir: .pytest_cache rootdir: C:\temp\qqq collected 0 items === no tests ran in 0.02 seconds > py -m pytest -v test session starts platform win32 -- Python 3.7.3, pytest-4.6.2, py-1.8.0, pluggy-0.12.0 -- C:\Python37\python.exe cachedir: .pytest_cache rootdir: C:\temp\qqq collected 0 items === no tests ran in 0.02 seconds -- components: Distutils, Installation, Windows messages: 345037 nosy: dstufft, eric.araujo, paul.moore, steve.dower, tim.golden, vlad, zach.ware priority: normal severity: normal status: open title: Scripts and binaries in PYTHON_PREFIX/Scripts contain unnecessarily lowercased path to Python location on Windows type: behavior versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue37204> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37204] Scripts and binaries in PYTHON_PREFIX/Scripts contain unnecessarily lowercased path to Python location on Windows
Vlad Shcherbina added the comment: https://github.com/pypa/pip/issues/6582 -- ___ Python tracker <https://bugs.python.org/issue37204> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31239] namedtuple comparison ignores types
New submission from Vlad Shcherbina:
Toy example:
>>> from collections import namedtuple
>>> Rectangle = namedtuple('Rectangle', 'width height')
>>> Ellipse = namedtuple('Ellipse', 'x_axis y_axis')
>>> Rectangle(width=1, height=2) == Ellipse(x_axis=1, y_axis=2)
True
I understand this happens because namedtuple inherits comparisons and hash from
the regular tuple.
However, this seems like confusing and dangerous behavior.
It is especially annoying to debug when these tuples are used as dict keys
(repr() shows one thing and dict item access shows another).
Why would anyone mix named tuples of different types?
Here is a use case: typing.NamedTuple together with typing.Union would be a
neat way to express algebraic data types.
Haskell's
data Shape = Rectangle Int Int | Ellipse Int Intderiving(Eq, Show)
would become
Shape = Union[Rectangle, Ellipse]
except that it does not work as expected because of the flawed comparisons.
--
components: Library (Lib)
messages: 300562
nosy: vlad
priority: normal
severity: normal
status: open
title: namedtuple comparison ignores types
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7
___
Python tracker
<http://bugs.python.org/issue31239>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31239] namedtuple comparison ignores types
Vlad Shcherbina added the comment: While we are at it, namedtuple inherits other operations that make no sense for fixed-length tuples: >>> Rectangle(width=1, height=2) * 3 (1, 2, 1, 2, 1, 2) >>> Rectangle(width=1, height=2) + Ellipse(x_axis=3, y_axis=4) (1, 2, 3, 4) But those are not so problematic because they are less likely to occur in practice. -- ___ Python tracker <http://bugs.python.org/issue31239> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35387] Dialogs on IDLE are accompanied by a small black window
Vlad Tudorache added the comment: I confirm the issue. Screenshot attached. -- type: -> behavior Added file: https://bugs.python.org/file47987/Capture d’écran 2018-12-11 à 22.07.30.png ___ Python tracker <https://bugs.python.org/issue35387> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35387] Dialogs on IDLE are accompanied by a small black window
Vlad Tudorache added the comment: At the line 102 in editor.py, I see: self.top = top = window.ListedToplevel(root, menu=self.menubar) Looking at window.py it seems that ListedToplevel builds a new Toplevel (the black one?) instead of adding an existing one (the editor) at the list, I'll check it again, maybe I didn't see right. The second window does not appear for me when using pure Tcl and toplevel widget (from Wish, for exemple) on MacOS, I don't think it's a Tk problem. -- ___ Python tracker <https://bugs.python.org/issue35387> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35387] Dialogs on IDLE are accompanied by a small black window
Vlad Tudorache added the comment: No, I'm wrong, the editor window seems created by the ListedToplevel. -- ___ Python tracker <https://bugs.python.org/issue35387> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34313] Tkinter crashes with Tk-related error on macOS with ActiveTcl 8.6
Vlad Tudorache added the comment: The only versions of Tk not showing issues on my Mac are: - 8.5.18 with any Python in 3.5, 3.6, 3.7 on Mojave AND previous versions; - 8.6.8 when built on a 10.13 SDK, with the same Python versions. For 8.6.8 built on Mojave SDK, there's the black background console window issue and for 8.6.9.1 the IDLE's problem showing a little black window. I've seen no crashes yet with 8.5.18, 8.6.8, 8.6.9 (on my Mac). -- ___ Python tracker <https://bugs.python.org/issue34313> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35889] sqlite3.Row doesn't have useful repr
New submission from Vlad Shcherbina :
To reproduce, run the following program:
import sqlite3
conn = sqlite3.connect(':memory:')
conn.row_factory = sqlite3.Row
print(conn.execute("SELECT 'John' AS name, 42 AS salary").fetchone())
It prints ''.
It would be nice if it printed something like "sqlite3.Row(name='Smith',
saraly=42)" instead.
It wouldn't satisfy the 'eval(repr(x)) == x' property, but it's still better
than nothing.
If the maintainers agree this is useful, I'll implement.
--
components: Library (Lib)
messages: 334746
nosy: vlad
priority: normal
severity: normal
status: open
title: sqlite3.Row doesn't have useful repr
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/issue35889>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35889] sqlite3.Row doesn't have useful repr
Vlad Shcherbina added the comment: There is no need to add explicit knowledge of reprlib to the Row object or vice versa. Those who use reprlib to limit output size will have no problem. Reprlib already truncates arbitrary reprs at the string level: https://github.com/python/cpython/blob/22bfe637ca7728e9f74d4dc8bb7a15ee2a913815/Lib/reprlib.py#L144 Those who use builtin repr() have to be prepared for the possibility of unbounded repr anyway, because all collection-like objects in Python have unbounded __repr__. It would be annoying if some collection-like objects decided to be clever and omit parts of their regular __repr__ because they feel it's too much for the user to handle. -- ___ Python tracker <https://bugs.python.org/issue35889> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34776] Postponed annotations break inspection of dataclasses
Vlad Shcherbina added the comment: Any chance this could get into 3.7.3? -- nosy: +vlad ___ Python tracker <https://bugs.python.org/issue34776> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33075] typing.NamedTuple does not deduce Optional[] from using None as default field value
New submission from Vlad Shcherbina :
from typing import *
def f(arg: str = None):
pass
print(get_type_hints(f))
# {'arg': typing.Union[str, NoneType]}
# as expected
class T(NamedTuple):
field: str = None
print(get_type_hints(T))
# {'field': }
# but it should be
# {'field': typing.Union[str, NoneType]}
# for consistency
--
components: Library (Lib)
messages: 313819
nosy: vlad
priority: normal
severity: normal
status: open
title: typing.NamedTuple does not deduce Optional[] from using None as default
field value
type: behavior
versions: Python 3.6, Python 3.7
___
Python tracker
<https://bugs.python.org/issue33075>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33075] typing.NamedTuple does not deduce Optional[] from using None as default field value
Vlad Shcherbina added the comment: If the maintainers agree that it's desirable to automatically deduce optionality, I'll implement it. -- ___ Python tracker <https://bugs.python.org/issue33075> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33263] Asyncio server enters an invalid state after a request with SO_LINGER
New submission from Vlad Starostin :
Long story short, if you have a TCP asyncio-server (implementing
asyncio.Protocol) that sends something to socket in connection_made callback,
it will leak fds and won't be able to handle some consequent requests, if you
will send to it RST right after TCP-handshake.
In my case, these requests are sent by keepalived demon (it makes TCP-checks
that way), but they can be easily hand-crafted.
Example server:
import asyncio
class EchoServerClientProtocol(asyncio.Protocol):
def connection_made(self, transport):
self.transport = transport
self.transport.write(b'Say something')
def data_received(self, data):
self.transport.write(data)
self.transport.close()
loop = asyncio.get_event_loop()
coro = loop.create_server(EchoServerClientProtocol, '127.0.0.1', )
server = loop.run_until_complete(coro)
loop.run_forever()
Example client:
import socket
import struct
import time
# first request
sock = socket.socket()
l_onoff = 1
l_linger = 0
sock.setsockopt(socket.SOL_SOCKET, socket.SO_LINGER, struct.pack('ii', l_onoff,
l_linger))
sock.connect(('127.0.0.1', 8022))
sock.close()
time.sleep(1)
# second request
sock = socket.socket()
sock.connect(('127.0.0.1', ))
print('Got', sock.recv(1024))
sock.sendall(b'Hi there')
print('Got', sock.recv(1024)) # <-- Will hang here
sock.close()
Why is this happening?
1. First request
1.1. _SelectorSocketTransport.__init__ schedules connection_made and
loop.add_reader.
1.2. connection_made tries to send data to the socket, it fails,
_SelectorTransport._fatal_error is called, then _SelectorTransport._force_close
is called.
1.3. _SelectorTransport._force_close removes the reader from the loop (there
is none, it's ok), and schedules closing the socket in
_SelectorTransport._call_connection_lost.
1.4. loop.add_reader is called (scheduled on step 1), it calls epoll_ctl, no
error is returned because the socket isn't closed yet.
1.5. the socket is closed by _SelectorTransport._call_connection_lost
(scheduled on step 3). The corresponding entry in _SelectorMapping remains and
isn't cleaned up.
2. Second request
2.1. FD from the first request is reused by the OS
2.2. BaseSelectorEventLoop._add_reader sees that the FD is already in
BaseSelectorEventLoop._selector, so it calls _selector.modify
2.3 _BaseSelectorImpl.modify sees that the events mask is the same, so it
uses a shortcut, changing only the callback, but without calling epoll_ctl. The
socket won't be polled.
I think the source of the error is in step 1.4, we shouldn't add the reader if
we are already closing the transport. I've made a simple PR fixing this, but
maybe there are other options here.
--
components: asyncio
messages: 315196
nosy: asvetlov, drtyrsa, giampaolo.rodola, yselivanov
priority: normal
severity: normal
status: open
title: Asyncio server enters an invalid state after a request with SO_LINGER
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8
___
Python tracker
<https://bugs.python.org/issue33263>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33263] Asyncio server enters an invalid state after a request with SO_LINGER
Change by Vlad Starostin : -- keywords: +patch pull_requests: +6146 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue33263> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34047] IDLE: on macOS, scroll slider 'sticks' at bottom of file
Vlad Tudorache added the comment: I can reproduce this problem only with Tk 8.6.7, both compiled by myself or installed from ActiveState (Python 3.7 and 3.6 compiled by myself, too). I can't see it with Tk 8.6.8 provided with the installers, nor with Tk 8.5.18. -- nosy: +vtudorache ___ Python tracker <https://bugs.python.org/issue34047> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34120] IDLE Caret/Focus Lost
New submission from Vlad Tudorache : When closing the IDLE's Preferences dialog the IDLE's Console window and/or Editor window (whichever was active before) doesn't show cursor/caret any more. One must click on Desktop or another window then click again in the IDLE's window in order to regain cursor/caret. This problem shows on macOS High Sierra, Python 3.6.N and 3.7.N (and even 3.5.N), with the provided installers (64 bit, 64/32 bit, Tk 8.6.8) and with self-compiled Python(s). After a number of openings IDLE will crash with an @autoreleasepool issue. I've compiled Tcl/Tk and Python with CC=clang CXX=clang++ MACOSX_DEPLOYMENT_TARGET=10.9 (10.10, 10.12 also), Tcl/Tk with and without --enable-threads, always with --enable-64bit --enable-framework and --enable-dtrace, clang 902.0.39.2 (Apple LLVM version 9.1.0), Python was compiled with and without --enable-dtrace and --enable-optimizations, with --enable-framework. -- assignee: terry.reedy components: IDLE messages: 321686 nosy: terry.reedy, vtudorache priority: normal severity: normal status: open title: IDLE Caret/Focus Lost type: behavior versions: Python 3.6, Python 3.7 ___ Python tracker <https://bugs.python.org/issue34120> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34120] IDLE: Freeze when closing Settings (& About) dialog on MacOS
Vlad Tudorache added the comment: I’m sorry for not being clear. This problem appears with Tk 8.6, even in Python 3.5 (compiled by me). I’ve succeeded to reproduce only once the @autorelease pool error (it appeared after several open/close of the preferences or about window). Did anyone else see it? Le lun. 30 juil. 2018 à 02:51, Terry J. Reedy a écrit : > > Terry J. Reedy added the comment: > > On idledev thread "Mac IDLE 3.7.0 freezes when accessing Preferences", > Walter Schnyder reported something similar. Combining two posts: > > "using python.org Python 3.7.0 (v3.7.0:1bf9cc5093, Jun 26 2018, 23:26:24) > [Clang 6.0 (clang-600.0.57)] on darwin [64-bit] and came across these [new] > bugs on several Macs, all running OS X v 10.13.5. > [Has run IDLE before, back to 3.4.] > > Bug A: > 1. From the shell select Preferences in the IDLE menu. > 2. Cancel the Preferences to get back to the Shell > 3. The shell is frozen. It doesn’t even react to CONTROL-D. > > The only way I found to resurrect it is to control-click the shell window > and select “Go to file/line” causing an error message to appear. Click OK > and the shell comes back to life. > > Note: This doesn’t only happen when accessing preferences. It also happens > when selecting “About IDLE” in the IDLE menu." > > After starting with 'python3 -m idlelib' > > "The same problems occur. There is no error in the terminal window. > But I learned something new: after running the steps for bug A, IDLE is > frozen (no blinking cursor, not responding to Control+D. However, if I > bring another application’s window to the front (by clicking on it) then > click back on IDLE’s window, this resurrects IDLE, the cursor blinks and > Control+D quits." > > test_idle passes. When running 'python3 -m idlelib.configdialog' or > 'idlelib.help_about', which run a human-viewed test, there is no problem > when closing either dialog. > > Vlad, if I understand your post, you *do* see the problem with 3.5? With > the python.org installer and tk 8.5? As far as I know, no one has had a > problem with this. Or only with a private compile with tk 8.6? > > This is important because 3.5 IDLE has not been touched since about 18 > months, and if there is only a problem when using tk 8.6, then I have to > suspect that this and other new problems are result of tk 8.6 on Mac or > tkinter needing a patch to support it. > > -- > components: +macOS > nosy: +ned.deily, rhettinger, ronaldoussoren, taleinat, walters > stage: -> needs patch > title: IDLE Caret/Focus Lost -> IDLE: Freeze when closing Settings (& > About) dialog on MacOS > versions: +Python 3.8 > > ___ > Python tracker > <https://bugs.python.org/issue34120> > ___ > -- ___ Python tracker <https://bugs.python.org/issue34120> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34120] IDLE: Freeze when closing Settings (& About) dialog on MacOS
Vlad Tudorache added the comment: I can confirm that removing the grab_set() calls fixes the locking. But am I the only one to notice that the dialogs aren't modal any more? -- ___ Python tracker <https://bugs.python.org/issue34120> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34120] IDLE: Freeze when closing Settings (& About) dialog on MacOS
Vlad Tudorache added the comment: Adding self.grab_release() in the ok() method for the dialogs BEFORE destroy() solved the problem for me, keeping the grab_set() methods in place (uncommented, actives). -- ___ Python tracker <https://bugs.python.org/issue34120> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34120] IDLE: Freeze when closing Settings (& About) dialog on MacOS
Vlad Tudorache added the comment: I've checked again the source code in config_key.py, configdialog.py, help_about.py, query.py, searchbase.py, textview.py and added a self.grab_release() in functions like ok() and cancel() before the call to self.destroy() and I see no more lock/focus issues. Maybe the grab was kept in the non-existent (destroyed) dialog window, so the click events could not be transferred to the pyshell or editor, but, because of a local (not global) grab, clicking on another application's window, by losing focus and grab, completely freed the event-chain, then clicks in IDLE were correctly received. Can you confirm if adding the grab_release() calls works for you too (do not remove the grab_set() calls!)? -- ___ Python tracker <https://bugs.python.org/issue34120> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34313] IDLE crashes with Tk-related error on macOS with ActiveTcl 8.6
Vlad Tudorache added the comment: I confirm the crashes. I've tried with personal builds of python 3.5, 3.6, 3.7, with ActiveTcl and personal builds of Tcl 8.6.x, the problem does not appear with 8.5.18, but shows itself with 8.5.19 (strange, API changes?). I'll try to investigate. -- ___ Python tracker <https://bugs.python.org/issue34313> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34313] IDLE crashes with Tk-related error on macOS with ActiveTcl 8.6
Vlad Tudorache added the comment:
The problem shows itself on macOS High Sierra in some Tk Demos, independently
of Python's IDLE. So there is something completely different, to report to the
Tcl/Tk community. Strangely, I didn't notice the issues on Sierra, but I have
no Sierra Mac right now to check it again. Even in Tk 8.5.18 (ActiveState or
self-compiled) there are issues (notably the cascade menus demo, the button
menus demo, others to) in rendering some UI elements. Sometimes bad indexes are
reported (sort of [lindex {A LIST} index $N] gives $N not found even when in
range)...
--
___
Python tracker
<https://bugs.python.org/issue34313>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34313] IDLE crashes with Tk-related error on macOS with ActiveTcl 8.6
Vlad Tudorache added the comment: I was telling only that I've seen myself the issues with some Tcl/Tk versions. As I often build Tcl/Tk on macOS, I can confirm that on 8.6.8 I didn't see issues (those were effectively present in (ActiveState or not) Tcl 8.5.18, 8.5.19, 8.6.6, 8.6.7. The only issue I had was an @autoreleasepool after several open/close of the Preferences dialog in IDLE (see the 34120 issue), related probably to a partial release of resources. -- ___ Python tracker <https://bugs.python.org/issue34313> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34047] IDLE: on macOS, scroll slider 'sticks' at bottom of file
Vlad Tudorache added the comment: Having 3.6.5 and 3.7.0 with Tcl/Tk 8.6.8, try to File->Open Module and open ssl module. On 3.6 everything is fine, on 3.7 the scroller sticks at the bottom. A Tk text widget with the same amount of lines shows no problem. Apple macOS 17.7.0 with 64 bit Python and Tcl/Tk. IDLE problem probably. -- ___ Python tracker <https://bugs.python.org/issue34047> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34047] IDLE: on macOS, scroll slider 'sticks' at bottom of file
Vlad Tudorache added the comment:
The solution was very simple on my Mac. In
/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/idlelib/editor.py,
lines 461-462 should be:
up = {EventType.MouseWheel: (event.delta >= 0) == darwin,
EventType.Button: event.num == 4}
instead of:
up = {EventType.MouseWheel: event.delta >= 0 == darwin,
EventType.Button: event.num == 4}
Does this solve the scrollbar locked down issue for anyone else?
--
___
Python tracker
<https://bugs.python.org/issue34047>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34047] IDLE: on macOS, scroll slider 'sticks' at bottom of file
Vlad Tudorache added the comment:
With:
up = {EventType.MouseWheel: (event.delta >= 0) == darwin,
EventType.Button: (event.num == 4)}
in editor.py at 461-462 I don't see bugs #1 neither #3 on 3.7.0 but I'll try
with other files.
--
___
Python tracker
<https://bugs.python.org/issue34047>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34047] IDLE: on macOS, scroll slider 'sticks' at bottom of file
Vlad Tudorache added the comment: In fact, if the first click before dragging takes place in the upper half of the scrollbar slider, the click is not received nor the drag after. Is like the scroll slider is translated down with half of the slider length (that's why I can drag the slider even when I'm a little bit lower with the pointer). I'll check the click callback and the scrollbar setup functions. Can anybody check if clicking then starting to drag the slider in the inferior half of the slider, even at the top of a file, functions well? -- ___ Python tracker <https://bugs.python.org/issue34047> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34047] IDLE: on macOS, scroll slider 'sticks' at bottom of file
Vlad Tudorache added the comment: Check the commands below and the results to see why the problem with the mouse wheel appeared: >>> a = 1 >>> a >= 0 == True False >>> (a >= 0) == True True >>> a >= (0 == True) True >>> a >= 0 == False True >>> (a >= 0) == False False >>> a >= (0 == False) True >>> (a >= 0) == True True -- ___ Python tracker <https://bugs.python.org/issue34047> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34343] Why is turtle still present in python embedded for Windows?
New submission from Vlad Tudorache : I've just started using the embedded Python 3.6 for Windows and I find turtle.py in the archive, knowing that tkinter isn't present. There's no large space loss because of it, but it's presence may be confusing. -- components: Library (Lib), Windows messages: 323188 nosy: paul.moore, steve.dower, tim.golden, vtudorache, zach.ware priority: normal severity: normal status: open title: Why is turtle still present in python embedded for Windows? type: resource usage versions: Python 3.6 ___ Python tracker <https://bugs.python.org/issue34343> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34344] Fix the docstring for AbstractEventLoopPolicy.get_event_loop
New submission from Vlad Starostin : The docstring says "This may be None or an instance of EventLoop". But docs explicitly state that get_event_loop "must never return None". The same docstring is also in the example in docs: https://docs.python.org/3.6/library/asyncio-eventloops.html#customizing-the-event-loop-policy I propose changing it to: def get_event_loop(self): """Get the event loop. Returns an instance of EventLoop or raises an exception. """ If the wording is ok, I'll make a PR. -- assignee: docs@python components: Documentation, asyncio messages: 323190 nosy: asvetlov, docs@python, drtyrsa, yselivanov priority: normal severity: normal status: open title: Fix the docstring for AbstractEventLoopPolicy.get_event_loop versions: Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue34344> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34343] Why is turtle still present in python embedded for Windows?
Vlad Tudorache added the comment: Thank you very much. Then I will simply remove it. -- ___ Python tracker <https://bugs.python.org/issue34343> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34047] IDLE: on macOS, scroll slider 'sticks' at bottom of file
Vlad Tudorache added the comment: I've tried to check the source code of IDLE in search of chained comparisons without parenthesis (like the example I showed and the bug with the mouse wheel). I couldn't find something important. Then I wrote in a file the following code: import tkinter root = tkinter.Tk() text = tkinter.Text(root) vbar = tkinter.Scrollbar(root) vbar.pack(side=tkinter.RIGHT, fill=tkinter.Y) text.pack(side=tkinter.LEFT, fill=tkinter.BOTH) text.config(yscrollcommand=vbar.set) vbar.config(command=text.yview) lines = ['This is the line number %d.\n' % i for i in range(200)] text.insert(tkinter.END, ''.join(lines)) In both Python 3.6 and 3.7 with Tk 8.6.8 on macOS 10.13, click-and-drag on the upper half of the scrollbar slider has no effect (the slider sticks at the top), like in the bugs #1 and #3. I strongly suspect a tkinter problem, as the equivalent Tcl/Tk code functions well. Click-and-drag in the lower half of the slider functions (in my code and IDLE) for me. Can someone reproduce this? -- ___ Python tracker <https://bugs.python.org/issue34047> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34047] IDLE: on macOS, scroll slider 'sticks' at bottom of file
Vlad Tudorache added the comment:
Edit:
The code is:
import tkinter
root = tkinter.Tk()
text = tkinter.Text(root)
vbar = tkinter.Scrollbar(root)
vbar.pack(side=tkinter.RIGHT, fill=tkinter.Y)
text.pack(side=tkinter.LEFT, fill=tkinter.BOTH, expand=1)
text.config(yscrollcommand=vbar.set)
vbar.config(command=text.yview)
lines = ['This is the line number %d.\n' % i for i in range(256)]
text.insert(tkinter.END, ''.join(lines))
def click_trace(event):
text.insert('%d.%d' % (1, 0), 'Clicked at (%d,%d) on %s.\n' % (event.x,
event.y, vbar.identify(event.x, event.y)))
vbar.bind('', click_trace)
root.mainloop()
Clicking at the top on the slider shows that the Scrollbar considers it as
being on "through1" (in Tk the zone between the upper arrow and the "slider")
and NOT on the "slider". Please, play with the script (python3 tktest.py) and
see the results for yourselves.
--
Added file: https://bugs.python.org/file47737/tktest.py
___
Python tracker
<https://bugs.python.org/issue34047>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34047] IDLE: on macOS, scroll slider 'sticks' at bottom of file
Vlad Tudorache added the comment: And the result (video) of my script is attached to this post. -- Added file: https://bugs.python.org/file47738/tkinter_scroll_issues.mov ___ Python tracker <https://bugs.python.org/issue34047> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34047] IDLE: on macOS, scroll slider 'sticks' at bottom of file
Vlad Tudorache added the comment: The scroll works. Many thanks, I thought the callback should have been rewritten, too. Should one open a different report for the clicks on the scrollbar ends, like in the script I put (independent of IDLE)? -- ___ Python tracker <https://bugs.python.org/issue34047> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34370] Tkinter scroll issues on macOS
New submission from Vlad Tudorache :
Run the python script below.
import tkinter
root = tkinter.Tk()
text = tkinter.Text(root)
vbar = tkinter.Scrollbar(root)
vbar.pack(side=tkinter.RIGHT, fill=tkinter.Y)
text.pack(side=tkinter.LEFT, fill=tkinter.BOTH, expand=1)
text.config(yscrollcommand=vbar.set)
vbar.config(command=text.yview)
lines = ['This is the line number %d.\n' % i for i in range(256)]
text.insert(tkinter.END, ''.join(lines))
def click_trace(event):
text.insert('%d.%d' % (1, 0), 'Clicked at (%d,%d) on %s.\n' % (event.x,
event.y, vbar.identify(event.x, event.y)))
vbar.bind('', click_trace)
root.mainloop()
When the slider is at the top of the scrollbar, clicking on its upper half
doesn't allow dragging. The little script shows that the Scrollbar considers it
as being on "through1" - in Tk the zone between the upper arrow and the
"slider" - and not on "slider". Another consequence is that one can drag (up
and down) the slider when clicking a little bit below the slider, on "through2"
region. This issue doesn't manifest on Windows, where the scrollbar's arrows
are shown.
I've seen this issue when trying to explore the reasons of another (34047,
fixed) concerning the slider locked at the end of the scrollbar in IDLE.
--
components: Tkinter
messages: 323363
nosy: vtudorache
priority: normal
severity: normal
status: open
title: Tkinter scroll issues on macOS
type: behavior
versions: Python 3.6, Python 3.7
___
Python tracker
<https://bugs.python.org/issue34370>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34343] Why is turtle still present in python embedded for Windows?
Change by Vlad Tudorache : -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue34343> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34370] Tkinter scroll issues on macOS
Vlad Tudorache added the comment:
The bug needs forwarding to the Tcl/Tk community. This is the script written in
Tcl (run with tclsh8.6 script.tcl for Tcl 8.6 and tclsh8.5 script.tcl for 8.5):
package require Tk
scrollbar .vbar -width 10
text .edit
pack .vbar -side right -fill y
pack .edit -side left -fill both -expand 1
.vbar configure -command {.edit yview}
.edit configure -yscrollcommand {.vbar set}
bind .vbar { } {
set cx %x
set cy %y
set dz [.vbar identify $cx $cy]
puts "You clicked at ($cx,$cy) on $dz.\n"
}
for {set i 1} {$i <= 256} {incr i} {
.edit insert "$i.0" "This is the line number $i.\n"
}
I will post two videos made on my MacBook, showing an expected behavior with Tk
8.5 and the scroll problems with Tk 8.6 on macOS.
--
Added file: https://bugs.python.org/file47742/Tk86MacIssue.mov
___
Python tracker
<https://bugs.python.org/issue34370>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34370] Tkinter scroll issues on macOS
Vlad Tudorache added the comment: Now, the video for TK 8.5 showing expected behavior on macOS. -- Added file: https://bugs.python.org/file47743/Tk85Mac.mov ___ Python tracker <https://bugs.python.org/issue34370> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34370] Tkinter scroll issues on macOS
Vlad Tudorache added the comment: It seems that Kevin's fix solves the issues. -- ___ Python tracker <https://bugs.python.org/issue34370> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
