Mailman 3 July 2010 - Python-ideas

i18n and Python tracebacks
by Andre Roberge Oct. 28, 2012

Oct. 28, 2012

I think it would be a good idea if Python tracebacks could be translated into languages other than English - and it would set a good example. For example, using French as my default local language, instead of >>> 1/0 Traceback (most recent call last): File "<stdin>", line 1, in <module> ZeroDivisionError: integer division or modulo by zero I might get something like >>> 1/0 Suivi d'erreur (appel le plus récent en dernier) : Fichier "<stdin>", à la … [View More]

9 15

Json object-level serializer
by Tarek Ziadé July 31, 2010

July 31, 2010

Hello, What about adding in the json package the ability for an object to provide a different object to serialize ? This would be useful to translate a class into a structure that can be passed to json.dumps So, it __json__ is provided, its used for serialization instead of the object itself: >>> import json >>> class MyComplexClass(object): ... def __json__(self): ... return 'json' ... >>> o = MyComplexClass() >>> json.dumps(o) '"json"' … [View More]

19 58

Exposing the ABC registration graph (was Re: Json object-level serializer)
by Nick Coghlan July 31, 2010

July 31, 2010

On Sat, Jul 31, 2010 at 10:12 PM, Antoine Pitrou <solipsis(a)pitrou.net> wrote: > On Sat, 31 Jul 2010 13:50:16 +0200 > Tarek Ziadé <ziade.tarek(a)gmail.com> wrote: >> On Sat, Jul 31, 2010 at 3:31 AM, Nick Coghlan <ncoghlan-Re5JQEeQqe8AvxtiuMwx3w(a)public.gmane.org> wrote: >> > To be honest, there are actually some more features I would want to >> > push for in ABCs (specifically, a public API to view an ABC's type >> > registry, as well … [View More]

1 0

PEP 3151: Reworking the OS and IO exception hierarchy
by Antoine Pitrou July 31, 2010

July 31, 2010

Hello, I would like to propose the following PEP for feedback and review. Permanent link to up-to-date version with proper HTML formatting: http://www.python.org/dev/peps/pep-3151/ Thank you, Antoine. PEP: 3151 Title: Reworking the OS and IO exception hierarchy Version: $Revision: 83042 $ Last-Modified: $Date: 2010-07-21 21:16:49 +0200 (mer. 21 juil. 2010) $ Author: Antoine Pitrou <solipsis(a)pitrou.net> Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 2010-07-… [View More]21 Python-Version: 3.2 or 3.3 Post-History: Resolution: TBD Abstract ======== The standard exception hierarchy is an important part of the Python language. It has two defining qualities: it is both generic and selective. Generic in that the same exception type can be raised - and handled - regardless of the context (for example, whether you are trying to add something to an integer, to call a string method, or to write an object on a socket, a TypeError will be raised for bad argument types). Selective in that it allows the user to easily handle (silence, examine, process, store or encapsulate...) specific kinds of error conditions while letting other errors bubble up to higher calling contexts. For example, you can choose to catch ZeroDivisionErrors without affecting the default handling of other ArithmeticErrors (such as OverflowErrors). This PEP proposes changes to a part of the exception hierarchy in order to better embody the qualities mentioned above: the errors related to operating system calls (OSError, IOError, select.error, and all their subclasses). Rationale ========= Confusing set of OS-related exceptions -------------------------------------- OS-related (or system call-related) exceptions are currently a diversity of classes, arranged in the following subhierarchies:: +-- EnvironmentError +-- IOError +-- io.BlockingIOError +-- io.UnsupportedOperation (also inherits from ValueError) +-- socket.error +-- OSError +-- WindowsError +-- mmap.error +-- select.error While some of these distinctions can be explained by implementation considerations, they are often not very logical at a higher level. The line separating OSError and IOError, for example, is often blurry. Consider the following:: >>> os.remove("fff") Traceback (most recent call last): File "<stdin>", line 1, in <module> OSError: [Errno 2] No such file or directory: 'fff' >>> open("fff") Traceback (most recent call last): File "<stdin>", line 1, in <module> IOError: [Errno 2] No such file or directory: 'fff' The same error condition (a non-existing file) gets cast as two different exceptions depending on which library function was called. The reason for this is that the ``os`` module exclusively raises OSError (or its subclass WindowsError) while the ``io`` module mostly raises IOError. However, the user is interested in the nature of the error, not in which part of the interpreter it comes from (since the latter is obvious from reading the traceback message or application source code). In fact, it is hard to think of any situation where OSError should be caught but not IOError, or the reverse. A further proof of the ambiguity of this segmentation is that the standard library itself sometimes has problems deciding. For example, in the ``select`` module, similar failures will raise either ``select.error``, ``OSError`` or ``IOError`` depending on whether you are using select(), a poll object, a kqueue object, or an epoll object. This makes user code uselessly complicated since it has to be prepared to catch various exception types, depending on which exact implementation of a single primitive it chooses to use at runtime. As for WindowsError, it seems to be a pointless distinction. First, it only exists on Windows systems, which requires tedious compatibility code in cross-platform applications (such code can be found in ``Lib/shutil.py``). Second, it inherits from OSError and is raised for similar errors as OSError is raised for on other systems. Third, the user wanting access to low-level exception specifics has to examine the ``errno`` or ``winerror`` attribute anyway. Lack of fine-grained exceptions ------------------------------- The current variety of OS-related exceptions doesn't allow the user to filter easily for the desired kinds of failures. As an example, consider the task of deleting a file if it exists. The Look Before You Leap (LBYL) idiom suffers from an obvious race condition:: if os.path.exists(filename): os.remove(filename) If a file named as ``filename`` is created by another thread or process between the calls to ``os.path.exists`` and ``os.remove``, it won't be deleted. This can produce bugs in the application, or even security issues. Therefore, the solution is to try to remove the file, and ignore the error if the file doesn't exist (an idiom known as Easier to Ask Forgiveness than to get Permission, or EAFP). Careful code will read like the following (which works under both POSIX and Windows systems):: try: os.remove(filename) except OSError as e: if e.errno != errno.ENOENT: raise or even:: try: os.remove(filename) except EnvironmentError as e: if e.errno != errno.ENOENT: raise This is a lot more to type, and also forces the user to remember the various cryptic mnemonics from the ``errno`` module. It imposes an additional cognitive burden and gets tiresome rather quickly. Consequently, many programmers will instead write the following code, which silences exceptions too broadly:: try: os.remove(filename) except OSError: pass ``os.remove`` can raise an OSError not only when the file doesn't exist, but in other possible situations (for example, the filename points to a directory, or the current process doesn't have permission to remove the file), which all indicate bugs in the application logic and therefore shouldn't be silenced. What the programmer would like to write instead is something such as:: try: os.remove(filename) except FileNotFound: pass Compatibility strategy ====================== Reworking the exception hierarchy will obviously change the exact semantics of at least some existing code. While it is not possible to improve on the current situation without changing exact semantics, it is possible to define a narrower type of compatibility, which we will call **useful compatibility**, and define as follows: * *useful compatibility* doesn't make exception catching any narrower, but it can be broader for *naïve* exception-catching code. Given the following kind of snippet, all exceptions caught before this PEP will also be caught after this PEP, but the reverse may be false:: try: os.remove(filename) except OSError: pass * *useful compatibility* doesn't alter the behaviour of *careful* exception-catching code. Given the following kind of snippet, the same errors should be silenced or reraised, regardless of whether this PEP has been implemented or not:: try: os.remove(filename) except OSError as e: if e.errno != errno.ENOENT: raise The rationale for this compromise is that careless (or "naïve") code can't really be helped, but at least code which "works" won't suddenly raise errors and crash. This is important since such code is likely to be present in scripts used as cron tasks or automated system administration programs. Careful code should not be penalized. Step 1: coalesce exception types ================================ The first step of the resolution is to coalesce existing exception types. The extent of this step is not yet fully determined. A number of possible changes are listed hereafter: * alias both socket.error and select.error to IOError * alias mmap.error to OSError * alias IOError to OSError * alias WindowsError to OSError Each of these changes doesn't preserve exact compatibility, but it does preserve *useful compatibility* (see "compatibility" section above). Not only does this first step present the user a simpler landscape, but it also allows for a better and more complete resolution of step 2 (see "Prerequisite" below). Deprecation of names -------------------- It is not yet decided whether the old names will be deprecated (then removed) or all alternative names will continue living in the root namespace. Deprecation of names from the root namespace presents some implementation challenges, especially where performance is important. Step 2: define additional subclasses ==================================== The second step of the resolution is to extend the hierarchy by defining subclasses which will be raised, rather than their parent, for specific errno values. Which errno values is subject to discussion, but a survey of existing exception matching practices (see Appendix A) helps us propose a reasonable subset of all values. Trying to map all errno mnemonics, indeed, seems foolish, pointless, and would pollute the root namespace. Furthermore, in a couple of cases, different errno values could raise the same exception subclass. For example, EAGAIN, EALREADY, EWOULDBLOCK and EINPROGRESS are all used to signal that an operation on a non-blocking socket would block (and therefore needs trying again later). They could therefore all raise an identical subclass and let the user examine the ``errno`` attribute if (s)he so desires (see below "exception attributes"). Prerequisite ------------ Step 1 is a loose prerequisite for this. Prerequisite, because some errnos can currently be attached to different exception classes: for example, EBADF can be attached to both OSError and IOError, depending on the context. If we don't want to break *useful compatibility*, we can't make an ``except OSError`` (or IOError) fail to match an exception where it would succeed today. Loose, because we could decide for a partial resolution of step 2 if existing exception classes are not coalesced: for example, EBADF could raise a hypothetical BadFileDescriptor where an IOError was previously raised, but continue to raise OSError otherwise. The dependency on step 1 could be totally removed if the new subclasses used multiple inheritance to match with all of the existing superclasses (or, at least, OSError and IOError, which are arguable the most prevalent ones). It would, however, make the hierarchy more complicated and therefore harder to grasp for the user. New exception classes --------------------- The following tentative list of subclasses, along with a description and the list of errnos mapped to them, is submitted to discussion: * ``FileAlreadyExists``: trying to create a file or directory which already exists (EEXIST) * ``FileNotFound``: for all circumstances where a file and directory is requested but doesn't exist (ENOENT) * ``IsADirectory``: file-level operation (open(), os.remove()...) requested on a directory (EISDIR) * ``NotADirectory``: directory-level operation requested on something else (ENOTDIR) * ``PermissionDenied``: trying to run an operation without the adequate access rights - for example filesystem permissions (EACCESS, optionally EPERM) * ``BlockingIOError``: an operation would block on an object (e.g. socket) set for non-blocking operation (EAGAIN, EALREADY, EWOULDBLOCK, EINPROGRESS); this is the existing ``io.BlockingIOError`` with an extended role * ``BadFileDescriptor``: operation on an invalid file descriptor (EBADF); the default error message could point out that most causes are that an existing file descriptor has been closed * ``ConnectionAborted``: connection attempt aborted by peer (ECONNABORTED) * ``ConnectionRefused``: connection reset by peer (ECONNREFUSED) * ``ConnectionReset``: connection reset by peer (ECONNRESET) * ``TimeoutError``: connection timed out (ECONNTIMEOUT); this could be re-cast as a generic timeout exception, useful for other types of timeout (for example in Lock.acquire()) This list assumes step 1 is accepted in full; the exception classes described above would all derive from the now unified exception type OSError. It will need reworking if a partial version of step 1 is accepted instead (again, see appendix A for the current distribution of errnos and exception types). Exception attributes -------------------- In order to preserve *useful compatibility*, these subclasses should still set adequate values for the various exception attributes defined on the superclass (for example ``errno``, ``filename``, and optionally ``winerror``). Implementation -------------- Since it is proposed that the subclasses are raised based purely on the value of ``errno``, little or no changes should be required in extension modules (either standard or third-party). As long as they use the ``PyErr_SetFromErrno()`` family of functions (or the ``PyErr_SetFromWindowsErr()`` family of functions under Windows), they should automatically benefit from the new, finer-grained exception classes. Library modules written in Python, though, will have to be adapted where they currently use the following idiom (seen in ``Lib/tempfile.py``):: raise IOError(_errno.EEXIST, "No usable temporary file name found") Fortunately, such Python code is quite rare since raising OSError or IOError with an errno value normally happens when interfacing with system calls, which is usually done in C extensions. If there is popular demand, the subroutine choosing an exception type based on the errno value could be exposed for use in pure Python. Possible objections =================== Namespace pollution ------------------- Making the exception hierarchy finer-grained makes the root (or builtins) namespace larger. This is to be moderated, however, as: * only a handful of additional classes are proposed; * while standard exception types live in the root namespace, they are visually distinguished by the fact that they use the CamelCase convention, while almost all other builtins use lowercase naming (except True, False, None, Ellipsis and NotImplemented) An alternative would be to provide a separate module containing the finer-grained exceptions, but that would defeat the purpose of encouraging careful code over careless code, since the user would first have to import the new module instead of using names already accessible. Earlier discussion ================== While this is the first time such as formal proposal is made, the idea has received informal support in the past [1]_; both the introduction of finer-grained exception classes and the coalescing of OSError and IOError. The removal of WindowsError alone has been discussed and rejected as part of another PEP [2]_, but there seemed to be a consensus that the distinction with OSError wasn't meaningful. This supports at least its aliasing with OSError. Moratorium ========== The moratorium in effect on language builtins means this PEP has little chance to be accepted for Python 3.2. Possible alternative ==================== Pattern matching ---------------- Another possibility would be to introduce an advanced pattern matching syntax when catching exceptions. For example:: try: os.remove(filename) except OSError as e if e.errno == errno.ENOENT: pass Several problems with this proposal: * it introduces new syntax, which is perceived by the author to be a heavier change compared to reworking the exception hierarchy * it doesn't decrease typing effort significantly * it doesn't relieve the programmer from the burden of having to remember errno mnemonics Exceptions ignored by this PEP ============================== This PEP ignores ``EOFError``, which signals a truncated input stream in various protocol and file format implementations (for example ``GzipFile``). ``EOFError`` is not OS- or IO-related, it is a logical error raised at a higher level. This PEP also ignores ``SSLError``, which is raised by the ``ssl`` module in order to propagate errors signalled by the ``OpenSSL`` library. Ideally, ``SSLError`` would benefit from a similar but separate treatment since it defines its own constants for error types (``ssl.SSL_ERROR_WANT_READ``, etc.). Appendix A: Survey of common errnos =================================== This is a quick recension of the various errno mnemonics checked for in the standard library and its tests, as part of ``except`` clauses. Common errnos with OSError -------------------------- * ``EBADF``: bad file descriptor (usually means the file descriptor was closed) * ``EEXIST``: file or directory exists * ``EINTR``: interrupted function call * ``EISDIR``: is a directory * ``ENOTDIR``: not a directory * ``ENOENT``: no such file or directory * ``EOPNOTSUPP``: operation not supported on socket (possible confusion with the existing io.UnsupportedOperation) * ``EPERM``: operation not permitted (when using e.g. os.setuid()) Common errnos with IOError -------------------------- * ``EACCES``: permission denied (for filesystem operations) * ``EBADF``: bad file descriptor (with select.epoll); read operation on a write-only GzipFile, or vice-versa * ``EBUSY``: device or resource busy * ``EISDIR``: is a directory (when trying to open()) * ``ENODEV``: no such device * ``ENOENT``: no such file or directory (when trying to open()) * ``ETIMEDOUT``: connection timed out Common errnos with socket.error ------------------------------- All these errors may also be associated with a plain IOError, for example when calling read() on a socket's file descriptor. * ``EAGAIN``: resource temporarily unavailable (during a non-blocking socket call except connect()) * ``EALREADY``: connection already in progress (during a non-blocking connect()) * ``EINPROGRESS``: operation in progress (during a non-blocking connect()) * ``EINTR``: interrupted function call * ``EISCONN``: the socket is connected * ``ECONNABORTED``: connection aborted by peer (during an accept() call) * ``ECONNREFUSED``: connection refused by peer * ``ECONNRESET``: connection reset by peer * ``ENOTCONN``: socket not connected * ``ESHUTDOWN``: cannot send after transport endpoint shutdown * ``EWOULDBLOCK``: same reasons as ``EAGAIN`` Common errnos with select.error ------------------------------- * ``EINTR``: interrupted function call Appendix B: Survey of raised OS and IO errors ============================================= Interpreter core ---------------- Handling of PYTHONSTARTUP raises IOError (but the error gets discarded):: $ PYTHONSTARTUP=foox ./python Python 3.2a0 (py3k:82920M, Jul 16 2010, 22:53:23) [GCC 4.4.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. Could not open PYTHONSTARTUP IOError: [Errno 2] No such file or directory: 'foox' ``PyObject_Print()`` raises IOError when ferror() signals an error on the `FILE *` parameter (which, in the source tree, is always either stdout or stderr). Unicode encoding and decoding using the ``mbcs`` encoding can raise WindowsError for some error conditions. Standard library ---------------- bz2 ''' Raises IOError throughout (OSError is unused):: >>> bz2.BZ2File("foox", "rb") Traceback (most recent call last): File "<stdin>", line 1, in <module> IOError: [Errno 2] No such file or directory >>> bz2.BZ2File("LICENSE", "rb").read() Traceback (most recent call last): File "<stdin>", line 1, in <module> IOError: invalid data stream >>> bz2.BZ2File("/tmp/zzz.bz2", "wb").read() Traceback (most recent call last): File "<stdin>", line 1, in <module> IOError: file is not ready for reading curses '''''' Not examined. dbm.gnu, dbm.ndbm ''''''''''''''''' _dbm.error and _gdbm.error inherit from IOError:: >>> dbm.gnu.open("foox") Traceback (most recent call last): File "<stdin>", line 1, in <module> _gdbm.error: [Errno 2] No such file or directory fcntl ''''' Raises IOError throughout (OSError is unused). imp module '''''''''' Raises IOError for bad file descriptors:: >>> imp.load_source("foo", "foo", 123) Traceback (most recent call last): File "<stdin>", line 1, in <module> IOError: [Errno 9] Bad file descriptor io module ''''''''' Raises IOError when trying to open a directory under Unix:: >>> open("Python/", "r") Traceback (most recent call last): File "<stdin>", line 1, in <module> IOError: [Errno 21] Is a directory: 'Python/' Raises IOError or io.UnsupportedOperation (which inherits from the former) for unsupported operations:: >>> open("LICENSE").write("bar") Traceback (most recent call last): File "<stdin>", line 1, in <module> IOError: not writable >>> io.StringIO().fileno() Traceback (most recent call last): File "<stdin>", line 1, in <module> io.UnsupportedOperation: fileno >>> open("LICENSE").seek(1, 1) Traceback (most recent call last): File "<stdin>", line 1, in <module> IOError: can't do nonzero cur-relative seeks Raises either IOError or TypeError when the inferior I/O layer misbehaves (i.e. violates the API it is expected to implement). Raises IOError when the underlying OS resource becomes invalid:: >>> f = open("LICENSE") >>> os.close(f.fileno()) >>> f.read() Traceback (most recent call last): File "<stdin>", line 1, in <module> IOError: [Errno 9] Bad file descriptor ...or for implementation-specific optimizations:: >>> f = open("LICENSE") >>> next(f) 'A. HISTORY OF THE SOFTWARE\n' >>> f.tell() Traceback (most recent call last): File "<stdin>", line 1, in <module> IOError: telling position disabled by next() call Raises BlockingIOError (inheriting from IOError) when a call on a non-blocking object would block. mmap '''' Undex Unix, raises its own ``mmap.error`` (inheriting from EnvironmentError) throughout:: >>> mmap.mmap(123, 10) Traceback (most recent call last): File "<stdin>", line 1, in <module> mmap.error: [Errno 9] Bad file descriptor >>> mmap.mmap(os.open("/tmp", os.O_RDONLY), 10) Traceback (most recent call last): File "<stdin>", line 1, in <module> mmap.error: [Errno 13] Permission denied Under Windows, however, it mostly raises WindowsError (the source code also shows a few occurrences of ``mmap.error``):: >>> fd = os.open("LICENSE", os.O_RDONLY) >>> m = mmap.mmap(fd, 16384) Traceback (most recent call last): File "<stdin>", line 1, in <module> WindowsError: [Error 5] Accès refusé >>> sys.last_value.errno 13 >>> errno.errorcode[13] 'EACCES' >>> m = mmap.mmap(-1, 4096) >>> m.resize(16384) Traceback (most recent call last): File "<stdin>", line 1, in <module> WindowsError: [Error 87] Paramètre incorrect >>> sys.last_value.errno 22 >>> errno.errorcode[22] 'EINVAL' multiprocessing ''''''''''''''' Not examined. os / posix '''''''''' The ``os`` (or ``posix``) module raises OSError throughout, except under Windows where WindosError can be raised instead. ossaudiodev ''''''''''' Raises IOError throughout (OSError is unused):: >>> ossaudiodev.open("foo", "r") Traceback (most recent call last): File "<stdin>", line 1, in <module> IOError: [Errno 2] No such file or directory: 'foo' readline '''''''' Raises IOError in various file-handling functions:: >>> readline.read_history_file("foo") Traceback (most recent call last): File "<stdin>", line 1, in <module> IOError: [Errno 2] No such file or directory >>> readline.read_init_file("foo") Traceback (most recent call last): File "<stdin>", line 1, in <module> IOError: [Errno 2] No such file or directory >>> readline.write_history_file("/dev/nonexistent") Traceback (most recent call last): File "<stdin>", line 1, in <module> IOError: [Errno 13] Permission denied select '''''' * select() and poll objects raise ``select.error``, which doesn't inherit from anything (but poll.modify() raises IOError); * epoll objects raise IOError; * kqueue objects raise both OSError and IOError. signal '''''' ``signal.ItimerError`` inherits from IOError. socket '''''' ``socket.error`` inherits from IOError. sys ''' ``sys.getwindowsversion()`` raises WindowsError with a bogus error number if the ``GetVersionEx()`` call fails. time '''' Raises IOError for internal errors in time.time() and time.sleep(). zipimport ''''''''' zipimporter.get_data() can raise IOError. References ========== .. [1] "IO module precisions and exception hierarchy" http://mail.python.org/pipermail/python-dev/2009-September/092130.html .. [2] Discussion of "Removing WindowsError" in PEP 348 http://www.python.org/dev/peps/pep-0348/#removing-windowserror Copyright ========= This document has been placed in the public domain. .. Local Variables: mode: indented-text indent-tabs-mode: nil sentence-end-double-space: t fill-column: 70 coding: utf-8 End: [View Less]

11 15

str.split with empty separator
by Alexandre Conrad July 30, 2010

July 30, 2010

Hello all, What if str.split could take an empty separator? >>> 'banana'.split('') ['b', 'a', 'n', 'a', 'n', 'a'] I know this can be done with: >>> list('banana') ['b', 'a', 'n', 'a', 'n', 'a'] I think that, semantically speaking, it would make sens to split where there are no characters (in between them). Right now you can join from an empty string: ''.join(['b', 'a', 'n', 'a', 'n', 'a']) So why can't we split from an empty string? This wouldn't introduce any … [View More]

4 7

Help!!please
by Barend erasmus July 30, 2010

July 30, 2010

Can someone help me and tell why this does not work. prys=0 tp=0 pr=0 f = open('C:\Documents and Settings\ZU1TN\Desktop\Nommers\K55.txt', 'r') pr=f.readline() prys =int(prys) tp =int(tp) pr =int(pr) tp=pr-prys f.close tp=str(tp) print tp raw_input() THX

2 1

Non-boolean return from __contains__
by Alex Gaynor July 29, 2010

July 29, 2010

Recently I've been wondering why __contains__ casts all of it's returns to be boolean values. Specifically I'd like to propose that __contains__'s return values be passed directly back as the result of the `in` operation. As a result I'd further propose the introduction of __not_contains__, which is the `not in` operator. The primary usecase for this is something like an expression recorder. For example in SQLAlchemy one can do: User.id == 3, but not User.id in SQLList([1, 2, 3]), because … [View More]

19 50

PEP 380 alternative: A yielding function
by Anders J. Munch July 29, 2010

July 29, 2010

Looking at PEP 380 (http://www.python.org/dev/peps/pep-0380/), the need for yield forwarding syntax comes from the inability to delegate yielding functionality in the usual way. For example, if you have a recurring pattern including yields, like this (this is a toy example, please don't take it for more than that): if a: yield a if b: yield b you cannot do the extract function refactoring in the usual way: def yield_if_true(x): if x: yield x … [View More]yield_if_true(a) yield_if_true(b) because yield_if_true would become a generator. PEP 380 addresses this by making the workaround - "for x in yield_if_true(a): yield x" - easier to write. But suppose you could address the source instead? Suppose you could write yield_if_true in such a way that it did not become a generator despite yielding? Syntactically this could be done with a yielding *function* in addition to the yield statement/expression, either as a builtin or a function in the sys module. Let's call it 'yield_' , for lack of a better name. The function would yield the nearest generator on the call stack. Now the example would work with a slight modifiction: def yield_if_true(x): if x: yield_(x) yield_if_true(a) yield_if_true(b) The real benefits from a yield_ function come with recursive functions. A recursive tree traversal that yields from the leaf nodes currently suffers from a performance penalty: Every yield is repeated as many times as the depth of the tree, turning a O(n) traversal algorithm into an O(n lg(n)) algorithm. PEP 380 does not change that. But a yield_ function could be O(1), regardless of the forwarding depth. To be fair, a clever implementation might be able to short-circuit a 'yield from' chain and achieve the same thing. Two main drawbacks of yield_: - Difficulty of implementation. Generators would need to keep an entire stack branch alive, instead of merely a single frame, and if that somehow affects the efficiency of simple generators, that would be bad. - 'the nearest generator on the call stack' is sort of a dynamic scoping thing, which has its problems. For example, if you forget to make the relevant function a generator (the "if 0: yield None" trick might have been needed but was forgotten), then the yield would trickle up to some random generator higher up, with confusing results. And if you use yield_ in a callback, well, let's just say that an interesting case too. All the same, if a yield_ function is practical, I think it is a better way to address the problems that motivate PEP 380. I'm guessing you could implement 'yield from' as a pure-Python function using yield_, making yield_ strictly more powerful, although I couldn't say for sure as I haven't studied the enhanced generator protocol. regards, Anders [View Less]

5 11

Distutils setup.py & per user site packages
by Mark Summerfield July 29, 2010

July 29, 2010

Hi, I have downloaded a package from PyPI that uses distutils setup.py. When I run it with -h it shows options for building and installing, but does not appear to have an option for installation in my per user site packages directory (see PEP 370). I think it would be useful to add a "--local" option to setup.py that would install into the per site package directory. This would allow people to keep their Linux distros pristine while still being able to install packages that their distros don'… [View More]

2 1

Counter
by Barend erasmus July 28, 2010

July 28, 2010

Hi made a counter that count till 1 000 000 000.How long will it take to get there when there is no delay. Thx Ben

3 2

Re: [Python-ideas] Readability of hex strings (Was: Use of coding cookie in 3.x stdlib)
by Nick Coghlan July 28, 2010

July 28, 2010

(another attempt at getting this discussion over on python-ideas where it belongs) On Tue, Jul 27, 2010 at 10:12 AM, Steven D'Aprano <steve(a)pearwood.info> wrote: > Since it only takes a pair of small helper functions to convert hex > dumps in the form "XXXX XXXX ..." to and from byte strings, I don't see > the need for new syntax and would vote -1 on the idea. However, I'd > vote +0 on a matching bytes.tohex() method to partner with the existing > bytes.fromhex(). … [View More]

1 0

Re: [Python-ideas] [Python-Dev] Set the namespace free!
by Stephen J. Turnbull July 27, 2010

July 27, 2010

Georg Brandl writes: > Am 26.07.2010 10:59, schrieb Anders Sandvig: > > On Sat, Jul 24, 2010 at 3:31 AM, Gregory P. Smith <greg(a)krypto.org> wrote: > >> Yuck. Anyone who feels they need a variable named the same a reserved word > >> simply feels wrong and needs reeducation. [...] > > > > While I agree with you in principle, I have been finding it > > frustrating trying to calculate yield in my financial applications > > lately.… [View More]

1 0

Re: [Python-ideas] [Python-Dev] Readability of hex strings (Was: Use of coding cookie in 3.x stdlib)
by Alexandre Vassalotti July 26, 2010

July 26, 2010

[+Python-ideas -Python-Dev] import binascii def h(s): return binascii.unhexlify("".join(s.split())) h("DE AD BE EF CA FE BA BE") -- Alexandre On Mon, Jul 26, 2010 at 11:29 AM, anatoly techtonik <techtonik(a)gmail.com> wrote: > I find "\xXX\xXX\xXX\xXX..." notation for binary data totally > unreadable. Everybody who uses and analyses binary data is more > familiar with plain hex dumps in the form of "XX XX XX XX...". > > I wonder if it is possible to introduce an … [View More]effective binary string > type that will be represented as h"XX XX XX" in language syntax? It > will be much easier to analyze printed binary data and copy/paste such > data as-is from hex editors/views. > > On Mon, Jul 19, 2010 at 9:45 AM, Guido van Rossum <guido(a)python.org> wrote: >> Sounds like a good idea to try to remove redundant cookies *and* to >> remove most occasional use of non-ASCII characters outside comments >> (except for unittests specifically trying to test Unicode features). >> Personally I would use \xXX escapes instead of spelling out the >> characters in shlex.py, for example. >> >> Both with or without the coding cookies, many ways of displaying text >> files garble characters outside the ASCII range, so it's better to >> stick to ASCII as much as possible. >> >> --Guido >> >> On Mon, Jul 19, 2010 at 1:21 AM, Alexander Belopolsky >> <alexander.belopolsky(a)gmail.com> wrote: >>> I was looking at the inspect module and noticed that it's source >>> starts with "# -*- coding: iso-8859-1 -*-". I have checked and there >>> are no non-ascii characters in the file. There are several other >>> modules that still use the cookie: >>> >>> Lib/ast.py:# -*- coding: utf-8 -*- >>> Lib/getopt.py:# -*- coding: utf-8 -*- >>> Lib/inspect.py:# -*- coding: iso-8859-1 -*- >>> Lib/pydoc.py:# -*- coding: latin-1 -*- >>> Lib/shlex.py:# -*- coding: iso-8859-1 -*- >>> Lib/encodings/punycode.py:# -*- coding: utf-8 -*- >>> Lib/msilib/__init__.py:# -*- coding: utf-8 -*- >>> Lib/sqlite3/__init__.py:#-*- coding: ISO-8859-1 -*- >>> Lib/sqlite3/dbapi2.py:#-*- coding: ISO-8859-1 -*- >>> Lib/test/bad_coding.py:# -*- coding: uft-8 -*- >>> Lib/test/badsyntax_3131.py:# -*- coding: utf-8 -*- >>> >>> I understand that coding: utf-8 is strictly redundant in 3.x. There >>> are cases such as Lib/shlex.py where using encoding other than utf-8 >>> is justified. (See >>> http://svn.python.org/view?view=rev&revision=82560). What are the >>> guidelines for other cases? Should redundant cookies be removed? >>> Since not all editors respect the -*- cookie, I think the answer >>> should be "yes" particularly when the cookie is setting encoding other >>> than utf-8. >>> _______________________________________________ >>> Python-Dev mailing list >>> Python-Dev(a)python.org >>> http://mail.python.org/mailman/listinfo/python-dev >>> Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org >>> >> >> >> >> -- >> --Guido van Rossum (python.org/~guido) >> _______________________________________________ >> Python-Dev mailing list >> Python-Dev(a)python.org >> http://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: http://mail.python.org/mailman/options/python-dev/techtonik%40gmail.com >> > _______________________________________________ > Python-Dev mailing list > Python-Dev(a)python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/alexandre%40peadrop.com > [View Less]

1 0

Re: [Python-ideas] Non-boolean return from __contains__
by Bruce Leban July 25, 2010

July 25, 2010

Let me see if I understand this: False in [False] Returns True now but would return False with your change. --- Bruce (via android) On Jul 25, 2010 11:15 AM, "Alex Gaynor" <alex.gaynor(a)gmail.com> wrote: Recently I've been wondering why __contains__ casts all of it's returns to be boolean values. Specifically I'd like to propose that __contains__'s return values be passed directly back as the result of the `in` operation. As a result I'd further propose the introduction of … [View More]

5 5

Re: [Python-ideas] [Python-Dev] Set the namespace free!
by Gregory P. Smith July 25, 2010

July 25, 2010

On Thu, Jul 22, 2010 at 9:24 AM, <gregory.smith3(a)sympatico.ca> wrote: > I agree with the idea, but a far less radical change is needed to get the > desired result. > The basic idea is this: it should be possible to use any name as an > identifier in the syntax, including names > like 'while' and 'import'. But there is no need to mess up the entire > language to allow this > (either by quoting all the identifiers, perl-style, or by marking the > keywords). > … [View More]Yuck. Anyone who feels they need a variable named the same a reserved word simply feels wrong and needs reeducation. New words are introduced very rarely and we do care about the ramifications when we do it. What next? An optional way to support case insensitive names using a unicode character prefix? -gps > > All that is needed is something like this: > > foo = 7 > :foo = 7 # exactly like foo=7 > :while= 3 # assigns 3 to variable 'while' > globals()['while']=3 # current way to do this > > print element.:for # from example below > # > # keyword parameters to a function call: > # > BuildUrlQuery( lang='en', item='monsoon', :class='normal') # -> > "?lang=en&query=monsoon&class=normal" > > > The generic keyword function call is a really nice language feature, but > it's rather impaired by the need to avoid > those names which happen to be keywords. > > The lack of this is most painful when you are auto-generating python code > which forms a bridge to another language with its own > namespace (as in XML example). It's a pain when some of the names you might > generate could conflict with python keywords. > So, you end up using dicts and getattrs for everything and the code gets > much less readable. With a simple escape like :name available, > it's worthwhile to do everything with identifiers and generate the escape > only as needed for these. > > > One of the great strengths of python is the ability to form cleans and > comprehensive bridges to other languages and environments (thus, > in many cases, avoiding the need to write programs in those other > environments :-) ). This feature would fill a gap there. > > The python tcl/tk interface is a bit messed up since tcl/tk uses some names > for options which conflict with python keywords, > and so you need to add '_' to those names. > > There is a feature like this in VHDL: \name\ and \while\ are identifiers, > the backslashes are not part of the name, but just > quote it. In VHDL you can write identifiers like \22\, and > \!This?is=Strange\ as well; since VHDL creates modules that > have named ports, and those modules can interface to things generated by > other environments, they needed a > way to assign any name to a port. > > For python, I'm not sure it makes sense to allow identifiers that doesn't > follow the basic rule "[A-Za-z_][A-Za-z_0-9]*" -- that could > break some debugging tools which expect variable names to be well-formed -- > but it would be useful > to be able to use any well-formed name as an identifier, including those > which happen to be keywords. > > I've suggested :name, which doesn't break old code, and doesn't require > using any new punctuation. Syntax would not change, > just the lexical definition of 'identifier'. If the intent is to allow > arbitrary names (not just well-formed ones), then n'name' would > work better (and is consistent with existing stuff). > > > > > Date: Thu, 22 Jul 2010 10:41:39 -0400 > > From: jnoller(a)gmail.com > > To: bartosz-tarnowski(a)zlotniki.pl > > CC: python-dev(a)python.org > > Subject: Re: [Python-Dev] Set the namespace free! > > > > > On Thu, Jul 22, 2010 at 10:04 AM, Bartosz Tarnowski > > <bartosz-tarnowski(a)zlotniki.pl> wrote: > > > > > > Hello, guys. > > > > > > Python has more and more reserved words over time. It becomes quite > > > annoying, since you can not use variables and attributes of such names. > > > Suppose I want to make an XML parser that reads a document and returns > an > > > object with attributes corresponding to XML element attributes: > > > > > >> elem = parse_xml("<element param='boo'/>") > > >> print elem.param > > > boo > > > > > > What should I do then, when the attribute is a reserver word? I could > use > > > trailing underscore, but this is quite ugly and introduces ambiguity. > > > > > >> elem = parse_xml("<element for='each'/>") > > >> print elem.for_ #????? > > >> elem = parse_xml("<element for_='each'/>") > > >> print elem.for__ #????? > > > > > > My proposal: let's make a syntax change. > > > > > > Let all reserved words be preceded with some symbol, i.e. "!" > (exclamation > > > mark). This goes also for standard library global identifiers. > > > > > > !for boo in foo: > > > !if boo is !None: > > > !print(hoo) > > > !else: > > > !return !sorted(woo) > > > > > > > > > This would allow the user to declare any identifier with any name: > > > > > > for = with(return) + try > > > > > > What do you think of it? It is a major change, but I think Python needs > it. > > > > > > -- > > > haael > > > > > > > I'm not a fan of this - I'd much prefer[1] that we use the exclamation > > point to determine scope: > > > > foobar - local > > !foobar - one up > > !!foobar - higher than the last one > > !!!foobar - even higher in scope > > > > We could do the inverse as well; if you append ! you can push variable > > down in scope. > > > > Jesse > > > > > > [1] I am not serious. > > _______________________________________________ > > Python-Dev mailing list > > Python-Dev(a)python.org > > http://mail.python.org/mailman/listinfo/python-dev > > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/gsmith%40alumni.uwaterloo… > > _______________________________________________ > Python-Dev mailing list > Python-Dev(a)python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/greg%40krypto.org > > [View Less]

7 7

Mont-E technical details, PEP 380, Monocle
by Laurens Van Houtven July 24, 2010

July 24, 2010

Hi! The people who attended EuroPython might remember my lightning talk about Mont-E. I wanted to go into more technical detail, but as I said in the talk it was very early days, and I was unable to get a reliable enough internet connection near the talk to really know what was done and what wasn't in detail (and I didn't want to lie about features that did and did not work). For those who haven't: it's a set of patches on top of Py3k that tries to introduce some of the ideas of E (a … [View More]programming language) into Python. I just read Guido's python-dev post and I was listening in on the discussion after Raymond's talk, and I agree with pretty much everything what was said in both cases. The most important part is PEP 380 expressing a great idea; which is pretty much done and ready for real use, I think the best proof of that is that people have already tried to solve it and the solutions people come up with are quite similar (except that one is specifically tuned towards subgenerators and the other isn't): Twisted's returnValue and Mont-E's return-from-a-generator. The latter looks like this: def port_scan(hostname): ip = defer gethostbyname(hostname) ports = set() for port in range(65536): if (defer is_port_connectable(ip, port)): ports.add(port) return ports (Except that uses E-style promises + resolvers, instead of Twisted and Monocle style deferreds.) I'm not suggesting Mont-E's syntax makes it in favor of anything else, like I mentioned in the talk we really just wanted an excuse to mess with the grammar (the official excuse is "we wanted to see what we could do given the power to do anything including mangling half the stdlib and grammar" ;-)). port_scan(spam) would return a promise, not a generator. Like @inlineCallbacks, the goal of yield/defer is to basically say "oh, okay, you can do other stuff now, just call me back as soon as this thing is done". The value of the promise is the returned value. I think in its core this is analogous to PEP380, except that this takes it a step further and applies it to callbacks/deferreds (well, callbacks/promises+resolvers, technically, but I say deferreds because it's close enough and people are familiar with them). I think stuff like Monocle is a great idea because it introduces portability for async code. I like Twisted and I will continue writing Twisted stuff regardless, but I would much rather write asyncOAuth which everyone can use than txOAuth which only Twisted users could use. I think Monocle shows how these two things are related. How do people feel about a portable-async-code story for the stdlib? Mont-E tries to do this in ways that will be... ahum... let's say "hard" to get into the stdlib: by introducing promises, resolvers, event loops, interfaces... I also agree that CSP is a good model; I prefer actor for most of the stuff I end up writing; but there are definitely cases (for my stuff this tends to be about numerical computation) where CSP rocks. But the stdlib already has multiprocessing, maybe it's time we started looking at other stuff :-) thanks in advance for your input Laurens [View Less]

