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

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

Re: OT: This Swift thing

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: OT: This Swift thing Sturla Molden <sturla.molden@gmail.com> - 2014-06-03 20:43 +0000
    Re: OT: This Swift thing Marko Rauhamaa <marko@pacujo.net> - 2014-06-04 00:19 +0300
      Re: OT: This Swift thing Steven D'Aprano <steve@pearwood.info> - 2014-06-04 04:30 +0000
        Re: OT: This Swift thing Marko Rauhamaa <marko@pacujo.net> - 2014-06-04 08:23 +0300
    Re: OT: This Swift thing Mark H Harris <harrismh777@gmail.com> - 2014-06-03 16:49 -0500
      Re: OT: This Swift thing Chris Angelico <rosuav@gmail.com> - 2014-06-04 08:01 +1000
      Re: OT: This Swift thing "Eric S. Johansson" <esj@harvee.org> - 2014-06-03 19:22 -0400
      Re: OT: This Swift thing Chris Angelico <rosuav@gmail.com> - 2014-06-04 09:29 +1000
      Re: OT: This Swift thing "Eric S. Johansson" <esj@harvee.org> - 2014-06-03 19:36 -0400
      Re: OT: This Swift thing Steven D'Aprano <steve@pearwood.info> - 2014-06-04 04:54 +0000
        Re: OT: This Swift thing Mark H Harris <harrismh777@gmail.com> - 2014-06-04 09:43 -0500
      Re: OT: This Swift thing Skip Montanaro <skip@pobox.com> - 2014-06-04 09:24 -0500
        Re: OT: This Swift thing Mark H Harris <harrismh777@gmail.com> - 2014-06-04 09:53 -0500
          Re: OT: This Swift thing Terry Reedy <tjreedy@udel.edu> - 2014-06-04 18:18 -0400
            Re: OT: This Swift thing Mark H Harris <harrismh777@gmail.com> - 2014-06-04 18:23 -0500
              Re: OT: This Swift thing Terry Reedy <tjreedy@udel.edu> - 2014-06-04 22:43 -0400
                Re: OT: This Swift thing Steven D'Aprano <steve@pearwood.info> - 2014-06-05 08:39 +0000
                  Re: OT: This Swift thing Chris Angelico <rosuav@gmail.com> - 2014-06-05 18:52 +1000
                  Re: OT: This Swift thing Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-06-05 08:27 -0400
                  Re: OT: This Swift thing Rustom Mody <rustompmody@gmail.com> - 2014-06-05 05:56 -0700
                    Re: OT: This Swift thing Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-06-05 15:12 +0000
                      Re: OT: This Swift thing Rustom Mody <rustompmody@gmail.com> - 2014-06-05 08:39 -0700
                        Re: OT: This Swift thing Rustom Mody <rustompmody@gmail.com> - 2014-06-05 08:44 -0700
                  Tabs (was Re: OT: This Swift thing) Terry Reedy <tjreedy@udel.edu> - 2014-06-05 15:05 -0400
                  Re: Tabs (was Re: OT: This Swift thing) Terry Reedy <tjreedy@udel.edu> - 2014-06-05 18:23 -0400
                  Re: Tabs (was Re: OT: This Swift thing) Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-06-05 20:52 -0400
          Re: OT: This Swift thing CHIN Dihedral <dihedral88888@gmail.com> - 2014-06-15 03:08 -0700
      Re: OT: This Swift thing Michael Torrie <torriem@gmail.com> - 2014-06-04 09:00 -0600
      Re: OT: This Swift thing Chris Angelico <rosuav@gmail.com> - 2014-06-05 01:26 +1000
    Re: OT: This Swift thing Kevin Walzer <kw@codebykevin.com> - 2014-06-03 19:39 -0400
      Re: OT: This Swift thing Sturla Molden <sturla.molden@gmail.com> - 2014-06-04 01:53 +0200
    Re: OT: This Swift thing Andrea D'Amore <anddamNOALPASTICCIODICARNE+gruppi@brapi.net> - 2014-06-04 09:47 +0200

Page 1 of 2  [1] 2  Next page →

#72546 — Re: OT: This Swift thing

Nicholas Cole <nicholas.cole@gmail.com> wrote:

> Of course, I wish they had picked Python rather than inventing their
> own language.  But Apple put a huge stock in the ability of their
> libraries to make full use of multiple cores. 

The GIL is not relevant if they stick to the Objective-C runtime and LLVM. 

> The GIL is surely the
> sticking point here. It is also clear (reading the Swift
> documentation) that they wanted a script-like language but with strict
> typing.

