Mailman 3 July 2014 - Python-Dev

Re: [Python-Dev] Remaining decisions on PEP 471 -- os.scandir()
by Ben Hoyt July 15, 2014

July 15, 2014

> I'd *keep DirEntry.lstat() method* regardless of existence of > .stat(*, follow_symlinks=True) method (despite the slight violation of > DRY principle) for readability. `dir_entry.lstat().st_mode` is more > consice than `dir_entry.stat(follow_symlinks=False).st_mode` and the > meaning of lstat is well-established -- get (symbolic link) status [2]. The meaning of lstat() is well-established, so I don't mind this. But I don't think it's necessary, either. My thought would be … [View More]that in new code/functions we should kind of prescribe best-practices rather than leave the options open. Yes, it's a few more characters, but "follow_symlinks=True" is allow much clear than "l" to describe this behaviour, especially for non-Linux hackers. > I suggest *renaming .full_name -> .path* due to reasons outlined in [1]. > > [1]: https://mail.python.org/pipermail/python-dev/2014-July/135441.html Hmmm, perhaps. You suggest .full_name implies it's the absolute path, which isn't true. I don't mind .path, but it kind of sounds like "the Path object associated with this entry". I think "full_name" is fine -- it's not "abs_name". > follow_symlinks (if added) should be *keyword-only parameter* because > `dir_entry.is_dir(False)` is unreadable (it is not clear at a glance > what `False` means in this case). Agreed follow_symlinks should be a keyword-only parameter (as it is in os.stat() in Python 3). > Exceptions are part of the public API. pathlib is inconsitent with > os.path here e.g., os.path.isdir() ignores all OS errors raised by > the stat() call but the corresponding pathlib call ignores only broken > symlinks (non-existent entries). > > The cherry-picking of which stat errors to silence (implicitly) seems > worse than either silencing the errors (like os.path.isdir does) or > allowing them to propagate. Hmmm, you're right there's a subtle difference here. I think the os.path.isdir() behaviour could mask real errors, and the pathlib behaviour is more correct. pathlib's behaviour is not implicit though -- it's clearly documented in the docs: https://docs.python.org/3/library/pathlib.html#pathlib.Path.is_dir > Returning False instead of raising OSError in is_dir() method simplifies > the usage greatly without (much) negative consequences. It is a *rare* > case when silencing errors could be more practical. I think is_X() *should* fail if there are permissions errors or other fatal errors. Whether or not they should fail if the file doesn't exist (unlikely to happen anyway) or on a broken symlink is a different question, but there's a good prececent with the existing os/pathlib functions there. -Ben [View Less]

2 1

PEP 3121, 384 Refactoring Issues
by Mark Lawrence July 15, 2014

July 15, 2014

I'm just curious as to why there are 54 open issues after both of these PEPs have been accepted and 384 is listed as finished. Did we hit some unforeseen technical problem which stalled development? For these and any other open issues if you need some Windows testing doing please feel free to put me on the nosy list and ask for a test run. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from … [View More]

8 11

Python Job Board
by Ethan Furman July 15, 2014

July 15, 2014

has now been dead for five months. -- ~Ethan~

4 5

Updates to PEP 471, the os.scandir() proposal
by Ben Hoyt July 14, 2014

July 14, 2014

