On Thu, Nov 24, 2016 at 11:27 AM, Mike Orr <[email protected]> wrote:
> I have a friend who teaches Python to beginners and uses it for
> scientific programming, so I'll see what he says.
> [He] does complain about how Python 3 forces the
> separation of strings and bytes: why not leave it as it was? So he
> would be sympathetic to that argument, and he preferred to stick with
> Python 2, but he's now migrating to 3 because it's the future.
Here's the reply from my friend Chris Barker:
{Re "The strings in Python 3 are very difficult to use for beginners. ")
CB: This is just plain wrong, I have been very pleasantly surprised
that my students have had NO issues with strings with py3 -- I don't
even need to teach a single thing about Unicode, whereas with py2, if
anyone wanted to use a non-english language, it needed to be
introduced early.
CB: I will say that py3 is a little pit less of a "scripting"
language, and more of a "systems" language. Even really little stuff
like print as a function makes it a little bit harder to whip out a
quickie script -- but that's not an issue for newbies that do intend
to work on larger systems.
CB: Very few people ever need to deal with bytes at all. The
string<>bytes thing has been a pain for folks doing low level protocol
libraries, but not an issue at all for newbies.
(Re Chris preferring Python 2.)
CB: I don't have any preference for sticking with py2 -- the
transition pain is unfortunate, though.
(Re format strings and Python 3 libraries.)
CB: The multiple formatting methods is too bad, but it's actually the
result if keeping backward compatibility - no one wants to disallow
also style % formatting. And for newbies, I just teach .format() -- no
problem there. I'll reserve judgement on f strings -- though I'm not a
fan yet.
CB: [using only f-strings is] probably not a bad idea -- but it only
works if your data you are using to format the strings is in local
variables -- what if you need to format a string from a dict???
.format is not legacy -- it's really useful, though maybe more for
advanced use cases. It does look like f-strings use the same
formatting language as .format() -- so that's really nice.
CB: There WERE some big issues with strings for folks writing "wire
protocol" code, where text and binary data are mixed -- and I think
those were addressed: surrogate pairs and bytestring formatting were
added.
CB: py3 introduced much smother compatibility between integers, long
integers and floats -- you'd think he's like that :-)
And that works because when you have a float, you know how it's encoded...
CB: I do want numpy to have a bytestring type, which it doesn't, but
that's only because it would be nice to have a compact type for
strings that are mostly ascii anyway.
CB: Though the introduction of pathlib without any other stlib stuff
allowing is was pretty lame -- I _think_ that's getting fixed for 3.6.
That's not a string issue, though.
(Re "Some people go so far as to ban my book because it does not
support Python 3, even though my book is the most effective method for
learning to code.")
CB: No one is "banning" his book. For one, no on is in the position to
ban anything, and for two, I at least, still recommend it to my
students, even though I'm teaching py3.
(Re " The solution is to create a "string" type that magically knows
how to be Unicode or raw bytes")
CB: This is actually what py2 did after introducing Unicode -- it
wasn't a magic string type, but it did auto-convert all over the place
-- and that was actually the source of most of the problems.
(Re "Python has a really good Chardet library")
CB: He's got a good point here, but I thin he's very wrong about where
it shoudl be applied -- haivng a good encoding detection at teh
boundaries of the app would be nice: open a text file, and allow
auto-detection of encoding -- the user gets nice clean unicode strings
-- very nice. But having that kind of auto-detection happen inside
your app whenever bytes meets strings is a really bad idea -- it can
fail, and whether it fails depends on the data, not types or anything
you can test properly ahead of time.
--
Mike Orr <[email protected]>
--
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/pylons-discuss/CAH9f%3DurcfZbYN2SZBqfrb2Oi_BShOsUVrOb5%2BwMz_PJs561ZhA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
