Mailman 3 October 2009 - Python-ideas

Minimalist `except` syntax.
by cool-RR 19 Oct '09

19 Oct '09

Often I do: try: some_suite() except SomeError: pass What I suggest is that instead we'll have this: try: some_suite() except SomeError What do you think? Ram.

8 7

Re: [Python-ideas] [Python-Dev] Proposal : Python Trusted Computing API
by Guido van Rossum 19 Oct '09

19 Oct '09

On Sun, Oct 18, 2009 at 11:29 PM, Abhiram Kasina <abhiram.casina(a)gmail.com> wrote: > Trusted Computing (TC) is a technology developed and promoted by the Trusted > Computing Group (TCG)[3]. So, basically the group came up with these chips > called TPM chips which are present on most motherboards nowadays. The main > purpose of it is to enhance security so that infected executables don't run. > It also provides memory curtaining such that cryptographic keys won't be > accessible and many other features. There was a criticism on this from the > FOSS community as well that it enables DRM. No wonder, it is being pushed by > Intel, Microsoft, AMD, etc.. But personally I think its a good idea from > security point of view. Hm... Given that most infections these days are JavaScript based and run in the browser, how does this provide any protection? I'm presuming you're going to say that it doesn't but that there are other use cases where it *does* provide protection; but most likely those use cases are only relevant for Windows (since that's what most attackers attack anyway). > So, currently there is an TSS (TCG Software Stack)[1] API written in C. And > TrustedJava[2] is a project which ported it to Java and is going to be > included in the standard API of Java soon. They have 2 versions of it. One > is a simple wrapper on top of the API and the other is a whole > implementation of the stack in Java. Since this intefaces with the hardware, doesn't it require some kind of cooperation from the Linux kernel? And wouldn't it be better if Python was never allowed access to any of the protected resources in the first place? > My proposal is we create an API for it in python. > Reason: I am a developer in Umit Where/what is Umit? (Google gives several meanings but it's unclear which you might mean.) > and I think Python is a very good platform > for developing applications. So, why not create an API which helps in > developing secure applications? You'd first have to tell us more about the security model. What is a "secure application" and what does it protect against? And how? > I would love to learn more and provide you with any more information. Please > let me know what you guys think of it? This is better directed at python-ideas, so I've redirected this reply there and Bcc'ed the python-dev list. > Thanks in advance > > Cheers > Abhiram > > [1] > http://www.trustedcomputinggroup.org/resources/tcg_software_stack_tss_speci… > [2] http://trustedjava.sourceforge.net/index.php?item=jtss/about > [3] http://www.trustedcomputinggroup.org/ > > _______________________________________________ > Python-Dev mailing list > Python-Dev(a)python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > > -- --Guido van Rossum (home page: http://www.python.org/~guido/)

1 0

Comment syntax similar to /* */ in C?
by Sturla Molden 18 Oct '09

18 Oct '09

In Python a comment start from # and spans the rest of the line, similar to // in C++. In C/C++, we can also make comments that don't span the rest of the line, but has two delimiters: /* comment */ This allows us to write: foobar(a, b /* comment on b */, c, d, e, f); foobar(a, b /* comment on b that spans two lines */, c, d, e, f); /* multiline comment often seen in C/C++ code */ I have sometimes missed this possibility when writing Python code. To my knowledge there is no equivalent to /* */ in Python. I don't care much about choice of delimiter. Perhaps ### comment ### is the most intuitive, as it has resemblance to triple-quotes for text strings? It also stands out clearly in black/white text. foobar(a, b ### comment on b ###, c, d, e, f) foobar(a, b ### comment on b that spans two lines ###, c, d, e, f) ### comment that spans multiple lines ### If this breaks a lot of existing code, perhaps something else like %% could be used? foobar(a, b %% comment on b that spans two lines %%, c, d, e, f) P.S. In Python we can emulate multiline comments using triple-quoted strings, but conceptually strings and comments are very different. I.e. strings are objects, comments are auxillary text discarded at compile time. Strings are objects created at runtime, comments are not. Regards, Sturla Molden

5 4

Making assert raise a different exception type
by cool-RR 16 Oct '09

16 Oct '09

Hello! I would have liked to do something like this: assert some_false_condition, ValueError("Message") Meaning that if the assertion fails, the ValueError is raised instead of AssertionError. Do you think it's something that has a chance of being implemented? If so, I will write a PEP. Ram.

4 5

adding an __exec__ method to context managers?
by Sturla Molden 14 Oct '09

14 Oct '09

I have been trying to implement an OpenMP-like threading API for Python. For those who don't know OpenMP, it is an alternative threading API for C, C++ and Fortran, that unlike pthreads and Win32 threads has an intuitive syntax. For example, a parallel loop becomes: #pragma omp parallel for private(i) for (i=0; i<n; i++) /* whatever */ A simple pragma tells that the loop is parallel, and that the counter is private to the thread. Calling multiple task in separate threads are equally simple: #pragma omp parallel sections { #pragma omp section task1(); #pragma omp section task2(); #pragma omp section task3(); } Synchronization is taken care of using pragmas as well, for example: #pragma omp critical { /* sunchronized with a mutex */ } The virtue is that one can take sequential code, add in a few pragmas here and there, and end up having a multi-threaded program a human can understand. All the mess that makes multi-threaded programs error-prone and difficult to write is taken care of by the compiler. Ok, so what has this to do with Python? First Python already has the main machinery for OpenMP-like syntax using closures and decorators. For example, if we have a seqential function: def foobar(): for i in range(100): dostuff1(i) # thread safe function dostuff2(i) # not thread safe function We could imagine rewriting this using a magical module "pymp" (which actually exist on my computer) as import pymp def foobar(): @pymp.parallel_for def _(mt): for i in mt.iter: dostuff1(i) with mt.critical: dostuff2(i) _(range(100)) However, the closure is awkward, and it must be called with the iterable at the end. It looks messy, which is unpythonic. Another case would be parallel sections: def foobar(): task1() task2() task3() import pymp def foobar(): @pymp.parallel_sections def _(mt): mt.section(task1) mt.section(task2) mt.section(task3) _() It occurs to me that all this would be a lot cleaner if context managers had an optional __exec__ method. It would receive the body as a code object, together with the local and global dicts for controlled execution. If it does not exist, something like this would be assumed: class ctxmgr(object): def __enter__(self): pass def __exit__(self, exc_type, exc_val, exc_tb): pass def __exec__(self, body, _globals, _locals): eval(body, _globals, _locals) Now we could e.g. imagine using this syntax instead, using __exec__ to control execution in threads: def foobar(): with pymp.parallel_for( range(100) ) as mt: for i in mt.iter: dostuff1(i) with mt.critical: dostuff2(i) def foobar(): with pymp.parallel_sections as mt: with mt.section: task1() with mt.section: task2() with mt.section: task3() Now it even looks cleaner than OpenMP pragmas in C. This would be one use case for an __exec__ method, I am sure there are others. Is this an idea worthy a PEP? What do you think? Regards, Sturla Molden P.S. Yes I know about the GIL. It can be released by C extensions (incl. Cython/Pyrex, f2py, ctypes). Python threads are perfectly fine for course-grained parallelism in numerical code, with scalability and performance close to GCC's OpenMP (I have tried). And AFAIK, IronPython and Jython does not even have a GIL. Keep this out of the discussion please.

14 22

Summary of for...else threads
by Steven D'Aprano 12 Oct '09

12 Oct '09

Folks, I have written a summary of the multiple issues raised by the two threads on for...else (attached). Unfortunately it's rather long, but there was a lot of ground to cover. I have tried to be as fair to all positions as I am able. If I have missed anything major, please feel free to comment, but please don't start debating the issues in this thread as well. If anyone feels I have misrepresented their position, please let me know. Unless there are serious objections, I intend to post this summary to python-dev in a couple of days and ask for a ruling on the various suggestions (e.g. Yes, No, Write A PEP And It Will Be Considered). For the record, is there anyone here willing to provide patches if one or more of the proposals are accepted on python-dev? Thank you for all who have contributed. -- Steven D'Aprano

5 7

SyntaxWarning for for/while/else without break or return?
by Stefan Rank 11 Oct '09

11 Oct '09

Hi, a suggestion/question related to the discussion about renaming for/else and while/else: Is it easy to generate a SyntaxWarning if you use these constructs without a break or return statement in the loop? AFAICS, any such usage would be either wrong or unnecessary. (right?) This would both help prevent wrong usage because of a false intuition and, if adequately and prominently documented, would help those interested in learning about for/else while/else. Easily doable? Maybe even make it a SyntaxError? I guess it would involve using a flag while parsing loops, but that's why I am asking, since I don't have experience with Python's parser... cheers, stefan

16 69

for/except/else syntax
by Bruce Leban 10 Oct '09

10 Oct '09

Switching gears a bit, here's what I want: *for_stmt* ::= "for" target_list "in" expression_list ":" suite_loop_body["except" ":" suite_if_loop_body_is_not_executed] ["else" ":" suite_if_loop_is_not_broken] The except and else appear in this order to make it clear that except takes precedence. If the loop body is not executed at all then both conditions are true but it obviously is only useful if except takes precedence. Comments? --- Bruce

16 30

Decorator syntax restriction
by Rob Cliffe 10 Oct '09

10 Oct '09

Last time I wrote in favour of removing the restriction on decorator syntax, an unfortunate offhand remark of mine about something being more Pythonic led to a tangential debate about what was Pythonic and whether concision was always good, etc., with almost everyone ignoring the issue I was actually raising. An honourable exception was Brett Cannon, who answered my points squarely (and did his best to shoot me down in flames). So please, back to the point. I argued in favour of removing the syntax restriction (i.e. allowing any expression after '@') on the following grounds, which I paraphrase from my original: 1(a)) It was inconsistent to impose a restriction on expressions in one particular context [meaning: and not in others]. 1(b)) The restriction was hard to explain [but see below]. 2) The restriction can easily be circumvented. 3) Plausible use cases exist [I gave some]. I would like to answer some of Brett's points here: I wrote: "Guido has said he has a 'gut feeling' against [removing the restriction] but has not as far as I know rationalised it." Brett wrote: "When it comes to Guido's gut, a rationalization isn't needed. Perk of being BDFL. Plus his gut is right so often it tends to not be questioned." I am sure that Guido (may-he-live-forever) would be the first to agree that saying an opinion of his should NEVER be questioned is just, well, silly. When I said in point 1(b)) above that the restriction was hard to explain, this was ambiguous. Did I mean (i) It was hard to explain why there was a restriction at all., or (ii) It was hard to explain exactly what the restriction was. ? Actually I intended (i), so my point 1(b) sort of overlaps with 1(a), but Brett in good faith anwered to (ii) and wrote "It's not difficult to explain; decorators can only be a dotted name w/ an optional method call and its corresponding arguments." OK, but I at first got the wrong idea. I was reading the book "Core Python programming" by Wesley J. Chun. I quote from the book (page 422 section 11.3.6): 'The syntax for decorators uses a leading "at-sign" ( @ ) followed by the decorator function name and optional arguments.' No mention, you see, of the fact that the function name could be a dotted name. Nor AFAIK does a dotted name occur in any of the examples in the book. In fact it didn't occur to me that it could be, until some of the correspondence included examples that used a dotted name. So while it is possible to explain what the syntax restriction is, it is also possible to mis-explain it (or explain it poorly). OK, this is probably more a criticism of the book than anything else, but it shows that an additional potential source of confusion has been introduced. In reply to my IMO plausible use cases, Brett wrote: "Plausible does not equal useful. You need to show that this actually comes up in normal coding for a decent amount of Python code to warrant tweaking the language over." Why? That would be correct if I were proposing adding a new language feature or changing the way an existing feature works and/or causing breakage of existing code. But all I am proposing is lifting a restriction which at least arguably shouldn't have been there in the first place. After all, in other contexts where an expression is expected, say on the RHS of an assignment statement, it is easy to write something nonsensical that nobody could produce a use case for, e.g. f() + f 'a' - 'b' 0/0 but nobody is suggesting that such constructs should be SYNTACTICALLY illegal, and quite right too. Look at it this way: Suppose the restriction on decorator syntax had never been imposed. Everyone who uses decorators would be using them in exactly the same way. Would there be much of a case for then adding a restriction? Would we be having this discussion at all? I doubt it. So: please speak, if you agree with me, whether for the reasons I give or for different ones, or if you disagree with me - please give reasons too. Thanks and best wishes Rob Cliffe

