Mailman 3 January 2012 - Python-ideas

@classproperty, @abc.abstractclasspropery, etc.
by K. Richard Pixley Dec. 16, 2020

Dec. 16, 2020

There's a whole matrix of these and I'm wondering why the matrix is currently sparse rather than implementing them all. Or rather, why we can't stack them as: class foo(object): @classmethod @property def bar(cls, ...): ... Essentially the permutation are, I think: {'unadorned'|abc.abstract}{'normal'|static|class}{method|property|non-callable attribute}. concreteness implicit first arg type name comments {unadorned} {unadorned} method def foo(): exists … [View More]now {unadorned} {unadorned} property @property exists now {unadorned} {unadorned} non-callable attribute x = 2 exists now {unadorned} static method @staticmethod exists now {unadorned} static property @staticproperty proposing {unadorned} static non-callable attribute {degenerate case - variables don't have arguments} unnecessary {unadorned} class method @classmethod exists now {unadorned} class property @classproperty or @classmethod;@property proposing {unadorned} class non-callable attribute {degenerate case - variables don't have arguments} unnecessary abc.abstract {unadorned} method @abc.abstractmethod exists now abc.abstract {unadorned} property @abc.abstractproperty exists now abc.abstract {unadorned} non-callable attribute @abc.abstractattribute or @abc.abstract;@attribute proposing abc.abstract static method @abc.abstractstaticmethod exists now abc.abstract static property @abc.staticproperty proposing abc.abstract static non-callable attribute {degenerate case - variables don't have arguments} unnecessary abc.abstract class method @abc.abstractclassmethod exists now abc.abstract class property @abc.abstractclassproperty proposing abc.abstract class non-callable attribute {degenerate case - variables don't have arguments} unnecessary I think the meanings of the new ones are pretty straightforward, but in case they are not... @staticproperty - like @property only without an implicit first argument. Allows the property to be called directly from the class without requiring a throw-away instance. @classproperty - like @property, only the implicit first argument to the method is the class. Allows the property to be called directly from the class without requiring a throw-away instance. @abc.abstractattribute - a simple, non-callable variable that must be overridden in subclasses @abc.abstractstaticproperty - like @abc.abstractproperty only for @staticproperty @abc.abstractclassproperty - like @abc.abstractproperty only for @classproperty --rich [View Less]

10 15

Specify number of items to allocate for array.array() constructor
by Sven Rahmann Feb. 22, 2020

Feb. 22, 2020

At the moment, the array module of the standard library allows to create arrays of different numeric types and to initialize them from an iterable (eg, another array). What's missing is the possiblity to specify the final size of the array (number of items), especially for large arrays. I'm thinking of suffix arrays (a text indexing data structure) for large texts, eg the human genome and its reverse complement (about 6 billion characters from the alphabet ACGT). The suffix array is a long int … [View More]

14 20

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

Re: [Python-ideas] Cofunctions - Back to Basics
by Mark Shannon Oct. 21, 2012

Oct. 21, 2012

Greg Ewing wrote: > Mark Shannon wrote: > >> Why not have proper co-routines, instead of hacked-up generators? > > What do you mean by a "proper coroutine"? > A parallel, non-concurrent, thread of execution. It should be able to transfer control from arbitrary places in execution, not within generators. Stackless provides coroutines. Greenlets are also coroutines (I think). Lua has them, and is implemented in ANSI C, so it can be done portably. See: http://www.jucs.… [View More]

9 25

Cofunctions PEP - Revision 4
by Greg Ewing Oct. 13, 2012

Oct. 13, 2012

Here's an updated version of the PEP reflecting my recent suggestions on how to eliminate 'codef'. PEP: XXX Title: Cofunctions Version: $Revision$ Last-Modified: $Date$ Author: Gregory Ewing <greg.ewing(a)canterbury.ac.nz> Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 13-Feb-2009 Python-Version: 3.x Post-History: Abstract ======== A syntax is proposed for defining and calling a special type of generator called a 'cofunction'. It is designed to provide a … [View More]streamlined way of writing generator-based coroutines, and allow the early detection of certain kinds of error that are easily made when writing such code, which otherwise tend to cause hard-to-diagnose symptoms. This proposal builds on the 'yield from' mechanism described in PEP 380, and describes some of the semantics of cofunctions in terms of it. However, it would be possible to define and implement cofunctions independently of PEP 380 if so desired. Specification ============= Cofunction definitions ---------------------- A cofunction is a special kind of generator, distinguished by the presence of the keyword ``cocall`` (defined below) at least once in its body. It may also contain ``yield`` and/or ``yield from`` expressions, which behave as they do in other generators. From the outside, the distinguishing feature of a cofunction is that it cannot be called the same way as an ordinary function. An exception is raised if an ordinary call to a cofunction is attempted. Cocalls ------- Calls from one cofunction to another are made by marking the call with a new keyword ``cocall``. The expression :: cocall f(*args, **kwds) is evaluated by first checking whether the object ``f`` implements a ``__cocall__`` method. If it does, the cocall expression is equivalent to :: yield from f.__cocall__(*args, **kwds) except that the object returned by __cocall__ is expected to be an iterator, so the step of calling iter() on it is skipped. If ``f`` does not have a ``__cocall__`` method, or the ``__cocall__`` method returns ``NotImplemented``, then the cocall expression is treated as an ordinary call, and the ``__call__`` method of ``f`` is invoked. Objects which implement __cocall__ are expected to return an object obeying the iterator protocol. Cofunctions respond to __cocall__ the same way as ordinary generator functions respond to __call__, i.e. by returning a generator-iterator. Certain objects that wrap other callable objects, notably bound methods, will be given __cocall__ implementations that delegate to the underlying object. Grammar ------- The full syntax of a cocall expression is described by the following grammar lines: :: atom: cocall | <existing alternatives for atom> cocall: 'cocall' atom cotrailer* '(' [arglist] ')' cotrailer: '[' subscriptlist ']' | '.' NAME Note that this syntax allows cocalls to methods and elements of sequences or mappings to be expressed naturally. For example, the following are valid: :: y = cocall self.foo(x) y = cocall funcdict[key](x) y = cocall a.b.c[i].d(x) Also note that the final calling parentheses are mandatory, so that for example the following is invalid syntax: :: y = cocall f # INVALID New builtins, attributes and C API functions -------------------------------------------- To facilitate interfacing cofunctions with non-coroutine code, there will be a built-in function ``costart`` whose definition is equivalent to :: def costart(obj, *args, **kwds): try: m = obj.__cocall__ except AttributeError: result = NotImplemented else: result = m(*args, **kwds) if result is NotImplemented: raise TypeError("Object does not support cocall") return result There will also be a corresponding C API function :: PyObject *PyObject_CoCall(PyObject *obj, PyObject *args, PyObject *kwds) It is left unspecified for now whether a cofunction is a distinct type of object or, like a generator function, is simply a specially-marked function instance. If the latter, a read-only boolean attribute ``__iscofunction__`` should be provided to allow testing whether a given function object is a cofunction. Motivation and Rationale ======================== The ``yield from`` syntax is reasonably self-explanatory when used for the purpose of delegating part of the work of a generator to another function. It can also be used to good effect in the implementation of generator-based coroutines, but it reads somewhat awkwardly when used for that purpose, and tends to obscure the true intent of the code. Furthermore, using generators as coroutines is somewhat error-prone. If one forgets to use ``yield from`` when it should have been used, or uses it when it shouldn't have, the symptoms that result can be extremely obscure and confusing. Finally, sometimes there is a need for a function to be a coroutine even though it does not yield anything, and in these cases it is necessary to resort to kludges such as ``if 0: yield`` to force it to be a generator. The ``cocall`` construct address the first issue by making the syntax directly reflect the intent, that is, that the function being called forms part of a coroutine. The second issue is addressed by making it impossible to mix coroutine and non-coroutine code in ways that don't make sense. If the rules are violated, an exception is raised that points out exactly what and where the problem is. Lastly, the need for dummy yields is eliminated by making it possible for a cofunction to call both cofunctions and ordinary functions with the same syntax, so that an ordinary function can be used in place of a cofunction that yields zero times. Record of Discussion ==================== An earlier version of this proposal required a special keyword ``codef`` to be used in place of ``def`` when defining a cofunction, and disallowed calling an ordinary function using ``cocall``. However, it became evident that these features were not necessary, and the ``codef`` keyword was dropped in the interests of minimising the number of new keywords required. The use of a decorator instead of ``codef`` was also suggested, but the current proposal makes this unnecessary as well. It has been questioned whether some combination of decorators and functions could be used instead of a dedicated ``cocall`` syntax. While this might be possible, to achieve equivalent error-detecting power it would be necessary to write cofunction calls as something like :: yield from cocall(f)(args) making them even more verbose and inelegant than an unadorned ``yield from``. It is also not clear whether it is possible to achieve all of the benefits of the cocall syntax using this kind of approach. Prototype Implementation ======================== An implementation of an earlier version of this proposal in the form of patches to Python 3.1.2 can be found here: http://www.cosc.canterbury.ac.nz/greg.ewing/python/generators/cofunctions.h… If this version of the proposal is received favourably, the implementation will be updated to match. 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 29

Re: [Python-ideas] PEP x: Static module/package inspection
by anatoly techtonik March 29, 2012

March 29, 2012

(reposting this from Google Group once more as the previous post missed Mailing List, because I was not subscribed in Mailman) *Static module/package inspection* Abstract: - static: without execution (as opposed to dynamic) - module/package: .py or __init__.py file - inspection: get an overview of the contents *What should this do?* * * The proposal to add a mechanism to Python interpreter to get an outline of module/package contents without importing or executing module/package. The … [View More]outline includes names of classes, functions, variables. It also should contain values for variables that could be provided without sophisticated calculations (e.g. a string, integer, but probably not expressions as it may lead to security leaks). *Why?* * * *user story PEPx.001:* As a Python package maintainer, I find it bothersome to repeatedly write bolierplate code (e.g. setup.py) to package my single file module. The reason I should write setup.py is to provide version and description info. This info is already available in my module source code. So I need to either copy/paste the info from the module manually, or to import (and hence execute) my module during packaging and installation, which I don't want either, because modules are often installed with root privileges. With this PEP, packing tool will be able to extract meta information from my module without executing it or without me manually copying version fields into some 'package configuration file'. *user story PEPx.002:* As a Python Application developer, I find it really complicated to provide plugin extension subsystem for my users. Users need a mechanism to switch between different versions of the plugin, and this mechanism is usually provided by external tool such as setuptools to manage and install multiple versions of plugins in local Python package repository. It is rather hard to create an alternative approach, because you are forced to maintain external meta-data about your plugin modules even in case it is already available inside the module. With this PEP, Python Application will be able to inspect meta-data embedded inside of plugins before choosing which version to load. This will also provide a standard mechanism for applications to check modules returned by packaging tools without executing them. This will greatly simplify writing and debugging custom plugins loaders on different platforms. *Feedback goal* At this stage I'd like to a community response to two separate questions: 1. If everybody feels this functionality will be useful for Python 2. If the solution is technically feasible [View Less]

4 5

A key parameter for heapq.merge
by Simon Sapin Feb. 6, 2012

Feb. 6, 2012

Hi, According to its own documentation, the merge() function in the heapq module is similar to sorted(). However, it has none of the key and reverse parameters that sorted() has. I think they could be just as useful as in sorted(). http://docs.python.org/dev/library/heapq.html#heapq.merge http://docs.python.org/dev/library/functions.html#sorted First of all what do you think of the idea? I’m working on a patch for a key parameter. I think it can be pretty straightforward, but I’ll … [View More]

4 6

Dict-like object with property access
by anatoly techtonik Feb. 5, 2012

Feb. 5, 2012

I expected to find the answer to this question in FAQ, but because there is no FAQ I ask it anyway. How about adding a new standard dict-like container type that allows access using . (dot) to its members instead of ['index']? Why? It is convenient to write options.help instead of options['halp'] etc. Example: >>> mydict = container(someprop=somevalue) >>> mydict['someprop'] somevalue >>> mydict.someprop somevalue >>> mydict.otherprop Exception KeyError ... … [View More]

26 47

Module field in tracker
by anatoly techtonik Jan. 26, 2012

Jan. 26, 2012

Is it a good idea to have a list of modules in tracker? So that you can have a summary of all bugs per component similar to Trac's http://trac.edgewall.org/milestone/0.12.3 -- anatoly t.

2 1

Re: [Python-ideas] Coroutines and PEP 380
by Nick Coghlan Jan. 26, 2012

Jan. 26, 2012

(redirecting to python-ideas - coroutine proposals are nowhere near mature enough for python-dev) On Wed, Jan 25, 2012 at 5:35 PM, Matt Joiner <anacrolix(a)gmail.com> wrote: > If someone can explain what's stopping real coroutines being into > Python (3.3), that would be great. The general issues with that kind of idea: - the author hasn't offered the code for inclusion and relicensing under the PSF license (thus we legally aren't allowed to do it) - complexity - maintainability - … [View More]

7 7

Retrying EAFP without DRY
by Mike Meyer Jan. 25, 2012

Jan. 25, 2012

Just running another half-baked "easy" idea up to see what others think of it. One of the cases where EAFP is clumsy is if the "forgiveness" portion is actually retrying what failed after fixing things. I just ran into this in real code, and the resulting discussion suggested this change. Eiffel's exception-handling mechanism is built assuming that's the *standard* way to do things. Seems to work ok, but if I had to choose one of the two, I'll take try/except. So here's the proposal: A … [View More]

17 59

Allow Profile() to be used as a context manager
by David Townshend Jan. 25, 2012

Jan. 25, 2012

I often find it useful to profile small sections to code in a running application to pinpoint a known bottleneck. The cProfile and profile modules don't make this easy as they stand, requiring the section of code to be wrapped into a single statement with can be called as a string using exec(). This always feels a bit clumsy to me, so my idea is simply to provide __enter__ and __exit__ methods to cProfile.Profile() and profile.Profile(). From a quick look at the code it seems that this should … [View More]

5 10

-m pstats should combine all the profiles given as arguments
by Matt Joiner Jan. 25, 2012

Jan. 25, 2012

Frequently when profiling multiple threads, I need to combine several dump stat files. Currently -m pstats reads the profiling data at only the first path given. It should merge all the profiling data from all the paths given. $ python3.3 -m pstats prof/5506-7f00f* http://bugs.python.org/issue13839

1 0

Combining test and assignment
by Eike Hein Jan. 24, 2012

Jan. 24, 2012

Hello, this is very spur of the moment, and so I apologize if I am missing the obvious reasons for why this would be horribly dumb. I sometimes find myself annoyed that I cannot access the result of an expression in a conditional statememt. Consider: if spam(): ... frobulate the return value of spam() ... else: ... value too low to frobulate ... In order to frobulate spam(), either need to call it again in the indented block, or preassign: x = spam() if x: ... frobulate x ...… [View More]

14 19

Re: [Python-ideas] Combining test and assignment
by Chris Rebert Jan. 22, 2012

Jan. 22, 2012

> On Sun, Jan 22, 2012 at 1:36 PM, Chris Rebert <pyideas(a)rebertia.com> wrote: >> On Sun, Jan 22, 2012 at 4:04 AM, Paul Moore <p.f.moore(a)gmail.com> wrote: >> > On 22 January 2012 04:51, Steven D'Aprano <steve(a)pearwood.info> wrote: >> >> Assignment as an expression feels unnatural to me: >> >> >> >> if spam() as x != 'ham': >> >> frobulate(x) >> >> >> >> doesn't really … [View More]

1 0

Symbolic expressions (or: partials and closures from the inside out)
by Nathan Rice Jan. 18, 2012

Jan. 18, 2012

Greetings, I have been writing a lot of code lately that involves creating symbolic expressions of one form or another, which are then fully evaluated at a later time. Examples of this include Elementwise, where I create expressions that act on every member of an iterable (there is a much improved new version coming soon, by the way), and a design by contract/validation lib I'm working on (which shall remain nameless :D) that uses symbolic expressions in the *args of the metaclass __new__ … [View More]method to generate a constraint class which validates input using __instancecheck__. I do most of this with lambdas, a little hacking with closures and FunctionType(), and chainable objects. I am very impressed that python is this flexible, but there are some issues with the approach that I would like to rectify, namely: 1. Because of the early binding behavior of most things in Python, if I want to include isinstance(X, someclass) in a symbolic expression, I have to wrap it in a lambda (or use .apply(), in the case of Elementwise). This is not a huge deal for me, but it forces me to create wrappers for lots of functions (e.g. isinstance_(X, someclass)) and/or have users wrap every such function they want to use in a symbolic expression. Having to do this also bloats the code a lot; the github version of Elementwise is over 3,000 LoC at this point (including prodigious documentation, but still...). 2. Python expects that certain functions, such as int(), str(), etc, will have a specific return type. While in general I agree with this, it makes Elementwise somewhat inconsistent (and it will do the same to anything else that wants to work with symbolic expressions). I'm interested in fixing both issues. I believe both issues I've had could be solved by having a robust "symbolic object". These objects would basically usable like ordinary objects, however upon any attribute access or other form of interaction, the object would basically short circuit the calling function, and return a symbolic object directly to the outer scope. The symbolic object would behave like a generator function frozen at the point of attribute access, and upon send()-ing (or whatever method), it would behave exactly as if the values sent had been the ones passed in originally (ideally without consuming the generator). I have thought about ways to approximate this behavior python currently, and while I could hack something together using inspect to pull relevant info from the stack, then break out using a special exception (potentially passing a generator with state as an exception arg), this approach strikes me as VERY brittle, implementation dependent, ugly and difficult to work with. Additionally, you would need to catch the special exception somewhere in the stack, so this trick wouldn't work on the first thing in an expression to be evaluated. As an aside, I'd like to solicit some feedback on the validation syntax I've been working on. Currently, I have code that support things like: X = SymbolicObject() const = Constraints(X * 2 + 1 >= 5, X % 2 != 0) const2 = Constraints(X[-1] == "h") const3 = Constraints(X[-1].upper() == "H") >>> print isinstance(3, const) True >>> print isinstance(2, const) False >>> print isinstance(1, const) False >>> print isinstance("bleh", const2) True >> print isinstance("bleh", const3) True Callables are supported as well, so if you wanted to do something like: Constraints(isinstance(X.attr, someclass), somefunc(X[-2].attr, args)) You could approximate that with: Constraints(lambda x: isinstance(x.attr, someclass), lambda x: somefunc(x[-2].attr, args)) As I mentioned in the first paragraph, Constraints is a metaclass, so your validations are checked using __instancecheck__. I'm also considering having __init__ generate mock objects (for certain straight-forward cases, anyhow). Thanks for your time, Nathan [View Less]

8 15

Fwd: quantifications, and tuple patterns
by Paul Moore Jan. 17, 2012

Jan. 17, 2012

Sorry, should have replied on list. On 14 January 2012 05:25, Annie Liu <liu(a)cs.stonybrook.edu> wrote: > For example, even the simplest "some x in s has pred", when a witness > for x is not needed, could end up like "{x for x in s if pred}", > "any(pred for x in s)", "len(...)!=0", "len...>0", len...>=1", ... not > to mention the many more kinds of loops and tests written by the > majority of students not used to writing queries/comprehensions. Even > more … [View More]

10 23

Re: [Python-ideas] Fwd: quantifications, and tuple patterns
by Tom Rothamel Jan. 17, 2012

Jan. 17, 2012

(Sorry about the formatting - I'm a former student of Annie's, who just joined the list.) Jim Jewett wrote: > Even in this thread, there have been multiple posts that would shown > bugs when the witness itself had a boolean evaluation of False. > What if any and all started to return a Witness object that evaluated > to True/False, but made the value available? I could see an object > like this being useful in other code as well. > class Witness(object): > … [View More]

2 1

Special method to delegate PEP 3118 buffer access to another object?
by Nick Coghlan Jan. 15, 2012

Jan. 15, 2012

I'm still working on fixing CPython's operand precedence bug for pure sequence types implemented in C [1], and, while trying to test bytearray, came across the problem that there doesn't appear to be a way to write a class in pure Python that redirects the PEP 3118 buffer access slots to another object (e.g. a memoryview instance or a bytes object). Did I miss something? And, if not, would it make sense to have the buffer retrieval operations look for a __buffer__ method in the type dictionary … [View More]

2 1

Re: [Python-ideas] Pythonic buffering in Py3 print()
by Cameron Simpson Jan. 15, 2012

Jan. 15, 2012

[ Taken back on list - I can't see anyway personal here, and the objection is a good one. - Cameron ] On 11Jan2012 08:41, Paul Moore <p.f.moore(a)gmail.com> wrote: | On 11 January 2012 06:15, Cameron Simpson <cs(a)zip.com.au> wrote: | > | flush=None? | > | > +1 from me, if None means "honour the file's default flushing | > behaviour". | | The trouble with this is that we then have: | - no parameter (default None) => default behaviour | - flush=True => Always … [View More]

4 5

quantifications, and tuple patterns
by Annie Liu Jan. 14, 2012

Jan. 14, 2012

Hi! I'd like to propose adding quantifications to python. It'd be very helpful to have tuple patterns as well. I found extensive use of quantifications while learning and teaching distributed algorithms in the last few years, and I saw more and more places where they can help make programming easier and make programs clearer and less error-prone. They didn't show up this much until I started to pay attention, since my students (even the best ones) and myself too just coded them … [View More]away too quickly. For example, even the simplest "some x in s has pred", when a witness for x is not needed, could end up like "{x for x in s if pred}", "any(pred for x in s)", "len(...)!=0", "len...>0", len...>=1", ... not to mention the many more kinds of loops and tests written by the majority of students not used to writing queries/comprehensions. Even more kinds of loops and bigger hassles are involved when a witness for x is needed. For another example, a simple "each x in s has x > y" tends to end up like "min(s)>y", which is incorrect, since s could be empty, so one has to either add this condition or invent some boundary value for min, which is error-prone since it is sensitive to the possible values of elements of s and the uses of these values. For an example distributed algorithm, one may look at Robbert von Renesse's "Paxos made moderately complex", at http://www.cs.cornell.edu/courses/CS7412/2011sp/paxos.pdf (he has newer versions but the pseudo code didn't change). It has 8 uses of quantifications. His algorithm can be coded almost exactly like that in our language DistAlgo (python with small extensions for distributed programming) if we have quantifications and tuple patterns. For example (using "!" to indicate a bound variable in tuple patterns), while some (!slot_num,p1) in decisions: if some (!slot_num,p2) in proposals has p2 != p1: is currently written as follows (it happens to be correct here to use "for" for "if" but generally requires more code to be correct): while {p1 for (s0,p1) in decisions if s0==slot_num}: p1 = {p1 for (s0,p1) in decisions if s0==slot_num}.pop() for p2 in {p2 for (s0,p2) in proposals if s0==slot_num if p2 != p1}: Both a witness for p1 and a witness for p2 are needed here. (BTW a best student working on this, after given advanced warnings and hints, wrote a 4-line nested "for"s and "if"s that were actually incorrect) So we started to think about adding quantifications and tuple patterns to DistAlgo too (other extensions are all distributed programming features). In general, "some x in s has pred" should return true/false AND bind x to a witness if true is returned. One might object to the side effect of the binding, but it is most natural here for ease of programming and clarity of programs, and it helps program efficiency too. Witness in existential quantification is also standard in logic. Of course, there is the obvious problem of new keywords: "some", "each", "has" (perhaps one may use ":" for "has") or some others. The "!" syntax would be ok for tuple patterns but only if there are no "equal cards", i.e., multiple occurrences of a same variable (though such occurrences don't seem to be useful in current python semantics for "for". A special symbol for wildcard would be more useful). So we are looking for good syntax. Thanks, Annie Liu [View Less]

1 0

os.listdir default to '.'
by Michael Foord Jan. 12, 2012

Jan. 12, 2012

Hello all, I frequently use Python from the interactive interpreter as a shell. It is a frequent, but mild, irritant that I have to type os.listdir('.') instead of just os.listdir(). How about making '.' a default argument for os.listdir ? All the best, Michael -- 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

12 14

An etherpad for every idea
by anatoly techtonik Jan. 12, 2012

Jan. 12, 2012

The last thread about "Posting style" makes me think that effective communication with email is impossible at all in modern world, where time pressure doesn't allow to read responses, not speaking about properly formatting them or following guidelines. The problem with email threads that they can be hijacked, polluted with irrelevant info (context garbage), personal opinions etc. If the aim of the thread is to "sell" some idea, it is almost impossible to track when people change their minds. … [View More]

9 11

"while ... try" - block or "for ... try" - block
by Manuel Bärenz Jan. 12, 2012

Jan. 12, 2012

I propose two new control flows for Python: "while ... try": while expr try: suite1 except SomeException: suite2 else: suite3 This executes suite1 as long as handled exceptions are thrown and expr is True. * If an unhandled exception is thrown, it passes the exception on to the surrounding or the stack. * If no exception occurs, life goes on as normal, suite3 is executed and execution goes on afterwards. The control flow is thus equivalent to: while expr: try: … [View More]

11 12

Posting style
by Oleg Broytman Jan. 12, 2012

Jan. 12, 2012

Hello! I very much hope I do not embarrass the audience but people can we return back to email etiquette? Inline quoting instead of top-posting, proper trimming instead of overquoting, an empty line to separate quoted text from the reply. Sorry for the noise but can I ask at least? Yes, I am an old fart joined the Net at 1991, but I find netiquette really useful for effective communication and deviations from it inconvenient and annoying. A: Because it messes up the order in which … [View More]

17 22