1 0

'where' statement in Python?
by Sergio Davis July 24, 2010

July 24, 2010

Dear members of the python-ideas mailing list, I'm not quite sure if this is the right place to ask for feedback about the idea, I apologize if this is not the case. I'm considering the following extension to Python's grammar: adding the 'where' keyword, which would work as follows: where_expr : expr 'where' NAME '=' expr The idea is to be able to write something like: a = (z**2+5) where z=2 being equivalent to (current Python syntax): a = (lambda z: z**2+5)(z=2) I thinkg this would be … [View More]

26 66

String interpolation again.
by INADA Naoki July 23, 2010

July 23, 2010

Hi, all. Below code is syntax error now: foo = 123 x = 'foo' foo 'bar' I wonder if that code is interpreted as: x = 'foo' + str(foo) + 'bar' or x = 'foo%sbar' % (foo,) I think this syntax sugar doesn't import any compatibility problem and simple enough for Python. What do you think about it? -- INADA Naoki <songofacandy(a)gmail.com>

8 17

Re: [Python-ideas] [Python-Ideas] Set the namespace free!
by Nick Coghlan July 23, 2010

July 23, 2010

(moving to python-ideas, where this discussion belongs) On Fri, Jul 23, 2010 at 7:01 AM, <gregory.smith3(a)sympatico.ca> wrote: > > >> Date: Thu, 22 Jul 2010 14:49:17 -0400 >> Subject: Re: [Python-Dev] Set the namespace free! >> From: alexander.belopolsky(a)gmail.com >> To: gregory.smith3(a)sympatico.ca >> CC: python-dev(a)python.org >> >> On Thu, Jul 22, 2010 at 12:53 PM, <gregory.smith3(a)sympatico.ca> wrote: >> .. >> &… [View More]gt; So, ::name or &name or |name or whatever. >> > >> > I'm very amused by all the jokes about turning python into perl, but >> > there's >> > a good idea here that doesn't actually require that... >> >> No, there isn't. And both '&' and '|' are valid python operators that >> cannot be used this way. >> > > Um, of course. Serious brain freeze today, using too many languages at once. > Yeah, that's it. > > Despite my knuckleheadedness, I say there's still a hole here that can be > easily plugged. it's clumsy that you can't call, e.g. > > GenerateURL( reqtype='basic', class='local') > > other than by > > GenerateURL( **{'reqtype': 'basic', 'class': 'local'}) > > ... just because 'class' is a keyword. That's letting a parser issue > degrade the value of a really good feature. Likewise for attributes; python > allows you to have > named parameters or attributes called 'class' and 'import' if you like; it > just doesn't let you write them directly; this restriction doesn't seem to > be necessary except for the parse issue, which is fixable. I.e. nothing > would break by allowing GenerateURL(::class = 'local') or > Request.::class. Or, rather than making a major syntactic change that affects not just all Python implementations, but also every syntax highlighter that understands the set of reserved words, we instead encourage external interface developers to implement three simple rules: 1. If a name coming from an external resource clashes with a Python keyword, append a single underscore 2. If a name coming from an external resource ends with an underscore, append an additional underscore 3. If a name being written to or otherwise used to access an external resource ends with an underscore, remove it The above example would then be written as: GenerateURL( reqtype='basic', class_='local') Why should the entire language toolset be burdened with additional syntax in order to deal with an issue that could be handled perfectly well by the adoption of some simple API conventions? Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia [View Less]

