Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #83793 > unrolled thread
| Started by | yawar.amin@gmail.com |
|---|---|
| First post | 2015-01-14 21:54 -0800 |
| Last post | 2015-01-15 19:20 -0800 |
| Articles | 4 on this page of 64 — 21 participants |
Back to article view | Back to comp.lang.python
lambdak: multi-line lambda implementation in native Python yawar.amin@gmail.com - 2015-01-14 21:54 -0800
Re: lambdak: multi-line lambda implementation in native Python Steven D'Aprano <steve@pearwood.info> - 2015-01-15 06:06 +0000
Re: lambdak: multi-line lambda implementation in native Python Ian Kelly <ian.g.kelly@gmail.com> - 2015-01-14 23:39 -0700
Re: lambdak: multi-line lambda implementation in native Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-16 01:29 +1100
Re: lambdak: multi-line lambda implementation in native Python Skip Montanaro <skip.montanaro@gmail.com> - 2015-01-15 08:38 -0600
Re: lambdak: multi-line lambda implementation in native Python Yawar Amin <yawar.amin@gmail.com> - 2015-01-15 18:07 -0800
Re: lambdak: multi-line lambda implementation in native Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-16 15:17 +1100
Re: lambdak: multi-line lambda implementation in native Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-01-15 17:22 +0000
Re: lambdak: multi-line lambda implementation in native Python Roy Smith <roy@panix.com> - 2015-01-15 08:04 -0500
Re: lambdak: multi-line lambda implementation in native Python Chris Angelico <rosuav@gmail.com> - 2015-01-16 00:09 +1100
Re: lambdak: multi-line lambda implementation in native Python Skip Montanaro <skip.montanaro@gmail.com> - 2015-01-15 07:11 -0600
Re: lambdak: multi-line lambda implementation in native Python Marko Rauhamaa <marko@pacujo.net> - 2015-01-15 15:24 +0200
Re: lambdak: multi-line lambda implementation in native Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-16 01:24 +1100
Re: lambdak: multi-line lambda implementation in native Python Chris Angelico <rosuav@gmail.com> - 2015-01-16 01:50 +1100
Re: lambdak: multi-line lambda implementation in native Python Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-01-15 19:47 -0500
Re: lambdak: multi-line lambda implementation in native Python Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-01-17 00:21 +1300
Re: lambdak: multi-line lambda implementation in native Python Marko Rauhamaa <marko@pacujo.net> - 2015-01-16 14:06 +0200
Re: lambdak: multi-line lambda implementation in native Python Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-01-17 10:24 +1300
Re: lambdak: multi-line lambda implementation in native Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-17 21:33 +1100
Re: lambdak: multi-line lambda implementation in native Python alister <alister.nospam.ware@ntlworld.com> - 2015-01-17 18:30 +0000
Re: lambdak: multi-line lambda implementation in native Python Roy Smith <roy@panix.com> - 2015-01-15 20:34 -0500
Re: lambdak: multi-line lambda implementation in native Python Michael Torrie <torriem@gmail.com> - 2015-01-15 18:44 -0700
Re: lambdak: multi-line lambda implementation in native Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-01-16 02:14 +0000
Re: lambdak: multi-line lambda implementation in native Python Chris Angelico <rosuav@gmail.com> - 2015-01-16 15:00 +1100
Re: lambdak: multi-line lambda implementation in native Python Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-01-17 10:29 +1300
Re: lambdak: multi-line lambda implementation in native Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-17 21:30 +1100
Re: lambdak: multi-line lambda implementation in native Python Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2015-01-17 12:49 +0200
Re: lambdak: multi-line lambda implementation in native Python Marko Rauhamaa <marko@pacujo.net> - 2015-01-17 13:07 +0200
Re: lambdak: multi-line lambda implementation in native Python Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2015-01-17 13:59 +0200
Re: lambdak: multi-line lambda implementation in native Python Marko Rauhamaa <marko@pacujo.net> - 2015-01-17 14:15 +0200
Re: lambdak: multi-line lambda implementation in native Python Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2015-01-17 14:54 +0200
Re: lambdak: multi-line lambda implementation in native Python Skip Montanaro <skip.montanaro@gmail.com> - 2015-01-17 06:19 -0600
Re: lambdak: multi-line lambda implementation in native Python Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2015-01-17 15:19 +0200
Re: lambdak: multi-line lambda implementation in native Python Roy Smith <roy@panix.com> - 2015-01-17 12:24 -0500
Re: lambdak: multi-line lambda implementation in native Python Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-01-18 11:41 +1300
Re: lambdak: multi-line lambda implementation in native Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-17 23:48 +1100
Re: lambdak: multi-line lambda implementation in native Python Roy Smith <roy@panix.com> - 2015-01-17 12:20 -0500
Re: lambdak: multi-line lambda implementation in native Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-18 13:45 +1100
Re: lambdak: multi-line lambda implementation in native Python Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-01-17 17:21 -0500
Re: lambdak: multi-line lambda implementation in native Python Danilo Coccia <daniloco@acm.org> - 2015-01-17 15:20 +0100
Re: lambdak: multi-line lambda implementation in native Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-17 23:49 +1100
Re: lambdak: multi-line lambda implementation in native Python Chris Angelico <rosuav@gmail.com> - 2015-01-18 00:33 +1100
Re: lambdak: multi-line lambda implementation in native Python Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-01-18 10:56 +1300
Re: lambdak: multi-line lambda implementation in native Python Chris Angelico <rosuav@gmail.com> - 2015-01-18 09:04 +1100
Re: lambdak: multi-line lambda implementation in native Python Roy Smith <roy@panix.com> - 2015-01-17 11:56 -0500
Re: lambdak: multi-line lambda implementation in native Python Grant Edwards <invalid@invalid.invalid> - 2015-01-17 18:51 +0000
Re: lambdak: multi-line lambda implementation in native Python Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-01-18 10:48 +1300
Re: lambdak: multi-line lambda implementation in native Python Grant Edwards <invalid@invalid.invalid> - 2015-01-17 18:44 +0000
Re: lambdak: multi-line lambda implementation in native Python Dan Sommers <dan@tombstonezero.net> - 2015-01-17 19:08 +0000
Re: lambdak: multi-line lambda implementation in native Python alister <alister.nospam.ware@ntlworld.com> - 2015-01-17 20:22 +0000
Factories and Builders [was Re: lambdak...] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-16 16:08 +1100
Re: Factories and Builders [was Re: lambdak...] Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-01-17 10:25 +1300
Re: lambdak: multi-line lambda implementation in native Python Ian Kelly <ian.g.kelly@gmail.com> - 2015-01-15 22:29 -0700
Re: lambdak: multi-line lambda implementation in native Python Ethan Furman <ethan@stoneleaf.us> - 2015-01-15 21:42 -0800
Re: lambdak: multi-line lambda implementation in native Python Michael Torrie <torriem@gmail.com> - 2015-01-16 09:23 -0700
Re: lambdak: multi-line lambda implementation in native Python Rustom Mody <rustompmody@gmail.com> - 2015-01-15 09:19 -0800
Re: lambdak: multi-line lambda implementation in native Python Yawar Amin <yawar.amin@gmail.com> - 2015-01-15 18:18 -0800
Re: lambdak: multi-line lambda implementation in native Python Rustom Mody <rustompmody@gmail.com> - 2015-01-15 18:48 -0800
Re: lambdak: multi-line lambda implementation in native Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-01-16 03:02 +0000
Re: lambdak: multi-line lambda implementation in native Python Rustom Mody <rustompmody@gmail.com> - 2015-01-15 19:14 -0800
Re: lambdak: multi-line lambda implementation in native Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-16 15:16 +1100
Re: lambdak: multi-line lambda implementation in native Python Rustom Mody <rustompmody@gmail.com> - 2015-01-15 20:58 -0800
Re: lambdak: multi-line lambda implementation in native Python Rick Johnson <rantingrickjohnson@gmail.com> - 2015-01-15 19:06 -0800
Re: lambdak: multi-line lambda implementation in native Python Yawar Amin <yawar.amin@gmail.com> - 2015-01-15 19:20 -0800
Page 4 of 4 — ← Prev page 1 2 3 [4]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2015-01-16 15:16 +1100 |
| Message-ID | <54b89091$0$13004$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #83854 |
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
[toc] | [prev] | [next] | [standalone]
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2015-01-15 20:58 -0800 |
| Message-ID | <9dc2afda-4264-4ecb-a0ba-d523e186dc58@googlegroups.com> |
| In reply to | #83861 |
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 :-)
[toc] | [prev] | [next] | [standalone]
| From | Rick Johnson <rantingrickjohnson@gmail.com> |
|---|---|
| Date | 2015-01-15 19:06 -0800 |
| Message-ID | <20afdff6-1391-4bcf-a412-1c579ca15b6b@googlegroups.com> |
| In reply to | #83793 |
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. :-(
[toc] | [prev] | [next] | [standalone]
| From | Yawar Amin <yawar.amin@gmail.com> |
|---|---|
| Date | 2015-01-15 19:20 -0800 |
| Message-ID | <b2418438-2314-45ab-8a31-4711f24ebb2a@googlegroups.com> |
| In reply to | #83856 |
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
[toc] | [prev] | [standalone]
Page 4 of 4 — ← Prev page 1 2 3 [4]
Back to top | Article view | comp.lang.python
csiph-web