[issue4899] doctest should support fixtures
New submission from Giovanni : The doctest module should have support for fixtures (e.g. setUp and tearDown methods). It is very silly to be forced to always re-import all the modules needed in every function tested with doctest. For example, when you have to document functions that open files, you have to import StringIO or TempFile, and then create a file, while this could be done easily with a fixture. -- components: Tests messages: 79477 nosy: dalloliogm severity: normal status: open title: doctest should support fixtures type: feature request ___ Python tracker <http://bugs.python.org/issue4899> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4899] doctest should support fixtures
Giovanni added the comment: I was proposing to adopt doctest in the biopython project (modules for bioinformatics in python, http://biopython.org/). Doctest is very useful to document modules that will be used by many other people: for example, there are many different file formats in bioinformatics, and it is very useful to add an example of the file to be parsed in the documentation of a file parser. Look at my code here: - http://github.com/dalloliogm/biopython---popgen/blob/980419dbc0666e2578c2486dab1fef23ccfbb72c/src/PopGen/Gio/TpedIO.py However, it is very uncomfortable to have to create a file-like object in every docstring, especially when you want to document the methods of a class. It would be useful if at least the doctests of the methods of a class share the objects created in the main doctest of the class. Let's say I have a class called FastaIO (fasta is a file format for sequence). This module would have many methods: format, to_dict (returns a dictionary of the sequences included in the file), and many others. The main docstring of the class will have an example of a fasta file, and shows how to create an instance of FastaIO. It is silly to have to repeat this example (creating an instance of FastaIO) in every submethod. Moreover, it is more difficult to maintain and more error prone (imagine you have a class with one hundred methods). ___ Python tracker <http://bugs.python.org/issue4899> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6721] Locks in python standard library should be sanitized on fork
Giovanni Bajo added the comment: If there's agreement that the general problem is unsolvable (so fork and threads just don't get along with each other), what we could attempt is trying to limit the side effects in the standard library, so that fewest users as possible are affected by this problem. For instance, having deadlocks just because of print statements sounds like a bad QoI that we could attempt to improve. Is there a reason while BufferedIO needs to hold its internal data-structure lock (used to make it thread-safe) while it's doing I/O and releasing the GIL? I would think that it's feasible to patch it so that its internal lock is only used to synchronize accesses to the internal data structures, but it is never held while I/O is performed (and thus the GIL is released -- at which point, if another threads forks, the problem appears). -- nosy: +Giovanni.Bajo ___ Python tracker <http://bugs.python.org/issue6721> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7213] Popen.subprocess change close_fds default to True
Giovanni Bajo added the comment: Hi Gregory, I saw your commit here: http://code.activestate.com/lists/python-checkins/91914/ This basically means that in 3.2 it is mandatory to specify close_fds to avoid a DeprecationWarning. *BUT* there is no good value that works both on Windows and Linux if you redirect stdout/stderr, as shown in this bug. So basically in 3.2 to avoid a warning, each and every usage of Popen() with a redirection should be guarded by an if that checks the platform. I don't think this is acceptable. Have I misunderstood something? Also: can you please explain how the behaviour is going to change in 3.3? I assume that you are planning to change the default to True; but would that also cover Windows' singularity in redirection cases? -- nosy: +Giovanni.Bajo ___ Python tracker <http://bugs.python.org/issue7213> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7213] Popen.subprocess change close_fds default to True
Giovanni Bajo added the comment: Setting CLOEXEC on the pipes seems like a very good fix for this bug. I'm +1 on it, but I think it should be the default; instead, your proposed patch adds a new argument to the public API. Why do you think it's necessary to do so? At the same time, we need a solution to handle close_fds, because the current status of the 3.2 with the DeprecationWarning (on 90% of subprocess uses in the world, if it ever gets backported to 2.7) and no way to fix it in a multi-platform way is really sad. I don't think a new constant DISREGARD_FDS is necessary. I think we can just use "None" as intermediate default (just like the current 3.2 does), and later switch it to True. The only further required action is to make "True" always work on Windows and never error out (just make it do nothing if there are some redirections), which is an obviously good thing to do to increase portability of subprocess. Otherwise, if this can't make 3.2, I think the DeprecationWarning should be reverted until we agree on a different solution. -- ___ Python tracker <http://bugs.python.org/issue7213> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7213] Popen.subprocess change close_fds default to True
Giovanni Bajo added the comment: Would you mind elaborating on where is the race condition? -- ___ Python tracker <http://bugs.python.org/issue7213> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7213] subprocess leaks open file descriptors between Popen instances causing hangs
Giovanni Bajo added the comment: Hi Gregory, will you backport Mirko's patches to subprocess32? The last thing left in this bug is my proposal to change the default of close_fds to True to Windows too, but at the same time detect whether this is possible or not (depending on the pipe redirections). So basically close_fds=True would be changed to mean "close the FDs, if it is possible, otherwise never mind". This is not a break in compatibility on Linux/UNIX (where it is always "possible"), nor Windows (where currently it just raises a ValueError if you ask it to raise close the file descriptors while doing redirections). The rationale for this change is again cross-compatibility. I don't like when my code breaks because of a limitation of an OS that has a clear workaround. Subprocess is a high-level library after all, it's not like os.fork() or similar low-level libraries which expose the underlying platform differences. -- ___ Python tracker <http://bugs.python.org/issue7213> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1342] Crash on Windows if Python runs from a directory with umlauts
Changes by Giovanni Bajo: -- nosy: +rasky __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1342> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2128] sys.argv is wrong for unicode strings
New submission from Giovanni Bajo: Under Windows, sys.argv is created through the Windows ANSI API. When you have a file/directory which can't be represented in the system encoding (eg: a japanese-named file or directory on a Western Windows), Windows will encode the filename to the system encoding using what we call the "replace" policy, and thus sys.argv[] will contain an entry like "c:\\foo\\??.dat". My suggestion is that: * At the Python level, we still expose a single sys.argv[], which will contain unicode strings. I think this exactly matches what Py3k does now. * At the C level, I believe it involves using GetCommandLineW() and CommandLineToArgvW() in WinMain.c, but should Py_Main/PySys_SetArgv() be changed to also accept wchar_t** arguments? Or is it better to allow for NULL to be passed (under Windows at least), so that the Windows code-path in there can use GetCommandLineW()/CommandLineToArgvW() to get the current process' arguments? -- components: Interpreter Core messages: 62458 nosy: giovannibajo severity: normal status: open title: sys.argv is wrong for unicode strings type: behavior versions: Python 3.0 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2128> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2066] Adding new CNS11643, a *huge* charset, support in cjkcodecs
Giovanni Bajo added the comment: Making the standard Windows Python DLL larger is not only a problem of disk size: it will make all packages produced by PyInstaller or py2exe larger, and that means lots of wasted bandwidth. I see that MvL is still -1 on simply splitting CJK codecs out, and vetos it by asking for a generalization work of insane proportion (a hard-to-define PEP, an entirely new build system for Windows, etc.). I understand (and *agree*) that having a general rule would be a much superior solution, but CJK is already almost 50% of the python.dll, so it *is* already a special case by any means. And special cases like these could be handled with special-case decisions. Thus, I still strongly disagree with MvL and would like CJK be split out of python.dll as soon as possible. I would not really ask this for any other modules but CJK, and understand that further actions would really require a PEP and a new build system for Windows. So, I ask again MvL to soften his position and reconsider the CJK splitting in all its singularity. Please! (in case it's not clear, I would prepare a patch to split CJK out anyday if there were hopes that it gets accepted) -- nosy: +giovannibajo __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2066> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2128] sys.argv is wrong for unicode strings
Giovanni Bajo added the comment: I'm attaching a simple patch that seems to work under Py3k. The trick is that Py3k already attempts (not sure how or why) to decode argv using utf-8. So it's sufficient to setup argv as UTF8-encoded strings. Notice that brings the output of "python à" from this: Fatal Python error: no mem for sys.argv UnicodeDecodeError: 'utf8' codec can't decode bytes in position 0-2: invalid data to this: TypeError: zipimporter() argument 1 must be string without null bytes, not str which is expected since zipimporter_init() doesn't even know to ignore unicode strings (let alone handle them correctly...). Added file: http://bugs.python.org/file9449/argv_unicode.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2128> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2128] sys.argv is wrong for unicode strings
Giovanni Bajo added the comment: mbstowcs uses LC_CTYPE. Is that correct and consistent with the way default encoding under UNIX is handled by Py3k? Would a Py_MainW or similar wrapper be easier on the UNIX guys? I'm just asking, I don't have a definite idea. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2128> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44359] test_ftplib fails as "env changes" if a socket operation times out in a thread: TimeoutError is not catched
Change by Giovanni Wijaya : -- nosy: +giovanniwijaya nosy_count: 7.0 -> 8.0 pull_requests: +26699 stage: -> patch review pull_request: https://github.com/python/cpython/pull/28228 ___ Python tracker <https://bugs.python.org/issue44359> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37496] Support annotations in signature strings.
Giovanni Cappellotto added the comment: Thanks for the info. Yes, I’m still interested in working on the issue, but lately I didn’t have much time to do it. If this is a high priority feel free to re-assign to someone else, otherwise I’ll start working on it next week. On Sun, Dec 1, 2019 at 6:59 AM Batuhan wrote: > > Batuhan added the comment: > > We have exposed Tools/unparse.py under ast module, so that option also can > help. @potomak are you still interested in working on this issue? > > -- > nosy: +BTaskaya, pablogsal > > ___ > Python tracker > <https://bugs.python.org/issue37496> > ___ > -- ___ Python tracker <https://bugs.python.org/issue37496> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31485] Tkinter widget.unbind(sequence, funcid) unbind all bindings
Giovanni Lombardo added the comment: http://docs.python.org/devguide/triaging.html#assigned-to -- nosy: +glombardo ___ Python tracker <https://bugs.python.org/issue31485> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39152] Faulty override of tkinter.Misc.configure in tkinter.ttk.Scale.configure
New submission from Giovanni Lombardo :
The issue arises by simply calling configure on the Scale widget of the themed
tk (ttk) widgets set:
```
cursor = scale.configure('cursor')[-1]
```
The above casues the following error:
```
File "C:\Users\Giovanni\Tests\test_scale.py", line 604, in main
cursor = scale.configure('cursor')[-1]
File
"C:\Users\Giovanni\AppData\Local\Programs\Python\Python37\lib\tkinter\ttk.py",
line 1090, in configure
kw.update(cnf)
ValueError: dictionary update sequence element #0 has length 1; 2 is required
```
The interpreter is:
```
Python 3.7.4 (tags/v3.7.4:e09359112e, Jul 8 2019, 20:34:20) [MSC v.1916 64 bit
(AMD64)] on win32```
--
components: Tkinter
messages: 358987
nosy: glombardo
priority: normal
severity: normal
status: open
title: Faulty override of tkinter.Misc.configure in tkinter.ttk.Scale.configure
type: crash
versions: Python 3.7
___
Python tracker
<https://bugs.python.org/issue39152>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39152] Faulty override of tkinter.Misc.configure in tkinter.ttk.Scale.configure
Giovanni Lombardo added the comment:
I've modified the `Scale.configure` implementation as follows:
```
def configure(self, cnf=None, **kw):
"""Modify or query scale options.
Setting a value for any of the "from", "from_" or "to" options
generates a <> event."""
if cnf:
kw.update(cnf)
retval = Widget.configure(self, **kw)
if any(['from' in kw, 'from_' in kw, 'to' in kw]):
self.event_generate('<>')
return retval
```
It works as expected for my project, but I don't have regression tests or
exahustive code checking in place to verify it behaves correctly for all use
cases. How can we manage to perform those tests?
--
___
Python tracker
<https://bugs.python.org/issue39152>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39152] Faulty override of tkinter.Misc.configure in tkinter.ttk.Scale.configure
Giovanni Lombardo added the comment:
Hello Terry J. Reedy, first and foremost thanks for the time you've dedicated
to this issue! I really appreciate you work!! Even if I work with Python since
2007, I'm new here, and not very well versed with this issue management system.
This has been my first issue, hopefully not the last.. or maybe yes. Anyway,
I'm going to clarify some points about your answers:
1: scale.configure('whateveroption') can take the name of an option and should
return its value, usually a tuple (unless you've already customized the
option's value) as all other widgets already do.
2. The code I've provided is not correct you're right. Mistakenly I've pasted
the wrong one, but when I realized it, trying to delete and replace the
uncorrect part, I've been unable to find the edit or delete feature on the
issue tracker. Sorry for that.
3. I'd like to thank you for the clarification you've given about correct
definition of crash and exception. I knew them. Anyway I'd like point out that
there is no option in the 'create ticket' page of the issue tracker to specify
that an exception that shouldn't be raised at all is instead raised.
Considering that, if a piece of code is not supposed to raise exceptions
managing them involve a runtime overhead we all want to avoid. Eventually the
raising of the exception may stop an application abnormally leading to the same
effect experienced in an application crash.
4. Exaclty, Scale is the only one widget that override configure. So in theory
no other similar issues should be found there.
It there is some action I need to do, or some documentation I need to read in
order to be able to help here please point me there. Thank you again.
--
___
Python tracker
<https://bugs.python.org/issue39152>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39152] Faulty override of tkinter.Misc.configure in tkinter.ttk.Scale.configure
Giovanni Lombardo added the comment: @serhiy.storchaka I didn't found any old issue not closed aboud tkinter Scale widget. -- ___ Python tracker <https://bugs.python.org/issue39152> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31485] Tkinter widget.unbind(sequence, funcid) unbind all bindings
Giovanni Lombardo added the comment:
I propose the below fix:
```
def unbind(self, sequence, funcid=None):
"""Unbind for this widget for event SEQUENCE the
function identified with FUNCID."""
bound = ''
if funcid:
self.deletecommand(funcid)
funcs = self.tk.call('bind', self._w, sequence, None).split('\n')
bound = '\n'.join([f for f in funcs if not f.startswith('if
{{"[{0}'.format(funcid))])
self.tk.call('bind', self._w, sequence, bound)
```
--
___
Python tracker
<https://bugs.python.org/issue31485>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43110] import aiohttp crash closes Python from Windows Installer
New submission from Giovanni Wijaya : Since Python 3.10.0a4, importing aiohttp crash closes Python, only on Python installed from Windows Installer x64. Python installed in Debian (both from source and otherwise) does not produce this issue. -- components: Windows messages: 386180 nosy: giovanniwijaya, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: import aiohttp crash closes Python from Windows Installer versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue43110> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43110] import aiohttp crash closes Python from Windows Installer
Giovanni Wijaya added the comment: Update: I tried installing Python from source in x64, and same issue persists. -- ___ Python tracker <https://bugs.python.org/issue43110> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43110] import aiohttp crash closes Python from Windows Installer
Giovanni Wijaya added the comment: I'm not sure whether aiohttp has released packages specifically for the alphas, but I tried rebuilding aiohttp and its extension modules and it currently works. Thank you for the solution. -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue43110> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41291] Race conditions when opening and deleting a file on Mac OS X
New submission from Giovanni Pizzi : Hello, when creating deleting (with `os.remove`/`os.unlink`) a file and opening it in a different process at (almost) the same time, on Mac OS X relatively often I get a file that is empty instead of either a `FileNotFoundError` exception, or an open handle with the original content, i.e. at least one of the two operations (unlinking or opening) seems to be non-atomic. (With empty I mean that if after I open the file (mode 'rb'), then `fhandle.read()` returns me b''. More in particular, after quite some debugging I noticed that what happens is that if I stat the file descriptor, `st_ino` is zero. This can reproduced very easily. I set up a GitHub repository here: https://github.com/giovannipizzi/concurrent-delete-race-problem with simple examples and tests (and both a Python implementation and a C implementation). There are also GitHub Actions that run on Mac, Ubuntu and Windows, and apparently the problem exists only on Mac (and happens on all versions). For completeness I attach also here a tar.gz with the two very short python files that just need be run in parallel - in my Mac OS X (macOS 10.14.6, 15" 2016 MacBook Pro, python 3.6) I get the error essentially at every run. Important: while much harder to reproduce, I can get the same error and behaviour also with the (I think equivalent) C code. Therefore, this seems to be more a problem with the Mac OS standard libraries? My first question is: has anybody ever seen this problem? It seems to me quite easy to reproduce, but I'm surprised that I couldn't find any reference in the internet even after searching for various hours (maybe I used the wrong keywords?) Second question: should this be reported directly to Apple? Third question: Even if this is a bug, would it make sense to implement a patch in python that raises some exception if st_ino is zero when opening a file? Or am I simplifying too much and in some conditions st_ino=0 is valid on some types of mounted filesystems? Is there some other way to have a more atomic behaviour for this race condition in python? Thanks a lot! -- components: IO, macOS files: concurrency-tests.tar.gz messages: 373606 nosy: Giovanni Pizzi, ned.deily, ronaldoussoren priority: normal severity: normal status: open title: Race conditions when opening and deleting a file on Mac OS X versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8 Added file: https://bugs.python.org/file49315/concurrency-tests.tar.gz ___ Python tracker <https://bugs.python.org/issue41291> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41291] Race conditions when opening and deleting a file on Mac OS X
Giovanni Pizzi added the comment: Thanks for your feedback! I also just reported the issue to Apple. For reference I got the Feedback ID FB8009608. I will let you know if they answer. In any case I agree that also your other error is unexpected. I am writing a library that should provide atomicity guarantees and this issue is creating me a lot of headaches :-) -- ___ Python tracker <https://bugs.python.org/issue41291> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13893] Make CGIHTTPServer capable of redirects (and status other than 200)
New submission from Giovanni Funchal : GIHTTPServer.py is a very handy module for quickly setting up a full HTTP server with CGI support. However, I noticed that it doesn't support responses other than "200 OK". So, for instance if the page wants to do a redirect (response 303), it just isn't supported. It's documented as so, but still I think this is a major drawback that can be easily overcome. I have attached a patch against 2.7. I'd be happy to port it to dev branch if help provided as I'm new to Python. Reviews/suggestions more than welcome. -- components: Library (Lib) files: CGIHTTPServer.patch keywords: patch messages: 152137 nosy: Giovanni.Funchal priority: normal severity: normal status: open title: Make CGIHTTPServer capable of redirects (and status other than 200) type: enhancement versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file24342/CGIHTTPServer.patch ___ Python tracker <http://bugs.python.org/issue13893> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13893] Make CGIHTTPServer capable of redirects (and status other than 200)
Giovanni Funchal added the comment: @Glenn Linderman, can you please share your changes? You can upload a patch. -- versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.4 ___ Python tracker <http://bugs.python.org/issue13893> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13893] Make CGIHTTPServer capable of redirects (and status other than 200)
Giovanni Funchal added the comment: @Éric Araujo, yes this is a duplicate of #10487. I now think this should be marked as bug instead of enhancement. The documentation warns about this behavior but it is documenting a bug. -- resolution: -> duplicate ___ Python tracker <http://bugs.python.org/issue13893> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10805] traceback.print_exception throws AttributeError when exception is None
Giovanni Funchal added the comment: This bug affects me, found it when migrating from 2.7 to 3.2, in a function calling traceback.print_exc() called while there were no "active" exception being handled. Previous behavior was to print "None". -- nosy: +Giovanni.Funchal ___ Python tracker <http://bugs.python.org/issue10805> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10484] http.server.is_cgi fails to handle CGI URLs containing PATH_INFO
Giovanni Funchal added the comment: This is still an issue as of python 3.2.2 and is affecting me. -- nosy: +Giovanni.Funchal ___ Python tracker <http://bugs.python.org/issue10484> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37284] Not obvious that new required attrs of sys.implementation must have a PEP.
Giovanni Cappellotto added the comment: Hi, I'd like to claim this task if nobody else already started working on it. -- nosy: +potomak ___ Python tracker <https://bugs.python.org/issue37284> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37284] Not obvious that new required attrs of sys.implementation must have a PEP.
Change by Giovanni Cappellotto : -- keywords: +patch pull_requests: +14148 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/14328 ___ Python tracker <https://bugs.python.org/issue37284> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37386] [EASY] test_io: test_large_file_ops() failed on AMD64 Windows7 SP1 3.x with: [Errno 28] No space left on device
Giovanni Cappellotto added the comment: Hi, I'd like to claim this task if nobody else already started working on it. -- nosy: +potomak ___ Python tracker <https://bugs.python.org/issue37386> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37386] [EASY] test_io: test_large_file_ops() failed on AMD64 Windows7 SP1 3.x with: [Errno 28] No space left on device
Change by Giovanni Cappellotto : -- keywords: +patch pull_requests: +14173 stage: -> patch review pull_request: https://github.com/python/cpython/pull/14356 ___ Python tracker <https://bugs.python.org/issue37386> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13127] xml.dom.Attr.name is not labeled as read-only
Giovanni Cappellotto added the comment:
I took a quick look at `minidom.py` and `test_minidom.py`. It seems that you
should always use `doc.renameNode(attr, namespace, new_name)` for renaming an
attribute (or an element).
When `doc.renameNode` is applied on an attribute node, it removes the attribute
from the `ownerElement` and re-set it after renaming it.
For instance:
```
>>> import xml.dom.minidom
>>> from xml.dom import minidom
>>> doc = minidom.parseString("http://foo.com\";>foo")
>>> attr = doc.childNodes[0].attributes.item(0)
>>> doc.renameNode(attr, xml.dom.EMPTY_NAMESPACE, "bar")
>>> doc.toxml()
'http://foo.com";>foo'
```
I agree that this behavior should be documented somewhere.
Maybe there should be a note/warning in the `name` attribute description. It
should says that resetting an attribute `name` won't change the document
representation and that `doc.renameNode` should be used instead.
Another approach may be to update the `name` setter implementation to remove
and then re-set the attribute in the `ownerElement`.
What do you think it's the best approach:
1. update the doc
2. update the `name` setter implementation
I'd be happy to help to fix this issue.
--
nosy: +potomak
___
Python tracker
<https://bugs.python.org/issue13127>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37386] [EASY] test_io: test_large_file_ops() failed on AMD64 Windows7 SP1 3.x with: [Errno 28] No space left on device
Giovanni Cappellotto added the comment: Serhiy, Victor: I didn't get what's your suggested solution for this task. Should we just close it as "wontfix", can I go ahead and merge the existing PR, or do you have a better suggestion on how to solve this issue? -- ___ Python tracker <https://bugs.python.org/issue37386> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37548] Document range of atan, acos and asin
Change by Giovanni Cappellotto : -- keywords: +patch pull_requests: +14517 stage: -> patch review pull_request: https://github.com/python/cpython/pull/14717 ___ Python tracker <https://bugs.python.org/issue37548> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37548] Document range of atan, acos and asin
Giovanni Cappellotto added the comment: I created a small diff to update the documentation of `math.atan`, `math.asin` and `math.acos`. -- nosy: +potomak ___ Python tracker <https://bugs.python.org/issue37548> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13127] xml.dom.Attr.name is not labeled as read-only
Change by Giovanni Cappellotto : -- keywords: +patch pull_requests: +14552 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/14757 ___ Python tracker <https://bugs.python.org/issue13127> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13127] xml.dom.Attr.name is not labeled as read-only
Giovanni Cappellotto added the comment: In https://github.com/python/cpython/pull/14757 I tried updating the implementation of `Attr._set_name` to remove and reset the attr node in the owner element. So now `Attr._set_name` behaves similarly to `Document.renameNode`. All existing tests are still passing and I added one more test for checking the issue described here. -- ___ Python tracker <https://bugs.python.org/issue13127> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37496] Support annotations in signature strings.
Change by Giovanni Cappellotto : -- nosy: +potomak ___ Python tracker <https://bugs.python.org/issue37496> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7202] "python setup.py cmd --verbose" does not set verbosity
Change by Giovanni Cappellotto : -- keywords: +patch pull_requests: +14585 stage: -> patch review pull_request: https://github.com/python/cpython/pull/14787 ___ Python tracker <https://bugs.python.org/issue7202> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7202] "python setup.py cmd --verbose" does not set verbosity
Giovanni Cappellotto added the comment: I took a stab at this, see attached PR. I was able encode the first two cases described by @tarek, but not the first one because `_parse_command_opts` doesn't have visibility to the list of global options that have already been parsed. Note: I had to move `log.set_verbosity(self.verbose)` after the call to `_parse_command_opts` in order to correctly apply the verbosity level after all command options are parsed. I think there should be a better way to handle this case, maybe by creating a `verbose` setter that re-runs `log.set_verbosity` every time `verbose` value is updated. -- nosy: +potomak ___ Python tracker <https://bugs.python.org/issue7202> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37613] Broken "Back to top" link in www.python.org (mobile)
Change by Giovanni Cappellotto : -- title: Fix broken "Back to top" link in www.python.org (mobile) -> Broken "Back to top" link in www.python.org (mobile) ___ Python tracker <https://bugs.python.org/issue37613> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37613] Fix broken "Back to top" link in www.python.org (mobile)
New submission from Giovanni Cappellotto : The mobile version of https://www.python.org/ has a "Back to top" link at the bottom of every page that should scroll the page back to the top, but it doesn't work in Chrome for Android. Note: it works with Safari on iOS. -- assignee: docs@python components: Documentation messages: 348087 nosy: docs@python, potomak priority: normal severity: normal status: open title: Fix broken "Back to top" link in www.python.org (mobile) ___ Python tracker <https://bugs.python.org/issue37613> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37613] Broken "Back to top" link in www.python.org (mobile)
Giovanni Cappellotto added the comment: I can reproduce the error in Chrome for MacOS when I emulate the resolution of a generic mobile device. I think I have a quick fix for the issue, I will publish a PR soon. -- ___ Python tracker <https://bugs.python.org/issue37613> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37496] Support annotations in signature strings.
Giovanni Cappellotto added the comment: I'd like to work on this, but I'm kind of new to the codebase. Do you think I should leave this task to someone more expert on the matter? I took a look at the function you mentioned and I was able to support simple annotations, for instance `x: int`, by evaluating `node.annotation.id`. This method doesn't work with more complex annotations thought. For instance a simple type alias (`Foo = int`, `x: Foo`) breaks this naive implementation. Another error happens if the annotation is not a simple `id`, but a subscript function application, for instance `x: List[int]`. Do you have any suggestion for how to continue working on this task? -- ___ Python tracker <https://bugs.python.org/issue37496> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37496] Support annotations in signature strings.
Giovanni Cappellotto added the comment: > You might want to look into how PEP 563 is implemented, it has a utility to > turn an AST back into a string (I assume this is what you want). Thanks for your suggestion @levkivskyi. I took a look at https://github.com/python/cpython/pull/4390, that implements PEP 563. In that PR `ast_unparse.c` has been introduced, that is > a close translation of the relevant parts of `Tools/unparse.py` Source: https://github.com/python/cpython/pull/4390#issuecomment-346554817 I have a couple of questions about how to use `ast_unparse.c`'s `expr_as_unicode` function: 1. Should I create a new function in the `ast` module that exposes that C function in Python in order to use it in `Lib/inspect.py`? 2. Would it be better to just re-use the _AST to string_ implementation in `Tools/unparse.py`? On a side note: would it make sense to reconcile the two "unparse AST" implementations? > +1 on using a string for Parameter.annotation and Signature.return_annotation. Thanks for your comment @eric.snow. >From what I saw in the test I've written, right now `Parameter.annotation` and >`Signature.return_annotation` return Python type classes. At the beginning, in order to keep `Parameter.annotation`'s return type consistent with the current implementation, I tried to evaluate the annotation's "unparse AST" string output, but I was getting errors evaluating type aliases and refined types. Returning strings would make `parse_name`'s implementation easier, but I'm wondering if would be backward compatible. -- ___ Python tracker <https://bugs.python.org/issue37496> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37666] urllib.requests.urlopen doesn't support cadata=
Change by Giovanni Cappellotto : -- nosy: +potomak ___ Python tracker <https://bugs.python.org/issue37666> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21992] New AST node Else() should be introduced
Change by Giovanni Cappellotto : -- nosy: +potomak ___ Python tracker <https://bugs.python.org/issue21992> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37678] Incorrect behaviour for user@password URI pattern in urlparse
Giovanni Cappellotto added the comment:
What do you mean that urlparse act as unexpected?
I tried your example and I think urlparse's behavior is correct.
>From the RFC 1738:
> Octets must be encoded if they have no corresponding graphic
> character within the US-ASCII coded character set, if the use of the
> corresponding character is unsafe, or if the corresponding character
> is reserved for some other interpretation within the particular URL
> scheme.
Your example:
```
>>> from urllib.parse import urlparse
>>> urlparse('http://user:pass#?[w...@example.com:80/path')
ParseResult(scheme='http', netloc='user:pass', path='', params='', query='',
fragment='?[w...@example.com:80/path')
```
Part of the password is parsed as the URL fragment because the character `#`
has a special meaning:
> The character "#" is unsafe and should
> always be encoded because it is used in World Wide Web and in other
> systems to delimit a URL from a fragment/anchor identifier that might
> follow it.
--
nosy: +potomak
___
Python tracker
<https://bugs.python.org/issue37678>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37724] [[Errno 17] File exists: ] # Try create directories that are not part of the archive with
Giovanni Cappellotto added the comment: There's also the `makedirs`'s `exist_ok` optional parameter, `False` by default. You could use it to avoid this error, but I'm not an expert on this particular library, so I'm not sure if it would make sense to make this change. On a side note, searching for `_extract_member`, I found a very similar implementation of that function in `tarfile.py`. In case I think we should apply the same behavior in that module too. -- nosy: +potomak ___ Python tracker <https://bugs.python.org/issue37724> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15266] Perform the same checks as PyPI for Description field
Giovanni Cappellotto added the comment: Hi Victor, This is the 3rd issue in a row I found in the "Easy issues" list where you added a comment saying > I remove the "Easy" label Why are can I still find these issues in the "Easy issues" list? Do you mean that you already removed the "Easy" label or that you plan to remove it? -- nosy: +potomak ___ Python tracker <https://bugs.python.org/issue15266> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37700] shutil.copyfile does not raise SpecialFileError for socket files
Change by Giovanni Cappellotto : -- nosy: +potomak ___ Python tracker <https://bugs.python.org/issue37700> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15266] Perform the same checks as PyPI for Description field
Change by Giovanni Cappellotto : -- nosy: -potomak ___ Python tracker <https://bugs.python.org/issue15266> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14621] Hash function is not randomized properly
Giovanni Bajo added the comment: Christian, there are good semi-crypto hash functions that don't leak as bad as Python's own modified FNV hash, without going all the way to HMAC. SipHash has very good collision resistance and doesn't leak anything: https://www.131002.net/siphash/ (notice: they distribute a python program to recover python's seed) It's obviously slower than Python's FNV, but it's hard to beat a sum+multiplication per character. -- nosy: +Giovanni.Bajo ___ Python tracker <http://bugs.python.org/issue14621> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14621] Hash function is not randomized properly
Giovanni Bajo added the comment: For short strings, you might want to have a look at the way you fetch the final partial word from memory. If the string is >= 8 bytes, you can fetch the last partial word as an unaligned memory fetch followed by a shift, instead of using a switch like in the reference code. -- ___ Python tracker <http://bugs.python.org/issue14621> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14621] Hash function is not randomized properly
Giovanni Bajo added the comment: Until it's broken with a yet-unknown attack, SipHash is a pseudo-random function and as such it does uniformly distribute values across the output space, and never leak any information on the key (the randomized seed). Being designed by cryptographers, it is likely that it doesn't turn out to be a "fail" like the solution that was just released (no offense intended, but it's been a large-scale PR failure). As long as we don't introduce bias while reducing SipHash's output to fit the hash table size (so for instance, usage of modulus is not appropriate), then the hash function should behave very well. Any data type can be supplied to SipHash, including numbers; you just need to take their (platform-dependent) memory representation and feed it to SipHash. Obviously it will be much much slower than the current function which used to be hash(x) = x (before randomization), but that's the price to pay to avoid security issues. -- ___ Python tracker <http://bugs.python.org/issue14621> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14621] Hash function is not randomized properly
Giovanni Bajo added the comment: Il giorno 07/nov/2012, alle ore 08:40, Serhiy Storchaka ha scritto: > Serhiy Storchaka added the comment: > > I tested different kind of strings. > > $ ./python -m timeit -n 1 -s "t = b'a' * 10**8" "hash(t)" > $ ./python -m timeit -n 1 -s "t = 'a' * 10**8" "hash(t)" > $ ./python -m timeit -n 1 -s "t = '\u0100' * 10**8" "hash(t)" > $ ./python -m timeit -n 1 -s "t = '\U0001' * 10**8" "hash(t)" > > current SipHash > > bytes 181 msec 453 msec 2.5x > UCS1 429 msec 453 msec 1.06x > UCS2 179 msec 897 msec 5x > UCS4 183 msec 1.79 sec 9.8x Hi Serhiy, can you please attach the generated assembly code for the siphash function with your compiler and your optimization flags (that is, the one that produces the above results)? Thanks! -- Giovanni Bajo -- ___ Python tracker <http://bugs.python.org/issue14621> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14621] Hash function is not randomized properly
Giovanni Bajo added the comment: Il giorno 07/nov/2012, alle ore 12:59, Marc-Andre Lemburg ha scritto: > > Marc-Andre Lemburg added the comment: > > On 07.11.2012 12:55, Mark Dickinson wrote: >> >> Mark Dickinson added the comment: >> >> [MAL] >>> I don't understand why we are only trying to fix the string problem >>> and completely ignore other key types. >> >> [Armin] >>> estimating the risks of giving up on a valid query for a truly random >>> hash, at an overestimated one billion queries per second ... >> >> That's fine in principle, but if this gets extended to integers, note that >> our current integer hash is about as far from 'truly random' as you can get: >> >>Python 3.4.0a0 (default:f02555353544, Nov 4 2012, 11:50:12) >>[GCC 4.2.1 (Apple Inc. build 5664)] on darwin >>Type "help", "copyright", "credits" or "license" for more information. >>>>> [hash(i) for i in range(20)] >>[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19] >> >> Moreover, it's going to be *very* hard to change the int hash while >> preserving the `x == y implies hash(x) == hash(y)` invariant across all the >> numeric types (int, float, complex, Decimal, Fraction, 3rd-party types that >> need to remain compatible). > > Exactly. And that's why trying to find secure hash functions isn't > going to solve the problem. Together with randomization they may > make things better for strings, but they are no solution for numeric > types, and they also don't allow detecting possible attacks on your > systems. > > But yeah, I'm repeating myself :-) > I don't see how it follows. Python has several hash functions in its core, one of which is the string hash function; it is currently severely broken from a security standpoint; it also happens to be probably the most common case for dictionaries in Python, and the ones that it is more easily exploited in web frameworks. If we can manage to fix the string hash function (eg: through SipHash) we will be one step further in mitigating the possible attacks. Solving collisions and mitigating attacks on numeric types is a totally different problem because it is a totally different function. I suggest we keep different discussions and different bugs for it. For instance, I'm only personally interested in mitigating attacks on the string hash function. -- Giovanni Bajo -- ___ Python tracker <http://bugs.python.org/issue14621> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14621] Hash function is not randomized properly
Giovanni Bajo added the comment: Il giorno 11/nov/2012, alle ore 05:56, Chris Rebert ha scritto: > > Chris Rebert added the comment: > > What about CityHash? (http://code.google.com/p/cityhash/ ; unofficial C port: > http://code.google.com/p/cityhash-c/ ) > It's good enough for Google... It's good enough for Google in a context that does not require protection against collision attacks. If you have a look at SipHash' page, you will find a program to generate collisions to CityHash. -- Giovanni Bajo My Blog: http://giovanni.bajo.it -- ___ Python tracker <http://bugs.python.org/issue14621> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14621] Hash function is not randomized properly
Giovanni Bajo added the comment: Il giorno 02/gen/2013, alle ore 00:20, Domen Kožar ha scritto: > > Domen Kožar added the comment: > > According to talk at 29c3: > http://events.ccc.de/congress/2012/Fahrplan/events/5152.en.html > > Quote: We also describe a vulnerability of Python's new randomized hash, > allowing an attacker to easily recover the 128-bit secret seed. As a reliable > fix to hash-flooding, we introduce SipHash, a family of cryptographically > strong keyed hash function competitive in performance with the weak hashes, > and already adopted in OpenDNS, Perl 5, Ruby, and in the Rust language. That is exactly the vulnerability that was previously mentioned in the context of this bug. SipHash is currently the only solution for a collision-resistant fast-enough hash. -- Giovanni Bajo -- ___ Python tracker <http://bugs.python.org/issue14621> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14621] Hash function is not randomized properly
Giovanni Bajo added the comment: Il giorno 02/gen/2013, alle ore 06:52, Christian Heimes ha scritto: > > Christian Heimes added the comment: > > Thanks for the information! I'm working on a PEP for the issue at hand. Since you're collecting ideas on this, I would like to stress that, in the Python 3 transition, it was deemed acceptable to switch all objects to use unicode strings for attribute names, making the hash computation of such attributes (in the context of the instance dictionary) at least twice as slow than it used to be (the 'at least' refers to the fact that longer strings might have even worse effects because of a higher number of cache misses). SipHash isn't twice as slow as the current hash function, not even for short strings. So there is a precedent in slowing down the hash computation time in a very important use case, and it doesn't look like hell froze over. -- Giovanni Bajo -- ___ Python tracker <http://bugs.python.org/issue14621> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14621] Hash function is not randomized properly
Giovanni Bajo added the comment: Il giorno 02/gen/2013, alle ore 19:51, Christian Heimes ha scritto: > > Christian Heimes added the comment: > > Giovanni, why do you think that hashing of unicode strings is slower than > byte strings? > > First of all ASCII only unicode strings are packed and use just one byte per > char. CPython's FNV implementation processes one element in each cycle, that > is one byte for bytes and ASCII unicode, two bytes for UCS-2 and four bytes > for UCS-4. Bytes and UCS-4 strings require the same amount of CPU > instructions. Ah sorry, I stand corrected (though packing wasn't there in 3.0, was it? I was specifically referred to the 2.x -> 3.0 transition). -- Giovanni Bajo My Blog: http://giovanni.bajo.it -- ___ Python tracker <http://bugs.python.org/issue14621> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12226] use HTTPS by default for uploading packages to pypi
Giovanni Bajo added the comment: Please notice that a redesign of PyPI and package security is ongoing in catalog-sig. -- nosy: +Giovanni.Bajo ___ Python tracker <http://bugs.python.org/issue12226> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23554] EchoServerClientProtocol class should be called EchoServerProtocol
New submission from Giovanni Cannata: In 18.5.4.3.2. TCP echo server protocol the class in the example code is called EchoServerClientProtocol. It should be EchoServerProtocol. (The client protocol example is correctly called EchoClientProtocol). -- assignee: docs@python components: Documentation messages: 236932 nosy: docs@python, gc priority: normal severity: normal status: open title: EchoServerClientProtocol class should be called EchoServerProtocol versions: Python 3.4 ___ Python tracker <http://bugs.python.org/issue23554> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23749] asyncio missing wrap_socket
New submission from Giovanni Cannata: It's not possible to wrap a socket in tls. The StreamWriter object should have an option to start a tls negotiation using the SSLContext of the server. This is needed for protocols the have a "start_tls" feature, for example the ldap protocol. In a non async program it's very easy: wrapped_socket = ssl_context.wrap_socket(connection.socket, server_side=True, do_handshake_on_connect=True) there should be something similar in the StreamWriter interface: yield from writer.wrap_socket() Bye, Giovanni -- components: asyncio messages: 239021 nosy: gc, gvanrossum, haypo, yselivanov priority: normal severity: normal status: open title: asyncio missing wrap_socket type: enhancement versions: Python 3.4 ___ Python tracker <http://bugs.python.org/issue23749> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23749] asyncio missing wrap_socket
Giovanni Cannata added the comment: Thanks, I will look to the new implementation of ssl in 3.5, and try to adapt it for my project (sldap3). I'd like to help, but I'm not skilled in asynchronous programming so I'm not sure if I succeed. Bye, Giovanni -- ___ Python tracker <http://bugs.python.org/issue23749> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
