Mailman 3 February 2017 - Python-ideas

List indexing multiple elements
by Ryan Gonzalez Feb. 21, 2017

Feb. 21, 2017

Apologies if this has already been covered! Right now, if you want to get multiple elements in a list, you have to do: elements = [mylist[a], mylist[b]] My proposal is two-folded: - Right now, a[b,c] is already valid syntax, since it's just indexing a with the tuple (b, c). The proposal is to make this a specialization in the grammar, and also allow stuff like a[b:c, d:e] (like `a.__getitem__(slice(b, c), slice(d, e))`). - Add support for indexing via tuples in list.__getitem__. list.… [View More]

6 5

More classical for-loop
by Mikhail V Feb. 19, 2017

Feb. 19, 2017

Here is a summary of my idea about for-loop. It focuses on readability and does not take in account possible technical nuances. This is my first attempt to write a full proposal and I suppose it is ok to post it here. Many things (readability) can raise opinion based dispute, so it is sort of my opinion. I am not sure how topical/realistic is it, or contains technical flaws, so your note and recommendations are welcome. Proposal -------- Introduce a more classical, "Fortran-ish" loop syntax. … [View More]The simplest syntax could be: for i somekeyword 10 : which logically will be the same as for i in range(10) : Keyword supposed to have sense only inside the statement, thus not interfere with variables and other keywords. At this moment the proposal will be to use the word "over": for i over 10 : The choice of the word is based only on its look - middle sized, has related meaning(?), and easy to type. Of course, if a better word can be found, it can be used. Note: the meaning of the word is of much less importance than optical qualities. Other good looking options: for i count 10 : for i range 10 : for i steps 10 : for i sieve 10 : Parameters same as in range(): for i over a, b, step : is the same as for i in range(a, b, step) : Rationale ----------- Removing the brackets will help concentrate on other parts of code, though it has some price, since if more than one range parameter is used, it loses some emphasis. This is easiliy compensated by IDE's syntax highlighting, namely by slightly graying out the keyword. Currently the loop statement uses the word "in". This word creates rather unpleasant visual 'stick and hole' effect on eyes due to its short size. Is quite noticable, especially in case of one-letter varaibles (e.g. for i in ...). And the 'bulky' range() part is bit too heavy. More problems to 'holes' effect, especially in monospaced editors, adds the form of glyphs "i" and "n" which both have vertical stick structure and also interfere with the very common variable name "i". Also new sytax needs less typing. Examples -------- Common use case: L = [1,3,5,7] for i over len(L): e = L[i] or: length = len(L) for i over length: e = L[i] Nested: for y over 0,480 : for x over 0,640 : putpixel (x, y) or: width = 640 height = 480 for y over 0, height : for x over 0, width : putpixel (x, y) Surprisingly good result is achieved if simply remove the keyword and put more space: for y 0, height : for x 0, width : putpixel (x, y) But similar effect can be achieved by graying out the word with syntax highlighting. Compare with existing syntax: for y in range(0,480) : for x in range(0,640) : putpixel (x, y) for y in range(0, height) : for x in range(0, width) : putpixel (x, y) Notes ------- Although it is true that the whole idea is more about cosmetics, still the for-loop is important structural component and slight improvement could count. Mikhail [View Less]

11 23

String Format Callable Flag (Was: Efficient Debug Logging)
by Mark E. Haase Feb. 19, 2017

Feb. 19, 2017

In the debug logging thread, somebody suggested the "%r" format specifier and a custom __repr__. This is a neat solution because Python logging already includes a "delayed" evaluation of sorts: it formats the logging string *after* it determines that the message's log level is greater than or equal to the logger's level. However, wrapping up every expensive debugging computation in a new class might get tedious, so here's a strawman proposal for something lighter weight. Python has two string … [View More]formatting mini-languages. Both allow formatting flags, for example in "%03d", the "0" (zero) is a flag that means to pad with leading zeroes. I propose to add a string format flag to both mini-languages that explicitly says, "this argument is callable, and its *return value* should be formatted." In current Python: >>> expensive = lambda: 2 >>> logging.debug('%03d %03d', 1, expensive()) In this case, the "expensive" code is executed even though nothing is logged. >>> expensive = lambda: 2 >>> logging.root.setLevel(logging.DEBUG) >>> logging.debug('%03d %03d', 1, expensive()) DEBUG:root:001 002 With a different log level, the expensive code is executed and the message is logged. The suggested change is to add a "C" flag to the formatting language that indicates an argument is callable. When formatting the string, the argument will be called and its result will be used for the formatting operation. The C flag must be handled before any other flags, regardless of the order in which they are specified. The callable's return value is then formatted according to the rest of the specifier. With this change, the above example can now be written as: >>> expensive = lambda: 2 >>> logging.debug('%03d %C03d', 1, expensive) The "expensive" code is not executed at this log level. >>> expensive = lambda: 2 >>> logging.root.setLevel(logging.DEBUG) >>> logging.warn('%03d %C03d', 1, expensive) WARNING:root:001 002 The expensive code is *only* executed when the message will be logged. The callable's return value is formatted with the specifier '%03d', i.e. the same specifier as the callable but without the "C" flag. Pros: 1) Much smaller change to the language. 2) Simplifies a common (?) problem with logging. 3) Applies to all string formatting, not just logging. (But I'm not sure what the other use cases are.) Cons: 1) Doesn't generalize as well as the various "delayed" proposals. (But I'm not sure what other use cases "delayed" has.) [View Less]

