Re: [Python-Dev] Status of the fix for the hash collision ulnerability
Am 15.01.2012 15:27, schrieb Victor Stinner: I don't think that it would be hard to patch this library to use another hash function. It can implement its own hash function, use MD5, SHA1, or anything else. hash() is not stable accross Python versions and 32/64 bit systems. As I wrote in a reply further down: no, it isn't hard to change this behaviour (and I find the current caching system, which uses hash() on an URL to choose the cache index, braindead to begin with), but, as with all other considerations: the current version of the library, with the default options, depends on hash() to be stable for the cache to make any sense at all (and especially with "generic" schema such as the referenced xml.dtd, caching makes a lot of sense, and not being able to cache _breaks_ applications as it did mine). This is juts something to bear in mind. -- --- Heiko. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python.org crashing Mozilla?
Am Dienstag, 26. April 2005 22:53 schrieb Paul Dubois: > Three different computers running Linux / Mozilla are crashing Mozilla > when directed to python.org. A Netscape works ok. Are we hacked or are > we showing off? Firefox on Gentoo works okay...? -- --- Heiko. listening to: Incubus - Megalomaniac see you at: http://www.stud.mh-hannover.de/~hwundram/wordpress/ pgpFEmDQR8jXl.pgp Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] socket module recvmsg/sendmsg
Hi all! I've implemented recvmsg and sendmsg for the socket module in my private Python tree for communication between two forked processes, which are essentially wrappers for proper handling of SCM_RIGHTS and SCM_CREDENTIALS Unix-Domain-Socket messages (which are the two types of messages that are defined on Linux). The main reason I need these two primitives is that I require (more or less transparent) file/socket descriptor exchange between two forked processes, where one process accepts a socket, and delegates processing of the socket connection to another process of a set of processes; this is much like a ForkingTCPServer, but with the Handler-process prestarted. As connection to the Unix-Domain-Socket is openly available, the receiving process needs to check the identity of the first process; this is done using a getsockopt(SO_PEERCRED) call, which is also handled more specifically by my socket extension to return a socket._ucred-type structure, which wraps the pid/uid/gid-structure returned by the corresponding getsockopt call, and also the socket message (SCM_CREDENTIALS) which passes or sets this information for the remote process. I'd love to see these two socket message primitives (of which the first, SCM_RIGHTS, is available on pretty much any Unix derivative) included in a Python distribution at some point in time, and as I've not got the time to push for an inclusion in the tree (and even less time to work on other Python patches myself) at the moment, I thought that I might just post here so that someone interested might pick up the work I've done so far and check the implementation for bugs, and at some stage these two functions might actually find their way into the Python core. Anyway, my private Python tree (which has some other patches which aren't of general interest, I'd think) is available at: http://dev.modelnine.org/hg/python and I can, if anyone is interested, post a current diff of socketmodule.* against 2.4.3 to the Python bug tracker at sourceforge. I did that some time ago (about half a year) when socket-passing code wasn't completely functioning yet, but at least at that point there didn't seem much interest in the patch. The patch should apply pretty cleanly against the current HEAD too, at least it did the last time I checked. I'll add a small testsuite for both functions to my tree some time tomorrow. --- Heiko. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Python long command line options
Hi all! Martin von Löwis said that it'd be necessary to discuss a patch to Python's ability to parse command-line parameters to the interpreter here, and I thought I might start the ball rolling. The associated patch of mine is: http://sourceforge.net/tracker/index.php?func=detail&aid=1481112&group_id=5470&atid=305470 which refers to: http://groups.google.de/group/comp.lang.python/browse_thread/thread/e3db1619040d7c6c/3c119e09122c83ed?hl=de#3c119e09122c83ed (sorry for the long URLs, tinyurl isn't working for me at the moment...) The patch itself is an extension of the Python/getopt.c module to handle long command-line parameters (including option data passed as --=), which are specified in the optstring as: "[(longopt)][:]" for example: "V(version)" or "c(command):" The patch doesn't change behaviour on old optstrings, except where an old optstring relied on the fact that one of :, (, ) are valid parameter names (because of the unconditional strchr to find the option name). I've not found any reference to _PyOS_GetOpt besides the one in Modules/main.c, so I don't think this change in behaviour breaks any existing code. The patch relies only on usability of strchr (which the old getopt.c did too), removes a usage of strcmp which was completely unneccesary, fixes some checks which were unneccesarily broad (>= replaced by ==), and compilation doesn't show any warnings on gcc 3.4.6; as for Windows (and MSVC), I don't have the means to test there. The current patch offers prefix matching: when an option is only specified with a significant amount of prefix characters which doesn't match any other long option, the patch assumes that the user meant this option. For example: --ver would also be interpreted as command-line parameter --version just as would --v --ve --vers --versi --versio if there are no other long options that start with the corresponding prefix. This "trick" is easy enough to remove from the sources, though, so that only correctly spelled options are actually returned. Anyway, back on topic, I personally agree with the people who posted to comp.lang.python that --version (and possibly --help, possibly other long parameters too) would be useful additions to Pythons command-line parameters, as it's increasingly getting more common amongst GNU and BSD utilities to support these command-line options to get information about the utility at hand (very popular amongst system administrators) and to use long commandline options to be able to easily see what an option does when encountered in a shell script of some sort. And, as this doesn't break any old code (-V isn't going away by the patch), I personally find this to be a very useful change. Your thoughts? --- Heiko. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python long command line options
Am Donnerstag 04 Mai 2006 15:41 schrieb Georg Brandl: > Heiko Wundram wrote: > > Your thoughts? > > Personally, I'm +1, but wonder if it would be enough to support '--help' > and '--version'. We then could cut out the "best guess" code and the code > to enable --opt=value. The code for the above functionality is about 10-12 lines of C of the whole patch. If there's concensus to remove it, I'll gladly prepare a patch that doesn't contain this, but I don't think it's sensible to do so just because it makes the code shorter. But, the "best guess" functionality most certainly is debatable on other grounds. --- Heiko. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python long command line options
Am Donnerstag 04 Mai 2006 16:21 schrieb Fredrik Lundh: > I'm +1 on adding --help and --version, +1 on adding -? and /? for windows > only, -0=slightly sceptical if adding a generic long option machinery is > worth it, and -1 on a guessing machinery. I've updated the patch on the SourceForge tracker to reflect this criticism. In effect: 1) --help and --version are added unconditionally on all platforms 2) -? and /? are recognized on Windows, as are /help and /version, because / is just a different longopt-specifier on Windows for the getopt machinery in _PyOS_GetOpt 3) I removed the prefix matching 4) I removed the last reference to a string function in _PyOS_GetOpt 5) --command, which was a test-case for me, has been removed as a long-opt again. The module has undergone a complete rewrite with this patch, and I've adapted the module header to reflect this (because there's absolutely no legacy code left now, which can be seen pretty clearly when you look at a diff...). The usage output in Modules/main.c has also been adapted, as have the test cases in test_cmd_line.py for usage and version, which pass cleanly for me. The patch doesn't produce any warnings on gcc 3.4.6, and I've tested the Windows-specific additions to _PyOS_GetOpt by injecting MS_WINDOWS into the compilation on my system for Python/getopt.c, and it produces correct results on /?, /version, /help, and -?, but as I said before I can't tell whether there are bugs left which surface when it's being compiled on Windows directly, as I don't have a Windows system to test this patch on. Anyway, would be glad to hear any feedback. --- Heiko. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python long command line options
Am Donnerstag 04 Mai 2006 21:25 schrieb Heiko Wundram: > 2) -? and /? are recognized on Windows, as are /help and /version, >because / is just a different longopt-specifier on Windows for the >getopt machinery in _PyOS_GetOpt Just on a side-note: I chose for '/' to be a long-opt identifier on Windows, because it is for pretty much any Microsoft programming tool out there, starting with the linker, ending with the compiler of MSVC++, amongst others. I know that shell commands such as dir, etc. take / to be similar to - on *nix (as single character command line arguments), but I guess the former is more useful. It's no problem to change this behaviour, though. --- Heiko. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] correction of a bug
Am Samstag 13 Mai 2006 17:30 schrieb draconux:
> I found a bug in python
> I'm using python 2.4 with debian etch
>
> string.lstrip("source/old_prog","source/") return "ld_prog" instead of
> "old_prog"
This is not a bug, but rather expected behaviour. Read the specification of
lstrip() correctly.
--- Heiko.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New string method - splitquoted
Am Donnerstag 18 Mai 2006 06:06 schrieb Dave Cinege: > This is useful, but possibly better put into practice as a separate > method?? I personally don't think it's particularily useful, at least not in the special case that your patch tries to address. 1) Generally, you won't only have one character that does quoting, but several. Think of the Python syntax, where you have ", ', """ and ''', which all behave slightly differently. The logic for " and ' is simple enough to implement (basically that's what your patch does, and I'm sure it's easy enough to extend it to accept a range of characters as splitters), but if you have more complicated quoting operators (such as """), are you sure it's sensible to implement the logic in split()? 2) What should the result of "this is a \"test string".split(None,-1,'"') be? An exception (ParseError)? Silently ignoring the missing delimiter, and returning ['this','is','a','test string']? Ignoring the delimiter altogether, returning ['this','is','a','"test','string']? I don't think there's one case to satisfy all here... 3) What about escapes of the delimiter? Your current patch doesn't address them at all (AFAICT) at the moment, but what should the escaping character be? Should "escape processing" take place, i.E. what should the result of "this is a \\\"delimiter \\test".split(None,-1,'"') be? Don't get me wrong, I personally find this functionality very, very interesting (I'm +0.5 on adding it in some way or another), especially as a part of the standard library (not necessarily as an extension to .split()). But there's quite a lot of semantic stuff to get right before you can implement it properly; see the complexity of the csv module, where you have to define pretty much all of this in the dialect you use to parse the csv file... Why not write up a PEP? --- Heiko. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New string method - splitquoted
Am Donnerstag 18 Mai 2006 10:21 schrieb Giovanni Bajo: > Heiko Wundram <[EMAIL PROTECTED]> wrote: > > Don't get me wrong, I personally find this functionality very, very > > interesting (I'm +0.5 on adding it in some way or another), > > especially as a > > part of the standard library (not necessarily as an extension to > > .split()). > > It's already there. It's called shlex.split(), and follows the semantic of > a standard UNIX shell, including escaping and other things. I knew about *nix shell escaping, but that isn't necessarily what I find in input I have to process (although generally it's what you see, yeah). That's why I said that it would be interesting to have a generalized method, sort of like the csv module but only for string "interpretation", which takes a dialect, and parses a string for the specified dialect. Remember, there also escaping by doubling the end of string marker (for example, '""this is not a single argument""'.split() should be parsed as ['"this','is','not','a',]), and I know programs that use exactly this format for file storage. Maybe, one could simply export the function the csv module uses to parse the actual data fields as a more prominent method, which accepts keyword arguments, instead of a Dialect-derived class. --- Heiko. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New string method - splitquoted
Am Donnerstag 18 Mai 2006 12:26 schrieb Giovanni Bajo: > I believe the standard library already covers common usage. There will > surely be cases where a custom lexer/splitetr will have to be written, but > that's life The csv data field parser handles all common usage I have encountered so far, yes. ;-) But, generally, you can't (easily) get at the method that parses a data field directly, that's why I proposed to publish that method with keyword arguments. (actually, I've only tried getting at it when the csv module was still plain-python, I wouldn't even know whether the "method" is exported now that the module is written in C). I've had the need to write a custom lexer time and again, and generally, I'd love to have a little more general string interpretation facility available to spare me from writing a state automaton... But as I said before, the "simple" patch that was proposed here won't do for my case. But I don't know if it's worth the trouble to actually write a more general version, because there are quite some different pitfalls that have to be overcome... I still remain +0.5 for adding something like this to the stdlib, but only if it's overly general so that it can handle all cases the csv module can handle. --- Heiko. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New string method - splitquoted
Am Donnerstag 18 Mai 2006 17:11 schrieb Guido van Rossum: > (Did anyone mention the csv module yet? It deals with this too.) Yes, mentioned it thrice. ;-) --- Heiko. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New string method - splitquoted
Am Donnerstag 18 Mai 2006 06:06 schrieb Dave Cinege: > This is useful, but possibly better put into practice as a separate > method?? I personally don't think it's particularily useful, at least not in the special case that your patch tries to address. 1) Generally, you won't only have one character that does quoting, but several. Think of the Python syntax, where you have ", ', """ and ''', which all behave slightly differently. The logic for " and ' is simple enough to implement (basically that's what your patch does, and I'm sure it's easy enough to extend it to accept a range of characters as splitters), but if you have more complicated quoting operators (such as """), are you sure it's sensible to implement the logic in split()? 2) What should the result of "this is a \"test string".split(None,-1,'"') be? An exception (ParseError)? Silently ignoring the missing delimiter, and returning ['this','is','a','test string']? Ignoring the delimiter altogether, returning ['this','is','a','"test','string']? I don't think there's one case to satisfy all here... 3) What about escapes of the delimiter? Your current patch doesn't address them at all (AFAICT) at the moment, but what should the escaping character be? Should "escape processing" take place, i.E. what should the result of "this is a \\\"delimiter \\test".split(None,-1,'"') be? Don't get me wrong, I personally find this functionality very, very interesting (I'm +0.5 on adding it in some way or another), especially as a part of the standard library (not necessarily as an extension to .split()). But there's quite a lot of semantic stuff to get right before you can implement it properly; see the complexity of the csv module, where you have to define pretty much all of this in the dialect you use to parse the csv file... Why not write up a PEP? --- Heiko. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP-xxx: Unification of for statement and list-comp syntax
Hi all!
The following PEP tries to make the case for a slight unification of for
statement and list comprehension syntax.
Comments appreciated, including on the sample implementation.
===
PEP: xxx
Title: Unification of for-statement and list-comprehension syntax
Version: $Revision$
Last-Modified: $Date$
Author: Heiko Wundram <[EMAIL PROTECTED]>
Status: Active
Type: Standards Track
Content-Type: text/plain
Created: 21-May-2006
Post-History: 21-May-2006 17:00 GMT+0200
Abstract
When list comprehensions were introduced, they added the ability
to add conditions which are tested before the expression which is
associated with the list comprehension is evaluated. This is
often used to create new lists which consist only of those items
of the original list which match the specified condition(s). For
example:
[node for node in tree if node.haschildren()]
will create a new list which only contains those items of the
original list (tree) whose items match the havechildren()
condition. Generator expressions work similarily.
With a standard for-loop, this corresponds to adding a continue
statement testing for the negated expression at the beginning of
the loop body.
As I've noticed that I find myself typing the latter quite often
in code I write, it would only be sensible to add the corresponding
syntax for the for statement:
for node in tree if node.haschildren():
as syntactic sugar for:
for node in tree:
if not node.haschildren():
continue
There are several other methods (including generator-expressions or
list-comprehensions, the itertools module, or the builtin filter
function) to achieve this same goal, but all of them make the code
longer and harder to understand and/or require more memory, because
of the generation of an intermediate list.
Implementation details
The implementation of this feature requires changes to the Python
grammar, to allow for a variable number of 'if'-expressions before
the colon of a 'for'-statement:
for_stmt: 'for' exprlist 'in' testlist_safe ('if' old_test)* ':'
suite ['else' ':' suite]
This change would replace testlist with testlist_safe as the
'in'-expression of a for statement, in line with the definition of
list comprehensions in the Python grammar.
Each of the 'if'-expressions is evaluated in turn (if present), until
one is found False, in which case the 'for'-statement restarts at the
next item from the generator of the 'in'-expression immediately
(the tests are thus short-circuting), or until all are found to be
True (or there are no tests), in which case the suite body is executed.
The behaviour of the 'else'-suite is unchanged.
The intermediate code that is generated is modelled after the
byte-code that is generated for list comprehensions:
def f():
for x in range(10) if x == 1:
print x
would generate:
2 0 SETUP_LOOP 42 (to 45)
3 LOAD_GLOBAL 0 (range)
6 LOAD_CONST 1 (10)
9 CALL_FUNCTION1
12 GET_ITER
>> 13 FOR_ITER28 (to 44)
16 STORE_FAST 0 (x)
19 LOAD_FAST0 (x)
22 LOAD_CONST 2 (1)
25 COMPARE_OP 2 (==)
28 JUMP_IF_FALSE9 (to 40)
31 POP_TOP
3 32 LOAD_FAST0 (x)
35 PRINT_ITEM
36 PRINT_NEWLINE
37 JUMP_ABSOLUTE 13
>> 40 POP_TOP
41 JUMP_ABSOLUTE 13
>> 44 POP_BLOCK
>> 45 LOAD_CONST 0 (None)
48 RETURN_VALUE
where all tests are inserted immediately at the beginning of the
loop body, and jump to a new block if found to be false which pops
the comparision from the stack and jumps back to the beginning of
the loop to fetch the next item.
Implementation issues
The changes are backwards-compatible, as they don't change the
default behaviour of the 'for'-loop. Also, as the changes that
this PEP proposes don't change the byte-code structure of the
interpreter, old byte-code continues to run on Python with this
addition unchanged.
Implementation
A sample implementation (with updates to the grammar documentation
and a small test case) is available at:
http://sourceforge.net/tracker/index.php?func=detail&aid=1492509&group_id=5470&am
Re: [Python-Dev] PEP-xxx: Unification of for statement and list-comp syntax
Am Sonntag 21 Mai 2006 17:38 schrieb Guido van Rossum: > -1. The contraction just makes it easier to miss the logic. I actually don't think so, because it's pretty synonymous to what 'if' means for list comprehensions which use the same keywords (that's why I called it "unification of ... syntax"), but I guess it's superfluous to discuss this if you're -1. > Also, it would be a parsing conflict for the new conditional > expressions (x if T else y). It isn't, if you change the grammar to use testlist_safe as the 'in'-expression, just as is used for list comprehensions. As I've said in the PEP, I've created a patch that implements this, and Python's test suite passes cleanly (except for a little buglet in test_dis, which stems from the fact that the generated byte-code for a for-loop is slightly altered by this patch). > This was proposed and rejected before. I haven't seen this proposed before (at least not in PEP form, or with a working implementation against the current trunk, or just in some form of mail on python-dev), so that's why I posted this. But, if I've really repeated things that were proposed before, feel free to ignore this. --- Heiko. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP-xxx: Unification of for statement and list-compsyntax
Am Sonntag 21 Mai 2006 20:31 schrieb Terry Reedy: > Isn't this the same as > > for node in tree: > if node.haschildren(): > > > so that all you would save is ':\n' and the extra indents? Saving an extra indent and the ':\n' makes it quite a bit easier for me to read and understand in the long run. I find: for x in range(10): if not x % 2: print "Another even number:", print x ... print "Finished processing the even number" a lot harder to read and understand than: for x in range(10): if x % 2: continue print "Another even number:", print x ... print "Finished processing the even number" because with the latter it's much more obvious for me how the flow of control in the indented block is structured (and to what part of the loop the condition applies, namely to the whole loop body). That's why I'd prefer the "combination" of the two as: for x in range(10) if not x % 2: print "Another even number:", print x ... print "Finished processing the even number" because the logic is immediately obvious (at least if you find the logic to be obvious when reading list comprehensions, simply because the format is similar), and there's no extra indentation (as in your example), which makes the block, as I said, a lot easier to parse for my brain. But, probably, that's personal preference. --- Heiko. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP-xxx: Unification of for statement and list-comp syntax
Am Sonntag 21 Mai 2006 18:08 schrieb Steven Bethard: > While this has been proposed before, I'd like to thank you for putting > together a full PEP and a working implementaiton. I think you should > still submit the PEP, if for nothing else so that when the issue comes > up again, we can point to the PEP and explain that Guido's already > rejected it. I'll submit the PEP tomorrow, after I've reworded it slightly. I'll also add Guido's rejection notice to the PEP, so that a number can be assigned to it properly and it can be added to the PEP list on python.org. --- Heiko. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP-xxx: Unification of for statement and list-comp syntax
Am Sonntag 21 Mai 2006 22:11 schrieb Talin: > As a general guideline, I've noticed that proposals which are purely > syntactic sugar are unlikely to be accepted unless there is some > additional benefit other than just compression of source code. I know about this, but generally, I find there's more to this "syntactic sugar" than just source code compression. 1) It unifies the syntax for list comprehensions and for loops, which use the same keywords (and are thus identified easily). Basically, you can then think of a for-loop as a list comprehension which evaluates a suite instead of an expression, and doesn't store the evaluated items, or vice versa, which at the moment you can't, because of the difference in setup. 2) Just as I've replied to Terry J. Reed, if you find list comprehensions easy to read, you're also bound to be able to understand what "for in if :" does, at least AFAICT. 3) Generally, indentation, as Terry J. Reed suggested, isn't always good. If the body of the loop is more than a few lines long (which happens more often than not in my code), extra indentation is bound to confuse me. That's why I use "if not : continue" at the moment, so that I don't need extra indentation. If I could just append the condition to the loop to get it out of the way (just as you do with a list comprehension), I save the obnoxious "if not : continue" (which destroys my read flow of the body somewhat too), and still get the same behaviour without any extra (errorprone, in my eyes) indentation. Anyway, it's fine if Guido says this is -1. I don't need to discuss this, as I guess it's a pretty futile attempt to get people to consider this against Guido's will. I just found this to be something I'd personally longed for for a long time, and had time free today, so I thought I'd just implement it. ;-) And, additionally, nobody's keeping me from making my own Python tree where I can keep this patch for my very personal scripts where I don't need to have interoperability. This is open source, isn't it? ;-) --- Heiko. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP-xxx: Unification of for statement and list-comp syntax
Am Montag 22 Mai 2006 01:59 schrieb Josiah Carlson: > > 1) It unifies the syntax for list comprehensions and for loops, which use > > the > > No, it /partially unifies/ list comprehensions and for loops. To > actually unify them, you would need to allow for arbitrarily nested fors > and ifs... > > for ... in ... [if ...] [for ... in ... [if ...]]*: > > If I remember correctly, this was why it wasn't accepted before; because > actual unification is ugly. This syntax is ugly, that's why the PEP doesn't try to make a case for this. But, one level equivalence to list comprehensions isn't bad, again, at least in my eyes. > > 2) Just as I've replied to Terry J. Reed, if you find list comprehensions > > easy to read, you're also bound to be able to understand what "for > > in if :" does, at least AFAICT. > > Not everyone finds list comprehensions easy to read. Why has Python added list-comprehensions, then? (or at least, why has Python added the 'if'-expression to list-comprehensions if they're hard to read? filter/itertools/any of the proposed "workarounds" in the PEP would also work for list-comprehensions). > > 3) Generally, indentation, as Terry J. Reed suggested, isn't always good. > > If the body of the loop is more than a few lines long (which happens more > > often than not in my code), extra indentation is bound to confuse me. > > That's why I > > [snip] > > I feel for you; I really do. I've done the same thing myself. However, > I don't believe that it is a good practice, in general, and I don't > think that syntax should support this special case. Why isn't this good practice? It's not always sensible to refactor loop code to call methods (to make the loop body shorter), and it's a pretty general case that you only want to iterate over part of a generator, not over the whole content. Because of this, list comprehensions grew the 'if'-clause. So: why doesn't the for-loop? --- Heiko. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP-xxx: Unification of for statement and list-comp syntax
Am Montag 22 Mai 2006 02:22 schrieb Greg Ewing: > Heiko Wundram wrote: > > for node in tree: > > if not node.haschildren(): > > continue > > > > Er, you do realise that can be written more straightforwardly as > >for node in tree: > if node.haschildren(): > Yes, of course. Read my replies to Terry J. Reed, to Josiah Carlton, to Talin, to see why I chose to compare it to the 'continue' syntax. --- Heiko. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP-xxx: Unification of for stateme nt and list-comp syntax
Am Montag 22 Mai 2006 02:46 schrieben Sie: > Heiko Wundram wrote: > > 2) Just as I've replied to Terry J. Reed, if you find list comprehensions > > easy to read, you're also bound to be able to understand what "for > > in if :" does, at least AFAICT. > > I tend to write non-trivial LCs on multiple lines, e.g. > >l = [foo(x) > for x in stuff >if something_about(x)] > > for the very reason that it makes them easier to read. You can also do the same here (by using normal bracketing): for in ( ) if ( and and ): foo(x) --- Heiko. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
