Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #83793 > unrolled thread

lambdak: multi-line lambda implementation in native Python

Back to article view | Back to comp.lang.python

Contents

  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 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#83845

In article <87zj9kb2j0.fsf@elektro.pacujo.net>,
 Marko Rauhamaa <marko@pacujo.net> wrote:

> Skip Montanaro <skip.montanaro@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.

[toc] | [prev] | [next] | [standalone]

#83846

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.

[toc] | [prev] | [next] | [standalone]

#83849

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

[toc] | [prev] | [next] | [standalone]

#83860

On Fri, Jan 16, 2015 at 12:44 PM, Michael Torrie <torriem@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

[toc] | [prev] | [next] | [standalone]

#83901

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

[toc] | [prev] | [next] | [standalone]

#83908

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

[toc] | [prev] | [next] | [standalone]

#83910

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.

[toc] | [prev] | [next] | [standalone]

#83911

Jussi Piitulainen <jpiitula@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

[toc] | [prev] | [next] | [standalone]

#83913

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.

[toc] | [prev] | [next] | [standalone]

#83914

Jussi Piitulainen <jpiitula@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

[toc] | [prev] | [next] | [standalone]

#83919

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 )

[toc] | [prev] | [next] | [standalone]

#83915

On Sat, Jan 17, 2015 at 5:59 AM, Jussi Piitulainen
<jpiitula@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

[toc] | [prev] | [next] | [standalone]

#83920

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.

[toc] | [prev] | [next] | [standalone]

#83935

In article <mailman.17811.1421497179.18130.python-list@python.org>,
 Skip Montanaro <skip.montanaro@gmail.com> wrote:

> On Sat, Jan 17, 2015 at 5:59 AM, Jussi Piitulainen
> <jpiitula@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.

[toc] | [prev] | [next] | [standalone]

#83957

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

[toc] | [prev] | [next] | [standalone]

#83917

Marko Rauhamaa wrote:

> Jussi Piitulainen <jpiitula@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

[toc] | [prev] | [next] | [standalone]

#83934

In article <54ba5a25$0$12991$c3e8da3$5496439d@news.astraweb.com>,
 Steven D'Aprano <steve+comp.lang.python@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.

[toc] | [prev] | [next] | [standalone]

#83963

Roy Smith wrote:

> In article <54ba5a25$0$12991$c3e8da3$5496439d@news.astraweb.com>,
>  Steven D'Aprano <steve+comp.lang.python@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

[toc] | [prev] | [next] | [standalone]

#83955

On Sat, 17 Jan 2015 23:48:35 +1100, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> declaimed the following:

>Marko Rauhamaa wrote:
>
>> Jussi Piitulainen <jpiitula@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.
>
	You missed the better example

	DO10I=1,10
vs
	DO 10 I = 1	.	10

	The two do NOT mean the same thing -- the first being a loop
instruction over an integer range, and the second is a plain assignment of
a floating point.

-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [next] | [standalone]

#83923

Il 17/01/2015 12.07, Marko Rauhamaa ha scritto:
> Jussi Piitulainen <jpiitula@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

[toc] | [prev] | [next] | [standalone]

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

Back to top | Article view | comp.lang.python

csiph-web