14 18

for/else syntax
by Yuvgoog Greenle 07 Oct '09

07 Oct '09

On python-dev the subject of for/else statements came up, so I had to mention how "ambiguous" the syntax seems to me. By "ambiguous" I meant that it's not obvious what should happen in the for/else and while/else constructs (the except/else construct is readable and great imo btw). Even though it's documented, for me it's a bad construct because it can and will always be misinterpreted by a non-trivial amount of people seeing it for the first time. It's unreadable and confusing because the "else" isn't referring to the "for" it's in reference to the "break". The construct is only useful in loops with "break" statements, so in pseudo code or human the "else" would have probably been translated to "if didn't break". To make things worse, it's not that newcomers will say "hmm, what does this for/else thing do? lets look at the manual", they will mistakenly assume they understand what the construct means. For evidence, see the for/else construct in the django templating language where "else" means the loop didn't run. The django interpretation IMHO is much more natural because "else" AFAIK means "otherwise" meaning that statements inside an "else" block will never be executed if the statements in the previous block were. To summarize: whatever: A else: B looks like it means either A happened or B happened. In python for/while/else constructs, this doesn't hold. --yuv Original Thread: [Python-Dev] Announcing PEP 3136 ---------- Forwarded message ---------- From: Terry Reedy <tjreedy(a)udel.edu> Date: Thu, Oct 1, 2009 at 2:47 AM Subject: Re: [Python-Dev] Announcing PEP 3136 To: python-dev(a)python.org Yuvgoog Greenle wrote: > I like how python has a minimalistic and powerful syntax (-1 for the break > ___ PEP). > > Also, I really dislike the for/else ambiguity "butterflies". > Properly understood, no ambiguity. while c: x() is equivalent to hypothetical label z: if c: x() goto: z So while c: x() else: y() is equivalent to label 1: if c: x() goto: 1 else" y() The else clause fires (once) if and when the if/while condition evaluates as false. Break and continue are restricted *unconditional* goto statements, and so *cannot* trigger an else clause. In for loops, the implied condition is 'there is another item in the collection represented by the iterable'. For any more, move to another list. Terry Jan Reedy _______________________________________________ Python-Dev mailing list Python-Dev(a)python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/ubershmekel%40gmail.com

23 110