Safihre added the comment:
Implementing for write is not needed as OpenSSL's SSL_write_ex that is used by
write() already writes the whole buffer at once. Only reading OpenSSL does in
the 16k segments.
The new option was introduced to prevent the compatibility problems for code
that
Safihre added the comment:
Pinging in hope for a review on https://github.com/python/cpython/pull/31492
--
___
Python tracker
<https://bugs.python.org/issue37
Safihre added the comment:
Could the new PR be reviewed? Thank you!
https://github.com/python/cpython/pull/31492
Documentation still needs updating, but would like feedback.
PS: Why not enable the setting the GitHub Actions workflow only need to be
approved for new GitHub accounts instead of
Change by Safihre :
--
pull_requests: +29622
pull_request: https://github.com/python/cpython/pull/31492
___
Python tracker
<https://bugs.python.org/issue37
Safihre added the comment:
Is anyone available to give feedback on the remaining questions/problems in the
PR?
I don't want to be pushy and if it's only changed in 3.11, I understand, but
just hoping for some progress :)
Also willing to dive into it myself, but not a network/p
Safihre added the comment:
Understandable, as the feature freeze was yesterday :)
Just like to note that we have a 100.000 or so users (which I know is very
little compared to overal number of Python users) of our application that this
could really help.
We have used a lot of CPU cycles
Safihre added the comment:
It would be very beneficial if this gets added. In our application (usenet
client) I have wondered for years why we had to limit ourselves to 16k blocks
and have such lower speeds compared to non SSL connections.
--
nosy: +Safihre
Change by Safihre :
--
nosy: +Safihre
___
Python tracker
<https://bugs.python.org/issue43638>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Safihre :
--
title: os.makedirs fails long-path UNC-paths if it is the first sub-folder ->
os.makedirs fails on long-path UNC-paths if it is the first sub-folder
type: -> crash
___
Python tracker
<https://bugs.python.org/i
New submission from Safihre :
It consistently fails on the first directory in a long-path UNC notation
server-folder.
>>> os.makedirs(r"\\?\UNC\DiskStation\already_exists", exist_ok=True)
Traceback (most recent call last):
File "", line 1, in
File "C:\Us
Safihre added the comment:
Would anyone be able to review this? People keep reporting this bug in my
project.
Months are just passing while the PR is just a few lines of code:
https://github.com/python/cpython/pull/18772/files
--
___
Python
Safihre added the comment:
In the CherryPy project it is also observed on Windows with Python 3,7.2.
In CherryPy it's triggered by Checker plugin, which connects to the app
listening to the socket port in TLS mode via plain HTTP during startup (from
the same process).
It has been aroun
Safihre added the comment:
Although this issue is very old, in case anyone else like us need this
functionality I created a package that implements the proposed C-fix.
https://pypi.python.org/pypi/subprocessww
Simply "import subprocessww" and POpen is patched. We tested it and it doe
Safihre added the comment:
If you know the problem, would you also know the solution?
What is the difference in how they generate sys.path entries and how does this
affect performance during execution of the module function?
Just want to understand what is going on
Safihre added the comment:
Very good question!
5000 times via imp.load_dynamic:
yEnc C New took 5870 ms
yEnc C New took 5878 ms
yEnc C New took 5835 ms
5000 times via "pip: having the .pyd in site-packages"
yEnc C New took 6489 ms
yEnc C New too
Change by Safihre :
--
resolution: third party ->
___
Python tracker
<https://bugs.python.org/issue31555>
___
___
Python-bugs-list mailing list
Unsubscrib
Safihre added the comment:
No, the difference is not wheel vs setuptools. They both generate the identical
pyd file.
The difference is python: if the module is loaded by just being available on
the path or if the module is loaded via imp.load_dynamic
I understand if it's closed be
New submission from S Safihre:
I have a Python 2.7 C-extension that was made for performance, however, I
noticed something strange on Windows:
When I run locally python setup.py install and it installs it the "egg" way,
the performance of calling the function in the module 500x in
S Safihre added the comment:
>From the changelog I interpreted this to mean that Python would now use
>OpenSSL 1.0.2j on macOS for it's ssl module.
But this is not the case?
On a fresh macOS Sierra VM I get:
Python 2.7.13rc1 (v2.7.13rc1:4d6fd49eeb14, Dec 3 2016, 13:01:23)
[GCC 4
19 matches
Mail list logo
