Re: Python usage numbers

Discussion in 'Python' started by Chris Angelico, Feb 12, 2012.

  1. On Sun, Feb 12, 2012 at 12:21 PM, Eric Snow <> wrote:
    > However, in at
    > least one current thread (on python-ideas) and at a variety of times
    > in the past, _some_ people have found Unicode in Python 3 to make more
    > work.


    If Unicode in Python is causing you more work, isn't it most likely
    that the issue would have come up anyway? For instance, suppose you
    have a web form and you accept customer names, which you then store in
    a database. You could assume that the browser submits it in UTF-8 and
    that your database back-end can accept UTF-8, and then pretend that
    it's all ASCII, but if you then want to upper-case the name for a
    heading, somewhere you're going to needto deal with Unicode; and when
    your programming language has facilities like str.upper(), that's
    going to make it easier, not later. Sure, the simple case is easier if
    you pretend it's all ASCII, but it's still better to have language
    facilities.

    ChrisA
     
    Chris Angelico, Feb 12, 2012
    #1
    1. Advertising

  2. On Sun, 12 Feb 2012 12:28:30 +1100, Chris Angelico wrote:

    > On Sun, Feb 12, 2012 at 12:21 PM, Eric Snow
    > <> wrote:
    >> However, in at
    >> least one current thread (on python-ideas) and at a variety of times in
    >> the past, _some_ people have found Unicode in Python 3 to make more
    >> work.

    >
    > If Unicode in Python is causing you more work, isn't it most likely that
    > the issue would have come up anyway?


    The argument being made is that in Python 2, if you try to read a file
    that contains Unicode characters encoded with some unknown codec, you
    don't have to think about it. Sure, you get moji-bake rubbish in your
    database, but that's the fault of people who insist on not being
    American. Or who spell Zoe with an umlaut.

    In Python 3, if you try the same thing, you get an error. Fixing the
    error requires thought, and even if that is only a minuscule amount of
    thought, that's too much for some developers who are scared of Unicode.
    Hence the FUD that Python 3 is too hard because it makes you learn
    Unicode.

    I know this isn't exactly helpful, but I wish they'd just HTFU. I'm with
    Joel Spolsky on this one: if you're a programmer in 2003 who doesn't have
    at least a basic working knowledge of Unicode, you're the equivalent of a
    doctor who doesn't believe in germs.

    http://www.joelonsoftware.com/articles/Unicode.html

    Learning a basic working knowledge of Unicode is not that hard. You don't
    need to be an expert, and it's just not that scary.

    The use-case given is:

    "I have a file containing text. I can open it in an editor and see it's
    nearly all ASCII text, except for a few weird and bizarre characters like
    £ © ± or ö. In Python 2, I can read that file fine. In Python 3 I get an
    error. What should I do that requires no thought?"

    Obvious answers:

    - Try decoding with UTF8 or Latin1. Even if you don't get the right
    characters, you'll get *something*.

    - Use open(filename, encoding='ascii', errors='surrogateescape')

    (Or possibly errors='ignore'.)



    --
    Steven
     
    Steven D'Aprano, Feb 12, 2012
    #2
    1. Advertising

  3. Chris Angelico

    Rick Johnson Guest

    On Feb 11, 8:23 pm, Steven D'Aprano <steve
    > wrote:
    > On Sun, 12 Feb 2012 12:28:30 +1100, Chris Angelico wrote:
    > > On Sun, Feb 12, 2012 at 12:21 PM, Eric Snow
    > > <> wrote:
    > >> However, in at
    > >> least one current thread (on python-ideas) and at a variety of times in
    > >> the past, _some_ people have found Unicode in Python 3 to make more
    > >> work.

    >
    > > If Unicode in Python is causing you more work, isn't it most likely that
    > > the issue would have come up anyway?

    >
    > The argument being made is that in Python 2, if you try to read a file
    > that contains Unicode characters encoded with some unknown codec, you
    > don't have to think about it. Sure, you get moji-bake rubbish in your
    > database, but that's the fault of people who insist on not being
    > American. Or who spell Zoe with an umlaut.


    That's not the worst of it... i have many times had a block of text
    that was valid ASCII except for some intermixed Unicode white-space.
    Who the hell would even consider inserting Unicode white-space!!!

    > "I have a file containing text. I can open it in an editor and see it's
    > nearly all ASCII text, except for a few weird and bizarre characters like
    > £ © ± or ö. In Python 2, I can read that file fine. In Python 3 Iget an
    > error. What should I do that requires no thought?"
    >
    > Obvious answers:


    the most obvious answer would be to read the file WITHOUT worrying
    about asinine encoding.
     
    Rick Johnson, Feb 12, 2012
    #3
  4. On Sun, Feb 12, 2012 at 1:36 PM, Rick Johnson
    <> wrote:
    > On Feb 11, 8:23 pm, Steven D'Aprano <steve
    > > wrote:
    >> "I have a file containing text. I can open it in an editor and see it's
    >> nearly all ASCII text, except for a few weird and bizarre characters like
    >> £ © ± or ö. In Python 2, I can read that file fine. In Python 3 I get an
    >> error. What should I do that requires no thought?"
    >>
    >> Obvious answers:

    >
    > the most obvious answer would be to read the file WITHOUT worrying
    > about asinine encoding.


    What this statement misunderstands, though, is that ASCII is itself an
    encoding. Files contain bytes, and it's only what's external to those
    bytes that gives them meaning. The famous "bush hid the facts" trick
    with Windows Notepad shows the folly of trying to use internal
    evidence to identify meaning from bytes.

    Everything that displays text to a human needs to translate bytes into
    glyphs, and the usual way to do this conceptually is to go via
    characters. Pretending that it's all the same thing really means
    pretending that one byte represents one character and that each
    character is depicted by one glyph. And that's doomed to failure,
    unless everyone speaks English with no foreign symbols - so, no
    mathematical notations.

    ChrisA
     
    Chris Angelico, Feb 12, 2012
    #4
  5. On Sun, 12 Feb 2012 15:38:37 +1100, Chris Angelico wrote:

    > Everything that displays text to a human needs to translate bytes into
    > glyphs, and the usual way to do this conceptually is to go via
    > characters. Pretending that it's all the same thing really means
    > pretending that one byte represents one character and that each
    > character is depicted by one glyph. And that's doomed to failure, unless
    > everyone speaks English with no foreign symbols - so, no mathematical
    > notations.


    Pardon me, but you can't even write *English* in ASCII.

    You can't say that it cost you £10 to courier your résumé to the head
    office of Encyclopædia Britanica to apply for the position of Staff
    Coördinator. (Admittedly, the umlaut on the second "o" looks a bit stuffy
    and old-fashioned, but it is traditional English.)

    Hell, you can't even write in *American*: you can't say that the recipe
    for the 20¢ WobblyBurger™ is © 2012 WobblyBurgerWorld Inc.

    ASCII truly is a blight on the world, and the sooner it fades into
    obscurity, like EBCDIC, the better.

    Even if everyone did change to speak ASCII, you still have all the
    historical records and documents and files to deal with. Encodings are
    not going away.


    --
    Steven
     
    Steven D'Aprano, Feb 12, 2012
    #5
  6. On Sun, Feb 12, 2012 at 4:51 PM, Steven D'Aprano
    <> wrote:
    > You can't say that it cost you £10 to courier your résumé to the head
    > office of Encyclopædia Britanica to apply for the position of Staff
    > Coördinator.


    True, but if it cost you $10 (or 10 GBP) to courier your curriculum
    vitae to the head office of Encyclopaedia Britannica to become Staff
    Coordinator, then you'd be fine. And if it cost you $10 to post your
    work summary to Britannica's administration to apply for this Staff
    Coordinator position, you could say it without 'e' too. Doesn't mean
    you don't need Unicode!

    ChrisA
     
    Chris Angelico, Feb 12, 2012
    #6
  7. On Sat, 11 Feb 2012 18:36:52 -0800, Rick Johnson wrote:

    >> "I have a file containing text. I can open it in an editor and see it's
    >> nearly all ASCII text, except for a few weird and bizarre characters
    >> like £ © ± or ö. In Python 2, I can read that file fine. In Python 3 I
    >> get an error. What should I do that requires no thought?"
    >>
    >> Obvious answers:

    >
    > the most obvious answer would be to read the file WITHOUT worrying about
    > asinine encoding.


    Your mad leet reading comprehension skillz leave me in awe Rick.

    If you try to read a file containing non-ASCII characters encoded using
    UTF8 on Windows without explicitly specifying either UTF8 as the
    encoding, or an error handler, you will get an exception.

    It's not just UTF8 either, but nearly all encodings. You can't even
    expect to avoid problems if you stick to nothing but Windows, because
    Windows' default encoding is localised: a file generated in (say) Israel
    or Japan or Germany will use a different code page (encoding) by default
    than one generated in (say) the US, Canada or UK.



    --
    Steven
     
    Steven D'Aprano, Feb 12, 2012
    #7
  8. Chris Angelico

    Andrew Berg Guest

    On 2/12/2012 12:10 AM, Steven D'Aprano wrote:
    > It's not just UTF8 either, but nearly all encodings. You can't even
    > expect to avoid problems if you stick to nothing but Windows, because
    > Windows' default encoding is localised: a file generated in (say) Israel
    > or Japan or Germany will use a different code page (encoding) by default
    > than one generated in (say) the US, Canada or UK.

    Generated by what? Windows will store a locale value for programs to
    use, but programs use Unicode internally by default (i.e., API calls are
    Unicode unless they were built for old versions of Windows), and the
    default filesystem (NTFS) uses Unicode for file names. AFAIK, only the
    terminal has a localized code page by default.
    Perhaps Notepad will write text files with the localized code page by
    default, but that's an application choice...

    --
    CPython 3.2.2 | Windows NT 6.1.7601.17640
     
    Andrew Berg, Feb 12, 2012
    #8
  9. Chris Angelico

    Matej Cepl Guest

    On 12.2.2012 03:23, Steven D'Aprano wrote:
    > The use-case given is:
    >
    > "I have a file containing text. I can open it in an editor and see it's
    > nearly all ASCII text, except for a few weird and bizarre characters like
    > £ © ± or ö. In Python 2, I can read that file fine. In Python 3 I get an
    > error. What should I do that requires no thought?"
    >
    > Obvious answers:
    >
    > - Try decoding with UTF8 or Latin1. Even if you don't get the right
    > characters, you'll get *something*.
    >
    > - Use open(filename, encoding='ascii', errors='surrogateescape')
    >
    > (Or possibly errors='ignore'.)


    These are not good answer, IMHO. The only answer I can think of, really, is:

    - pack you luggage, your submarine waits on you to peel onions in it
    (with reference to the Joel's article). Meaning, really, you should
    learn your craft and pull up your head from the sand. There is a wider
    world around you.

    (and yes, I am a Czech, so I need at least latin-2 for my language).

    Best,

    Matěj
     
    Matej Cepl, Feb 12, 2012
    #9
  10. Chris Angelico

    Matej Cepl Guest

    On 12.2.2012 09:14, Matej Cepl wrote:
    >> Obvious answers:
    >>
    >> - Try decoding with UTF8 or Latin1. Even if you don't get the right
    >> characters, you'll get *something*.
    >>
    >> - Use open(filename, encoding='ascii', errors='surrogateescape')
    >>
    >> (Or possibly errors='ignore'.)

    >
    > These are not good answer, IMHO. The only answer I can think of, really,
    > is:


    Slightly less flameish answer to the question “What should I do,
    really?†is a tough one: all these suggested answers are bad because
    they don’t deal with the fact, that your input data are obviously
    broken. The rest is just pure GIGO … without fixing (and I mean, really,
    fixing, not ignoring the problem, which is what the previous answers
    suggest) your input, you’ll get garbage on output. And you should be
    thankful to py3k that it shown the issue to you.

    BTW, can you display the following line?

    PříliÅ¡ žluÅ¥ouÄký kůň úpÄ›l Äábelské ódy.

    Best,

    Matěj
     
    Matej Cepl, Feb 12, 2012
    #10
  11. On Sun, 12 Feb 2012 01:05:35 -0600, Andrew Berg wrote:

    > On 2/12/2012 12:10 AM, Steven D'Aprano wrote:
    >> It's not just UTF8 either, but nearly all encodings. You can't even
    >> expect to avoid problems if you stick to nothing but Windows, because
    >> Windows' default encoding is localised: a file generated in (say)
    >> Israel or Japan or Germany will use a different code page (encoding) by
    >> default than one generated in (say) the US, Canada or UK.

    > Generated by what? Windows will store a locale value for programs to
    > use, but programs use Unicode internally by default


    Which programs? And we're not talking about what they use internally, but
    what they write to files.


    > (i.e., API calls are
    > Unicode unless they were built for old versions of Windows), and the
    > default filesystem (NTFS) uses Unicode for file names.


    No. File systems do not use Unicode for file names. Unicode is an
    abstract mapping between code points and characters. File systems are
    written using bytes.

    Suppose you're a fan of Russian punk bank Ðаӥв and you have a directory
    of their music. The file system doesn't store the Unicode code points
    1053 1072 1253 1074, it has to be encoded to a sequence of bytes first.

    NTFS by default uses the UTF-16 encoding, which means the actual bytes
    written to disk are \x1d\x040\x04\xe5\x042\x04 (possibly with a leading
    byte-order mark \xff\xfe).

    Windows has two separate APIs, one for "wide" characters, the other for
    single bytes. Depending on which one you use, the directory will appear
    to be called Ðаӥв or 0Ã¥2.

    But in any case, we're not talking about the file name encoding. We're
    talking about the contents of files.


    > AFAIK, only the
    > terminal has a localized code page by default. Perhaps Notepad will
    > write text files with the localized code page by default, but that's an
    > application choice...


    Exactly. And unless you know what encoding the application chooses, you
    will likely get an exception trying to read the file.


    --
    Steven
     
    Steven D'Aprano, Feb 12, 2012
    #11
  12. Chris Angelico

    Andrew Berg Guest

    On 2/12/2012 3:12 AM, Steven D'Aprano wrote:
    > NTFS by default uses the UTF-16 encoding, which means the actual bytes
    > written to disk are \x1d\x040\x04\xe5\x042\x04 (possibly with a leading
    > byte-order mark \xff\xfe).

    That's what I meant. Those bytes will be interpreted consistently across
    all locales.

    > Windows has two separate APIs, one for "wide" characters, the other for
    > single bytes. Depending on which one you use, the directory will appear
    > to be called Ðаӥв or 0Ã¥2.

    Yes, and AFAIK, the wide API is the default. The other one only exists
    to support programs that don't support the wide API (generally, such
    programs were intended to be used on older platforms that lack that API).

    > But in any case, we're not talking about the file name encoding. We're
    > talking about the contents of files.

    Okay then. As I stated, this has nothing to do with the OS since
    programs are free to interpret bytes any way they like.

    --
    CPython 3.2.2 | Windows NT 6.1.7601.17640
     
    Andrew Berg, Feb 12, 2012
    #12
  13. On 12/02/2012 08:26, Matej Cepl wrote:
    > On 12.2.2012 09:14, Matej Cepl wrote:
    >>> Obvious answers:
    >>>
    >>> - Try decoding with UTF8 or Latin1. Even if you don't get the right
    >>> characters, you'll get *something*.
    >>>
    >>> - Use open(filename, encoding='ascii', errors='surrogateescape')
    >>>
    >>> (Or possibly errors='ignore'.)

    >>
    >> These are not good answer, IMHO. The only answer I can think of, really,
    >> is:

    >
    > Slightly less flameish answer to the question “What should I do,
    > really?†is a tough one: all these suggested answers are bad because
    > they don’t deal with the fact, that your input data are obviously
    > broken. The rest is just pure GIGO … without fixing (and I mean, really,
    > fixing, not ignoring the problem, which is what the previous answers
    > suggest) your input, you’ll get garbage on output. And you should be
    > thankful to py3k that it shown the issue to you.
    >
    > BTW, can you display the following line?
    >
    > PříliÅ¡ žluÅ¥ouÄký kůň úpÄ›l Äábelské ódy.
    >
    > Best,
    >
    > Matěj


    Yes in Thunderbird, Notepad, Wordpad and Notepad++ on Windows Vista,
    can't be bothered to try any other apps.

    --
    Cheers.

    Mark Lawrence.
     
    Mark Lawrence, Feb 12, 2012
    #13
  14. Chris Angelico

    Roy Smith Guest

    In article <>,
    Chris Angelico <> wrote:

    > On Sun, Feb 12, 2012 at 1:36 PM, Rick Johnson
    > <> wrote:
    > > On Feb 11, 8:23 pm, Steven D'Aprano <steve
    > > > wrote:
    > >> "I have a file containing text. I can open it in an editor and see it's
    > >> nearly all ASCII text, except for a few weird and bizarre characters like
    > >> £ © ± or ö. In Python 2, I can read that file fine. In Python 3 I get an
    > >> error. What should I do that requires no thought?"
    > >>
    > >> Obvious answers:

    > >
    > > the most obvious answer would be to read the file WITHOUT worrying
    > > about asinine encoding.

    >
    > What this statement misunderstands, though, is that ASCII is itself an
    > encoding. Files contain bytes, and it's only what's external to those
    > bytes that gives them meaning.


    Exactly. <soapbox class="wise-old-geezer">. ASCII was so successful at
    becoming a universal standard which lasted for decades, people who grew
    up with it don't realize there was once any other way. Not just EBCDIC,
    but also SIXBIT, RAD-50, tilt/rotate, packed card records, and so on.
    Transcoding was a way of life, and if you didn't know what you were
    starting with and aiming for, it was hopeless. Kind of like now where
    we are again with Unicode. </soapbox>
     
    Roy Smith, Feb 12, 2012
    #14
  15. Chris Angelico

    Roy Smith Guest

    In article <4f375347$0$29986$c3e8da3$>,
    Steven D'Aprano <> wrote:

    > ASCII truly is a blight on the world, and the sooner it fades into
    > obscurity, like EBCDIC, the better.


    That's a fair statement, but it's also fair to say that at the time it
    came out (49 years ago!) it was a revolutionary improvement on the
    extant state of affairs (every manufacturer inventing their own code,
    and often different codes for different machines). Given the cost of
    both computer memory and CPU cycles at the time, sticking to a 7-bit
    code (the 8th bit was for parity) was a necessary evil.

    As Steven D'Aprano pointed out, it was missing some commonly used US
    symbols such as ¢ or ©. This was a small price to pay for the
    simplicity ASCII afforded. It wasn't a bad encoding. I was a very good
    encoding. But the world has moved on and computing hardware has become
    cheap enough that supporting richer encodings and character sets is
    realistic.

    And, before people complain about the character set being US-Centric,
    keep in mind that the A in ASCII stands for American, and it was
    published by ANSI (whose A also stands for American). I'm not trying to
    wave the flag here, just pointing out that it was never intended to be
    anything other than a national character set.

    Part of the complexity of Unicode is that when people switch from
    working with ASCII to working with Unicode, they're really having to
    master two distinct things at the same time (and often conflate them
    into a single confusing mess). One is the Unicode character set. The
    other is a specific encoding (UTF-8, UTF-16, etc). Not to mention silly
    things like BOM (Byte Order Mark). I expect that some day, storage
    costs will become so cheap that we'll all just be using UTF-32, and
    programmers of the day will wonder how their poor parents and
    grandparents ever managed in a world where nobody quite knew what you
    meant when you asked, "how long is that string?".
     
    Roy Smith, Feb 12, 2012
    #15
  16. Chris Angelico

    Dan Sommers Guest

    On Sun, 12 Feb 2012 17:08:24 +1100, Chris Angelico wrote:

    > On Sun, Feb 12, 2012 at 4:51 PM, Steven D'Aprano
    > <> wrote:
    >> You can't say that it cost you £10 to courier your résumé to the head
    >> office of Encyclopædia Britanica to apply for the position of Staff
    >> Coördinator.

    >
    > True, but if it cost you $10 (or 10 GBP) to courier your curriculum
    > vitae to the head office of Encyclopaedia Britannica to become Staff
    > Coordinator, then you'd be fine. And if it cost you $10 to post your
    > work summary to Britannica's administration to apply for this Staff
    > Coordinator position, you could say it without 'e' too. Doesn't mean you
    > don't need Unicode!


    Back in the late 1970's, the economy and the outlook in the USA sucked,
    and the following joke made the rounds:

    Mr. Smith: Good morning, Mr. Jones. How are you?

    Mr. Jones: I'm fine.

    (The humor is that Mr. Jones had his head so far [in the sand] that he
    thought that things were fine.)

    American English is my first spoken language, but I know enough French,
    Greek, math, and other languages that I am very happy to have more than
    ASCII these days. I imagine that even Steven's surname should be spelled
    D’Aprano rather than D'Aprano.

    Dan
     
    Dan Sommers, Feb 12, 2012
    #16
  17. On Sun, 12 Feb 2012 10:48:36 -0500, Roy Smith <> wrote:

    >As Steven D'Aprano pointed out, it was missing some commonly used US
    >symbols such as ¢ or ©. This was a small price to pay for the
    >simplicity ASCII afforded. It wasn't a bad encoding. I was a very good
    >encoding. But the world has moved on and computing hardware has become
    >cheap enough that supporting richer encodings and character sets is
    >realistic.
    >

    Any volunteers to create an Extended Baudot... Instead of "letter
    shift" and "number shift" we could have a generic "encoding shift" which
    uses the following characters to identify which 7-bit subset of Unicode
    is to be represented <G>
    --
    Wulfraed Dennis Lee Bieber AF6VN
    HTTP://wlfraed.home.netcom.com/
     
    Dennis Lee Bieber, Feb 12, 2012
    #17
  18. Chris Angelico

    rusi Guest

    On Feb 12, 10:51 am, Steven D'Aprano <steve
    > wrote:
    > On Sun, 12 Feb 2012 15:38:37 +1100, Chris Angelico wrote:
    > > Everything that displays text to a human needs to translate bytes into
    > > glyphs, and the usual way to do this conceptually is to go via
    > > characters. Pretending that it's all the same thing really means
    > > pretending that one byte represents one character and that each
    > > character is depicted by one glyph. And that's doomed to failure, unless
    > > everyone speaks English with no foreign symbols - so, no mathematical
    > > notations.

    >
    > Pardon me, but you can't even write *English* in ASCII.
    >
    > You can't say that it cost you £10 to courier your résumé to the head
    > office of Encyclopædia Britanica to apply for the position of Staff
    > Coördinator. (Admittedly, the umlaut on the second "o" looks a bit stuffy
    > and old-fashioned, but it is traditional English.)
    >
    > Hell, you can't even write in *American*: you can't say that the recipe
    > for the 20¢ WobblyBurger™ is © 2012 WobblyBurgerWorld Inc.


    [Quite OT but...] How do you type all this?
    [Note: I grew up on APL so unlike Rick I am genuinely asking :) ]
     
    rusi, Feb 12, 2012
    #18
  19. Chris Angelico

    Roy Smith Guest

    In article <>,
    Dennis Lee Bieber <> wrote:

    > On Sun, 12 Feb 2012 10:48:36 -0500, Roy Smith <> wrote:
    >
    > >As Steven D'Aprano pointed out, it was missing some commonly used US
    > >symbols such as ¢ or ©.


    That's interesting. When I wrote that, it showed on my screen as a cent
    symbol and a copyright symbol. What I see in your response is an upper
    case "A" with a hat accent (circumflex?) over it followed by a cent
    symbol, and likewise an upper case "A" with a hat accent over it
    followed by copyright symbol.

    Oh, for the days of ASCII again :)

    Not to mention, of course, that I wrote <colon><dash><close-paren>, but
    I fully expect some of you will be reading this with absurd clients
    which turn that into some kind of smiley-face image.


    > Any volunteers to create an Extended Baudot... Instead of "letter
    > shift" and "number shift" we could have a generic "encoding shift" which
    > uses the following characters to identify which 7-bit subset of Unicode
    > is to be represented <G>


    I think that's called UTF-8.
     
    Roy Smith, Feb 12, 2012
    #19
  20. Chris Angelico

    Roy Smith Guest

    In article
    <>,
    rusi <> wrote:

    > On Feb 12, 10:51 am, Steven D'Aprano <steve
    > > wrote:
    > > On Sun, 12 Feb 2012 15:38:37 +1100, Chris Angelico wrote:
    > > > Everything that displays text to a human needs to translate bytes into
    > > > glyphs, and the usual way to do this conceptually is to go via
    > > > characters. Pretending that it's all the same thing really means
    > > > pretending that one byte represents one character and that each
    > > > character is depicted by one glyph. And that's doomed to failure, unless
    > > > everyone speaks English with no foreign symbols - so, no mathematical
    > > > notations.

    > >
    > > Pardon me, but you can't even write *English* in ASCII.
    > >
    > > You can't say that it cost you £10 to courier your résumé to the head
    > > office of Encyclopædia Britanica to apply for the position of Staff
    > > Coördinator. (Admittedly, the umlaut on the second "o" looks a bit stuffy
    > > and old-fashioned, but it is traditional English.)
    > >
    > > Hell, you can't even write in *American*: you can't say that the recipe
    > > for the 20¢ WobblyBurger is © 2012 WobblyBurgerWorld Inc.

    >
    > [Quite OT but...] How do you type all this?
    > [Note: I grew up on APL so unlike Rick I am genuinely asking :) ]


    What I do (on a Mac) is open the Keyboard Viewer thingie and try various
    combinations of shift-control-option-command-function until the thing
    I'm looking for shows up on a keycap. A few of them I've got memorized
    (for example, option-8 gets you a bullet €). I would imagine if you
    commonly type in a language other than English, you would quickly
    memorize the ones you use a lot.

    Or, open the Character Viewer thingie and either hunt around the various
    drill-down menus (North American Scripts / Canadian Aboriginal
    Syllabics, for example) or type in some guess at the official unicode
    name into the search box.
     
    Roy Smith, Feb 12, 2012
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. metfan
    Replies:
    2
    Views:
    4,863
    Robert Olofsson
    Oct 21, 2003
  2. Colin J. Williams

    Webchecker Usage - a problem with local usage

    Colin J. Williams, Feb 25, 2004, in forum: Python
    Replies:
    1
    Views:
    556
    Colin J. Williams
    Feb 26, 2004
  3. hvt
    Replies:
    0
    Views:
    1,220
  4. hvt
    Replies:
    0
    Views:
    1,498
  5. Eric Snow

    Python usage numbers

    Eric Snow, Feb 11, 2012, in forum: Python
    Replies:
    0
    Views:
    142
    Eric Snow
    Feb 11, 2012
Loading...

Share This Page