Re: [Python-Dev] PEP 446: Add new parameters to configure the inherance of files and for non-blocking sockets
2013/7/5 Cameron Simpson c...@zip.com.au: You might want to make clear that the blocking parameter refers only to the file creation calls (eg socket.socket) and not to the file descriptor itself, and is not to be confused with the UNIX O_NONBLOCK file descriptor flag (and whatever equivalent flag may apply on Windows). The two following codes are the same: s = socket.socket(..., blocking=False) and s = socket.socket(...) s.setblocking(False) Both set O_NONBLOCK flag (UNIX) or clear HANDLE_FLAG_INHERIT (Windows) on the socket (which is a file descriptor). socket.socket(..., blocking=False) cannot fail with EAGAIN or EWOULDBLOCK (at least on Linux according to the manual page). This is deducable from your PEP, but I was at first confused, and initially expected get_blocking/set_blocking functions in New Functions. socket objects already have get_blocking() and set_blocking() methods. If we supported the blocking flag on any file descriptor, it would make sense to add such function to the os module. But I explained in the Add blocking parameter for file descriptors and Windows overlapped I/O section why I only want to set/clear the blocking file on sockets. I would expect Popen and friends to need to both clear the flag to get the descriptors across the fork() call, and _possibly_ to set the flag again after the fork. Naively, I would expect the the flag to be as it was before the Popen call, after the call. As explained in the Inheritance of file descriptors section, the close-on-exec flag has no effect on fork: The flag has no effect on fork(), all file descriptors are inherited by the child process. The close-on-exec flag is cleared after the fork and before the exec(). Pseudo-code for Popen: pid = os.fork() if pid: return pid # child process for fd in pass_fds: os.set_cloexec(fd, False) os.execv(...) Victor ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Oddity in MISC/News on default
On 7/4/2013 3:36 PM, Guido van Rossum wrote: Maybe the mistake is that the others aren't mentioned? Or perhaps everything before 3.4a1 should be dropped? I forget what kind of policy we have for this -- is it all changes in this branch or only changes unique to this branch? It cannot be 'unique' because most bug fixes are not unique to any branch. News for 3.x should have all relevant changes to 3.x, and, I think, only those. The question is whether the entries under 3.3.1rc1 in 3.4 News are changes unique to 3.3.1rc1 that should not be in News 3.4; changes to both 3.3 and 3.4 that are now listed twice, and should only be listed once; or changes to 3.4 that are now listed only under 3.3 but should instead be listed as 3.4 changes. I am not looking at the moment because is it 3am here. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] lament for the demise of unbound methods
On 4 Jul 2013, at 19:00, Guido van Rossum gu...@python.org wrote: Thanks for the code pointers. So it's all about monkeypatching. :-) I have only a little sympathy, as there still seems to be a way to do this, it's just less convenient. Too bad. I've also lamented the death of bound methods in Python 3 for mock autospeccing. Autospec introspects objects and provides mock objects with the same attributes - and with the same method signatures. For methods it needs to trim the first argument (because instances are called externally without self of course). Not being able to tell the difference between a module level function and an unbound method caused some pain then. (I worked round it by flowing the information about where the object came from through the code but it did add ugliness). Michael --Guido On Thu, Jul 4, 2013 at 9:42 AM, Chris Withers ch...@simplistix.co.uk wrote: Hi Guido, I've bumped into this a couple of times. First time was when I wanted to know whether what I had was a classmethod, staticmethod or normal method here: https://github.com/Simplistix/testfixtures/blob/master/testfixtures/replace.py#L59 This resulted in having to trawl through __dict__ here: https://github.com/Simplistix/testfixtures/blob/master/testfixtures/resolve.py#L17 ...rather than just using getattr. I bumped into it again, yesterday, trying to add support for classes to this lightweight dependency injection framework I'm developing: https://github.com/Simplistix/mush/blob/master/tests/test_runner.py#L189 Here's my local copy of that test: https://gist.github.com/cjw296/db64279c69cdc0c5e112 The workaround I was playing with this morning is a wrapper so that I know I have a class method, although what I really want to write at this line is: https://gist.github.com/cjw296/db64279c69cdc0c5e112#file-gistfile1-txt-L40 runner = Runner(T0, C1.meth, C2.meth1, C2.meth2) ...but if I do that, how can the runner know that what it gets for its second argument is a class method of C1? (which is this case means that it should do C1().meth() rather than C1.meth()) cheers, Chris On 04/07/2013 17:25, Guido van Rossum wrote: Chris, what do you want to do with the knowledge you are seeking? --Guido van Rossum (sent from Android phone) On Jul 4, 2013 4:28 AM, Chris Withers ch...@simplistix.co.uk mailto:ch...@simplistix.co.uk wrote: Hi All, In Python 2, I can figure out whether I have a method or a function, and, more importantly, for an unbound method, I can figure out what class the method belongs to: class MyClass(object): ... def method(self): pass ... MyClass.method unbound method MyClass.method MyClass.method.im_class class '__main__.MyClass' There doesn't appear to be any way in Python 3 to do this, which is a little surprising and frustrating... What am I missing here? Chris -- Simplistix - Content Management, Batch Processing Python Consulting - http://www.simplistix.co.uk _ Python-Dev mailing list Python-Dev@python.org mailto:Python-Dev@python.org http://mail.python.org/__mailman/listinfo/python-dev http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/__mailman/options/python-dev/__guido%40python.org http://mail.python.org/mailman/options/python-dev/guido%40python.org __ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com __ -- Simplistix - Content Management, Batch Processing Python Consulting - http://www.simplistix.co.uk -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] lament for the demise of unbound methods
Am 05.07.13 11:23, schrieb Michael Foord: I've also lamented the death of bound methods in Python 3 for mock autospeccing. Autospec introspects objects and provides mock objects with the same attributes - and with the same method signatures. I wonder why you need to figure out the signatures in advance. Can you just wait until the function is actually used, and then process the parameters as you get them? Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] lament for the demise of unbound methods
On 5 lip 2013, at 12:07, Martin v. Löwis mar...@v.loewis.de wrote: I wonder why you need to figure out the signatures in advance. Can you just wait until the function is actually used, and then process the parameters as you get them? My guess is that Michael's design lets mock objects be introspected as well, i.e. they don't appear as magical as they really are to the user code. -- Best regards, Łukasz Langa WWW: http://lukasz.langa.pl/ Twitter: @llanga IRC: ambv on #python-dev ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 446: Add new parameters to configure the inherance of files and for non-blocking sockets
2013/7/4 Victor Stinner victor.stin...@gmail.com: Even if the PEP 433 was not explicitly rejected, no consensus could be reached. I didn't want to loose all my work on this PEP and so I'm proposing something new which should make everbody agrees :-) Thanks Victor, I think this one is perfectly fine! cf ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] lament for the demise of unbound methods
Am 04.07.13 18:42, schrieb Chris Withers: Hi Guido, I've bumped into this a couple of times. First time was when I wanted to know whether what I had was a classmethod, staticmethod or normal method here: https://github.com/Simplistix/testfixtures/blob/master/testfixtures/replace.py#L59 This resulted in having to trawl through __dict__ here: https://github.com/Simplistix/testfixtures/blob/master/testfixtures/resolve.py#L17 You could use __getattribute__ instead: class A: ... @staticmethod ... def s(): ... pass ... @classmethod ... def c(cl): ... pass ... def r(self): ... pass ... A.__getattribute__(A,'s') staticmethod object at 0x100937828 A.__getattribute__(A,'c') classmethod object at 0x100937860 A.__getattribute__(A,'r') function A.r at 0x100938378 Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 446: Add new parameters to configure the inherance of files and for non-blocking sockets
On 05Jul2013 08:24, Victor Stinner victor.stin...@gmail.com wrote: | 2013/7/5 Cameron Simpson c...@zip.com.au: | You might want to make clear that the blocking parameter refers | only to the file creation calls (eg socket.socket) and not to the | file descriptor itself, and is not to be confused with the UNIX | O_NONBLOCK file descriptor flag (and whatever equivalent flag may | apply on Windows). | | The two following codes are the same: | | s = socket.socket(..., blocking=False) | and | s = socket.socket(...) | s.setblocking(False) | | Both set O_NONBLOCK flag (UNIX) Oh, how embarassing. | or clear HANDLE_FLAG_INHERIT (Windows) | on the socket (which is a file descriptor). | | socket.socket(..., blocking=False) cannot fail with EAGAIN or | EWOULDBLOCK (at least on Linux according to the manual page). Fair enough. | This is deducable from your PEP, but I was at first confused, and | initially expected get_blocking/set_blocking functions in New | Functions. | | socket objects already have get_blocking() and set_blocking() methods. Ah, ok then. As far as it goes. Shouldn't there be a general purpose os.get_blocking() and os.set_blocking() functions that operate on any file descriptor, paralleling os.get_cloexec() and os.set_cloexec()? They're not socket specific operations in principle, merely commonly used with sockets. | If we supported the blocking flag on any file descriptor, it would | make sense to add such function to the os module. But I explained in | the Add blocking parameter for file descriptors and Windows | overlapped I/O section why I only want to set/clear the blocking file | on sockets. But WHY? I think socket file decriptors should be treated little differently from other file descriptors. Certainly a stream socket connection is outstanding like other unseekable file descriptors in many respects. Just only wanting it on sockets seems a bit special purpose. If you're going address O_NONBLOCK in this proposal in addition to the close-on-exec flag, it should be general purpose. Otherwise, I think it should be separated out into a separate proposal if you're proposing it just for sockets; make this proposal just close-on-exec and forget the blocking stuff for this specific PEP. | I would expect Popen and friends to need to both clear the flag to | get the descriptors across the fork() call, and _possibly_ to set | the flag again after the fork. Naively, I would expect the the flag | to be as it was before the Popen call, after the call. | | As explained in the Inheritance of file descriptors section, the | close-on-exec flag has no effect on fork: | | The flag has no effect on fork(), all file descriptors are inherited | by the child process. Agreed, see my second post where I explained I'd misthought it. However, as stated there, I think the side effects should be fairly overtly stated in the docuemntation. | The close-on-exec flag is cleared after the fork and before the | exec(). Pseudo-code for Popen: | | pid = os.fork() | if pid: | return pid | # child process | for fd in pass_fds: os.set_cloexec(fd, False) | os.execv(...) Fine. No state restore is fine with me. I think it should be as clear as possible in the doco. Cheers, -- Cameron Simpson c...@zip.com.au Experience is what you have got after you needed it. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2013-06-28 - 2013-07-05) 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: open4072 ( +3) closed 26066 (+39) total 30138 (+42) Open issues with patches: 1803 Issues opened (32) == #5308: cannot marshal objects with more than 2**31 elements http://bugs.python.org/issue5308 reopened by christian.heimes #13153: IDLE crashes when pasting non-BMP unicode char on Py3 http://bugs.python.org/issue13153 reopened by serhiy.storchaka #18324: set_payload does not handle binary payloads correctly http://bugs.python.org/issue18324 opened by r.david.murray #18325: test_kqueue fails in OpenBSD http://bugs.python.org/issue18325 opened by Federico.Schwindt #18326: Not Clear Docs http://bugs.python.org/issue18326 opened by icedream91 #18327: swapped arguments in compatible_for_assignment()? http://bugs.python.org/issue18327 opened by christian.heimes #18329: for line in socket.makefile() speed degradation http://bugs.python.org/issue18329 opened by mmarkk #18330: Fix idlelib.PyShell.build_subprocess_arglist use of __import_ http://bugs.python.org/issue18330 opened by terry.reedy #18331: Document that runpy.run_path and run_module copy the module gl http://bugs.python.org/issue18331 opened by Drekin #18334: type(name, bases, dict) does not call metaclass' __prepare__ a http://bugs.python.org/issue18334 opened by Nikratio #18335: Add textwrap.dedent, .indent, as str methods. http://bugs.python.org/issue18335 opened by terry.reedy #18336: codecs: Link to readline module (history) instead of fd.readli http://bugs.python.org/issue18336 opened by guettli #18338: python --version should send output to STDOUT http://bugs.python.org/issue18338 opened by jaalto #18340: float related test has problem with Denormal Flush to Zero com http://bugs.python.org/issue18340 opened by V.E.O #18342: Use the repr of a module name for ModuleNotFoundError in ceval http://bugs.python.org/issue18342 opened by brett.cannon #18344: _bufferedreader_read_all() may leak reference to data http://bugs.python.org/issue18344 opened by christian.heimes #18345: logging: file creation options with FileHandler and friends http://bugs.python.org/issue18345 opened by pitrou #18348: Additional code pages for EBCDIC http://bugs.python.org/issue18348 opened by roskakori #18349: argparse usage should preserve () in metavars such as range(20 http://bugs.python.org/issue18349 opened by paul.j3 #18351: Incorrect variable name in importlib._bootstrap._get_sourcefil http://bugs.python.org/issue18351 opened by brett.cannon #18352: collections.Counter with added attributes are not deepcopied p http://bugs.python.org/issue18352 opened by Olivier.Gagnon #18353: PyUnicode_WRITE_CHAR macro definition missing http://bugs.python.org/issue18353 opened by Wolf.Ihlenfeldt #18354: http://www.python.org/doc/ has outdated note http://bugs.python.org/issue18354 opened by dholth #18355: Merge super() guide into documentation http://bugs.python.org/issue18355 opened by Russkel #18356: help(numpy) causes segfault on exit http://bugs.python.org/issue18356 opened by Leeward #18357: add tests for dictview set difference operations http://bugs.python.org/issue18357 opened by frasertweedale #18360: Won't install. Keeps telling me DLL is missing. http://bugs.python.org/issue18360 opened by daleastar #18361: Move dev-in-a-box to os.cpu_count() http://bugs.python.org/issue18361 opened by brett.cannon #18362: Make build_cpython.py from dev-in-a-box work outside of a box http://bugs.python.org/issue18362 opened by brett.cannon #18363: Change use of acronym tag in devinabox index.html to abbr http://bugs.python.org/issue18363 opened by brett.cannon #18364: Remove _not_found hack from importlib http://bugs.python.org/issue18364 opened by brett.cannon #18365: Idle: mock Text class and test thereof http://bugs.python.org/issue18365 opened by terry.reedy Most recent 15 issues with no replies (15) == #18364: Remove _not_found hack from importlib http://bugs.python.org/issue18364 #18363: Change use of acronym tag in devinabox index.html to abbr http://bugs.python.org/issue18363 #18362: Make build_cpython.py from dev-in-a-box work outside of a box http://bugs.python.org/issue18362 #18361: Move dev-in-a-box to os.cpu_count() http://bugs.python.org/issue18361 #18355: Merge super() guide into documentation http://bugs.python.org/issue18355 #18349: argparse usage should preserve () in metavars such as range(20 http://bugs.python.org/issue18349 #18348: Additional code pages for EBCDIC http://bugs.python.org/issue18348 #18345: logging: file creation options with FileHandler and friends http://bugs.python.org/issue18345 #18342: Use the repr of a module name for ModuleNotFoundError in ceval http://bugs.python.org/issue18342
Re: [Python-Dev] PEP 446: Add new parameters to configure the inherance of files and for non-blocking sockets
2013/7/5 Cameron Simpson c...@zip.com.au: | Both set O_NONBLOCK flag (UNIX) Oh, how embarassing. You said that the PEP is not cristal clear. Do you have a suggestion to make it more clear? Should I mention that the close-on-exec flag is O_CLOEXEC on UNIX, and HANDLE_FLAG_INHERIT on Windows? (except that HANDLE_FLAG_INHERIT set means inheritable, whereas O_CLOEXEC set means *not* inheritable) | This is deducable from your PEP, but I was at first confused, and | initially expected get_blocking/set_blocking functions in New | Functions. | | socket objects already have get_blocking() and set_blocking() methods. Ah, ok then. As far as it goes. Shouldn't there be a general purpose os.get_blocking() and os.set_blocking() functions that operate on any file descriptor, paralleling os.get_cloexec() and os.set_cloexec()? I didn't propose to add these two functions, because I'm not sure that they are really useful. We can add os.get_blocking() and os.set_blocking() on UNIX, but these functions would not be available on Windows. On Windows, os.set_blocking() only makes sense for sockets, and sockets already have a set_blocking() method. On UNIX, it makes sense because set_blocking(fd, True) can be implemented as a single syscall on some platforms (using ioctl), whereas most developers implement it using two syscalls (fcntl to get current flags, and fcntl to set the O_NONBLOCK flag) maybe because it is more portable. But we cannot add a new blocking parameter to all functions creating file descriptors, like open(), because of Windows. Or do you like the raise NotImplementedError on Windows option? But WHY? I think socket file decriptors should be treated little differently from other file descriptors. Because of Windows. On Windows, sockets and files are two different things. sockets have no file descriptor, they have a HANDLE. For example, sockobj.fileno() on Windows returns a huge number, not something like 3 or 10. The C type HANDLE is larger than a file descriptor on Windows 64-bit (sizeof(void*) sizeof(int)) and so functions must be modified to use a wider type (to parse their argument), and must support the HANDLE type (_open_osfhandle() can be used to have a single version of the code). Otherwise, I think it should be separated out into a separate proposal if you're proposing it just for sockets; make this proposal just close-on-exec and forget the blocking stuff for this specific PEP. The reason for addressing close-on-exec and blocking parameters in the same PEP is that new versions of operating systems support setting the two flags at the creation a new file descriptor and a new socket. Read the article linked at the end of the PEP for the background: http://udrepper.livejournal.com/20407.html The Python call socket.socket(..., cloexec=True, blocking=False) only calls one syscall on Linux = 2.6.27. | I would expect Popen and friends to need to both clear the flag to | get the descriptors across the fork() call, and _possibly_ to set | the flag again after the fork. Naively, I would expect the the flag | to be as it was before the Popen call, after the call. | | As explained in the Inheritance of file descriptors section, the | close-on-exec flag has no effect on fork: | | The flag has no effect on fork(), all file descriptors are inherited | by the child process. Agreed, see my second post where I explained I'd misthought it. However, as stated there, I think the side effects should be fairly overtly stated in the docuemntation. Sorry, I don't understand. Which side effect? The close-on-exec flag only affects inheritance of file descriptors at the execv() syscall, not at fork(). And execv() can be called without fork(). Popen must clear close-on-exec flag on files from its pass_fds parameter for convinience. It would be surprising to not inherit a file descriptor passed to Popen in pass_fds, don't you think so? os.execv() has no pass_fds parameter, and it is a thin wrapper on the syscall. Popen is a high-level API, that's why it prepares more things before calling the new program. | The close-on-exec flag is cleared after the fork and before the | exec(). Pseudo-code for Popen: | | pid = os.fork() | if pid: | return pid | # child process | for fd in pass_fds: os.set_cloexec(fd, False) | os.execv(...) Fine. No state restore is fine with me. I think it should be as clear as possible in the doco. I don't understand. I already wrote The flag has no effect on fork(), all file descriptors are inherited by the child process in the PEP. It is not enough? Do you have a suggestion to explain it better? Victor ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 423 : naming conventions and recipes related to packaging
Hi! Attached is a an updated proposal for PEP 423. You can also find it online at https://gist.github.com/benoitbryon/2815051 I am attending at EuroPython 2013 in Florence. Isn't it a great opportunity to get feedback and discuss about a PEP? I registered an open-space session and a lightning-talk today! Some notes about the update... The main point that was discussed in the previous proposal was the top-level namespace relates to code ownership rule. Here is a quote from Antoine Pitrou: Le 27/06/2012 12:50, Antoine Pitrou a écrit : On Wed, 27 Jun 2012 11:08:45 +0200 Benoît Bryonben...@marmelune.net wrote: Hi, Here is an informational PEP proposal: http://hg.python.org/peps/file/52767ab7e140/pep-0423.txt Could you review it for style, consistency and content? There is one Zen principle this PEP is missing: Flat is better than nested. This PEP seems to promote the practice of having a top-level namespace denote ownership. I think it should do the reverse: promote meaningful top-level packages (e.g. sphinx) as standard practice, and allow an exception for when a piece of software is part of a larger organizational body. So, the main change in the proposal I'm sending today is the removal of this ownership rule. It has been replaced by Use a single namespace (except special cases). Some additional changes have been performed, such as removal of some sections about opportunity or promote migrations. I also added a Rationale section where I pointed out some issues related to naming. The PEP has been marked as deferred because it was inactive and it is partly related to PEP 426. I left this deferred state. I am aware that some links in the PEP are broken... I will fix them later. My very first motivation is to get feedback about the big changes in the PEP. I wanted the update to be sent before EuroPython-2013's open-space session. I guess a detailed review would be nice anyway, for links, style, grammar... Also, I wonder whether the PEP could be shortened or not. Sometimes I cannot find straightforward words to explain things, so perhaps someone with better skills in english language could help. Or maybe some parts, such as the How to rename a project section, could be moved in other documents. Regards, Benoît PEP: 423 Title: Naming conventions and recipes related to packaging Version: $Revision$ Last-Modified: $Date$ Author: Benoît Bryon ben...@marmelune.net Discussions-To: distutils-...@python.org Status: Deferred Type: Informational Content-Type: text/x-rst Created: 24-May-2012 Post-History: 5-Jul-2013 Abstract This document deals with: * names of Python projects, * names of Python packages or modules being distributed, * namespace packages. It provides guidelines and recipes for distribution authors: * new projects should follow the `guidelines #overview`_ below. * existing projects should be aware of these guidelines and can follow `specific recipes for existing projects #how-to-apply-naming-guidelines-on-existing-projects`_. PEP Deferral Further consideration of this PEP has been deferred at least until after PEP 426 (package metadata 2.0) and related updates have been resolved. Rationale: issues related to names == For a long time, there have been no official reference on the how to choose names topic in the Python community. As a consequence, the Python package index (`PyPI`_) contains many naming patterns. The fact is that this heterogeneity causes some issues. Some of them are described below. .. note:: Examples were taken on July 2013. Naming things is a hard task, and naming Python projects or packages is not an exception. The purpose of this PEP is to help project authors to avoid common traps about naming, and focus on valuable things. Clashes --- Projects names are unique on `PyPI`_. But names of distributed things (packages, modules) are not. And there are clashes. As an example, pysendfile and django-sendfile projects both distribute a sendfile package. Users cannot use both in an environment. Deep nested hierarchies --- Deep nested namespaces mean deep nested hierarchies. It obfuscates valuable project contents. As an example, with plone.app.content you get a deeply nested directory hierarchy: .. code:: text plone/ └── app/ └── command/ └── ... valuable code is here... Whereas, with flat packages like sphinx, you have valuable code near the top-level directory: .. code:: text sphinx/ └── ... valuable code is here... Unrelated namespaces When project names are made of nested namespaces, and these namespaces are not strongly related, then there is confusion. As an example, it is not obvious that zc.rst2 project is a general Python project, not tied to zc (Zope Corporation), but related to docutils' reStructuredText. As a consequence, some users discard zc.rst2 project, because they think it
Re: [Python-Dev] PEP 423 : naming conventions and recipes related to packaging
In your first plone example you first use plone.app.content, but then present the directory structure of plone.app.command. Apart from that, the PEP seems legit to me, contentwise. I think some parts are clumsily formulated, but IMO rewriting these parts wouldn't even decrease the text's length or improve readability. -- Markus (from phone) Benoît Bryon ben...@marmelune.net wrote: Hi! Attached is a an updated proposal for PEP 423. You can also find it online at https://gist.github.com/benoitbryon/2815051 I am attending at EuroPython 2013 in Florence. Isn't it a great opportunity to get feedback and discuss about a PEP? I registered an open-space session and a lightning-talk today! Some notes about the update... The main point that was discussed in the previous proposal was the top-level namespace relates to code ownership rule. Here is a quote from Antoine Pitrou: Le 27/06/2012 12:50, Antoine Pitrou a écrit : On Wed, 27 Jun 2012 11:08:45 +0200 Benoît Bryonben...@marmelune.net wrote: Hi, Here is an informational PEP proposal: http://hg.python.org/peps/file/52767ab7e140/pep-0423.txt Could you review it for style, consistency and content? There is one Zen principle this PEP is missing: Flat is better than nested. This PEP seems to promote the practice of having a top-level namespace denote ownership. I think it should do the reverse: promote meaningful top-level packages (e.g. sphinx) as standard practice, and allow an exception for when a piece of software is part of a larger organizational body. So, the main change in the proposal I'm sending today is the removal of this ownership rule. It has been replaced by Use a single namespace (except special cases). Some additional changes have been performed, such as removal of some sections about opportunity or promote migrations. I also added a Rationale section where I pointed out some issues related to naming. The PEP has been marked as deferred because it was inactive and it is partly related to PEP 426. I left this deferred state. I am aware that some links in the PEP are broken... I will fix them later. My very first motivation is to get feedback about the big changes in the PEP. I wanted the update to be sent before EuroPython-2013's open-space session. I guess a detailed review would be nice anyway, for links, style, grammar... Also, I wonder whether the PEP could be shortened or not. Sometimes I cannot find straightforward words to explain things, so perhaps someone with better skills in english language could help. Or maybe some parts, such as the How to rename a project section, could be moved in other documents. Regards, Benoît ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/markus%40unterwaditzer.net ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 446: Add new parameters to configure the inherance of files and for non-blocking sockets
On 05Jul2013 19:03, Victor Stinner victor.stin...@gmail.com wrote: | 2013/7/5 Cameron Simpson c...@zip.com.au: | | Both set O_NONBLOCK flag (UNIX) | | Oh, how embarassing. | | You said that the PEP is not cristal clear. Do you have a suggestion | to make it more clear? | | Should I mention that the close-on-exec flag is O_CLOEXEC on UNIX, and | HANDLE_FLAG_INHERIT on Windows? (except that HANDLE_FLAG_INHERIT set | means inheritable, whereas O_CLOEXEC set means *not* inheritable) It wouldn't hurt. Otherwise, colour me mostly convinced. I've read your Rejected Alternatives more closely and Ulrich Drepper's article, though I think the article also supports adding a blocking (default True) parameter to open() and os.open(). If you try to change that default on a platform where it doesn't work, an exception should be raised. | The close-on-exec flag only affects inheritance of file descriptors at | the execv() syscall, not at fork(). And execv() can be called without | fork(). Yes. Please forget I mentioned fork(); it is only relevant if you were offering some facility to undo the addition of cloexec to a Popen passed file descriptor. Which you are not. | Popen must clear close-on-exec flag on files from its pass_fds | parameter for convinience. It would be surprising to not inherit a | file descriptor passed to Popen in pass_fds, don't you think so? Yes yes yes. | I don't understand. I already wrote The flag has no effect on fork(), | all file descriptors are inherited by the child process in the PEP. | It is not enough? Do you have a suggestion to explain it better? My concerns are probably as well bundled with concerns about users not realising the a file descriptor state after a fork is shared, and then being confused if the other process did a seek() etc. I think I'm just concerned about a naive caller using this scenario: # gather up some already open fds to pass fds = (5,6,7) P = Popen(, pass_fds=fds) # now restore the cloexec state from before for fd in fds: os.set_cloexec(fd) where the cleanup loop in the parent gets to run before the exec() in the child. We could just consider it one of the pitfalls of fork/exec situations in general an expect people being this fiddly to need to add some synchornisation. Please consider your argument won. Cheers, -- Cameron Simpson c...@zip.com.au ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
