Mailman 3 June 2009 - Python-ideas

Re: [Python-ideas] Accessing the result of comprehension's expression from the conditional
by average 20 Jun '09

20 Jun '09

From: Lie Ryan wrote: > In list/generator comprehension, currently we have no way to access the > result of the expression and have to write something like this: > > [f(x) for x in l if f(x) > 0] > > if f() is heavy or non-pure (i.e. have side effects), calling f() twice > might be undesirable. > > I'm suggesting about something like: > > [f(x) for x in l if @ > 0] > > where @ is the result of the listcomp's expression (i.e. f(x)) > > Personally, I don't like the use of symbols like @, as python is not > perl. I'm still thinking of a better syntax/approach and is open for > suggestion. > > What do you guys think? I think it's a fine idea. The English language has evolved such a construct, typically used when one wants to highlight (rather than simply *refer* (as a pronoun does) to) the dominant noun without resorting to redundancy. [f(x) for x in l if same > 0] OR another possibility [f(x) for x in l if self > 0] obviously syntax highlighting makes this (or any keyword) standout better. Would be interesting to consider other usages for such a keyword addition (in the case of the former). Aahz: > Listcomps and genexps are like lambdas: run up against their limits and > you should switch to a regular for loop or generator. Generally decent advice, but there is value to exploring the Kolomogorov optimums for a given expressive need (compressing the highest amount of meaning in the simplest construction). In fact, I consider Python to be one of best languages in this regard (it's syntax being the evolution of programming-expressive compactness while being complete in itself. (In contrast to Perl, for example, which offloads the complexity to the programmer.) mark

2 1

Re: [Python-ideas] Aid reiteration with new class: gfic
by yoav glazner 20 Jun '09

20 Jun '09

On Fri, Jun 19, 2009 at 6:11 AM, Steven D'Aprano <steve(a)pearwood.info>wrote: > On Fri, 19 Jun 2009 07:02:12 am Terry Reedy wrote: > > As I see it, the correct solution for "my function needs to iterate over > an iterable twice" is not to expect the caller to pass a sequence, but > to convert the iterable to a sequence inside your function: > > def function(iterable): > # Iterate over iterable twice > L = list(iterable) > for _ in (1, 2): > for x in L: > pass > As I see it the correct solution is def function(iterable): # Iterate over iterable twice L = iterable.clone() #can be done? for x in L: pass for x in iterable : pass this way i avoid endless iterators...

9 11

enhance filecmp to support text-and-universal-newline-mode file comparison
by zhong nanhai 19 Jun '09

19 Jun '09

Hello everyone: We know that we often use programmes or scripts to generate useful output files ,but these files may come from different OS platforms. Comparing them by reading line by line may seem a bit trivial and we can use the filecmp model to do such thing(the cmp function). But when we try to compare two text files from different platforms,e.g. Ubuntu and Windows, even though these two files contain the same content, the filecmp.cmp will return false.We know that the reason is different ways to handle newline flag in different platforms, '\n\r' for Windows,'\n' for Unix,'\r' for Mac, e.t.c. So is it a good idea to enhance the filecmp to support universal-newline-mode?If so, we can compare different files from different operation systems and if they have the same content, the filecmp.cmp would return true. Hoping everyone can give some advice about this idea. Thanks in advance, higer

2 1

Possible method of distinguishing between set-literals, dict-literals, and odict-literals
by Carl Johnson 18 Jun '09

18 Jun '09

I thought of this in the shower. It might not be a good idea, but I'd like to hear what other people think. On analogy with b"", r"", etc. we could introduce an empty set-literal and an odict-literal, and add a more explicit form to replace the existing set literal. s{} could be the empty set, o{} could be an empty odict, and we could leave {} alone as the form for dicts. So, an odict literal would look like o{'a':'1', 'b':'2', 'c':'3'} instead of OrderedDict([('a', '1'), ('b', '2'), ('c', '3')]). And the set {'a', 'c', 'b'} could (optionally?) have a little s{'a', 'c', 'b'} to make it more explicit that this is a set, not a dict. I suppose if we wanted to get crazy, we could also have a frozenset literal, fs{}… So what do people think? Is this too ugly to do? Does it confuse users who are used to C-style braces? Or is it a logical extension of the b"", r"", etc. system that could help make things follow EIBI better? -- Carl Johnson

16 28

file(fn).read()
by spir 14 Jun '09

14 Jun '09

Hello, this post is half a question, half a proposal. Q: what happens to the filesystem file, and to the python file object below? text = file(fn).read() (used 'file' instead of 'open' in purpose) Note that there seemingly is no way to close or del the file object, nor even to check its 'closed' flag. I would expect that, in the case a file remains unnnamed, it is automatically closed and del-ed. If not, do you think it is sensible to ensure that? In this case, we have a both safe and compact idiom to read file content. I consider this good, because the concept of "read file content" is both a single and simple operation -- and rather common. Else, I would propose a pair of string methods (rather than 2 more builtin funcs) .filetext() & .filebytes(). In both cases, the target string is (supposed to be) a filename. Below an example. =================== class FString(str): ''' custom string implementing file content reading ''' TEXT_MODE = 'r' BYTES_MODE = 'rb' NO_FILE_MESSAGE = 'Cannot open file "%s".' def filetext(self): return self._filecontent(FString.TEXT_MODE) def filebytes(self): return self._filecontent(FString.BYTES_MODE) def _filecontent(self, mode): try: f = open(self, mode) except IOError,e: raise ValueError(FString.NO_FILE_MESSAGE % self) bytes = f.read() f.close() return bytes =================== >>> from FString import FString >>> fn = FString("test.txt") >>> fn.filetext() 'foo\nbar\n' >>> fn.filebytes() 'foo\nbar\n' >>> fn = FString("fool.txt") >>> fn.filetext() Traceback (most recent call last): File "<stdin>", line 1, in <module> File "FString.py", line 12, in filetext raise ValueError(NO_FILE_MESSAGE % fn) ValueError: Cannot open file "fool.txt". =================== I take the opportunity to ask whether there is a chance in the future to be able to customize builtin types. (In this case many proposals on this list will simply vanish.) Denis ------ la vita e estrany

5 5

with statement vs. try...except...finally
by Gerald Britton 03 Jun '09

03 Jun '09

I'm wondering if the "with" statement should have exception clauses like the "try" statement, even though this seems to defeat part of the reason for the "with" statement. Currently I have a program segment that opens a file and reads a line, something like this (distilled to its elements for illustration): try: f = open('foo') line = f.readline() f.close() except IOError: line = 'default' So that I get a default value if anything goes awry whilst reading the file. If I write it using a "with" statement, I might have: line = 'default' with open('foo') as f: line = f.readline() Fine so far, but what if I want to be more granular? e.g. with "try...except": try: f = open('foo') except IOError: line = "can't open" try: line = f.readline() except IOError: line = "can't read" try: f.close() except IOError: line = "can't close" I can't see how to replace the above try-triplet with a "with" encapsulation. Or, do I have to wrap the "with" statement in try like this: try: with open('foo') as f: line = f.readline() except IOError: line = 'problem with read or close" -- Gerald Britton

11 13

Python-ideas June 2009