Mailman 3 October 2009 - Python-ideas

Minimalist `except` syntax.
by cool-RR Oct. 19, 2009

Oct. 19, 2009

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 Oct. 19, 2009

Oct. 19, 2009

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 > … [View More]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/) [View Less]

1 0

Comment syntax similar to /* */ in C?
by Sturla Molden Oct. 18, 2009

Oct. 18, 2009

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

5 4

Making assert raise a different exception type
by cool-RR Oct. 16, 2009

Oct. 16, 2009

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 Oct. 14, 2009

Oct. 14, 2009

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

14 22

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

Oct. 12, 2009

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

5 7

SyntaxWarning for for/while/else without break or return?
by Stefan Rank Oct. 11, 2009

Oct. 11, 2009

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

16 69

for/except/else syntax
by Bruce Leban Oct. 10, 2009

Oct. 10, 2009

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 Oct. 10, 2009

Oct. 10, 2009

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

14 18

for/else syntax
by Yuvgoog Greenle Oct. 7, 2009

Oct. 7, 2009

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

23 110