1 0

Re: [Python-ideas] 'where' statement in Python?
by geremy condra July 22, 2010

July 22, 2010

On Thu, Jul 22, 2010 at 3:55 PM, Terry Reedy <tjreedy(a)udel.edu> wrote: > > > On 7/22/2010 4:38 AM, geremy condra wrote: >> >> On Wed, Jul 21, 2010 at 9:21 PM, Terry Reedy<tjreedy(a)udel.edu> wrote: > >>> e = fe(a,b,c, p1) where: >>> c = fc(a, d, p2 where: >>> d = fd(a, p1) where: >>> a = fa(p1, p2) >>> b = fb(a,p2) >>> >>> where p1,p2 are input … [View More]

4 3

Infix application of binary functions
by Dag Odenhall July 22, 2010

July 22, 2010

It could help readability if binary (arity of 2) functions could be applied infix with some syntax. For example, borrowing from Haskell, the backtick could be reintroduced for this purpose. Good examples for this are isinstance and hasattr: if some_object `isinstance` Iterable: ... elif some_object `hasattr` '__iter__': ... It is already possible[1] to make infix functions, but the solution is a hack and requires functions to be marked as infix. (The use of backticks … [View More]

5 10

Add faster locks to the threading module?
by Sturla Molden July 21, 2010

July 21, 2010

Thread synchronization with threading.Lock can be expensive. But consider this: Why should the active thread need to aquire a mutex, when it already holds one? That would be the GIL. Instead of acqiring a lock (and possibly inducing thread swiching etc.), it could just deny the other threads access to the GIL for a while. The cost of that synchronization method would be completely amortized, as check intervals happen anyway. Here is what a very naïve implementation would look like in … [View More]

4 10

fancy indexing
by Bruce Leban July 21, 2010

July 21, 2010

[changing the subject; was: 'where' statement in Python?] I think this is an interesting idea (whether worth adding is a different question). I think it would be confusing that a[x] = (y,z) does something entirely different when x is 1 or (1,2). If python *were* to add something like this, I think perhaps a different syntax should be considered: a[[x]] = y y = a[[x]] which call __setitems__ and __getitems__ respectively. This makes it clear that something different is going on and … [View More]eliminates the ambiguity for dicts. --- Bruce http://www.vroospeak.com http://google-gruyere.appspot.com On Tue, Jul 20, 2010 at 10:18 AM, Sturla Molden <sturla(a)molden.no> wrote: > So I'd rather speak of something useful instead: NumPy's "Fancy indexing". > > "Fancy indexing" (NumPy jargon) will in this context mean that we allow > indexes to be an iterable, not just integers: > > mylist[(1,2,3)] == mylist[1,2,3] > mylist[iterable] == [a(i) for i in iterable] > > That is what NumPy and Matlab do, as well as Fortran 90 (and certain C++ > libraries such as Blitz++). It has all the power of the "where keyword", > while being more flexible to use, and intention is more explicit. It is also > well tested syntax. > > Thus with "fancy indexing": > > alist[iterable] == [alist[i] for i in iterable] > > That is what we really need! > > Note that this is not a language syntax change, it is just a change of how > __setitem__ and __getitem__ works for certain container types. NumPy already > does this, so the syntax itself is completely valid Python. And as for > "where", it is just a function. > > Andrey's proposed where keyword is a crippled tool in comparison. That is, > the real power of a list of indexers is that it can be obtained and > manipulated with any conceivable method, e.g. slicing. It also allows numpy > to have an "argsort" function, since an index list can be reused on multiple > arrays: > > idx = np.argsort(array_a) > sorteda = array_a[idx] > sortedb = array_b[idx] > > is the same as > > tmp = sorted([a,i for i,a in enumerate(lista)]) > sorteda = [a for a,i in tmp] > sortedb = [listb[i] for a,i in tmp] > > Which is the more readable? > > Implementing a generic "where function" can be achieved with a lambda: > > idx = where(lambda x: x== 47, alist) > > or a list comprehension (this would be very similar to NumPy): > > idx = where([x==47 for x in alist]) > > But to begin with, I think we should get NumPy style "fancy indexing" to > standard container types like list, tuple, string, bytes, bytearray, array > and deque. That would just be a handful of subclasses, and I think they > should (initially) be put in a standard library module, and possibly replace > the current cointainers in Python 4000. > > But as for a where keyword: My opinion is a big -1, if I have the right to > vote. We should rather implement a where function and overload the mentioned > container types. The where function should go in the same module. > > So all in all, I am +1 for a "where module" and -1 for a "where keyword". > > P.S. I'll admit that dict and set might add to some confusion, since "fancy > indexing" would be ambigous for them. > > Regards, > Sturla > > _______________________________________________ > Python-ideas mailing list > Python-ideas(a)python.org > http://mail.python.org/mailman/listinfo/python-ideas > [View Less]

5 7

Re: [Python-ideas] 'where' statement in Python?
by Alex Light July 20, 2010

July 20, 2010

MRAB wrote: > > Why use 'as'? Why not: > i would use as because this whole where clause acts very similarly to a context manager in that it sets a variable to a value for a small block > c = a + b with: > get_a(), get_b() as a, b > is equivilent to > with get_a(), get_b() as a, b: > c = a + b > assuming get_a() and get_b() are context manager that return the values of a and b and then delete them at the end > the thing with this though it that the … [View More]get_a() and get_b() do not need to be context managers the interpreter will create one so this will be valid: > c = a**2 with: > 4 as a > i.e. it creates a context manager whose __enter__ method returns 4 and whose exit method deletes a from the current namespace > strula moldan wrote: >That will not work, the parser would think like this: > >c = sqrt(a*a + b*b) with: > get_a(), (get_b() as a), b sorry haven't used 'as' in a while and i forgot that you could not use it like you can everything else in compound assignments (BTW why isn't a, b as c, d allowed it makes sense especially since a, b = c, d is allowed it should be changed so it does) >>c = sqrt(a*a + b*b) with: >> get_a() as a >> get_b() as b > > >I think it tastes too much like functional programming. Specifically: > >It forces you to think backwards: it does not evaluate the lines in the order they read. i think you miss the point which is understandable considering such a short example but consider if there are many many steps used to arrive at the variable. you can give it a simple, descriptive name and nobody needs to see how you got it unless they want to. or a situation where you have many many variables in the with statement and it is possible to understand from their names what they represent. i.e. sea = water() with (get_temperature(sea) as temp, get_depth(sea) as depth, get_purity(sea) as purity, get_salinity(sea) as saltiness, get_size(sea) as size #etc for a few more lines get_density(sea) as density): sea_num = temp**depth + purity - salinity * size - density # one line only is much harder to understand than simply sea_num = temp**depth + purity - salinity * size - density with: # one line only get_temperature(sea) as temp, get_depth(sea) as depth, get_purity(sea) as purity, get_salinity(sea) as saltiness, get_size(sea) as size #etc for a few more lines get_density(sea) as density the meaning of all the words is obvious (assuming you know that sea_num has to do with the sea and water) and since it is you do not really need to have all that clutter up above and can just put it below > On Tue, Jul 20, 2010 at 3:15 PM, MRAB <python(a)mrabarnett.plus.com> wrote: > Alex Light wrote: > >> i would suggest overloading the 'with', 'as' combo >> >>> >> c = sqrt(a*a + b*b) with: >> >>> get_a(), get_b() as a, b >> >>> >> or >> >>> >> >> c = sqrt(a*a + b*b) with: >> >>> get_a() as a >> >>> get_b() as b >> >> Why use 'as'? Why not: > >> > > c = sqrt(a*a + b*b) with: > >> a = get_a() > >> b = get_b() > >> > which is like: > >> > def _(): > >> a = get_a() > >> b = get_b() > >> > return sqrt(a*a + b*b) > >> > c = _() > >> del _ > >> > >> it reads well and plus it follows since this statement acts similarly to a >> regular with and as statement with the behavior of the context manager being >> (in psudocode): set up: store original value of variable if any and set >> variable to new value. >> >>> tear down: set value back to original or delete from local namespace if >> it never had one >> >>> >> additionally we do not need to introduce any new keywords >> >>> >> any way that this is implemented though it would be quite useful >> >>> >> On Tue, Jul 20, 2010 at 2:35 PM, George Sakkis <george.sakkis(a)gmail.com<mailto: >> george.sakkis(a)gmail.com>> wrote: >> >>> >> On Tue, Jul 20, 2010 at 8:29 PM, Daniel Stutzbach >> >>> <daniel(a)stutzbachenterprises.com >> >>> <mailto:daniel@stutzbachenterprises.com>> wrote: >> >>> >> > On Tue, Jul 20, 2010 at 1:16 PM, Guido van Rossum >> >>> <guido(a)python.org <mailto:guido@python.org>> wrote: >> >>> >> >> >>> >> Given the large number of Python users familiar with SQL compared >> to >> >>> >> those familiar with Haskell, I think we'd do wise to pick a >> >>> different >> >>> >> keyword instead of 'where'. I can't think of one right now though. >> >>> > >> >>> > Taking a cue from mathematics, how about "given"? >> >>> > >> >>> > c = sqrt(a*a + b*b) given: >> >>> > a = retrieve_a() >> >>> > b = retrieve_b() >> >>> >> Or if we'd rather overload an existing keyword than add a new one, >> >>> "with" reads well too. >> >> _______________________________________________ > >> Python-ideas mailing list > >> Python-ideas(a)python.org > http://mail.python.org/mailman/listinfo/python-ideas > [View Less]

3 3

Re: [Python-ideas] first() and last() tests in for x in y loops
by et gmail July 20, 2010

July 20, 2010

While doing "for x in y" loops I often need to know if I'm working on the first item or the last item in the list. For example imagine you are building a list of values separated by ","s. The last iteration you need to suppress the ",". One work around is to just take the last character off during at the end, but you get the idea. I could see the code looking something like this for item in List: if __first__: print 'we are in the … [View More]

4 3