Mailman 3 February 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 … [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

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

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

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.… [View More]

17 21

str.split() oddness
by Mart Sõmermaa March 7, 2011

March 7, 2011

IMHO, x.join(a).split(x) should be "idempotent" in regard to a. >>> foo = ['a', 'b', 'c'] >>> assert '|'.join(foo).split('|') == foo >>> foo = ['a'] >>> assert '|'.join(foo).split('|') == foo >>> foo = [] >>> assert ' '.join(foo).split() == foo And now the odd exception to the rule: >>> assert '|'.join(foo).split('|') == foo Traceback (most recent call last): File "<stdin>", line 1, in <module> AssertionError That … [View More]

9 18

str.split with multiple individual split characters
by Andy Buckley March 2, 2011

March 2, 2011

Here's another str.split() suggestion, this time an extension (Pythonic, I think) rather than a change of semantics. There are cases where, especially in handling user input, I'd like to be able to treat any of a series of possible delimiters as acceptable. Let's say that I want commas, underscores, and hyphens to all be treated as delimiters (as I did in some code I was writing today). I guessed, based on some other Python std lib behaviours, that this might work: usertokens = userstr.split([… [View More]

18 35

class ModuleNotFoundError(ImportError)
by cool-RR March 1, 2011

March 1, 2011

There are many programs out there, including Django, that "carefully import" a module by doing: try: import simplejson except ImportError: import whatever_instead as simplejson # or whatever This is problematic because sometimes an `ImportError` is raised not because the module is missing, but because there's some error in the module, or because the module raises an `ImportError` itself. Then the exception gets totally swallowed, resulting in delightful … [View More]

5 7

Coercing str.join() argument elements to str
by Dirkjan Ochtman Feb. 28, 2011

Feb. 28, 2011

I just saw someone mention this on Twitter, and I know that I've been bitten by it before. Seems like it wouldn't break any existing code... The worst that could happen is that someone gets nonsensical strings in new code instead of an exception. >>> ', '.join(range(5)) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: sequence item 0: expected string, int found >>> ', '.join(str(i) for i in range(5)) '0, 1, 2, 3, 4' Has this … [View More]

5 4

Fw: New pattern-matching library (was: str.split with multiple individual split characters)
by Mike Meyer Feb. 28, 2011

Feb. 28, 2011

I accidental dropped the list from my reply to his comment. I'm forwarding that and his reply (with permission). <mike Begin forwarded message: Date: Mon, 28 Feb 2011 09:59:48 -0800 From: Guido van Rossum <guido(a)python.org> To: Mike Meyer <mwm(a)mired.org> Subject: Re: [Python-ideas] New pattern-matching library (was: str.split with multiple individual split characters) On Mon, Feb 28, 2011 at 9:40 AM, Mike Meyer <mwm(a)mired.org> wrote: > On Mon, 28 Feb 2011 … [View More]

1 0

A couple of with statement ideas
by Nick Coghlan Feb. 27, 2011

Feb. 27, 2011

I've been considering which broad concerns I want to focus on for 3.3, and have come to the conclusion that I'm going to have plenty to keep me busy between helping to smooth over some of the rough edges left over from the PEP 3118 implementation, as well as championing the module aliasing concept I first brought up a few weeks ago. That means there are a couple of with statement ideas that I still like, but almost certainly won't have the time to champion myself. So, I'm lobbing them over the … [View More]fence in a half-baked form. If anyone feels strongly enough about them to get them into a PEP-worthy state, go right ahead (that's the whole point of this message). If nobody else cares enough to pick them up... well, that will simply justify my decision that they weren't important enough to worry about. Idea 1: Implicit context managers PEP 343 included the idea of a "__context__" method that permitted the creation of objects with an implicit associated context manager. It was eventually dropped because we couldn't find a good way to explain it to users at the time. Instead, you see things like "decimal.localcontext()" and various other objects that need to be called every time you want to use them as a context manager. If you want an object to have a "native" context manager, you have to either write __enter__ and __exit__ manually, or use a mixin or class decorator that adapts the __enter__/__exit__ interface to a single method (e.g. the ContextManager class and manage_context method from GarlicSim that Ram Rachum posted about here some time ago). Now that everyone has had time to get used to the way context managers work, I believe the concept may usefully make a return using the "implicit context manager" terminology. While the "__context__" name has since been claimed by PEP 3134, the alternative name used in PEP 346 ("__with__") is still a possibility. The idea of bringing back this concept would be to allow an object to implement *either* a __with__ method that returns a context manager, or else implement __enter__/__exit__ directly. The behaviour would be similar to the relationship between iterators and iterables, except that a missing "__with__" implementation would imply the "return self" semantics that iterators must implement explicitly. Anyone picking up this idea should be prepared for a lot of pushback, as the last few years have shown us that the with statement is perfectly usable without this feature, and the GarlicSim example shows that this is already feasible using existing mechanisms (even I am at best lukewarm on the concept). Idea 2: Son of PEP 377 (letting context managers skip the body of the with statement) The niggles that lead me to write PEP 377 still bug me. There are some nested with statements that are perfectly valid as inline code but will throw RuntimeError if you make them into a single context manager via contextlib.contextmanager. That PEP was rightly rejected as having too great an impact on "normal" code for something that is a comparatively exotic corner case. As I noted in issue 5251, I've since thought of an alternative, lower impact solution that may prove more acceptable to Guido and others: an optional "__entered__" method for context managers that, if present, would be executed *inside* the scope of the try/finally block before the body of the with statement itself started executing. Any exceptions raised in that method would be passed to the __exit__ method, thus increasing the flexibility of the context management protocol, while having minimal impact Most significantly, contextlib.GeneratorContextManager could be adjusted to make use of this feature to correctly skip the body of the with statement when the internal generator doesn't yield (attempt to invoke __enter__ a second time would still trigger RuntimeError, though). The translation of the problematic nested with statements into a single generator based context manager would then work correctly, functioning in the same way as the equivalent inline code. I really like this idea, since it provides a genuinely new capability to the context management protocol in a relatively low impact manner. However, as noted in the intro, there are other, more immediately practical, questions I want to deal with first, so who knows if or when I'll be able to devote a significant amount of time to this one. So, if anyone is feeling particularly keen to champion a PEP and dig into the internals of contextlib and CPython's with statement implementation, there's a couple of ideas for you to mull over :) Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia [View Less]

8 12

Support for regular expression syntax
by Alexander Feb. 26, 2011

Feb. 26, 2011

Hello. Maybe this topic has been discussed. I would like to have the support of alphabetic rules, such as \p{...}, in re module.

4 3

Re: [Python-ideas] [Python-Dev] Let's get PEP 380 into Python 3.3
by Joao S. O. Bueno Feb. 26, 2011

Feb. 26, 2011

On Fri, Feb 25, 2011 at 8:01 PM, Greg Ewing <greg.ewing(a)canterbury.ac.nz> wrote: > From: Guido van Rossum > >> (OTOH I am not much enamored with cofunctions, PEP 3152.) > > That's okay, I don't like it much myself in its current form. > I plan to revisit it at some point, but there's no hurry. I've just gone through PEP 3152 - and the first though that occurred me is that a decorator is perfectly usable instead of the new proposed keyword "codef". (It would need to … [View More]

1 0

Cleaner separation of help() and interactive help.
by Ron Adam Feb. 24, 2011

Feb. 24, 2011

Currently any call to help() uses the pager in pydoc. Because of that, you can't do some things (easily) like... >>> result = help(thing) It also can be annoying (to me) when I use help and the result is cleared after the pager is done with it. That requires me to re-do the same help requests to recheck details rather than simply scroll back in the current console window. The alternative is to keep another console open just for using help. That's not always good when you … [View More]

10 21

Cleanup, uniformization and documentation of stdlib module reactions to `python -m <module>`
by Masklinn Feb. 19, 2011

Feb. 19, 2011

There are three ways a Python module can react to `-m`: do nothing, selftest (via doctests or via python code) and do something "useful" (for Python users). The former is fine, but the latter two have more issues: For modules which selftest, the self-tests/sanity check are generally undocumented and potentially long-running or destructive. It would be nice if those were protected behind an argument (e.g. `-x` for `—execute`) just in case For "useful" modules, the issues are far more complex: … [View More]

1 0

wsgiref.simple_server should mount and serve a provided WSGI application script
by Masklinn Feb. 19, 2011

Feb. 19, 2011

Many (most?) WSGI servers use WSGI application scripts (a Python script with a `.py` or `.wsgi` extension generally, providing a global `application` variable) to setup and mount applications. Currently, `python -m wsgiref.simple_server` mounts a trivial "hello world" application and opens it in the web browser. It would be nice if `python -m wsgiref.simple_server file` mounted and served the application set up by the script instead.

1 0

Re: [Python-ideas] adding possibility for declaring a function in Matlab's way
by Géza Feb. 14, 2011

Feb. 14, 2011

All, Thank you for the constructive remarks, especially Bruce Leban for pointing out the TOOWTDI principle, which is why it wouldn't fit into the Python philosophy, and Stephen J. Turnbull for the idea of doing it with decorators. I could actually implement something similar to what I wanted with decorators, although it still needs improvement. All the best, Géza P.S. This is somewhat off-topic, but if someone has ideas on improving it, personal replies are welcome. Two things that are … [View More]

1 0

Re: [Python-ideas] Alternative formatting styles for logging events in Python 3.3
by Nick Coghlan Feb. 13, 2011

Feb. 13, 2011

On Fri, Feb 11, 2011 at 3:21 AM, Vinay Sajip <vinay_sajip(a)yahoo.co.uk> wrote: > Perhaps this style could be emphasised in the stdlib documentation. The > XXXMessage classes could be brought into stdlib (not something I'm particularly > advocating, mind you). Given that the ability to pass in something other than a %-formatting format string isn't even *mentioned* in the API documentation for logging.debug [1][2] this trick could definitely use some additional exposure. While … [View More]

2 2

adding possibility for declaring a function in Matlab's way
by Géza Feb. 12, 2011

Feb. 12, 2011

It would be nice if you could write a function header like this (besides, of course, the current way): def result=functionname(params): ... result=something This would suffice for most functions, since you usually return one type of value, and it can be very convenient in certain cases. This is the way it is done e.g. in Matlab, which also has a huge user base. Some more details to the idea: - The return values are initialized to None. - Setting the return values does not … [View More]

6 5

Re: [Python-ideas] Python-ideas Digest, Vol 51, Issue 16
by Arthur Feb. 12, 2011

Feb. 12, 2011

You can return a tuple instead change the syntax... def res1, res2 = foo(): #code here can be def foo(): #code here return (res1,res2) Até mais! Ass.: Arthur Julião ------------------------------------------------------------------------------------------------ "Quero que a estrada venha sempre até você e que o vento esteja sempre a seu favor, quero que haja sempre uma cerveja em sua mão e que esteja ao seu lado seu grande amor." (Tempo Ruim - A Arte do Insulto - Matanza) 2011/2/12 <… [View More]python-ideas-request(a)python.org> > 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. adding possibility for declaring a function in Matlab's way (G?za) > 2. Re: adding possibility for declaring a function in Matlab's > way (Terry Reedy) > 3. Re: adding possibility for declaring a function in Matlab's > way (Bruce Leban) > 4. adding possibility for declaring a function in Matlab's way > (Stephen J. Turnbull) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 11 Feb 2011 19:48:38 -0800 > From: G?za <kgeza7(a)gmail.com> > To: "python-ideas" <python-ideas(a)python.org> > Subject: [Python-ideas] adding possibility for declaring a function in > Matlab's way > Message-ID: <7C2FD842074A470387F4F83B280C22A3@GezaVAIO> > Content-Type: text/plain; format=flowed; charset="ISO-8859-1"; > reply-type=original > > It would be nice if you could write a function header like this (besides, > of > course, the current way): > > def result=functionname(params): > ... > result=something > > This would suffice for most functions, since you usually return one type of > value, and it can be very convenient in certain cases. This is the way it > is > done e.g. in Matlab, which also has a huge user base. > > Some more details to the idea: > - The return values are initialized to None. > - Setting the return values does not need to be the last line in the > function. > - You can use the "return" statement just as before, but without arguments, > to return from anywhere in the code. > - If you specify arguments to the "return" statement, Python stops with an > exception. > - The return value can be a tuple: def (result1, result2, > result3)=functionname(parameters) > > Some advantages: > - You can easily see what the function returns, without having to read the > function body, or hoping to find it in the comments. > - You can initialize the return values (if None is not good enough), and > then care about the cases where they change. > - If you change the setup of the return value (e.g. insert a new item into > the tuple), you do not need to change the "return" statement at possibly > several places in the function body. > - It is very easy to write the function call prototype: just copy the > function declaration without the "def" and final colon. Python GUIs will be > able to do the same, thus not only giving you the function parameter > template automatically, but also the return value template. > > Some disadvantages: > - I suggest it as an addition to the current way, so there isn't any > serious > disadvantage. One person may decide to use one way, one the other. > - Of course, if you mix the two types of function declarations in your > software, you may need to look at the function header to see which one you > used in the specific case. > - You need to be aware of both ways when reading someone else's code --- > which is not hard, as both ways are quite easy to read. > > The idea at this stage of Python development may be surprising, but I hope > that nevertheless you will consider it seriously. > There has been a lot of experience and developlment regarding this in > connection with Matlab, > and I am sure that many of you know better than me how it would fit into > Python's philosophy, and what consequences adding it may have. > > Thanks for your time, and best regard! > G?za > > > > ------------------------------ > > Message: 2 > Date: Fri, 11 Feb 2011 23:05:20 -0500 > From: Terry Reedy <tjreedy(a)udel.edu> > To: python-ideas(a)python.org > Subject: Re: [Python-ideas] adding possibility for declaring a > function in Matlab's way > Message-ID: <ij50tv$tmn$1(a)dough.gmane.org> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 2/11/2011 10:48 PM, G?za wrote: > > It would be nice if you could write a function header like this > > (besides, of course, the current way): > > > > def result=functionname(params): > > ... > > result=something > > > > This would suffice for most functions, since you usually return one type > > of value, and it can be very convenient in certain cases. This is the > > way it is done e.g. in Matlab, which also has a huge user base. > > Perhaps you should also suggest to the Matlab people that they add > Python-style declarations to Matlab;-! After all, Python also has a huge > user base. > > > Some disadvantages: > > - I suggest it as an addition to the current way, so there isn't any > > serious disadvantage. One person may decide to use one way, one the > other. > > This is a huge disadvantage. Everyone would have to learn two equivalent > syntaxes instead of one, which would make the language much more > difficult to learn. > > Python's syntax is essentially frozen except for possible minor > additions that show some real gain. > > -- > Terry Jan Reedy > > > > > ------------------------------ > > Message: 3 > Date: Fri, 11 Feb 2011 20:10:30 -0800 > From: Bruce Leban <bruce(a)leapyear.org> > To: G?za <kgeza7(a)gmail.com> > Cc: python-ideas <python-ideas(a)python.org> > Subject: Re: [Python-ideas] adding possibility for declaring a > function in Matlab's way > Message-ID: > <AANLkTikZ=mdhsKwqO3DhBzBXPZKCDo5zn80RVy=BH4Mz(a)mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Before suggesting "improvements" to Python (or anything else for that > matter), it's helpful to identify exactly what problem you are trying to > solve. I don't see one. And having multiple entirely different ways to do > things for no good reason mean code is harder to read. Google TOOWTDI for > more info. > > If you love this paradigm I suggest you write it this way: > > def foo(): > global result > result = None > if bar() is not None: > raise UnnecessaryException > return result > def bar(): > pass # real code goes here > > > --- Bruce > New Puzzazz newsletter: http://j.mp/puzzazz-news-2011-02 > > > > On Fri, Feb 11, 2011 at 7:48 PM, G?za <kgeza7(a)gmail.com> wrote: > > > It would be nice if you could write a function header like this (besides, > > of course, the current way): > > > > def result=functionname(params): > > ... > > result=something > > > > This would suffice for most functions, since you usually return one type > of > > value, and it can be very convenient in certain cases. This is the way it > is > > done e.g. in Matlab, which also has a huge user base. > > > > Some more details to the idea: > > - The return values are initialized to None. > > - Setting the return values does not need to be the last line in the > > function. > > - You can use the "return" statement just as before, but without > arguments, > > to return from anywhere in the code. > > - If you specify arguments to the "return" statement, Python stops with > an > > exception. > > - The return value can be a tuple: def (result1, result2, > > result3)=functionname(parameters) > > > > Some advantages: > > - You can easily see what the function returns, without having to read > the > > function body, or hoping to find it in the comments. > > - You can initialize the return values (if None is not good enough), and > > then care about the cases where they change. > > - If you change the setup of the return value (e.g. insert a new item > into > > the tuple), you do not need to change the "return" statement at possibly > > several places in the function body. > > - It is very easy to write the function call prototype: just copy the > > function declaration without the "def" and final colon. Python GUIs will > be > > able to do the same, thus not only giving you the function parameter > > template automatically, but also the return value template. > > > > Some disadvantages: > > - I suggest it as an addition to the current way, so there isn't any > > serious disadvantage. One person may decide to use one way, one the > other. > > - Of course, if you mix the two types of function declarations in your > > software, you may need to look at the function header to see which one > you > > used in the specific case. > > - You need to be aware of both ways when reading someone else's code --- > > which is not hard, as both ways are quite easy to read. > > > > The idea at this stage of Python development may be surprising, but I > hope > > that nevertheless you will consider it seriously. > > There has been a lot of experience and developlment regarding this in > > connection with Matlab, > > and I am sure that many of you know better than me how it would fit into > > Python's philosophy, and what consequences adding it may have. > > > > Thanks for your time, and best regard! > > G?za > > _______________________________________________ > > Python-ideas mailing list > > Python-ideas(a)python.org > > http://mail.python.org/mailman/listinfo/python-ideas > > > [View Less]

1 0

Changing the name of __pycache__
by Raymond Hettinger Feb. 10, 2011

Feb. 10, 2011

It would be great if there was some way to change the name to .pycache so that it doesn't pollute directory listings. The dot-naming convention seems to be widely used (.bashrc, .emacs, .hgignore, etc.). Ideally, we should follow that convention also or at least provide a way to make the change locally (perhaps an environment variable). Raymond

16 41

Alternative formatting styles for logging events in Python 3.3
by Nick Coghlan Feb. 10, 2011

Feb. 10, 2011

Via the new "style" parameter to logging.Formatter objects, Python 3.2 adds support for newer formatting styles (str.format, string.template) when defining output formats for log messages. However, actual logging calls are still constrained to using %-formatting if they want to benefit from the "lazy formatting" feature (you can obviously generate pre-formatted messages any way you like). For 3.3, I'd like to propose extending this flexibility to the input side as well: 1. Add an optional … [View More]

1 0

Change the array declaration syntax.
by Arthur Feb. 8, 2011

Feb. 8, 2011

(Sorry for any spelling errors, I'm using Google translator to write this message) Lists and tuples are data structures dynamically typed, and that's great! Makes writing code easier, and allows the developer to keep the focus on more important things. However, when these structures contain large amounts of elements, or when the program requires a lot of computational resources, dynamic typingbecomes a waste if the lists and tuples not use it. One way to avoid wasting resources with dynamic … [View More]

5 5

Add a feature similar to C++ "using some_namespace"
by Manuel Bärenz Feb. 8, 2011

Feb. 8, 2011

In C++, the the approach to the namespace problem is having different namespaces that should not contain different definitions of the same name. Members of a namespace can be accessed explicitly by e.g. calling "std::cout<< etc." or "using namespace std; cout<< etc." I understand Pythons approach to be "objects can be used as namespaces and their attributes are the names they contain". I find this a very beautiful way of solving the issue, but it has a downside, in my opinion, … [View More]

6 6