[issue1978] Python(2.5.1) will be crashed when i use _ssl module in multi-threads environment in linux.
andrej added the comment: Is there a reason why this patch has not been implemented in the official release (2.5.4)? I am having plenty of troubles using it in a similar program. -- nosy: +andrej ___ Python tracker <http://bugs.python.org/issue1978> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46838] Parameters and arguments parser syntax error improvments
New submission from Andrej Klychin :
I saw that pablogsal welcomed improvments to the parser's suggestions, so here
are the messages for parameters and arguments lists I think should be written
instead of the current generic "invalid syntax".
>>> def foo(*arg, *arg): pass
SyntaxError: * argument may appear only once
>>> def foo(**arg, **arg): pass
SyntaxError: ** argument may appear only once
>>> def foo(arg1, /, arg2, /, arg3): pass
SyntaxError: / may appear only once
>>> def foo(*args, /, arg): pass
SyntaxError: / must be ahead of *
>>> def foo(/, arg): pass
SyntaxError: at least one argument must precede /
>>> def foo(arg=): pass
SyntaxError: expected default value expression
>>> def foo(*args=None): pass
SyntaxError: * argument cannot have default value
>>> def foo(**kwargs=None): pass
SyntaxError: ** argument cannot have default value
>>> foo(*args=[0])
SyntaxError: cannot assign to iterable argument unpacking
>>> foo(**args={"a": None})
SyntaxError: cannot assign to keyword argument unpacking
>>> foo(arg=)
SyntaxError: expected argument value expression
--
components: Parser
messages: 413856
nosy: Andy_kl, lys.nikolaou, pablogsal
priority: normal
severity: normal
status: open
title: Parameters and arguments parser syntax error improvments
type: enhancement
versions: Python 3.11
___
Python tracker
<https://bugs.python.org/issue46838>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46838] Parameters and arguments parser syntax error improvments
Andrej Klychin added the comment: I also sometimes write def foo(pos_only, /*, kwarg): pass. Perhaps this can be special cased with SyntaxError: expected comma between / and * -- ___ Python tracker <https://bugs.python.org/issue46838> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46838] Parameters and arguments parser syntax error improvments
Andrej Klychin added the comment:
@terry.reedy, I based that error message on current >>> foo(**{}, *())
SyntaxError: iterable argument unpacking follows keyword argument unpacking
and >>> foo(__debug__=True)
SyntaxError: cannot assign to __debug__
but the final error message could be anything if it explicitly says "what's
wrong".
--
___
Python tracker
<https://bugs.python.org/issue46838>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9067] Use macros from pyctype.h
Changes by Andrej Krpic : -- nosy: +akrpic77 ___ Python tracker <http://bugs.python.org/issue9067> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10966] eliminate use of ImportError implicitly representing SkipTest
Changes by Andrej Krpic : -- nosy: +akrpic77 ___ Python tracker <http://bugs.python.org/issue10966> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7879] Too narrow platform check in test_datetime
New submission from Andrej Krpic :
Windows doesn't accept negative timestamps (stated in the comment), yet checks
is made against os.name instead of sys.platform.
patch fixes that, and also enables windows ce to pass on this test.
I think this is better than having os.name in ("nt", "ce").
--
components: Tests
files: test_datetime_win32_check.patch
keywords: patch
messages: 99026
nosy: akrpic77
severity: normal
status: open
title: Too narrow platform check in test_datetime
versions: Python 2.7
Added file: http://bugs.python.org/file16171/test_datetime_win32_check.patch
___
Python tracker
<http://bugs.python.org/issue7879>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7879] Too narrow platform check in test_datetime
Changes by Andrej Krpic : -- components: +Windows type: -> behavior ___ Python tracker <http://bugs.python.org/issue7879> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41216] eval don't load local variable in dict and list comprehensions.
New submission from Andrej Klychin :
I'm not sure is it a bug or a fecature of comprehensions or eval, but
intuitively it seems like it should work.
def foo(baz):
return eval("[baz for _ in range(10)]")
foo(3)
Traceback (most recent call last):
File "", line 1, in
File "", line 2, in foo
File "", line 1, in
File "", line 1, in
NameError: name 'baz' is not defined
def bar(baz):
return eval("{i: baz for i in range(10)}")
bar(3)
Traceback (most recent call last):
File "", line 1, in
File "", line 2, in bar
File "", line 1, in
File "", line 1, in
NameError: name 'baz' is not defined
--
components: Interpreter Core
messages: 373054
nosy: Andy_kl
priority: normal
severity: normal
status: open
title: eval don't load local variable in dict and list comprehensions.
type: behavior
versions: Python 3.9
___
Python tracker
<https://bugs.python.org/issue41216>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7706] Missing #include guards
New submission from Andrej Krpic : Patch provides consistency with include guards already present in core. This issue is somehow next step to #1495999 and #1492356. These headers are missing from MSVC when targeting MS Windows CE . HAVE_PROCESS_H already used in: Modules/posixmodule.c, Python/thread_nt.h HAVE_SYS_TYPES_H already used in: Modules/io/_iomodule.c, Objects/fileobject.c, ... HAVE_SIGNAL_H already in: Modules/posixmodule.c HAVE_ERRNO_H already in: Include/Python.h, Python/ceval.c, ... DONT_HAVE_ERRNO_H is not used anywhere HAVE_FCNTL_H already in: Modules/posixmodule.c, Modules/socketmodule.c -- components: Interpreter Core files: missing_ifdef_s.patch keywords: patch messages: 97809 nosy: akrpic77 severity: normal status: open title: Missing #include guards type: compile error versions: Python 2.7 Added file: http://bugs.python.org/file15891/missing_ifdef_s.patch ___ Python tracker <http://bugs.python.org/issue7706> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8142] libffi update to 3.0.9
Changes by Andrej Krpic : -- nosy: +akrpic77 status: pending -> open ___ Python tracker <http://bugs.python.org/issue8142> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17634] Win32: shutil.copy leaks file handles to child processes
New submission from Andrej Krpic:
Function shutil.copy opens source file with open('rb') and destination file
with open('wb') and then proceeds to copy the content.
If you create child process from the same python process during that time, that
process will inherit open file handles.
This could lead to situation when parent process tries to delete the file, but
child process prevents that by holding an open handle to the file (Windows XP,
Windows 7).
This is not expected side effect for copy file operation.
Win32's native CopyFile API call doesn't leak file handles to child processes.
Python's open function behavior is defined by platform's implementation, which
translates C function fopen with 'rb' and 'wb' modes to CRT open call without
O_NOINHERIT flag, which creates inheritable Win32 HANDLEs.
Possible fix would be to add 'N' to mode string in calls to open function in
shutil.copy.
--
components: Library (Lib), Windows
messages: 186041
nosy: akrpic77
priority: normal
severity: normal
status: open
title: Win32: shutil.copy leaks file handles to child processes
type: security
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3
___
Python tracker
<http://bugs.python.org/issue17634>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14157] time.strptime without a year fails on Feb 29
Andrej Antonov added the comment:
$ python
Python 3.5.1 (default, Dec 7 2015, 12:58:09)
[GCC 5.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>>
>>>
>>>
>>> import time
>>>
>>> time.strptime("Feb 29", "%b %d")
time.struct_time(tm_year=1900, tm_mon=2, tm_mday=29, tm_hour=0, tm_min=0,
tm_sec=0, tm_wday=0, tm_yday=60, tm_isdst=-1)
>>>
>>>
>>> import datetime
>>>
>>> datetime.datetime.strptime("Feb 29", "%b %d")
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python3.5/_strptime.py", line 511, in _strptime_datetime
return cls(*args)
ValueError: day is out of range for month
--
nosy: +polymorphm
___
Python tracker
<http://bugs.python.org/issue14157>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26460] datetime.strptime without a year fails on Feb 29
Changes by Andrej Antonov : -- nosy: +polymorphm ___ Python tracker <http://bugs.python.org/issue26460> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14134] "xmlrpc.client.ServerProxy()" -- need for "timeout"-parameter
New submission from Andrej A Antonov : good day! "xmlrpc.client.ServerProxy()" -- not has "timeout"-parameter "xmlrpc.client.Transport()" and "xmlrpc.client.SafeTransport()" -- not has "timeout"-parameter too but "http.client.HTTPConnection()" and http.client.HTTPSConnection() -- has "timeout"-parameter -- components: Library (Lib) messages: 154409 nosy: polymorphm priority: normal severity: normal status: open title: "xmlrpc.client.ServerProxy()" -- need for "timeout"-parameter type: enhancement versions: Python 2.7, Python 3.3 ___ Python tracker <http://bugs.python.org/issue14134> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14134] "xmlrpc.client.ServerProxy()" -- need for "timeout"-parameter
Andrej A Antonov added the comment: in this subject -- I think about like this changes (see file "example-of-changes.patch") -- keywords: +patch Added file: http://bugs.python.org/file24675/example-of-changes.patch ___ Python tracker <http://bugs.python.org/issue14134> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14134] xmlrpc.client.ServerProxy needs timeout parameter
Andrej A Antonov added the comment: Jeff McNeil (mcjeff)> I would think it might make more sense just to make the change to the Transport object. Since there's an argument for a transport on ServerProxy already, that seems more straightforward and keeps the network layer isolated. in theoretical-side -- this layer isolation may be good and clean. but in practical-side -- situation is next: there are 3 alternative-variants of using timeout parameter in XMLRPC-Client: situation 1. programmer (who makes script or program) -- using XMLRPC-Client *WITH* timeout parameter, because timeout parameter should be using in his program. program runs in regular environment. situation 2. programmer (who makes script or program) -- using XMLRPC-Client *WITHOUT* timeout parameter, because XMLRPC-connection runs in localhost environment. situation 3. programmer (who makes script or program) -- using XMLRPC-Client *WITHOUT* timeout parameter, because he makes mistake. "situation 1" -- very often. (or must be very often). "situation 2" -- very rare. "situation 3" -- leads to possible cases of freezing program/script or resource-leak. if we will try to hide timeout parameter (in other layer), then "situation 3" will be more than "situation 1" # p.s.: sorry for my bad english -- ___ Python tracker <http://bugs.python.org/issue14134> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21356] Support LibreSSL (instead of OpenSSL): make RAND_egd optional
Changes by Andrej A Antonov : -- nosy: +polymorphm ___ Python tracker <http://bugs.python.org/issue21356> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14134] xmlrpc.client.ServerProxy needs timeout parameter
Andrej A Antonov added the comment: @demian.brecht , your example code-fragment is too big. :-) too many lines -- just only for adding "timeout". it is uncomfortably. most people will not using that: most likely they just will forget about "timeout" (but in *MOST* situations not using "timeout" -- it is mistake). -- ___ Python tracker <http://bugs.python.org/issue14134> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14134] xmlrpc.client.ServerProxy needs timeout parameter
Andrej A Antonov added the comment:
@demian.brecht , socket.setdefaulttimeout([timeout]) -- it is bad practice,
because setting this global varible we may spoil other cases. example "TCP
keepalive" [ s.setsockopt(socket.SOL_SOCKET, socket.SO_KEEPALIVE, true) ]
and global variables is bad practice for other things.
and again -- compare what shorter (and what more clear):
proxy = ServerProxy('http://example.com/gateway/', transport=Transport(
connection_factory=lambda h: HTTPConnection(h, timeout=42)))
or
proxy = ServerProxy('http://example.com/gateway/', timeout=42)
> There should be one-- and preferably only one --obvious way to do it.".
> Having a timeout at the top level ServerProxy object introduces ambiguity and
> therefore doesn't conform
if you NOT point timeout in "RPC-client" -- you program will freeze or will
maked resource leak (with small probability).
"RPC-client" and "timeout" -- these two concepts are inseparable!
you are allowed *NOT_using* "timeout" in "RPC-client" -- *ONLY* in *localhost*
operations!
--
___
Python tracker
<http://bugs.python.org/issue14134>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14134] xmlrpc.client.ServerProxy needs timeout parameter
Andrej A Antonov added the comment: ok, let's go to other side of this problem: question: why default transport (xmlrpc.client.Transport()) is not setting value of timeout?`` answer: because *unknown* which value need to using by default. in various cases programmer need various timeout. default value of timeout for default transport -- what may be this number? may be value "300" for timeout of default transport (xmlrpc.client.Transport()) may be normal in *most_cases*. but this will brake legacy soft that using socket.setdefaulttimeout(...) -- ___ Python tracker <http://bugs.python.org/issue14134> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14134] xmlrpc.client.ServerProxy needs timeout parameter
Andrej A Antonov added the comment:
>> if you NOT point timeout in "RPC-client" -- you program will freeze or will
>> maked resource leak (with small probability).
> Assuming a lack of concurrency, your program will indeed freeze until the
> system timeout has been reached. I'm not sure about a leak. If you have an
> example of such a case, it would likely be a good candidate for a new issue.
I do not know how behavior in Microsoft Windows...
in GNU/Linux "system timeout has been reached" -- means that system timeout
will *never* reached.
you may easy to test this (to make this test -- we need using:
"client-computer" and "network-router-computer"):
step 1. run next code on "client-computer" (GNU/Linux):
$ python3
>>> from xmlrpc.client import ServerProxy
>>> server = ServerProxy("http://betty.userland.com";)
>>> for _ in range(100): print(server.examples.getStateName(41))
step 2: to broke network in "network-router-computer".
step 3: wait some minutes. example 60 minutes.
step 4: to repear netework in "network-router-computer".
step 5: we will see, that program on "client-computer" will freeze *forever*.
system timeout will *never* reached. even after some days -- system timeout
will not reached. :-)
> it would likely be a good candidate for a new issue.
yes, may be we need new issue-ticket?
--
___
Python tracker
<http://bugs.python.org/issue14134>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14134] xmlrpc.client.ServerProxy needs timeout parameter
Andrej A Antonov added the comment:
I just will write next code-fragment:
import socket
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM, socket.IPPROTO_TCP)
s.connect(('python.org', 80))
print(
'is my operation system using (by default) "tcpkeepalive"-algorithm
for testing broken-connection? answer:',
s.getsockopt(socket.SOL_SOCKET, socket.SO_KEEPALIVE)
)
# answer is 0 (false) -- for all GNU/Linux
my previous code-example has 100-iteration -- only for we could catch the
right-moment when testing (and for nothing else).
--
___
Python tracker
<http://bugs.python.org/issue14134>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14134] xmlrpc.client.ServerProxy needs timeout parameter
Andrej A Antonov added the comment: >> in GNU/Linux "system timeout has been reached" -- means that system timeout >> will *never* reached. > That's quite likely because the system limits may be very large. I tested system-timeout GNU/Linux (on various computers). I waited more then 5 days. system-timeout works on GNU/Linux -- only if was custom-set tcpkeepalive, else (by default): even after 5 days system-timeout was not reached. -- ___ Python tracker <http://bugs.python.org/issue14134> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14134] xmlrpc.client.ServerProxy needs timeout parameter
Andrej A Antonov added the comment:
@demian.brecht , for high probably to catch *infinite_freeze* (at GNU/Linux) --
if we may will run requests of "xmlrpc.client.ServerProxy" -- parallely:
(when running next code -- need to make some network-disconnections on
"network-router-computer")
#!/usr/bin/env python3
import threading
from xmlrpc.client import ServerProxy
ITERATION_COUNT = 100
THREAD_COUNT = 100
def thread_func(thread_name):
for i in range(ITERATION_COUNT):
try:
server = ServerProxy("http://betty.userland.com";)
rpc_result = server.examples.getStateName(41)
print('{}/iter_{} {!r}'.format(thread_name, i, rpc_result))
except Exception as e:
print('{}/iter_{} error: {} {}'.format(thread_name, i, type(e),
str(e)))
def main():
print('* testing begin *')
thread_list = []
for i in range(THREAD_COUNT):
thread_name = 'thread_{}'.format(i)
thread_list.append(threading.Thread(target=thread_func,
args=(thread_name,)))
for thr in thread_list:
thr.start()
for thr in thread_list:
thr.join()
print('* testing end *')
if __name__ == '__main__':
main()
--
___
Python tracker
<http://bugs.python.org/issue14134>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14134] xmlrpc.client.ServerProxy needs timeout parameter
Andrej A Antonov added the comment: good patch (issue14134.patch) ! thanks! -- ___ Python tracker <http://bugs.python.org/issue14134> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24755] asyncio.wrap_future undocumented
Changes by Andrej A Antonov : -- nosy: +polymorphm ___ Python tracker <http://bugs.python.org/issue24755> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
