Mailman 3 January 2011 - 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 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

10 15

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 ligne 1, dans <module> ZeroDivisionError: division entière ou modulo par zéro André

9 15

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 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:

11 29

Bring back callable()
by Antoine Pitrou March 7, 2011

March 7, 2011

Hello, Python 3 has removed callable() under the justification that's it's not very useful and duck typing (EAFP) should be used instead. However, it has since been felt by many people that it was an annoying loss; there are situations where you truly want to know whether something is a callable without actually calling it (for example when writing sophisticated decorators, or simply when you want to inform the user of an API misuse). The substitute of writing `isinstance(x, collections.Callable)` is not good, 1) because it's wordier 2) because collections is really not an intuitive place where to look for a Callable ABC. So, I would advocate bringing back the callable() builtin, which was easy to use, helpful and semantically sane. Regards Antoine.

17 21

Re: [Python-ideas] [Python-Dev] Byte code arguments from two to one byte: did anyone try this?
by Nick Coghlan Jan. 31, 2011

Jan. 31, 2011

On Mon, Jan 31, 2011 at 7:17 PM, Jurjen N.E. Bos <j.bos-interpay(a)xs4all.nl> wrote: > Did anyone try this already? If not, I might take up the gauntlet > and try it myself, but I never did this before... a) This is more on topic for python-ideas rather than python-dev (cc changed accordingly) b) My off-the-top-of-my-head guess is that caching effects will swamp any impact such a change might have. The only way to find out for sure is going to be for someone to try it (along the lines of the already mentioned WPython variant) and see what happens for benchmarks like pybench and the execution times of various test suites. Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

1 0

Adding threading.RepeatTimer class
by Daniel da Silva Jan. 28, 2011

Jan. 28, 2011

We have a threading.Timer class which executes after a given delay and then terminates. I was thinking about a pre-made class that would execute, wait an interval, and then repeat. It would cut down on the logic people need to implement themselves, and make simple scripts faster. Here are some use cases: # Send a ping message to all connected clients every 120 seconds from server import ping_all_clients pinger = threading.RepeatTimer(120, ping_all_clients) pinger.start() # Check for updates every 3 hours from mymodule import check_for_updates update_checker = threading.RepeatTimer(60*60*3, check_for_updates) update_checker.start() I was thinking of the class having an initializer signature as follows: class threading.RepeatTimer(interval, function, args=[], kwargs={}, limit=None) Create a timer that will run function with args and kwargs and repeat every interval secods. If limit is an integer, limits repetitions to that many calls. cancel() Stop the repeat timer. If in the middle of a call, the call is allowed to finish. Daniel

4 3

Re: [Python-ideas] Location of tests for packages
by Ron Adam Jan. 25, 2011

Jan. 25, 2011

Moving these suggestions to python ideas as they are not immediately relevant to the current python dev discussion at this time. ;-) I'm really just wondering what others think, is this something worth working on? On 01/24/2011 01:46 PM, Raymond Hettinger wrote: > Right now, the tests for the unittest package are under the package > directory instead of Lib/test where we have most of the other tests. > > There are some other packages that do the same thing, each for their own > reason. > > I think we should develop a strong preference for tests going under > Lib/test unless there is a very compelling reason. > * For regrtest to work, there still needs to be some file in Lib/test > that dispatches to the alternate test directory. Currently tests are mostly separate from the modules. Mostly separate because, some modules have doctests in them, and/or a test() function to run tests. But the test function name isn't special in any way as far as I know. It's usually _test(), but it could be something else. Would it help things to have a special __test__ name? ie... special to python, in that module.__test__() can be depended on to run the tests for that module? (or package) I've found it useful to add a -T option to my own python applications to run tests. But moving it from being a module option to a python option, would make that even nicer. Where python -T modulename called the __test__() function. (or evoke the tests in another way.) With a dependable way to evoke the tests no matter where they are located, it then becomes just a matter of iterating the list of modules in the library (or a directory) to run all the tests. But then, what's the best way to actually do that? The current method uses pattern matching ... (not my first choice for sure) python -m unittest discover -s project_directory -p '*_test.py' python -m unittest discover project_directory '*_test.py' Those lines are way too long in my opinion. In the above, the test functions need to begin with an underscore. I'm not sure the discoverable test function should be private, The very act of finding them suggests they should be a public, but special API, rather than a private API to me. If they were only accessed from inside the module or package they are in, then being private makes sense. One choice is that __test__ is special to doctest and unittest only. python -m unittest module # runs module.__test__() if it exists. Or a little more far out ... The __test__() function could be called with "python -T module". But then it seems that maybe we could also have a __main__() function be called with "python -M module". (?) Alternately ... "python -T module" could alter the name of the module. if __name__ == "__main__": main() elif __name__ == "__test__": _test() # a private name is ok here. Cheers, Ron

