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

#72709

On Thu, 05 Jun 2014 05:56:07 -0700, Rustom Mody wrote:

> 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


I don't understand why you posted this link. I wasn't questioning Terry's 
description of the problem, that his mail client eats tabs. Thunderbird 
doesn't eat tabs for me, but I believe Terry when he says it eats them 
for him. I was questioning his assertion that there is no standard way to 
render a tab character.



-- 
Steven D'Aprano
http://import-that.dreamwidth.org/

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

#72713

On Thursday, June 5, 2014 8:42:53 PM UTC+5:30, Steven D'Aprano wrote:
> On Thu, 05 Jun 2014 05:56:07 -0700, Rustom Mody wrote:
> > A random thread (I guess one can find more):
> > https://mail.python.org/pipermail/python-list/2012-March/621993.html

> I don't understand why you posted this link. I wasn't questioning Terry's 
> description of the problem, that his mail client eats tabs. Thunderbird 
> doesn't eat tabs for me, but I believe Terry when he says it eats them 
> for him. I was questioning his assertion that there is no standard way to 
> render a tab character.

In the context of Mark Harris saying that people around him dont like
python because of tabs getting garbled in forum-transits, you made the
(rather extreme) statement:

> >> 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.

I was pointing out that that behavior is not unknown even on this very list.

Now whether thunderbird's behavior is straight buggy or compliant with (some
bizarre) standard is another question - for a thunderbird list I hope!

JFTR: For me this reason is miserable.
Communication with others is important.
Visual pleasantness¹ for oneself is more important.
Which is why I advocate unicode in program text even though
- there will be new breakages
- setting up efficient input methods may not be completely trivial
- and there will be problems (like with tab) on transiting systems
etc

------------
¹ One of Dijkstra's memorable quotes:
   <<when we recognize the battle against chaos, mess, and 
   unmastered complexity as one of computing science's major callings, 
   we must admit that "Beauty is our Business">>
   http://www.cs.utexas.edu/users/EWD/transcriptions/EWD06xx/EWD697.html

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

#72715

>    <<when we recognize the battle against chaos, mess, and 
>    unmastered complexity as one of computing science's major callings, 
>    we must admit that "Beauty is our Business">>

I write
LEFT/RIGHT-POINTING DOUBLE ANGLE QUOTATION MARK

They are silently transformed into << >>

So much for attempts at being beautiful!

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

#72749 — Tabs (was Re: OT: This Swift thing)

On 6/5/2014 4:39 AM, 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.

No *single* standard.

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

You forgot the other tab standards. In the US, the default tab stops are 
at 1/2 inch intervals, which is 5 or 6 chars for fixed 10 or 12 pitch 
fonts. Most email is not code from programmers and their bizarre (to a 
non-programmer) and dis-functional choice (sometimes) of 8 spaces.

> 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.

<\t> would be better than nothing. Let us see what Thunderbird does 
*now*. Maybe complaints prompted a change. Or maybe some clients eat 
tabs upon sending.

     4 spaces
         8 spaces
	tab, which displays as 8 spaces on input
		2 tabs

Regardless of what shows, there is still no configuration option.

-- 
Terry Jan Reedy

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

#72777 — Re: Tabs (was Re: OT: This Swift thing)

On 6/5/2014 3:05 PM, Terry Reedy wrote:
> On 6/5/2014 4:39 AM, Steven D'Aprano 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.
>
> <\t> would be better than nothing. Let us see what Thunderbird does
> *now*. Maybe complaints prompted a change. Or maybe some clients eat
> tabs upon sending.
>
>      4 spaces

This is now 5 spaces beyond the added '> ' quote marker.
>          8 spaces

9 spaces beyond ...

>      tab, which displays as 8 spaces on input

Not literally 8 spaces, but one jump of 8 spaces. Anyway, it is now 5 
actual spaces beyond '> '. Something changed somewhere.

>          2 tabs

9 actual spaces.

> Regardless of what shows, there is still no configuration option.

And what shows is not what I expected, but better than the previous 
non-rendering.

-- 
Terry Jan Reedy

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

#72803 — Re: Tabs (was Re: OT: This Swift thing)

On Thu, 05 Jun 2014 15:05:07 -0400, Terry Reedy <tjreedy@udel.edu>
declaimed the following:

>
01234567890
>     4 spaces
>         8 spaces
>	tab, which displays as 8 spaces on input
>		2 tabs
>
	Telling Agent to use fixed pitch font, I see

"4" under column 6 (column 0 being the quote > marker)
"8" under column 10
"t" under column 4
"2" under column 8

	If I turn off fixed pitch, my normal display has