A Python with static typing would have been far better, IMHO. It seems they
have created a Python-JavaScript bastard with random mix of features.
Unfortunately they retained the curly brackets from JS...

Are Python apps still banned from AppStore, even if we bundle an
interpreter? If not, I see no reason to use Swift instead of Python and
PyObjC – perhaps with some Cython if there is "need for speed".

Sturla

[toc] | [next] | [standalone]

#72551

Sturla Molden <sturla.molden@gmail.com>:

> A Python with static typing would have been far better, IMHO.

I don't think static typing and Python should be mentioned in the same
sentence.

> It seems they have created a Python-JavaScript bastard with random mix
> of features. Unfortunately they retained the curly brackets from JS...

It seems Swift is more of an imitation of Go than Python.

Swift leaves me cold: I actually *like* semicolons.


Marko

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

#72587

On Wed, 04 Jun 2014 00:19:34 +0300, Marko Rauhamaa wrote:

> Sturla Molden <sturla.molden@gmail.com>:
> 
>> A Python with static typing would have been far better, IMHO.
> 
> I don't think static typing and Python should be mentioned in the same
> sentence.

Guido disagrees with you:


https://www.python.org/~guido/static-typing/

http://www.artima.com/weblogs/viewpost.jsp?thread=85551



-- 
Steve

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

#72596

Steven D'Aprano <steve@pearwood.info>:

> On Wed, 04 Jun 2014 00:19:34 +0300, Marko Rauhamaa wrote:
>> I don't think static typing and Python should be mentioned in the
>> same sentence.
>
> Guido disagrees with you:

Do you have an opinion yourself?


Marko

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

#72554

On 6/3/14 3:43 PM, Sturla Molden wrote:
> Nicholas Cole <nicholas.cole@gmail.com> wrote:
 > {snip}
> Unfortunately they retained the curly brackets from JS...
>

The curly braces come from C, and before that B and A/.

(I think others used them too before that, but it escapes me now and I'm 
too lazy to google it)

... but the point is that curly braces don't come from JS !

I have been engaged in a minor flame debate (locally) over block 
delimiters (or lack thereof) which I'm loosing. Locally, people hate 
python's indentation block delimiting, and wish python would adopt curly 
braces. I do not agree, of course; however, I am noticing when new 
languages come out they either use END (as in Julia) or they propagate 
the curly braces paradigm as in C.   The issue locally is trying to pass 
code snippets around the net informally is a problem with indentation. 
My reply is, well, don't do that. For what I see as a freedom issue, 
folks want to format their white space (style) their way and don't want 
to be forced into an indentation paradigm that is rigid (or no so much!).

We even have a couple of clucks on our side of the world that refuse to 
even get their feet wet in python because they hate the indentation 
paradigm.


marcus

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

#72556

On Wed, Jun 4, 2014 at 7:49 AM, Mark H Harris <harrismh777@gmail.com> wrote:
> On 6/3/14 3:43 PM, Sturla Molden wrote:
>>
>> Nicholas Cole <nicholas.cole@gmail.com> wrote:
>
>> {snip}
>
>> Unfortunately they retained the curly brackets from JS...
>>
>
> The curly braces come from C, and before that B and A/.
>
> (I think others used them too before that, but it escapes me now and I'm too
> lazy to google it)
>
> ... but the point is that curly braces don't come from JS !

If a merger between JS and Python adopts braces, the braces came from
JS. You look at a baby and say he has his father's nose
(http://tinyurl.com/kqltth4 perhaps?), not that he has his
great-grandmother's nose, even if it's the same nose.

> I have been engaged in a minor flame debate (locally) over block delimiters
> (or lack thereof) which I'm loosing. Locally, people hate python's
> indentation block delimiting, and wish python would adopt curly braces. I do
> not agree, of course; however, I am noticing when new languages come out
> they either use END (as in Julia) or they propagate the curly braces
> paradigm as in C.   The issue locally is trying to pass code snippets around
> the net informally is a problem with indentation. My reply is, well, don't
> do that. For what I see as a freedom issue, folks want to format their white
> space (style) their way and don't want to be forced into an indentation
> paradigm that is rigid (or no so much!).

I quite like braces, myself, but I'm happy with either model. But I
don't like massively verbose "END" blocks, nor the syntactic salt of
bash's case/esac, if/fi, etc (match the end marker to the beginning).
Keep it simple and keep it unobtrusive.

ChrisA

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

#72557

On 6/3/2014 5:49 PM, Mark H Harris wrote:
>
> I have been engaged in a minor flame debate (locally) over block 
> delimiters (or lack thereof) which I'm loosing. Locally, people hate 
> python's indentation block delimiting, and wish python would adopt 
> curly braces. I do not agree, of course; however, I am noticing when 
> new languages come out they either use END (as in Julia) or they 
> propagate the curly braces paradigm as in C.   The issue locally is 
> trying to pass code snippets around the net informally is a problem 
> with indentation. My reply is, well, don't do that. For what I see as 
> a freedom issue, folks want to format their white space (style) their 
> way and don't want to be forced into an indentation paradigm that is 
> rigid (or no so much!).
>
the only problem I have with indentation defining blocks is that it's 
hard to cut and paste code and make it fit the right block level 
automatically. Too many times of made the mistake of one or two lines 
off by one or two levels of indentation and somehow the code doesn't 
work as I thought it would :-) It's also making it difficult to generate 
code automatically.