Hi folks, After some very good python-dev feedback on my first version of PEP 471, I've updated the PEP to clarify a few things and added various "Rejected ideas" subsections. Here's a link to the new version (I've also copied the full text below): http://legacy.python.org/dev/peps/pep-0471/ -- new PEP as HTML http://hg.python.org/peps/rev/0da4736c27e8 -- changes Specifically, I've made these changes (not an exhaustive list): * Clarified wording in several places, for example "Linux and OS … [View More]

11 65

Memory BIO for _ssl
by Geert Jansen July 12, 2014

July 12, 2014

Hi, the topic of a memory BIO for the _ssl module in the stdlib was discussed before here: http://mail.python.org/pipermail/python-ideas/2012-November/017686.html Since I need this for my Gruvi async framework, I want to volunteer to write a patch. It should be useful as well to Py3K's asyncio and other async frameworks. It would be good to get some feedback before I start on this. I was thinking of the following approach: * Add a new type to _ssl: PySSLMemoryBIO * PySSLMemoryBIO has a … [View More]public constructor, and at least the following methods: puts() puts_eof() and gets(). I aligned the terminology with the method names in OpenSSL. puts_eof() does a BIO_set_mem_eof_return(-1). * All accesses to the memory BIO as non-blocking. * Update PySSLSocket to add support for SSL_set_bio(). The fact that the memory BIO is non-blocking makes it easier. None of the logic in and around check_socket_and_wait_for_timeout() for example needs to be changed. For the parts that deal with the socket directly, and that are in the code path for non-blocking IO, I think the preference would be i) try to change the code to use BIO methods that works for both sockets and memory BIOs, and ii) if not possible, special case it. * At this point the PySSLSocket name is a bit of a misnomer as it does more than sockets. Probably not an issue. * Add a method _wrap_bio(rbio, wbio, ...) to _SSLContext. * Expose the low-level methods via the "ssl" module. Creating an SSLSocket with a memory BIO would work something like this: context = SSLContext() rbio = ssl.MemoryBIO() wbio = ssl.MemoryBIO() sslsock = ssl.wrap_bio(rbio, wbio) To pass SSL data from the network and decrypt it into application level data (and potentially new SSL level data): rbio.puts(ssldata) appdata = sslsock.read() ssldata = wbio.gets() I currently have a utility class in my async IO framework (gruvi.io) called SslPipe that does the above, but it uses a socketpair instead of a memory BIO, and hence it works with the current _ssl. See here: https://github.com/geertj/gruvi/blob/master/gruvi/ssl.py#L86 This approach, while fine and very fast on Linux, gives me problems on Windows. It appears that on some older Windows versions, when I write data to one side of an (emulated) socket pair, it takes some time for it to become available at the other side. That breaks the synchronous interface that I need in order for this to work. And I can't fully work around it as I do not know in all situations whether or not to expect data on the socketpair. A memory BIO should be the right solution to this. Any feedback? Regards, Geert [View Less]

2 2

buildbot.python.org down again?
by Ned Deily July 12, 2014

July 12, 2014

As of the moment, buildbot.python.org seems to be down again. Where is the best place to report problems like this? -- Ned Deily, nad(a)acm.org

8 10

Summary of Python tracker Issues
by Python tracker July 11, 2014

July 11, 2014

ACTIVITY SUMMARY (2014-07-04 - 2014-07-11) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open 4588 (-15) closed 29141 (+55) total 33729 (+40) Open issues with patches: 2151 Issues opened (24) ================== #21918: Convert test_tools to directory http://bugs.python.org/issue21918 opened by serhiy.storchaka #21919: Changing cls.__bases__ must … [View More]

1 0

== on object tests identity in 3.x - uploaded doc patch
by Andreas Maier July 11, 2014

July 11, 2014

Am 11.07.2014 10:54, schrieb Ethan Furman: > On 07/11/2014 01:51 AM, Andreas Maier wrote: >> I like the motivation provided by Benjamin and will work it into the >> doc patch for issue #12067. The NaN special case >> will also stay in. > > Cool -- you should nosy myself, D'Aprano, and Benjamin (at least) on > that issue. Done. Plus, I have uploaded a patch (v8) to issue #12067, that reflects hopefully everything that was said (to the extent it was related to comparisons). Andy

1 0

== on object tests identity in 3.x
by Andreas Maier July 11, 2014

July 11, 2014

While discussing Python issue #12067 (http://bugs.python.org/issue12067#msg222442), I learned that Python 3.4 implements '==' and '!=' on the object type such that if no special equality test operations are implemented in derived classes, there is a default implementation that tests for identity (as opposed to equality of the values). The relevant code is in function do_richcompare() in Objects/object.c. IMHO, that default implementation contradicts the definition that '==' and '!=' … [View More]

10 29

== on object tests identity in 3.x - summary
by Andreas Maier July 8, 2014

July 8, 2014

Thanks to all who responded. In absence of class-specific equality test methods, the default implementations revert to use the identity (=address) of the object as a basis for the test, in both Python 2 and Python 3. In absence of specific ordering test methods, the default implementations revert to use the identity (=address) of the object as a basis for the test, in Python 2. In Python 3, an exception is raised in that case. The bottom line of the discussion seems to be that this … [View More]

3 2