"4" under column 3.25 (estimating, it's not aligned with the 3, but not
quite at what I'd consider halfway to column 4)
"8" under column 5
"t"  around 2.5
"2" under 6
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

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

#73289

On Wednesday, June 4, 2014 10:53:13 PM UTC+8, Mark H. Harris wrote:
> 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

Well, I think a tool kit such as the 
Pascal to C translator can solve the 
problem. 

Since Python is OOP and functional with
dynamic typing,  a Python to Go or Swift translator can be written in Python. 

Of course some features of Python might be restricted.

We need to chunk out fashion jobs in 
different  commercial platforms to draw attentions from non-programmers
whose roles are to pay for fashion HW/SW products.  

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

#72643

On 06/03/2014 03: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. 

Yeah people do have strong opinions.  But regardless of those opinions,
a programmer who continually tries to fight the programming language (no
matter what language that is) is going to end up with low productivity
and probably bad code.  I may despise Java, but if my employer required
me to use it on a project, I need stop fighting the language and learn
to work with it and take advantage of it.  Also programmers who insist
on bringing certain paradigms and baggage with them from other languages
are going to really suffer I think.  For example, trying to program in a
Java style in Python is going to cause problems.  Back in uni I saw that
a lot with people trying to code in C++ using Javaisms.  (Hmm, I see a
pattern here... we can blame it all on Java.)

In any event, I confess I don't understand people who despise Python's
block style.  Do programmers not psuedo-code on paper or white boards
anymore?  If so, then we've definitely lost something.  That Python is
executable pseudo-code really appealed to me early on.

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

#72644

On Thu, Jun 5, 2014 at 1:00 AM, Michael Torrie <torriem@gmail.com> wrote:
> Do programmers not psuedo-code on paper or white boards anymore?

I pseudocode in a text editor, these days. Sometimes that pseudocode
gets reworked into code; more often it becomes comments that precede
the code (which may or may not get dropped once the code's working).

"Executable pseudo-code" is all very well as a concept, but there's an
awful lot that I can write down that doesn't run as Python. For
instance, Python stubbornly insists that assignment be written like
this:

x = expression

and flat out refuses to accept this:

4*x*x + 3*x + y + 50 = (x*y + z) * (x + z)

I mean honestly. I've translated all the mathematical notation into
programming style (asterisks for multiplication, etc). Why can't
Python take the values for y and z and give me back a value for x?

But seriously, this is the sort of thing that will most likely end up
as a comment, followed by the solved-for-x version (which will quite
possibly not be a single line of code, with something this complicated
- especially as there could be multiple solutions or no solutions).
And that transformation isn't really much easier in Python than any
other language with similar mathematical facilities (I used to do this
sort of thing in REXX back in the 90s). For the basic structure of the
code (which is where Python *does* look more like pseudo-code), I tend
to write actual code straight away; in a good editor, you can write
C/Java/Pike/etc code with auto indentation if you put in your braces,
so there's no advantage to leaving them off (as there would be on a
whiteboard).

Have we lost something by not working on whiteboards? I don't think
so. In fact, we've gained a lot, because I can pull up an editor,
share my screen with someone, and show my work directly as it happens.
A whiteboard allows that only if the two people are physically sharing
a room.

ChrisA

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

#72560

On 6/3/14, 4:43 PM, Sturla Molden wrote:
> Are Python apps still banned from AppStore, even if we bundle an
> interpreter?

Python apps are not banned from the App Store. See 
https://itunes.apple.com/us/app/quickwho/id419483981?mt=12.

-- 
Kevin Walzer
Code by Kevin/Mobile Code by Kevin
http://www.codebykevin.com
http://www.wtmobilesoftware.com

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

#72561

On 04/06/14 01:39, Kevin Walzer wrote:
> On 6/3/14, 4:43 PM, Sturla Molden wrote:
>> Are Python apps still banned from AppStore, even if we bundle an
>> interpreter?
>
> Python apps are not banned from the App Store. See
> https://itunes.apple.com/us/app/quickwho/id419483981?mt=12.
>

Mac AppStore yes, iOS AppStore as well?

There used to be a ban on interpreted languages to keep out Java and 
Flash, but it also hurt Python. On Mac there has never been a policy 
against Java or Flash.

Sturla

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

#72611

On 2014-06-03 20:43:06 +0000, Sturla Molden said:

> I see no reason to use Swift instead of Python and PyObjC

Most likely there'll be better integration with Xcode and its tools.


-- 
Andrea

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web