1 0

Re: [Python-ideas] A sorted version of **kwargs
by Hongbao Chen Jan. 21, 2011

Jan. 21, 2011

Hey, guys I must argue that make **kwargs sorted is really a terrible idea. Please think that when user wants a unsorted **kwargs, how can he or she bring the original unsorted dict back? When a dict is unsorted, we can sort it with implementation in Python/C interface or just python code for portability. That is what should be like! Give users more control over behavior of dict. That is what I propose. Best regards Hongbao Chen XJTU -----邮件原件----- 发件人: python-ideas-bounces+microcore=yahoo.com.cn(a)python.org [mailto:python-ideas-bounces+microcore=yahoo.com.cn@python.org] 代表 python-ideas-request(a)python.org 发送时间: 2011年1月21日 1:52 收件人: python-ideas(a)python.org 主题: Python-ideas Digest, Vol 50, Issue 34 Send Python-ideas mailing list submissions to python-ideas(a)python.org To subscribe or unsubscribe via the World Wide Web, visit http://mail.python.org/mailman/listinfo/python-ideas or, via email, send a message with subject or body 'help' to python-ideas-request(a)python.org You can reach the person managing the list at python-ideas-owner(a)python.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Python-ideas digest..." Today's Topics: 1. Re: A sorted version of **kwargs (Nick Coghlan) 2. Re: A sorted version of **kwargs (M.-A. Lemburg) 3. Re: A sorted version of **kwargs (Guido van Rossum) 4. Re: A sorted version of **kwargs (Imri Goldberg) 5. Re: A sorted version of **kwargs (geremy condra) ---------------------------------------------------------------------- Message: 1 Date: Thu, 20 Jan 2011 23:11:57 +1000 From: Nick Coghlan <ncoghlan(a)gmail.com> To: "Steven D'Aprano" <steve(a)pearwood.info> Cc: python-ideas(a)python.org Subject: Re: [Python-ideas] A sorted version of **kwargs Message-ID: <AANLkTik5XECCCBcgVvapyE4yEyCVAkN1-sFfaot+wbqE(a)mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jan 20, 2011 at 8:28 PM, Steven D'Aprano <steve(a)pearwood.info> wrote: > I would be +0 on making **kwargs an ordered dict automatically, and -1 on > adding ***ordered_kwargs. Because kwargs is mostly used only for argument > passing, and generally with only a small number of items, it probably > doesn't matter too much if it's slightly slower than an unordered dict. Yeah, simply making the kwargs dict always ordered is likely the way we would do it. That's also the only solution with any chance of working by default with the way most decorators are structured (accepting *args and **kwargs and passing them to the wrapped function). To expand on Raymond's response in the previous thread on this topic, there are likely a number of steps to this process: 1. Provide a _collections.OrderedDict C implementation 2. Create a PEP to gain agreement from other implementations (especially IronPython, PyPy and Jython) to proceed with the remaining steps 3. Make it a builtin class (odict?) in its own right (with collections.OrderedDict becoming an alias for the builtin type) 4. Update the interpreter to use the new builtin type for kwargs containers Use various microbenchmarks to check that the use of the new odict builtin type instead of a plain dict doesn't slow things down too much. Cheers, Nick. -- Nick Coghlan?? |?? ncoghlan(a)gmail.com?? |?? Brisbane, Australia ------------------------------ Message: 2 Date: Thu, 20 Jan 2011 15:05:23 +0100 From: "M.-A. Lemburg" <mal(a)egenix.com> To: Nick Coghlan <ncoghlan(a)gmail.com> Cc: python-ideas(a)python.org Subject: Re: [Python-ideas] A sorted version of **kwargs Message-ID: <4D384123.6040105(a)egenix.com> Content-Type: text/plain; charset=ISO-8859-1 Nick Coghlan wrote: > On Thu, Jan 20, 2011 at 8:28 PM, Steven D'Aprano <steve(a)pearwood.info> wrote: >> I would be +0 on making **kwargs an ordered dict automatically, and -1 on >> adding ***ordered_kwargs. Because kwargs is mostly used only for argument >> passing, and generally with only a small number of items, it probably >> doesn't matter too much if it's slightly slower than an unordered dict. > > Yeah, simply making the kwargs dict always ordered is likely the way > we would do it. That's also the only solution with any chance of > working by default with the way most decorators are structured > (accepting *args and **kwargs and passing them to the wrapped > function). -1. How often do you really need this ? In which of those cases wouldn't a static code analysis give you the call order of the parameters already ? "Nice to have" is not good enough to warrant a slow down of all function calls involving keyword arguments, adding overhead for other Python implementations and possibly causing problems with 3rd party extensions relying on getting a PyDict for the keyword arguments object. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 20 2011) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ------------------------------ Message: 3 Date: Thu, 20 Jan 2011 08:42:20 -0800 From: Guido van Rossum <guido(a)python.org> To: "M.-A. Lemburg" <mal(a)egenix.com> Cc: python-ideas(a)python.org Subject: Re: [Python-ideas] A sorted version of **kwargs Message-ID: <AANLkTimQmVdoR-hMc3Gq9Md+_w7bvra6uV1K2NjZaWoZ(a)mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jan 20, 2011 at 6:05 AM, M.-A. Lemburg <mal(a)egenix.com> wrote: > Nick Coghlan wrote: >> On Thu, Jan 20, 2011 at 8:28 PM, Steven D'Aprano <steve(a)pearwood.info> wrote: >>> I would be +0 on making **kwargs an ordered dict automatically, and -1 on >>> adding ***ordered_kwargs. Because kwargs is mostly used only for argument >>> passing, and generally with only a small number of items, it probably >>> doesn't matter too much if it's slightly slower than an unordered dict. >> >> Yeah, simply making the kwargs dict always ordered is likely the way >> we would do it. That's also the only solution with any chance of >> working by default with the way most decorators are structured >> (accepting *args and **kwargs and passing them to the wrapped >> function). > > -1. > > How often do you really need this ? > > In which of those cases wouldn't a static code analysis give you > the call order of the parameters already ?? > > "Nice to have" is not good enough to warrant a slow down of > all function calls involving keyword arguments, adding overhead > for other Python implementations and possibly causing problems > with 3rd party extensions relying on getting a PyDict for the > keyword arguments object. What he says. In addition, I wonder what the semantics would be if the caller passed **d where d was an *unordered* dict... -- --Guido van Rossum (python.org/~guido) ------------------------------ Message: 4 Date: Thu, 20 Jan 2011 18:53:54 +0200 From: Imri Goldberg <lorgandon(a)gmail.com> To: Guido van Rossum <guido(a)python.org> Cc: python-ideas(a)python.org, "M.-A. Lemburg" <mal(a)egenix.com> Subject: Re: [Python-ideas] A sorted version of **kwargs Message-ID: <AANLkTin0GApx57hHQXpQLZ00wmqC_zY_xxzyW8vpRgtN(a)mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" On Thu, Jan 20, 2011 at 6:42 PM, Guido van Rossum <guido(a)python.org> wrote: > > > -1. > > > > How often do you really need this ? > > > > In which of those cases wouldn't a static code analysis give you > > the call order of the parameters already ? > > > > "Nice to have" is not good enough to warrant a slow down of > > all function calls involving keyword arguments, adding overhead > > for other Python implementations and possibly causing problems > > with 3rd party extensions relying on getting a PyDict for the > > keyword arguments object. > > What he says. > > In addition, I wonder what the semantics would be if the caller passed > **d where d was an *unordered* dict... What if the default behavior stays as it is today, but a magic decorator is added, (maybe @ordered_kwargs or some such), and only for these kind of functions the new behavior applies. Also, given such a decorator, when given **d where d is a regular dict, the implementation could possibly throw an error. (Or maybe it is up to the implementor of the specific function). Cheers, Imri -- Imri Goldberg -------------------------------------- http://plnnr.com/ - automatic trip planning http://www.algorithm.co.il/blogs/ -------------------------------------- -- insert signature here ----