On the other hand, curly braces are royal pain to dictate or navigate 
around when programming with speech recognition.

--- eric

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

#72558

On Wed, Jun 4, 2014 at 9:22 AM, Eric S. Johansson <esj@harvee.org> wrote:
> On the other hand, curly braces are royal pain to dictate or navigate around
> when programming with speech recognition.

I've never done that, in any language, but if I had to guess, I'd say
that both braces and indentation are harder to work with than a REXX
style where *everything* is words. :)

ChrisA

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

#72559

On 6/3/2014 7:29 PM, Chris Angelico wrote:
> On Wed, Jun 4, 2014 at 9:22 AM, Eric S. Johansson <esj@harvee.org> wrote:
>> On the other hand, curly braces are royal pain to dictate or navigate around
>> when programming with speech recognition.
> I've never done that, in any language, but if I had to guess, I'd say
> that both braces and indentation are harder to work with than a REXX
> style where *everything* is words. :)

The model I am working with now, and it requires a very smart editor, is 
the jump down - jump up approach or the combination of mouse and voice 
where you move the cursor to where you want to go and say "go here". 
Yes, sometimes it's easier to move a mouse that is to click it and both 
are easier than dragging.

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

#72590

On Tue, 03 Jun 2014 16:49:55 -0500, Mark H Harris wrote:

> I have been engaged in a minor flame debate (locally) over block
> delimiters (or lack thereof) which I'm loosing. Locally, people hate
> python's indentation block delimiting, and wish python would adopt curly
> braces. 

Cats.

"It's different. I don't like it."

> I do not agree, of course; however, I am noticing when new
> languages come out they either use END (as in Julia) or they propagate
> the curly braces paradigm as in C.

Or the off-side rule:

ABC, Boo, BuddyScript, Cobra, CoffeeScript, Converge, Curry, F#, Genie, 
Haml, (partially) Haskell, ISWIM, LiveScript, Miranda, Nemerle, Nimrod, 
Occam, PROMAL, Python, Sass, Spin, XL, Ya, YAML.


> The issue locally is trying to pass
> code snippets around the net informally is a problem with indentation.

I've been passing code snippets by email and Usenet for 15 years or more, 
and I've never had a problem with indentation.

Of course, I've had problems with *other people's code*, because they use 
broken tools that break the text they send.

If web forum software routinely replaced {} with &lbra;&rbra; or worse 
just deleted them altogether, do you imagine for a second people would 
say "braces are broken"? No of course not, they would say the forum 
software was broken, and fix the damn things.

If your email client, News reader, or web forum software replaces runs of 
whitespace with a single space, or deletes leading whitespace, or mangles 
it in any way, *it is broken* just as clearly as if replaced every second 
use of the letter "a" with a "z".

> My reply is, well, don't do that. For what I see as a freedom issue,
> folks want to format their white space (style) their way and don't want
> to be forced into an indentation paradigm that is rigid (or no so
> much!).

*rolls eyes*

Ah, the C brace style wars. The Number One productivity killer among 
programmers before the rise of easy public access to the Internet. Nice 
to see old traditions haven't been forgotten.


> We even have a couple of clucks on our side of the world that refuse to
> even get their feet wet in python because they hate the indentation
> paradigm.

Chances are that they use *exactly the same* indentation rules as Python, 
except no braces. And if they don't indent their code? Then they're bad 
programmers.


-- 
Steven

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

#72639

On 6/3/14 11:54 PM, Steven D'Aprano wrote:
> I've been passing code snippets by email and Usenet for 15 years or more,
> and I've never had a problem with indentation.
>
> Of course, I've had problems with *other people's code*, because they use
> broken tools that break the text they send.
>

     Me too.

     The other way round is also true, that is, tools that break the 