5 5

Light-weight call-by-name syntax in Python
by Stephan Houben Feb. 19, 2017

Feb. 19, 2017

Proposal: Light-weight call-by-name syntax in Python The following syntax a : b is to be interpreted as: a(lambda: b) Effectively, this gives a "light-weight macro system" to Python, since it allows with little syntax to indicate that the argument to a function is not to be immediately invoked. It is a generalization of special-case syntax proposals like delayed: <expr> In this proposal, `delayed' can be a normal callable. Motivating examples follow: # Logging # The … [View More]

4 6

Efficient debug logging
by Barry Scott Feb. 19, 2017

Feb. 19, 2017

A common pattern I use is to have logging calls for debug and information with my applications. The logging calls can be separately enabled and disabled. For example: debug_log_enabled = False def debugLog( msg ): If debug_log_enabled: print( ‘Debug: %s’ % (msg,) ) Then the caller can simple write: def main(): debugLog( ‘Start of main’ ) This is fine until the evaluation of the msg becomes expensive. debugLog( ‘info is %r’ % (expensiveFunction(),) ) What would be … [View More]

15 30

Re: [Python-ideas] Light-weight call-by-name syntax in Python
by Stephan Houben Feb. 18, 2017

Feb. 18, 2017

Hi Erik, I have changed my proposal to the alternative syntax a:: b (Note my preferred spacing. This is to make it read like some annoation applied to the expression, like delayed:: expensive_function()+1 ) Since :: is a binary operator, we need to think about associativity. My conservative proposal would be to make it non-associative, you would have to write explicitly a:: (b:: c) or (a:: b):: c Stephan Op 17 feb. 2017 22:35 schreef "Erik" <python(a)lucidity.plus.com>: On 17/… [View More]

1 0

Fwd: Detecting Attribute Updates on Objects
by Gustavo Rehermann Feb. 17, 2017

Feb. 17, 2017

Whoops, I forgot to subscribe before. Seems like now I'm able to send this idea, so let's try again :) ================ According to this idea, the interpreter calls a function on an object O everytime an attribute A of it changes, recursing through objects that contain O as attribute as well. Avoiding loops too (refer to P3 below). Explanation: P1. When setting any property of an object inside a property, the interpreter should also call "__update_attr__(self, attr_name, old_item, new_item)"… [View More]

1 0

Passive tracing of function objects (was: Efficient debug logging)
by C Anthony Risinger Feb. 15, 2017

Feb. 15, 2017

On Tue, Feb 14, 2017 at 3:55 PM, Barry <barry(a)barrys-emacs.org> wrote: > > > The point is that the cost of creating the msg argument can be very high. > > At the point that logging decides to skip output it is to late to save the > cost of creating the arg tuple. > Awhile back I was playing with some code for the purpose of adding debug logs "after the fact": https://github.com/anthonyrisinger/retrospect/blob/master/README.rst I'm not trying to plug it (It's POC,… [View More]

1 1

Python package index: query and rating
by George Fischhof Feb. 15, 2017

Feb. 15, 2017

Hi There, I several times found that it is quite difficult to find an appropriate library in package index. I have two ides to improve the package index: 1.) Query like in a webshop: checkboxes should use to select from attributes. (topic, environment, category etc) It would br good to put a "do not want" column as well. For example right now I would like to search for a cryptographic library and I have the following page https://pypi.python.org/pypi?:action=browse&c=401 It contains … [View More]

4 3

Re: [Python-ideas] Python package index: query and rating
by George Fischhof Feb. 15, 2017

Feb. 15, 2017

2017-02-15 12:35 GMT+01:00 Paul Moore <p.f.moore(a)gmail.com>: > On 15 February 2017 at 11:07, Steven D'Aprano <steve(a)pearwood.info> wrote: > >> I have two ides to improve the package index: > > > > Thank you for your ideas, but I don't think this is the right place for > > suggesting improvements to PyPI. You could try looking through the list > > of other Python mailing lists: > > > > https://mail.python.org/mailman/listinfo > … [View More]

1 0