4 3

values in vs. values out
by Luc Goossens Jan. 21, 2011

Jan. 21, 2011

Hi all, There's a striking asymmetry between the wonderful flexibility in passing values into functions (positional args, keyword args, default values, *args, **kwargs, ...) and the limited options for processing the return values (assignment). Hence, whenever I upgrade a function with a new keyword arg and a default value, I do not have to change any of the existing calls, whereas whenever I add a new element to its output tuple, I find myself chasing all existing code to upgrade the corresponding assignments with an additional (unused) variable. So I was wondering whether this was ever discussed before (and recorded) inside the Python community. (naively what seems to be missing is the ability to use the assignment machinery that binds functions' formal params to the given actual param list also in the context of a return value assignment) cheers, Luc

15 25

Re: [Python-ideas] A sorted version of **kwargs
by 陈宏葆 Jan. 21, 2011

Jan. 21, 2011

Hi, By the way, a sorted **kwargs may slow down the speed of function invocation. But we do not know how often the function gets called. So we mustn't enforce the dict to be sorted for it unpredictable defects in performance. I need to emphasize the UNPREDICTABLE. Hongbao Chen Software Engineering School Xi'an Jiaotong University Cell:+8613891979195 ________________________________ 发件人： "python-ideas-request(a)python.org" <python-ideas-request(a)python.org> 收件人： python-ideas(a)python.org 发送日期： 2011/1/21 (周五) 9:59:06 上午主题： Python-ideas Digest, Vol 50, Issue 36 Send Python-ideas mailing list submissions to python-ideas(a)python.org To subscribe or unsubscribe via the World Wide Web, visit http://mail.python.org/mailman/listinfo/python-ideas or, via email, send a message with subject or body 'help' to python-ideas-request(a)python.org You can reach the person managing the list at python-ideas-owner(a)python.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Python-ideas digest..." Today's Topics: 1. Re: A sorted version of **kwargs (Don Spaulding) 2. Re: A sorted version of **kwargs (MRAB) 3. Re: A sorted version of **kwargs (Alexander Belopolsky) 4. Re: A sorted version of **kwargs (Nick Coghlan) 5. Re: A sorted version of **kwargs (Hongbao Chen) ---------------------------------------------------------------------- Message: 1 Date: Thu, 20 Jan 2011 14:26:23 -0600 From: Don Spaulding <donspauldingii(a)gmail.com> To: Bruce Leban <bruce(a)leapyear.org> Cc: python-ideas(a)python.org Subject: Re: [Python-ideas] A sorted version of **kwargs Message-ID: <AANLkTinvh22idu-PTNOEF=qu9njK4uBmxpc5LJ7CXW_6(a)mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" On Thu, Jan 20, 2011 at 2:05 PM, Bruce Leban <bruce(a)leapyear.org> wrote: > > On Thu, Jan 20, 2011 at 11:47 AM, Tim Delaney <timothy.c.delaney(a)gmail.com > > wrote: > >> >> ['b':1] would then be ambiguous (appears to be a slice of a list). More >> obvious in the case of [1:2] ... >> > > We use parenthesis for tuples and avoid the ambiguity by writing (1,). > In the same way, we could require your examples to be written ['b':1,] and > [1:2,] > Please, not this. I like the idea of syntactic support for the odict, but no need to spread the (foo,) syntax around. It's too easy to misinterpret when you do a quick scan of a body of code.

1 0