code when read into a formatting tool.

     The claim (which I cannot substantiate) is that code passed through 
emails/web, with indents, gets mangled in such a way that a formatting 
tool cannot restore the indent logic. Well, the problem is what mangles 
the code, not the indents.

     Regardless, the misconception that indents are bad prevails here 
almost universally.

marcus

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

#72638

On Tue, Jun 3, 2014 at 4:49 PM, Mark H Harris <harrismh777@gmail.com> wrote:
> I have been engaged in a minor flame debate (locally) over block delimiters
> (or lack thereof) which I'm loosing. Locally, people hate python's
> indentation block delimiting, and wish python would adopt curly braces.

Which reminds me of this note I saw the other day in a blog discussing
JavaScript for Python programmers: "JavaScript uses curly brackets to
denote code blocks. Python uses indentation. Get over it."

Surely your local colleagues realize that Python has been around for
20-odd years now, that indentation-based block structure has been
there since Day One, and that it's not going to change, right?

Here's a (bad?) analogy. Suppose I really, really hate blue as a car
color. Red's my favorite color. Blue's been around since, I don't
know, a long, long time. Still I really, really hate to see cars
painted blue. I really wish Chevrolet and Ford (Guido and the Python
development team) would stop painting cars blue. Furthermore, I'm so
disgusted by the color, I want the owners of all blue cars everywhere
(every Python programmer in the world) to take them to Maaco and get
them repainted red (converted to use curly braces or END tags,
whatever).

Why are you people even having this discussion?

Skip

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

#72642

On 6/4/14 9:24 AM, Skip Montanaro wrote:
> Surely your local colleagues realize that Python has been around for
> 20-odd years now, that indentation-based block structure has been
> there since Day One, and that it's not going to change, right?
>
     Yup. Its the primary argument on the side for indentation. "... and 
don't call me Surely"    :-)

> {snip}
>
> Why are you people even having this discussion?
>

     The topic came up because the C/C++ coders were being encouraged to 
try Python3 as the language of choice for a new project, and someone 
said they would never consider Python for a project primary language 
because of indentation block delimiting. The whole debate, as in most 
flames, was stupid. The primary paradigm on this topic locally is that 
indents are bad because malformed or mangled code cannot be reformatted 
easily (if at all).

     From my own perspective, if you tell me I need to use END, ok.  If 
I need to use {} , well ok, and if the BDFL says we use indents here, 
well that's cool tool.

     Getting back to Swift, did they choose {} braces because JS uses 
them, or did they choose {} braces because 'they' think most people will 
want that style?

marcus

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

#72663

On 6/4/2014 10:53 AM, Mark H Harris wrote:

>      The topic came up because the C/C++ coders were being encouraged to
> try Python3 as the language of choice for a new project, and someone
> said they would never consider Python for a project primary language
> because of indentation block delimiting. The whole debate, as in most
> flames, was stupid. The primary paradigm on this topic locally is that
> indents are bad because malformed or mangled code cannot be reformatted
> easily (if at all).

Begin solution:':' as the end of a line means 'begin block; indent next 
line'. If one is using tools that mangle, one can add end-of-block 
comments: '# end, # end if, # if (end implied), or even just ##. In any 
case, the stylized comment could mean 'dedent' and code could be 
reconstituted with all indents stripped. There are probably programs on 
PyPI to do that. End of excuse.

-- 
Terry Jan Reedy

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

#72664

On 6/4/14 5:18 PM, Terry Reedy wrote:
> On 6/4/2014 10:53 AM, Mark H Harris wrote:
>> The primary paradigm on this topic locally is that
>> indents are bad because malformed or mangled code cannot be reformatted
>> easily (if at all).
>
> Begin solution:':' as the end of a line means 'begin block; indent next
> line'. If one is using tools that mangle, one can add end-of-block
> comments: '# end, # end if, # if (end implied), or even just ##. In any
> case, the stylized comment could mean 'dedent' and code could be
> reconstituted with all indents stripped. There are probably programs on
> PyPI to do that. End of excuse.
>

    Yup. Well, I've only been doing python coding for ~9-10 years, but 
I've never had this formatting problem. I viewed the entire debate as 
'an excuse'. I'm going to do some looking on PyPI-- it would be nice to 
point folks to something concrete.  If its an excuse, then that puts an 
end to it.

    As long as I'm addressing an IDLE guy, what would you think of a 
feature for IDLE that would format python code with block delimiters 
automatically and visa versa ?

Thanks

marcus

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

#72670

