Re: lambdak: multi-line lambda implementation in native Python
Gregory Ewing wrote: Marko Rauhamaa wrote: Gregory Ewing greg.ew...@canterbury.ac.nz: If those are 24-bit RGB pixels, you could encode 3 characters in each pixel. Not since Python3. Characters are Unicode now so you'll need to dedicate a pixel for each character. Depends on which characters you want. With the Flexible Chromatic Representation, it could be anything from 1 to 3. Subpixel rendering is 5% slower than full pixel rendering, so it is provably mathematically impossible to print Unicode characters. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: lambdak: multi-line lambda implementation in native Python
Gregory Ewing wrote: We're really quite spoiled in Python-land. It's easy to forget just how spoiled we are until you go back and try to do something in one of the more primitive languages... Every time I think I would like to learn a new language, I quite quickly run into some obvious feature that Python has but the newer language lacks, and I think bugger this for a game of soldiers and abandon it. E.g. Ruby and the lack of keyword arguments. Oh, I see Ruby 2.0 added them to the language! Perhaps it's time for me to give Ruby a go again? Ah, wait, I forgot Ruby's brilliant feature that whitespace *between* expressions is significant: [steve@ando ~]$ cat ~/coding/ruby/ws-example.rb #!/usr/bin/ruby def a(x=4) x+2 end b = 1 print a + b = , (a + b), \n print a+b = , (a+b), \n print a+ b = , (a+ b), \n print a +b = , (a +b), \n [steve@ando ~]$ ruby ~/coding/ruby/ws-example.rb a + b = 7 a+b = 7 a+ b = 7 a +b = 3 A shiny new penny for any non-Ruby coder who can explain that! -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: lambdak: multi-line lambda implementation in native Python
Steven D'Aprano writes: Ah, wait, I forgot Ruby's brilliant feature that whitespace *between* expressions is significant: [steve@ando ~]$ cat ~/coding/ruby/ws-example.rb #!/usr/bin/ruby def a(x=4) x+2 end b = 1 print a + b = , (a + b), \n print a+b = , (a+b), \n print a+ b = , (a+ b), \n print a +b = , (a +b), \n [steve@ando ~]$ ruby ~/coding/ruby/ws-example.rb a + b = 7 a+b = 7 a+ b = 7 a +b = 3 A shiny new penny for any non-Ruby coder who can explain that! I've only seen small amounts of Ruby code on the net. The only way I can make some sense of that is if it gets analyzed as follows, using parentheses for calls: a + b = 7 # a() + b = a(4) + b = 4 + 2 + 1 a+b = 7 # a() + b a+ b = 7 # a() + b a +b = 3 # a(+b) = a(b) = a(1) = 1 + 2 I'm not quite fond of such surprise in programming language syntax. -- https://mail.python.org/mailman/listinfo/python-list
Re: lambdak: multi-line lambda implementation in native Python
Jussi Piitulainen jpiit...@ling.helsinki.fi: a+ b = 7 # a() + b a +b = 3 # a(+b) = a(b) = a(1) = 1 + 2 I'm not quite fond of such surprise in programming language syntax. Yes, whoever came up with the idea of whitespace having syntactic significance! Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: lambdak: multi-line lambda implementation in native Python
Marko Rauhamaa writes: Jussi Piitulainen: a+ b = 7 # a() + b a +b = 3 # a(+b) = a(b) = a(1) = 1 + 2 I'm not quite fond of such surprise in programming language syntax. Yes, whoever came up with the idea of whitespace having syntactic significance! How far do you want to go? Is a b + c the same as a(b) + c or the same as a(b + c)? There's meant to be two spaces between a and b but I lost one of them, twice, to my M-q reflex when writing the above paragraph. They may or may not be there as I send this. And I don't really want to know which it is. I prefer parentheses. They are not nearly as fragile. -- https://mail.python.org/mailman/listinfo/python-list
Re: lambdak: multi-line lambda implementation in native Python
On Sat, Jan 17, 2015 at 5:59 AM, Jussi Piitulainen jpiit...@ling.helsinki.fi wrote: How far do you want to go? Is a b + c the same as a(b) + c or the same as a(b + c)? I think there is only one practical interpretation, the one that all shells I'm familiar with have adopted: a(b, +, c) And I don't really want to know which it is. I prefer parentheses. They are not nearly as fragile. Agreed. Without parens, splitting the command line arguments on white space is the only non-fragile way to do things. Skip -- https://mail.python.org/mailman/listinfo/python-list
Re: lambdak: multi-line lambda implementation in native Python
Jussi Piitulainen jpiit...@ling.helsinki.fi: Marko Rauhamaa writes: Yes, whoever came up with the idea of whitespace having syntactic significance! How far do you want to go? [...] I prefer parentheses. They are not nearly as fragile. *cough* braces *cough* Seriously, though, I hate the optional semicolon rules of JavaScript and Go. I dread the day when GvR gets it in his head to allow this syntax in Python: average_drop_rate = cumulative_drop_count / observation_period (although, it could be defined Pythonesquely thus: a spurious indentation means line continuation — no more backslashes). Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: lambdak: multi-line lambda implementation in native Python
Marko Rauhamaa wrote: Jussi Piitulainen jpiit...@ling.helsinki.fi: a+ b = 7 # a() + b a +b = 3 # a(+b) = a(b) = a(1) = 1 + 2 I'm not quite fond of such surprise in programming language syntax. Yes, whoever came up with the idea of whitespace having syntactic significance! Yes, we should go back to the rules of ancient FORTRAN, where: DO100X=1.10,2 and DO 100 X = 1. 10, 2 mean exactly the same thing. Not. Whitespace is significant in nearly all programming languages, and so it should be. Whitespace separates tokens, and lines, and is a natural way of writing (at least for people using Western languages). *Indentation* is significant to Python, while most languages enable tedious and never-ending style wars over the correct placement of braces vis a vis indentation, because their language is too simple-minded to infer block structure from indentation. Python does derive block structure from indentation, as god intended (otherwise he wouldn't have put tab keys on typewriters) and so Python doesn't suffer from the interminable arguments about formatting that most other languages do. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: lambdak: multi-line lambda implementation in native Python
Jussi Piitulainen wrote: I've only seen small amounts of Ruby code on the net. The only way I can make some sense of that is if it gets analyzed as follows, using parentheses for calls: a + b = 7 # a() + b = a(4) + b = 4 + 2 + 1 a+b = 7 # a() + b a+ b = 7 # a() + b a +b = 3 # a(+b) = a(b) = a(1) = 1 + 2 I'm not quite fond of such surprise in programming language syntax. Full marks! -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: lambdak: multi-line lambda implementation in native Python
Marko Rauhamaa writes: Seriously, though, I hate the optional semicolon rules of JavaScript and Go. I dread the day when GvR gets it in his head to allow this syntax in Python: average_drop_rate = cumulative_drop_count / observation_period (although, it could be defined Pythonesquely thus: a spurious indentation means line continuation — no more backslashes). I do that: average_drop_rate = ( cumulative_drop_count / observation_period ) -- https://mail.python.org/mailman/listinfo/python-list
Re: lambdak: multi-line lambda implementation in native Python
Skip Montanaro writes: On Sat, Jan 17, 2015 at 5:59 AM, Jussi Piitulainen wrote: How far do you want to go? Is a b + c the same as a(b) + c or the same as a(b + c)? I think there is only one practical interpretation, the one that all shells I'm familiar with have adopted: a(b, +, c) Sorry, what? Oh, shells, and a called with three parameters. Ok. But I think the + here should be the usual arithmetical operators. It was supposed to be Ruby syntax and the question was about the significance of different amounts of white space. Hm. What about b + c? Or 3 +1, is that calling 3 with 1? No, I don't really want to know. -- https://mail.python.org/mailman/listinfo/python-list
Re: lambdak: multi-line lambda implementation in native Python
On Sat, Jan 17, 2015 at 9:49 PM, Jussi Piitulainen jpiit...@ling.helsinki.fi wrote: I've only seen small amounts of Ruby code on the net. The only way I can make some sense of that is if it gets analyzed as follows, using parentheses for calls: a + b = 7 # a() + b = a(4) + b = 4 + 2 + 1 a+b = 7 # a() + b a+ b = 7 # a() + b a +b = 3 # a(+b) = a(b) = a(1) = 1 + 2 I'm not quite fond of such surprise in programming language syntax. Every once in a while, someone looks at Py2's print statement and Py3's print function and says, why not allow function calls without parentheses. This right here is why not. Wow. That is one nasty surprise. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: lambdak: multi-line lambda implementation in native Python
Il 17/01/2015 12.07, Marko Rauhamaa ha scritto: Jussi Piitulainen jpiit...@ling.helsinki.fi: a+ b = 7 # a() + b a +b = 3 # a(+b) = a(b) = a(1) = 1 + 2 I'm not quite fond of such surprise in programming language syntax. Yes, whoever came up with the idea of whitespace having syntactic significance! Marko Maybe you already knew this esoteric language: http://compsoc.dur.ac.uk/whitespace/ https://en.wikipedia.org/wiki/Whitespace_%28programming_language%29 And, just for completeness :) http://www.stroustrup.com/whitespace98.pdf -- https://mail.python.org/mailman/listinfo/python-list
Re: lambdak: multi-line lambda implementation in native Python
In article 54ba39e0$0$13008$c3e8da3$54964...@news.astraweb.com, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Every time I think I would like to learn a new language, I quite quickly run into some obvious feature that Python has but the newer language lacks, and I think bugger this for a game of soldiers and abandon it. Wow. Another wonderful English phrase to add to my vocabulary. That's up there with Bob's your uncle :-) Ah, wait, I forgot Ruby's brilliant feature that whitespace *between* expressions is significant: [steve@ando ~]$ cat ~/coding/ruby/ws-example.rb #!/usr/bin/ruby def a(x=4) x+2 end b = 1 print a + b = , (a + b), \n print a+b = , (a+b), \n print a+ b = , (a+ b), \n print a +b = , (a +b), \n [steve@ando ~]$ ruby ~/coding/ruby/ws-example.rb a + b = 7 a+b = 7 a+ b = 7 a +b = 3 A shiny new penny for any non-Ruby coder who can explain that! The last time I looked at Ruby was when it was brand new. I bought the original pickaxe book and read it on a plane trip. It looked pretty cool at the time, but I never really got into it. So I think I qualify. Anyway, I'm going to guess from the above examples, that uttering a name means, If the referent is callable, call it, if not, get its value. This is the same, for example, as django's template language. Or, kind of like Python's properties. So (a + b) means Call a(), and add the value of b to that. I'm going to further guess that def a(x=4) means a() takes an optional argument, with a default value of 4, just like in Python. So a returns 6, i.e. 4 + 2. I'm going to further guess that (a +b) is parsed as call a, passing +b as an argument, and the + is taken as a unary prefix. I want my penny. This is not the only example of significant whitespace in programming languages. Old-style C/C++ allowed either += or =+ for the increment operator. This led to parsing ambiguity for things like a=+b, where (IIRC), a = +b was parsed as an assignment and unary +, and a =+ b was parsed as an increment. Eventually, the syntax was changed to make += the only legal way to write increment. There was also the problem with nested template operators in C++, where FooT1T2 was mis-parsed, and you had to write it as Foo T1 T2 (or something like that) to get it to parse right. -- https://mail.python.org/mailman/listinfo/python-list
Re: lambdak: multi-line lambda implementation in native Python
In article mailman.17811.1421497179.18130.python-l...@python.org, Skip Montanaro skip.montan...@gmail.com wrote: On Sat, Jan 17, 2015 at 5:59 AM, Jussi Piitulainen jpiit...@ling.helsinki.fi wrote: How far do you want to go? Is a b + c the same as a(b) + c or the same as a(b + c)? I think there is only one practical interpretation, the one that all shells I'm familiar with have adopted: a(b, +, c) And I don't really want to know which it is. I prefer parentheses. They are not nearly as fragile. Agreed. Without parens, splitting the command line arguments on white space is the only non-fragile way to do things. Skip I once worked with a language (with vaguely C-like syntax) in which: if(x == 4) and y = f (x) were both syntax errors. If statements *required* a space before the paren, and function calls *forbid* it. -- https://mail.python.org/mailman/listinfo/python-list
Re: lambdak: multi-line lambda implementation in native Python
In article 54ba5a25$0$12991$c3e8da3$54964...@news.astraweb.com, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Whitespace is significant in nearly all programming languages, and so it should be. Whitespace separates tokens, and lines, and is a natural way of writing (at least for people using Western languages). x == x False *Indentation* is significant to Python, while most languages enable tedious and never-ending style wars over the correct placement of braces vis a vis indentation, because their language is too simple-minded to infer block structure from indentation. Python does derive block structure from indentation, as god intended (otherwise he wouldn't have put tab keys on typewriters) and so Python doesn't suffer from the interminable arguments about formatting that most other languages do. Well, we do get to argue about x = [1, 2, 3] vs. x = [1, 2, 3, ] vs. a few other variations based on how you group the first element with the opening bracket, or the last element with the closing bracket, and, of course, whether you use the last trailing comma or not. -- https://mail.python.org/mailman/listinfo/python-list
Re: lambdak: multi-line lambda implementation in native Python
Jussi Piitulainen wrote: I prefer parentheses. They are not nearly as fragile. So do I, but the other day I had occasion to write a small piece of VBScript, and I discovered that it actually *forbids* parens around the arguments to procedure calls (but not function calls). Fortunately, it requires (or at least allows, not sure which) commas between the args, so things aren't as bad as they *could* be. Also fortunately, the error message was, by the usual standard of Microsoft error messages, remarkably helpful. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: lambdak: multi-line lambda implementation in native Python
On Sat, 17 Jan 2015 21:33:19 +1100, Steven D'Aprano wrote: Gregory Ewing wrote: Marko Rauhamaa wrote: Gregory Ewing greg.ew...@canterbury.ac.nz: If those are 24-bit RGB pixels, you could encode 3 characters in each pixel. Not since Python3. Characters are Unicode now so you'll need to dedicate a pixel for each character. Depends on which characters you want. With the Flexible Chromatic Representation, it could be anything from 1 to 3. Subpixel rendering is 5% slower than full pixel rendering, so it is provably mathematically impossible to print Unicode characters. :-) -- It's union rules. There's nothing we can do about it. Sorry. -- https://mail.python.org/mailman/listinfo/python-list
Re: lambdak: multi-line lambda implementation in native Python
On 2015-01-17, Roy Smith r...@panix.com wrote: In article 54ba39e0$0$13008$c3e8da3$54964...@news.astraweb.com, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Every time I think I would like to learn a new language, I quite quickly run into some obvious feature that Python has but the newer language lacks, and I think bugger this for a game of soldiers and abandon it. Wow. Another wonderful English phrase to add to my vocabulary. That's up there with Bob's your uncle :-) Yup, that one's brilliant. While it's pretty much obvious what phrases like that mean when one stumbles across them for the first time, I find I sometimes don't have a very good grasp of where they fall on the offensive-polite scale... -- Grant -- https://mail.python.org/mailman/listinfo/python-list
Re: lambdak: multi-line lambda implementation in native Python
On Sat, 17 Jan 2015 18:44:42 +, Grant Edwards wrote: ... somebody who only knows how to write C++ [though he can do it in several different languages]. +1 QOTW (brilliant phrases in other threads are off topic and are disqualified) I have also suffered through such maintenance, but I have never described it quite so succinctly. There was lot's of quiet swearing. Quiet is *not* one of my strong points. -- Dan -- https://mail.python.org/mailman/listinfo/python-list
Re: lambdak: multi-line lambda implementation in native Python
On Sat, 17 Jan 2015 19:08:21 +, Dan Sommers wrote: On Sat, 17 Jan 2015 18:44:42 +, Grant Edwards wrote: ... somebody who only knows how to write C++ [though he can do it in several different languages]. +1 QOTW (brilliant phrases in other threads are off topic and are disqualified) I have also suffered through such maintenance, but I have never described it quite so succinctly. There was lot's of quiet swearing. Quiet is *not* one of my strong points. How about Some programmes have 20 years of experience, some have 1 year of experience 20 times it covers pretty much the same poor coding practices. -- Ditat Deus. [God enriches] -- https://mail.python.org/mailman/listinfo/python-list
Re: lambdak: multi-line lambda implementation in native Python
Steven D'Aprano wrote: def a(x=4) x+2 end a + b = 7 a+b = 7 a+ b = 7 a +b = 3 A shiny new penny for any non-Ruby coder who can explain that! Seems pretty obvious to me: the Ruby interpreter is infested with demons. DWIM = Demonic Whim Infers Meaning -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: lambdak: multi-line lambda implementation in native Python
Chris Angelico wrote: Every once in a while, someone looks at Py2's print statement and Py3's print function and says, why not allow function calls without parentheses. This right here is why not. There's also the fact that the parens are needed to distinguish between calling a function and using the function itself as a value. Ruby doesn't have that problem because it doesn't have functions, only methods, and the only thing you can do with a method in Ruby is call it. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: lambdak: multi-line lambda implementation in native Python
On Sun, Jan 18, 2015 at 8:56 AM, Gregory Ewing greg.ew...@canterbury.ac.nz wrote: Ruby doesn't have that problem because it doesn't have functions, only methods, and the only thing you can do with a method in Ruby is call it. So functions aren't first-class objects in Ruby? Bleh. I've become quite accustomed to passing them around casually, in several languages. Even C lets you pass function pointers around. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: lambdak: multi-line lambda implementation in native Python
On 2015-01-16, Gregory Ewing greg.ew...@canterbury.ac.nz wrote: We're really quite spoiled in Python-land. It's easy to forget just *how* spoiled we are until you go back and try to do something in one of the more primitive languages... I had to do some work in PHP yesterday -- fixing up some code that was written by somebody who only knows how to write C++ [though he can do it in several different languages]. There was lot's of quiet swearing. -- Grant -- https://mail.python.org/mailman/listinfo/python-list
Re: lambdak: multi-line lambda implementation in native Python
Roy Smith wrote: In article 54ba5a25$0$12991$c3e8da3$54964...@news.astraweb.com, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Whitespace is significant in nearly all programming languages, and so it should be. Whitespace separates tokens, and lines, and is a natural way of writing (at least for people using Western languages). x == x False I'm not sure what you are trying to say there. The left hand side is the string x, the right hand side is the string x . I can tell you why they're different, I just can't tell you the definitive component in the Python interpreter which causes that difference (parser, lexer, keyhole optimizer, compiler...). I suspect the answer is implementation-dependent. is not the same as , just as 123 and 1 2 3 are not the same. *Indentation* is significant to Python, while most languages enable tedious and never-ending style wars over the correct placement of braces vis a vis indentation, because their language is too simple-minded to infer block structure from indentation. Python does derive block structure from indentation, as god intended (otherwise he wouldn't have put tab keys on typewriters) and so Python doesn't suffer from the interminable arguments about formatting that most other languages do. Well, we do get to argue about x = [1, 2, 3] vs. x = [1, 2, 3, ] vs. a few other variations based on how you group the first element with the opening bracket, or the last element with the closing bracket, and, of course, whether you use the last trailing comma or not. True, but nowhere near the Holy Wars about the One True Brace Style in languages like C. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: lambdak: multi-line lambda implementation in native Python
Dennis Lee Bieber wrote:
On Fri, 16 Jan 2015 01:50:00 +1100, Chris Angelico ros...@gmail.com
declaimed the following:
Problem: You have a smartphone with a 4x4 pixel screen.
BIG problem, considering that a late 70s DECWriter needed 5x7 pixels
for glyphs in an 8x10 pixel character cell {as I recall...}
If those are 24-bit RGB pixels, you could encode
3 characters in each pixel.
You'd need eyes with rather good colour perception
to read it, though.
--
Greg
--
https://mail.python.org/mailman/listinfo/python-list
Re: lambdak: multi-line lambda implementation in native Python
Gregory Ewing greg.ew...@canterbury.ac.nz:
Dennis Lee Bieber wrote:
On Fri, 16 Jan 2015 01:50:00 +1100, Chris Angelico ros...@gmail.com
declaimed the following:
Problem: You have a smartphone with a 4x4 pixel screen.
BIG problem, considering that a late 70s DECWriter needed 5x7
pixels for glyphs in an 8x10 pixel character cell {as I recall...}
If those are 24-bit RGB pixels, you could encode
3 characters in each pixel.
Not since Python3. Characters are Unicode now so you'll need to dedicate
a pixel for each character.
Marko
--
https://mail.python.org/mailman/listinfo/python-list
Re: lambdak: multi-line lambda implementation in native Python
On 01/15/2015 10:29 PM, Ian Kelly wrote: On Thu, Jan 15, 2015 at 9:00 PM, Chris Angelico ros...@gmail.com wrote: My first response was going to be Well, you can always add another layer of indirection to try to solve your problem, but then I went and looked up builders on Wikipedia. Now I'm confused. What can you do with a builder that you can't do with a constructor? In Java you have to write a separate constructor for every conceivable combination of arguments. If there are a lot of optional arguments, that's an exponentially large number of constructors. The builder pattern provides a solution to that problem. In Python you just have one initializer with defaults for the optional arguments, so it's not an issue. Which seems to confirm my understanding that these patterns are in large part a response to limitations in the language, which certainly doesn't engender a fondness for the Java. -- https://mail.python.org/mailman/listinfo/python-list
Re: lambdak: multi-line lambda implementation in native Python
Marko Rauhamaa wrote: Gregory Ewing greg.ew...@canterbury.ac.nz: If those are 24-bit RGB pixels, you could encode 3 characters in each pixel. Not since Python3. Characters are Unicode now so you'll need to dedicate a pixel for each character. Depends on which characters you want. With the Flexible Chromatic Representation, it could be anything from 1 to 3. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: lambdak: multi-line lambda implementation in native Python
Chris Angelico wrote: Is this to get around style guides that reject this kind of model: x = Foo( opt1=True, opt2=True, color=Yellow, ) It's to get around the fact that you *can't* do that in Java, because it doesn't have keyword arguments. This is a source of a lot of the complexity and boilerplate found in Java code -- the need to work around deficencies in the language. But if you can pass a mapping object to the constructor, you can do the same job that way, Yes, but constructing the mapping object is just as tedious. :-( you could pass an array of item,value,item,value,item,value or something. That's certainly possible, but then you have to write tedious code in the constructor to parse the arguments, you lose compile-time type safety, incur runtime overhead, etc. We're really quite spoiled in Python-land. It's easy to forget just *how* spoiled we are until you go back and try to do something in one of the more primitive languages... -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: lambdak: multi-line lambda implementation in native Python
On 15/01/2015 06:39, Ian Kelly wrote: On Wed, Jan 14, 2015 at 11:06 PM, Steven D'Aprano st...@pearwood.info wrote: I have a function, which I put into an expression like this: def func(a, b=None): global spam import math spam = [a, b]*3 print spam del spam value = [1, hello, int, func] del func How would I use lambdak to write that as an expression value = [1, hello, int, ??? ] without the intermediate def? # Untested, but seems like this should work. value = [1, hello, int, given_(lambda a, b=None: import_(math, lambda math: import_(operator, lambda operator: do_(lambda: operator.setitem(globals(), 'spam', [a, b]*3), lambda: print_(globals()['spam'], lambda: do_(lambda: operator.delitem(globals(), 'spam')))] To the OP: I note that although import_ is used in the examples, it's not found in the list of functions in the README. Just what I've been looking for, highly readable, higly maintainable Python code. Please put this up as an Activestate recipe so it's preserved for prosperity, so that the entire world can see its asthetically pleasing properties. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: lambdak: multi-line lambda implementation in native Python
On Thursday, January 15, 2015 at 11:25:11 AM UTC+5:30, Yawar Amin wrote: Hi all, First off, to each reader--if you believe that 'multi-line' lambdas are no good and we can just use functions, decorators, c. to accomplish everything in Python, advance warning: this post will annoy you. Now, the crux of my message. I have implemented what I believe is a fairly robust, if ugly-looking, native Python module made up of combinator functions which compose together to form function expressions (well, callable expressions). I've seen a lot of discussions on possibly introducing syntax support for multi-line lambdas in some future version, but I've never seen anyone say, here's a way you can do this in Python _today._ So I believe lambdak fits in that niche. https://github.com/yawaramin/lambdak Would anyone care to try it out? I would be happy to answer questions whenever I can. Looked at your suggestions... And then got distracted by your other project https://github.com/yawaramin/vim-cute-python Reminded me of what I had written some months ago along similar lines http://blog.languager.org/2014/04/unicoded-python.html At that time this was not suggested quite seriously. Now I see that this can be realized at least partially and on a personal level. -- https://mail.python.org/mailman/listinfo/python-list
Re: lambdak: multi-line lambda implementation in native Python
On Thu, Jan 15, 2015 at 8:29 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Now I shall try very hard to forget I ever saw it. There are some things, no matter how hard you try, which cannot be unseen. :-) Skip -- https://mail.python.org/mailman/listinfo/python-list
Re: lambdak: multi-line lambda implementation in native Python
On Fri, Jan 16, 2015 at 1:24 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Marko Rauhamaa wrote: Corollary: Make sure the complete definition of every function can be seen at once without scrolling. Problem: I like to view code on a smartphone with a 4x4 pixel screen, and the scroll bars obscure the text. Solution: Change the editor to a 1pt font. Problem: You have a smartphone with a 4x4 pixel screen. Solution: Utilize hammer, then get a laptop. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: lambdak: multi-line lambda implementation in native Python
Yawar Amin wrote: To the responders in the 'beauty of the code' subthread: yes, I realise that lambdak is not Pythonic, and it will make angels cry, and all that. My view is you should actually be happy that it looks like this. If anyone ever asks about multi-line lambdas again, you can point to lambdak and say, 'See! This is what happens if you try to go against Pythonic style.' And then you can shrug your head in disgust if they continue to use it anyway. :-) -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: lambdak: multi-line lambda implementation in native Python
Rustom Mody wrote: Let there be a hundred different versions, then people will begin to clamor against the non-necessity of the penury-of-ASCII: http://blog.languager.org/2015/01/unicode-and-universe.html Almost 30 years ago, Apple's Hypertalk language allowed, and encouraged, the use of certain non-ASCII symbols. You could use ≤ ≥ and ≠ for less-or-equal, greater-or-equal, and not-equal comparisons; you could use ÷ for division; and you could define a square root function using √ as the name. You could even define ∞ = 'INF' and do floating point operations on it. Apple could get away with this back in the 80s because they controlled the platform including keyboard mappings, and they could guarantee that key combinations such as Option-/ would generate the ÷ character and that any reasonable font would include a glyph for it. Alas and alack, 30 years on and we have to live with the down-side of multicultural computers. Any modern Linux system is almost sure to be fully Unicode compatible with a UTF-8 filesystem -- *almost* sure. But we have to interoperate with Windows machines still stuck in the Dark Ages of code pages; Java that insists that Unicode == UTF-16 (and support for the supplementary multilingual planes is weak); there is a plethora of fonts but Unicode support is extremely variable; many of us are using US keyboards and there's no well-known or standard input method for Unicode characters; and while Apple only had to support somewhat fewer than 256 characters, Unicode has tens of thousands. Before Unicode can take off for programming syntax, we need to solve at least four problems: - we need a good selection of decent programmer's fonts with extensive support for Unicode especially mathematical symbols; - we need a platform-independent input method that will allow programmers to enter these symbols without moving their hands off the keyboard; - and some way to make the existence of these symbols easily discoverable, e.g. for most of us, ~ is easily discoverable because we can see it on the keyboard, but the same doesn't apply for ≈ - we have to be confident that moving source code from one machine to another (Windows - Linux or visa versa) won't corrupt the file. That means UTF-8 everywhere. I live in hope, but I am not confident that these issues will be solved in my lifetime. One of the ten most popular programming languages, PHP, doesn't even support Unicode even as a data type. What hope do we have? -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: lambdak: multi-line lambda implementation in native Python
On Friday, January 16, 2015 at 9:46:30 AM UTC+5:30, Steven D'Aprano wrote: Rustom Mody wrote: Let there be a hundred different versions, then people will begin to clamor against the non-necessity of the penury-of-ASCII: http://blog.languager.org/2015/01/unicode-and-universe.html Almost 30 years ago, Apple's Hypertalk language allowed, and encouraged, the use of certain non-ASCII symbols. You could use ≤ ≥ and ≠ for less-or-equal, greater-or-equal, and not-equal comparisons; you could use ÷ for division; and you could define a square root function using √ as the name. You could even define ∞ = 'INF' and do floating point operations on it. Good stuff! Apple could get away with this back in the 80s because they controlled the platform including keyboard mappings, and they could guarantee that key combinations such as Option-/ would generate the ÷ character and that any reasonable font would include a glyph for it. APL went much further, 60 years ago. And IBM could get away with it for similar monopolistic reasons Alas and alack, 30 years on and we have to live with the down-side of multicultural computers. Any modern Linux system is almost sure to be fully Unicode compatible with a UTF-8 filesystem -- *almost* sure. But we have to interoperate with Windows machines still stuck in the Dark Ages of code pages; Java that insists that Unicode == UTF-16 (and support for the supplementary multilingual planes is weak); there is a plethora of fonts but Unicode support is extremely variable; many of us are using US keyboards and there's no well-known or standard input method for Unicode characters; and while Apple only had to support somewhat fewer than 256 characters, Unicode has tens of thousands. No direct experience but my impression is that windows is almost as unicode-compliant as linux: http://msdn.microsoft.com/en-us/library/windows/desktop/dd317752%28v=vs.85%29.aspx http://msdn.microsoft.com/en-us/library/windows/desktop/dd374081%28v=vs.85%29.aspx Yeah SMP support may be problematic. Anyways... 1. BMP alone is a 256-fold expansion over ASCII 2. SMP support all round is spotty. MySQL?? Blogger is messing my posts etc 3. For almost all the cases we're talking of BMP is enough and to spare Before Unicode can take off for programming syntax, we need to solve at least four problems: - we have to be confident that moving source code from one machine to another (Windows - Linux or visa versa) won't corrupt the file. That means UTF-8 everywhere. Ok - we need a good selection of decent programmer's fonts with extensive support for Unicode especially mathematical symbols; I guess so - we need a platform-independent input method that will allow programmers to enter these symbols without moving their hands off the keyboard; I dont see why. I use laptops and desktops having different layouts. Fumble a bit but not too much. Others probably use much more way out devices eg android phones. Likewise I dont see why input-methods need to match/be platform independent. As long as they work. eg Some cars have European controls – wiper on left, lights on right. Or American – the other way round. When changing I fumble a bit but not so much its an issue - and some way to make the existence of these symbols easily discoverable, e.g. for most of us, ~ is easily discoverable because we can see it on the keyboard, but the same doesn't apply for ≈ I believe this is the nub of the matter. Discoverability of 1 million characters is a very different matter from discoverability of a few hundred. eg 1. Beginning programmers do search-and-peck typing – they need to discover the US-104 (or whatever) keyboard 2. Beginning vi-users need to find the controls of the dragon with two modes — one in which it beeps and one in which it corrupts the file 3. Beginning python programmers need to discover the difference between typing at the command-prompt at the REPL and into a file… and a dozen other things before python begins to look barely friendly In the same way typing a ≤ ≥ ≠ on a stock keyboard may require some learning/acclimatization/setup. - Using a suitable editor mode it needs to be exactly the same as the ASCII =, =, != - With compose key setup its just a character more – the above preceded by the compose key [right-win, ALtGr, Menu, whatever] I live in hope, but I am not confident that these issues will be solved in my lifetime. One of the ten most popular programming languages, PHP, doesn't even support Unicode even as a data type. What hope do we have? Using, canvassing, clamoring, bugging (with bug-reports) is our toolset :-) -- https://mail.python.org/mailman/listinfo/python-list
Re: lambdak: multi-line lambda implementation in native Python
On Thu, Jan 15, 2015 at 9:00 PM, Chris Angelico ros...@gmail.com wrote: My first response was going to be Well, you can always add another layer of indirection to try to solve your problem, but then I went and looked up builders on Wikipedia. Now I'm confused. What can you do with a builder that you can't do with a constructor? In Java you have to write a separate constructor for every conceivable combination of arguments. If there are a lot of optional arguments, that's an exponentially large number of constructors. The builder pattern provides a solution to that problem. In Python you just have one initializer with defaults for the optional arguments, so it's not an issue. -- https://mail.python.org/mailman/listinfo/python-list
Re: lambdak: multi-line lambda implementation in native Python
On 01/15/2015 09:29 PM, Ian Kelly wrote: In Python you just have one initializer with defaults for the optional arguments, so it's not an issue. What, Python makes it easy? That must be a mistake somewhere! ;) -- ~Ethan~ signature.asc Description: OpenPGP digital signature -- https://mail.python.org/mailman/listinfo/python-list
Re: lambdak: multi-line lambda implementation in native Python
On 01/15/2015 06:34 PM, Roy Smith wrote: The ebb and flow of technology has recently brought me someplace I never thought I'd be. Java-land. And what I've discovered is that factories are so last year. Apparently builders are the new thing. It's never clear to me whether all these fancy design patterns are to make up for a deficient language, or whether some people just get their kicks from layer upon layer of abstraction. Certainly it's this sort of thing that turns me right off of Java. -- https://mail.python.org/mailman/listinfo/python-list
Re: lambdak: multi-line lambda implementation in native Python
On Thursday, January 15, 2015 at 1:40:09 AM UTC-5, Ian wrote: On Wed, Jan 14, 2015 at 11:06 PM, Steven D'Aprano steve@... wrote: [...] def func(a, b=None): global spam import math spam = [a, b]*3 print spam del spam value = [1, hello, int, func] del func [...] # Untested, but seems like this should work. [...] To the OP: I note that although import_ is used in the examples, it's not found in the list of functions in the README. Thanks Ian. I'll update the readme soon. It's still a little behind the actual code. Steve, here is your example translated, about as simple as I can make it: from lambdak import * value = [ 1, hello, int, given_(lambda a, b = None: import_(math, lambda math: given_(lambda globs = globals(), spam = spam: assign_(spam, [a, b] * 3, globs, lambda: print_(get_(spam, globs), lambda: del_(spam, globs)) ] value[3](1) del value[3] The problem with globals is that a Python module can't easily manipulate the globals of its caller modules. Here you can see I had to work around the issue by just creating a few functions[1] which generically work with dicts and then explicitly passing in the globals dict on each call. I don't see any other reasonable way to do it. I would welcome being proven wrong here. To the responders in the 'beauty of the code' subthread: yes, I realise that lambdak is not Pythonic, and it will make angels cry, and all that. My view is you should actually be _happy_ that it looks like this. If anyone ever asks about multi-line lambdas again, you can point to lambdak and say, 'See! This is what happens if you try to go against Pythonic style.' And then you can shrug your head in disgust if they continue to use it anyway. Regards, Yawar [1] `assign_`, `get_`, `del_`. I haven't pushed these to the project repo yet. Will do so after writing up the tests and docs. -- https://mail.python.org/mailman/listinfo/python-list
Re: lambdak: multi-line lambda implementation in native Python
Hi, On Thursday, January 15, 2015 at 12:19:31 PM UTC-5, Rustom Mody wrote: [...] Looked at your suggestions... And then got distracted by your other project https://github.com/yawaramin/vim-cute-python Reminded me of what I had written some months ago along similar lines http://blog.languager.org/2014/04/unicoded-python.html At that time this was not suggested quite seriously. Now I see that this can be realized at least partially and on a personal level. Glad it was useful. Although let me clarify that I just forked the repo from the original on GitHub, to publish my custom version. I have more conservative tastes than the original, so I chose to keep the `in`, `not in`, `and`, `or`, `not` keywords as is instead of using the symbols. I did go through your blog post and got a previously-unused symbol out of it: '÷' to represent '/'. Regards, Yawar -- https://mail.python.org/mailman/listinfo/python-list
Re: lambdak: multi-line lambda implementation in native Python
In article 87zj9kb2j0@elektro.pacujo.net, Marko Rauhamaa ma...@pacujo.net wrote: Skip Montanaro skip.montan...@gmail.com: Beautiful is better than ugly. Yes, our job is to increase the Harmony of the Universe. Useful applications are happy side effects. Explicit is better than implicit. Corollary: Constructors are usually preferable to factories. The ebb and flow of technology has recently brought me someplace I never thought I'd be. Java-land. And what I've discovered is that factories are so last year. Apparently builders are the new thing. Corollary: Make sure the complete definition of every function can be seen at once without scrolling. The problem with that, is I have a 30 inch monitor now. -- https://mail.python.org/mailman/listinfo/python-list
Re: lambdak: multi-line lambda implementation in native Python
On 16/01/2015 02:48, Rustom Mody wrote: The more forks the merrier! When counting them, or more specifically handles, thou shalt not stop counting at three, but thou shalt continue to four, and thou shalt not continue on to five https://www.youtube.com/watch?v=Cz2-ukrd2VQ -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: lambdak: multi-line lambda implementation in native Python
On Wednesday, January 14, 2015 at 11:55:11 PM UTC-6, Yawar Amin wrote: First off, to each reader--if you believe that 'multi- line' lambdas are no good and we can just use functions, decorators, c. to accomplish everything in Python, advance warning: this post will annoy you. Well i'm not religious in that way, but i can tell you that you'd be hard pressed to find a subject that did *NOT* annoy someone in this group. Heck, it might even be something like finding a holy grail if we all agreed! Now, the crux of my message. I have implemented what I believe is a fairly robust, if ugly-looking, native Python module made up of combinator functions which compose together to form function expressions (well, callable expressions). Oh my, that's atrocious! (but kudos for trying!). If you have not already done so, i would suggest you play around with the Ruby language -- for which anonymous blocks are quite prevalent. I myself have lamented the limited power and expressiveness of Python's anonymous functions. It's almost as though Python lambda's are barely worth having since they are so crippled. Of course the majority will say that is because people would use them for stupid things... well, i've seen Python used for stupid things -- how are they going to reconcile that?. These types of excuses are based purely on religious or fascist thinking, and nothing more. :-( -- https://mail.python.org/mailman/listinfo/python-list
Re: lambdak: multi-line lambda implementation in native Python
On 16/01/2015 01:44, Michael Torrie wrote: On 01/15/2015 06:34 PM, Roy Smith wrote: The ebb and flow of technology has recently brought me someplace I never thought I'd be. Java-land. And what I've discovered is that factories are so last year. Apparently builders are the new thing. It's never clear to me whether all these fancy design patterns are to make up for a deficient language, or whether some people just get their kicks from layer upon layer of abstraction. Certainly it's this sort of thing that turns me right off of Java. If you're interested in patterns in the Python world take a look at Alex Martelli's writings on the subject, e.g. http://www.aleax.it/gdd_pydp.pdf -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: lambdak: multi-line lambda implementation in native Python
On Friday, January 16, 2015 at 7:48:20 AM UTC+5:30, Yawar Amin wrote: Hi, On Thursday, January 15, 2015 at 12:19:31 PM UTC-5, Rustom Mody wrote: [...] Looked at your suggestions... And then got distracted by your other project https://github.com/yawaramin/vim-cute-python Reminded me of what I had written some months ago along similar lines http://blog.languager.org/2014/04/unicoded-python.html At that time this was not suggested quite seriously. Now I see that this can be realized at least partially and on a personal level. Glad it was useful. Although let me clarify that I just forked the repo from the original on GitHub, to publish my custom version. I have more conservative tastes than the original, so I chose to keep the `in`, `not in`, `and`, `or`, `not` keywords as is instead of using the symbols. I did go through your blog post and got a previously-unused symbol out of it: '÷' to represent '/'. The more forks the merrier! Let there be a hundred different versions, then people will begin to clamor against the non-necessity of the penury-of-ASCII: http://blog.languager.org/2015/01/unicode-and-universe.html -- https://mail.python.org/mailman/listinfo/python-list
Re: lambdak: multi-line lambda implementation in native Python
On Friday, January 16, 2015 at 8:33:14 AM UTC+5:30, Mark Lawrence wrote: On 16/01/2015 02:48, Rustom Mody wrote: The more forks the merrier! When counting them, or more specifically handles, thou shalt not stop counting at three, but thou shalt continue to four, and thou shalt not continue on to five https://www.youtube.com/watch?v=Cz2-ukrd2VQ Ha Ha -- Thanks -- https://mail.python.org/mailman/listinfo/python-list
Re: lambdak: multi-line lambda implementation in native Python
On Thu, Jan 15, 2015 at 7:04 AM, Roy Smith r...@panix.com wrote: I don't know which zen this is, but Beauty is important. Kinda near the front: % python -m this The Zen of Python, by Tim Peters Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. ... :-) Skip -- https://mail.python.org/mailman/listinfo/python-list
Re: lambdak: multi-line lambda implementation in native Python
yawar.a...@gmail.com wrote: I have implemented what I believe is a fairly robust, if ugly-looking, native Python module I don't know which zen this is, but Beauty is important. -- https://mail.python.org/mailman/listinfo/python-list
Re: lambdak: multi-line lambda implementation in native Python
On Fri, Jan 16, 2015 at 12:04 AM, Roy Smith r...@panix.com wrote: I don't know which zen this is, but Beauty is important. How about: Beautiful is better than ugly. Readability counts. If the implementation is hard to explain, it's a bad idea. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: lambdak: multi-line lambda implementation in native Python
Skip Montanaro skip.montan...@gmail.com: Beautiful is better than ugly. Yes, our job is to increase the Harmony of the Universe. Useful applications are happy side effects. Explicit is better than implicit. Corollary: Constructors are usually preferable to factories. Simple is better than complex. Corollary: Make sure the complete definition of every function can be seen at once without scrolling. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: lambdak: multi-line lambda implementation in native Python
Marko Rauhamaa wrote: Corollary: Make sure the complete definition of every function can be seen at once without scrolling. Problem: I like to view code on a smartphone with a 4x4 pixel screen, and the scroll bars obscure the text. Solution: Change the editor to a 1pt font. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: lambdak: multi-line lambda implementation in native Python
Ian Kelly wrote: On Wed, Jan 14, 2015 at 11:06 PM, Steven D'Aprano st...@pearwood.info wrote: I have a function, which I put into an expression like this: def func(a, b=None): global spam import math spam = [a, b]*3 print spam del spam value = [1, hello, int, func] del func How would I use lambdak to write that as an expression value = [1, hello, int, ??? ] without the intermediate def? # Untested, but seems like this should work. value = [1, hello, int, given_(lambda a, b=None: import_(math, lambda math: import_(operator, lambda operator: do_(lambda: operator.setitem(globals(), 'spam', [a, b]*3), lambda: print_(globals()['spam'], lambda: do_(lambda: operator.delitem(globals(), 'spam')))] Thank you for showing me that. Now I shall try very hard to forget I ever saw it. *shudders at the thought of maintaining such a beast* -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: lambdak: multi-line lambda implementation in native Python
On Thursday, January 15, 2015 at 10:06:34 PM UTC-5, Rick Johnson wrote: [...] Well i'm not religious in that way, but i can tell you that you'd be hard pressed to find a subject that did *NOT* annoy someone in this group. Heck, it might even be something like finding a holy grail if we all agreed! Ha! Indeed. And here I was thinking that Python's Holy Grail would be finding a good multi-line lambda :-) Oh my, that's atrocious! (but kudos for trying!). If you have not already done so, i would suggest you play around with the Ruby language -- for which anonymous blocks are quite prevalent. Yes, I've been very impressed by Ruby's æsthetics. Matz did something with Ruby that few other people were willing to do: he followed expression semantics to its logical conclusion. People (including myself) have asked if we could have that in Python, but as I understand it Python has some strict newline and indent requirements that prevent it. I myself have lamented the limited power and expressiveness of Python's anonymous functions. It's almost as though Python lambda's are barely worth having since they are so crippled. I guess they are crippled from the perspective of a functional programmer. But they work pretty well for their intended uses. And as I mentioned, if your editor masks the keyword and displays the symbol, they almost look natural in the code. Regards, Yawar -- https://mail.python.org/mailman/listinfo/python-list
Re: lambdak: multi-line lambda implementation in native Python
On Fri, Jan 16, 2015 at 12:44 PM, Michael Torrie torr...@gmail.com wrote: On 01/15/2015 06:34 PM, Roy Smith wrote: The ebb and flow of technology has recently brought me someplace I never thought I'd be. Java-land. And what I've discovered is that factories are so last year. Apparently builders are the new thing. It's never clear to me whether all these fancy design patterns are to make up for a deficient language, or whether some people just get their kicks from layer upon layer of abstraction. Certainly it's this sort of thing that turns me right off of Java. My first response was going to be Well, you can always add another layer of indirection to try to solve your problem, but then I went and looked up builders on Wikipedia. Now I'm confused. What can you do with a builder that you can't do with a constructor? Is this to get around style guides that reject this kind of model: x = Foo( opt1=True, opt2=True, color=Yellow, ) so you instead do this? x = Foo.Builder() x.opt1 = True x.opt2 = True x.color = Yellow x = x.get() How is that an improvement? In Python, of course, keyword arguments do this job brilliantly, but I'm aware that not all languages support them. Okay. But if you can pass a mapping object to the constructor, you can do the same job that way, and even if you can't do that, you could pass an array of item,value,item,value,item,value or something. Surely there must be some way that would work. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: lambdak: multi-line lambda implementation in native Python
On Wed, 14 Jan 2015 21:54:52 -0800, yawar.amin wrote: Now, the crux of my message. I have implemented what I believe is a fairly robust, if ugly-looking, native Python module made up of combinator functions which compose together to form function expressions (well, callable expressions). How about a demo? I have a function, which I put into an expression like this: def func(a, b=None): global spam import math spam = [a, b]*3 print spam del spam value = [1, hello, int, func] del func How would I use lambdak to write that as an expression value = [1, hello, int, ??? ] without the intermediate def? -- Steve -- https://mail.python.org/mailman/listinfo/python-list
Re: lambdak: multi-line lambda implementation in native Python
On Wed, Jan 14, 2015 at 11:06 PM, Steven D'Aprano st...@pearwood.info wrote: I have a function, which I put into an expression like this: def func(a, b=None): global spam import math spam = [a, b]*3 print spam del spam value = [1, hello, int, func] del func How would I use lambdak to write that as an expression value = [1, hello, int, ??? ] without the intermediate def? # Untested, but seems like this should work. value = [1, hello, int, given_(lambda a, b=None: import_(math, lambda math: import_(operator, lambda operator: do_(lambda: operator.setitem(globals(), 'spam', [a, b]*3), lambda: print_(globals()['spam'], lambda: do_(lambda: operator.delitem(globals(), 'spam')))] To the OP: I note that although import_ is used in the examples, it's not found in the list of functions in the README. -- https://mail.python.org/mailman/listinfo/python-list