On 6/4/2014 7:23 PM, Mark H Harris wrote:
> On 6/4/14 5:18 PM, Terry Reedy wrote:
>> On 6/4/2014 10:53 AM, Mark H Harris wrote:
>>> The primary paradigm on this topic locally is that
>>> indents are bad because malformed or mangled code cannot be reformatted
>>> easily (if at all).
>>
>> Begin solution:':' as the end of a line means 'begin block; indent next
>> line'. If one is using tools that mangle, one can add end-of-block
>> comments: '# end, # end if, # if (end implied), or even just ##. In any
>> case, the stylized comment could mean 'dedent' and code could be
>> reconstituted with all indents stripped. There are probably programs on
>> PyPI to do that. End of excuse.
>>
>
>     Yup. Well, I've only been doing python coding for ~9-10 years, but
> I've never had this formatting problem.

The only problem I have seen is when people post code here with \t for 
indent. Many mail readers treat \t as a null char since it actually has 
no standard translation into screen space. This is one reason why PEP8 
recommends using spaces rather than \t for indent. On today's systems, 
the space saved with \t is not worth the trouble.

 > I viewed the entire debate as
> 'an excuse'. I'm going to do some looking on PyPI-- it would be nice to
> point folks to something concrete.  If its an excuse, then that puts an
> end to it.
>
> As long as I'm addressing an IDLE guy, what would you think of a
> feature for IDLE that would format python code with block delimiters
> automatically and visa versa ?

I would not include it by default, as I would not want to encourage 
block-commenting Python code. However, anyone could write an extension 
that would add 3 menu items: BlockIn (add block comment), BlockDent 
(re-indent according to block markers), and BlockOut (remove block 
comments). The editor Format menu would be the obvious place. One would 
not have to parse; instead let tokenize do that. Then BlockIn: add Block 
comment and Newline tokens before Dedent tokens; BlockDent: replace 
BlockComment Newline with Dedent. In either case, follow with 
untokenize. Simply removing block markers could be done directly. The 
block comment could even be user configurable.

(At the moment, untokenize does not properly reconstitue files indented 
with \t.)

-- 
Terry Jan Reedy

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

#72694

On Wed, 04 Jun 2014 22:43:05 -0400, Terry Reedy wrote:

> Many mail readers treat \t as a null char since it actually has no
> standard translation into screen space.

I challenge that assertion. There are two standard translations into 
screen space: jump to the next multiple of 8 spaces, or 1 space.

Treating \t as a single space would be pathetic but standard. Treating it 
as (up to) 8 spaces would be more useful, and standard. Rendering it as a 
picture of a banana dancing on the ceiling would be silly and non-
standard. Not rendering it at all is even more stupid and less justified.


-- 
Steven

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

#72695

On Thu, Jun 5, 2014 at 6:39 PM, Steven D'Aprano <steve@pearwood.info> wrote:
> Treating \t as a single space would be pathetic but standard. Treating it
> as (up to) 8 spaces would be more useful, and standard. Rendering it as a
> picture of a banana dancing on the ceiling would be silly and non-
> standard. Not rendering it at all is even more stupid and less justified.

While I don't generally cite a show that I don't actively watch, it
seems appropriate here: http://youtu.be/F_1zoX5Ax9U?t=1m

ChrisA

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

#72700

On 05 Jun 2014 08:39:34 GMT, Steven D'Aprano <steve@pearwood.info>
declaimed the following:


>Treating \t as a single space would be pathetic but standard. Treating it 
>as (up to) 8 spaces would be more useful, and standard. Rendering it as a 
>picture of a banana dancing on the ceiling would be silly and non-
>standard. Not rendering it at all is even more stupid and less justified.

	The banana has no mnemonic sense... Rendering a tea-cup with a teaspoon
leaning out to the left side, OTOH <G>

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

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

#72703

On Thursday, June 5, 2014 2:09:34 PM UTC+5:30, Steven D'Aprano wrote:
> On Wed, 04 Jun 2014 22:43:05 -0400, Terry Reedy wrote:

> > Many mail readers treat \t as a null char since it actually has no
> > standard translation into screen space.

> I challenge that assertion. There are two standard translations into 
> screen space: jump to the next multiple of 8 spaces, or 1 space.

> Treating \t as a single space would be pathetic but standard. Treating it 
> as (up to) 8 spaces would be more useful, and standard. Rendering it as a 
> picture of a banana dancing on the ceiling would be silly and non-
> standard. Not rendering it at all is even more stupid and less justified.

A random thread (I guess one can find more):

https://mail.python.org/pipermail/python-list/2012-March/621993.html

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web