[Python-ideas] Python reviewed
Simon Lovell
simon58500 at bigpond.com
Mon Jan 9 08:50:12 EST 2017
Hmm, Thanks Chris. I thought I was posting this to the correct place.
I've never seen that "for line in open ..." after googling it many
times! Why is this question so often asked then?
Re:Indentation making end block markers not needed; well yes they aren't
/needed/. However, they are useful for readability purposes. Perhaps if
I use it some more I'll see that they aren't but I doubt it.
Re:PEP249 & SQL, I thought I was proposing something like that but it
can't be tacked on later I don't think - needs to be an inate part of
Python to work as cleanly as 4gl languages. Re: your named tuple
suggestion, wouldn't that mean that the naming is divorced from the
result column names - that is part of what shouldn't be.
Re:Everything being true of false. I don't see the value of that. Only
boolean data should be valid in boolean contexts. I don't really see how
that can be argued.
On 09/01/17 21:31, python-ideas-request at python.org wrote:
> Send Python-ideas mailing list submissions to
> python-ideas at python.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://mail.python.org/mailman/listinfo/python-ideas
> or, via email, send a message with subject or body 'help' to
> python-ideas-request at python.org
>
> You can reach the person managing the list at
> python-ideas-owner at python.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Python-ideas digest..."
>
>
> Today's Topics:
>
> 1. Re: PEP 540: Add a new UTF-8 mode (INADA Naoki)
> 2. Python Reviewed (Simon Lovell)
> 3. Re: Python Reviewed (Chris Angelico)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 9 Jan 2017 11:21:41 +0900
> From: INADA Naoki <songofacandy at gmail.com>
> To: "Stephen J. Turnbull" <turnbull.stephen.fw at u.tsukuba.ac.jp>
> Cc: Victor Stinner <victor.stinner at gmail.com>, python-ideas
> <python-ideas at python.org>
> Subject: Re: [Python-ideas] PEP 540: Add a new UTF-8 mode
> Message-ID:
> <CAEfz+TwaVHaKnyquXuUqBMk=AyUcwDMgyA8efuhU9=oMhaGZnQ at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On Sun, Jan 8, 2017 at 1:47 AM, Stephen J. Turnbull
> <turnbull.stephen.fw at u.tsukuba.ac.jp> wrote:
>> INADA Naoki writes:
>>
>> > I want UTF-8 mode is enabled by default (opt-out option) even if
>> > locale is not POSIX,
>> > like `PYTHONLEGACYWINDOWSFSENCODING`.
>> >
>> > Users depends on locale know what locale is and how to configure it.
>> > They can understand difference between locale mode and UTF-8 mode
>> > and they can opt-out UTF-8 mode.
>> > But many people lives in "UTF-8 everywhere" world, and don't know
>> > about locale.
>>
>> I find all this very strange from someone with what looks like a
>> Japanese name. I see mojibake and non-Unicode encodings around me all
>> the time. Caveat: I teach at a University that prides itself on being
>> the most international of Japanese national universities, so in my
>> daily work I see Japanese in 4 different encodings (5 if you count the
>> UTF-16 used internally by MS Office), Chinese in 3 different (claimed)
>> encodings, and occasionally Russian in at least two encodings, ...,
>> uh, I could go on but won't. In any case, the biggest problems are
>> legacy email programs and busted websites in Japanese, plus email that
>> is labeled "GB2312" but actually conforms to GBK (and this is a reply
>> in Japanese to a Chinese applicant writing in Japanese encoded as GBK).
> Since I work on tech company, and use Linux for most only "server-side" program,
> I don't live such a situation.
>
> But when I see non UTF-8 text, I don't change locale to read such text.
> (Actually speaking, locale doesn't solve mojibake because it doesn't change
> my terminal emulator's encoding).
> And I don't change my terminal emulator setting only for read such a text.
> What I do is convert it to UTF-8 through command like `view
> text-from-windows.txt ++enc=cp932`
>
> So there are no problem when Python always use UTF-8 for fsencoding
> and stdio encoding.
>
>> I agree that people around me mostly know only two encodings: "works
>> for me" and "mojibake", but they also use locales configured for them
>> by technical staff. On top of that, international students (the most
>> likely victims of "UTF-8 by default" because students are the biggest
>> Python users) typically have non-Japanese locales set on their
>> imported computers.
> Hmm, Which OS do they use? There are no problem in macOS and Windows.
> Do they use Linux with locale with encoding other than UTF-8, and
> their terminal emulator
> uses non-UTF-8 encoding?
>
> As my feeling, UTF-8 start dominating from about 10 years ago, and
> ja_JP.EUC_JP (it was most common locale for Japanese befoer UTF-8) is
> complete legacy.
>
> There is only one machine (which is in LAN, lives from 10+ years ago,
> /usr/bin/python is Python 1.5!),
> I can ssh which has ja_JP.eucjp locale.
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 9 Jan 2017 19:25:45 +0800
> From: Simon Lovell <simon58500 at bigpond.com>
> To: python-ideas at python.org
> Subject: [Python-ideas] Python Reviewed
> Message-ID: <69e3c5d4-d64b-063e-758e-2b0ac1720daa at bigpond.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Python Reviewed
>
> Having used a lot of languages a little bit and not finding satisfactory
> answers to these in some cases often asked questions, I thought I'd join
> this group to make a post on the virtues and otherwise of python.
>
> The Good:
> Syntactically significant new lines
> Syntactically significant indenting
> Different types of array like structures for different situations
> Mostly simple and clear structures
> Avoiding implicit structures like C++ references which add only
> negative value
> Avoiding overly complicated chaining expressions like
> "while(*d++=*s++);"
> Single syntax for block statements (well, sort of. I'm ignoring
> lines like "if a=b: c=d")
> Lack of a with statement which only obscures the code
>
>
> The Bad:
> Colons at the end of if/while/for blocks. Most of the arguments in
> favour of this decision boil down to PEP 20.2 "Explicit is better than
> implicit". Well, no. if/while/for blocks are already explicit. Adding
> the colon makes it doubly explicit and therefore redundant. There is no
> reason I can see why this colon can't be made optional except for
> possibly PEP20.13 "There should be one-- and preferably only one
> --obvious way to do it". I don't agree that point is sufficient to
> require colons.
>
>
> No end required for if/while/for blocks. This is particularly a
> problem when placing code into text without fixed width fonts. It also
> is a potential problem with tab expansion tricking the programmer. This
> could be done similarly to requiring declarations in Fortran, which if
> "implicit none" was added to the top of the program, declarations are
> required. So add a "Block Close Mandatory" (or similar) keyword to
> enforce this. In practice there is usually a blank line placed at the
> end of blocks to try to signal this to someone reading the code. Makes
> the code less readable and I would refer to PEP20.7 "Readability counts"
>
>
> This code block doesn't compile, even given that function "process"
> takes one string parameter:
> f=open(file)
> endwhile=""
> while (line=f.readline())!=None:
> process(line)
> endwhile
>
> I note that many solutions have been proposed to this. In C, it
> is the ability to write "while(line=fgets(f))" instead of
> "while((line=fgets(f))!=NULL)" which causes the confusion. No solutions
> have been accepted to the current method which is tacky:
> f=open(file)
> endwhile=""
> endif=""
> while True:
> line=f.readline
> if line = None:
> break
> endif
> process(line)
> endwhile
>
>
> Inadequacy of PEP249 - Python Database Specification. This only
> supports dynamic SQL but SQL and particularly select statements should
> be easier to work with in the normal cases where you don't need such
> statements. e.g:
> endselect=""
> idList = select from identities where surname = 'JONES':
> idVar = id
> forenameVar = forename
> surnameVar = surname
> dobVar = dob
> endselect
>
> endfor=""
> for id in idList:
> print id.forenameVar, id.dobVar
> endfor
>
> as opposed to what is presently required in the select case
> which is:
> curs = connection.cursor()
> curs.execute("select id, forename, surname, dob from
> identities where surname = 'JONES'")
> idList=curs.fetchall()
>
> endfor=""
> for id in idList:
> print id[1], id[3]
> endfor
>
> I think the improvement in readibility for the first option
> should be plain to all even in the extremely simple case I've shown.
>
> This is the sort of thing which should be possible in any
> language which works with a database but somehow the IT industry has
> lost it in the 1990s/2000s. Similarly an upgraded syntax for the
> insert/values statement which the SQL standard has mis-specified to make
> the value being inserted too far away from the column name. Should be
> more like:
> endinsert=""
> Insert into identities:
> id = 1
> forename = 'John'
> surname = 'Smith'
> dob = '01-Jan-1970'
> endinsert
>
> One of the major problems with the status quo is the lack of
> named result columns. The other is that the programmer is required to
> convert the where clause into a string. The functionality of dynamic
> where/from clauses can still be provided without needing to rely on
> numbered result columns like so:
> endselect=""
> idList = select from identities where :where_clause:
> id = id
> forename = forename
> surname = surname
> dob = dob
> endselect
>
> Ideally, the bit after the equals sign would support all
> syntaxes allowed by the host database server which probably means it
> needs to be free text passed to the server. Where a string variable
> should be passed, the :variable syntax could be supported but this is
> not often required
>
>
> Variables never set to anything do not error until they are used,
> at least in implementations of Python 2 I have tried. e.g.
> UnlikelyCondition = False
> endif=""
> if UnlikelyCondition:
> print x
> endif
>
> The above code runs fine until UnlikelyCondition is set to True
>
>
> No do-while construct
>
>
> else keyword at the end of while loops is not obvious to those not
> familiar with it. Something more like whenFalse would be clearer
>
>
> Changing print from a statement to a function in Python 3 adds no
> positive value that I can see
>
>
> Upper delimiters being exclusive while lower delimiters are
> inclusive. This is very counter intuitive. e.g. range(1,4) returns
> [1,2,3]. Better to have the default base as one rather than zero IMO. Of
> course, the programmer should always be able to define the lower bound.
> This cannot be changed, of course.
>
>
> Lack of a single character in a method to refer to an attribute
> instead of a local variable, similar to C's "*" for dereferencing a pointer
>
>
> Inability to make simple chained assignments e.g. "a = b = 0"
>
>
> Conditional expression (<true-value> if <condition> else
> <false-value>) in Python is less intuitive than in C (<condition> ?
> <true-value> : <false-value>). Ref PEP308. Why BDFL chose the syntax he
> did is not at all clear.
>
>
> The Ugly:
> Persisting with the crapulence from C where a non zero integer is
> true and zero is false - only ever done because C lacked a boolean data
> type. This is a flagrant violation of PEP 20.2 "Explicit is better than
> implicit" and should be removed without providing backwards compatibility.
>
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 10 Jan 2017 00:31:42 +1100
> From: Chris Angelico <rosuav at gmail.com>
> To: python-ideas <python-ideas at python.org>
> Subject: Re: [Python-ideas] Python Reviewed
> Message-ID:
> <CAPTjJmrTfYup+o7BYwnYB=yCbLof3Csq0CcNU36ke8J5ynb5QA at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On Mon, Jan 9, 2017 at 10:25 PM, Simon Lovell <simon58500 at bigpond.com> wrote:
>> Python Reviewed
>>
>> Having used a lot of languages a little bit and not finding satisfactory
>> answers to these in some cases often asked questions, I thought I'd join
>> this group to make a post on the virtues and otherwise of python.
> I think this thread belongs on python-list at python.org, where you'll
> find plenty of people happy to discuss why Python is and/or shouldn't
> be the way it is.
>
> A couple of responses to just a couple of your points.
>
>> The Good:
>> Syntactically significant new lines
>> Syntactically significant indenting
>> The Bad:
>> No end required for if/while/for blocks. This is particularly a problem
>> when placing code into text without fixed width fonts. It also is a
>> potential problem with tab expansion tricking the programmer.
> If indentation and line endings are significant, you shouldn't need
> end markers. They don't buy you anything. In any case, I've never
> missed them; in fact, Python code follows the "header and lines"
> concept that I've worked with in many, MANY data files for decades
> (think of the sectioned config file format, for example).
>
>> This code block doesn't compile, even given that function "process"
>> takes one string parameter:
>> f=open(file)
>> endwhile=""
>> while (line=f.readline())!=None:
>> process(line)
>> endwhile
>>
>> I note that many solutions have been proposed to this. In C, it is
>> the ability to write "while(line=fgets(f))" instead of
>> "while((line=fgets(f))!=NULL)" which causes the confusion. No solutions have
>> been accepted to the current method which is tacky:
>> f=open(file)
>> endwhile=""
>> endif=""
>> while True:
>> line=f.readline
>> if line = None:
>> break
>> endif
>> process(line)
>> endwhile
> Here's a better way:
>
> for line in open(file):
> process(line)
>
> If you translate C code to Python, sure, it'll sometimes come out even
> uglier than the C original. But there's often a Pythonic way to write
> things.
>
>> Inadequacy of PEP249 - Python Database Specification. This only supports
>> dynamic SQL but SQL and particularly select statements should be easier to
>> work with in the normal cases where you don't need such statements. e.g:
>> endselect=""
>> idList = select from identities where surname = 'JONES':
>> idVar = id
>> forenameVar = forename
>> surnameVar = surname
>> dobVar = dob
>> endselect
>>
>> endfor=""
>> for id in idList:
>> print id.forenameVar, id.dobVar
>> endfor
> You're welcome to propose something like this. I suspect you could
> build an SQL engine that uses a class to create those bindings -
> something like:
>
> class people(identities):
> id, forename, surname, dob
> where="surname = 'JONES'"
>
> for person in people:
> print(person.forename, person.dob)
>
> Side point: "forename" and "surname" are inadvisable fields.
> http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/
>
>> One of the major problems with the status quo is the lack of named
>> result columns. The other is that the programmer is required to convert the
>> where clause into a string. The functionality of dynamic where/from clauses
>> can still be provided without needing to rely on numbered result columns
>> like so:
>> endselect=""
>> idList = select from identities where :where_clause:
>> id = id
>> forename = forename
>> surname = surname
>> dob = dob
>> endselect
> That's easy enough to do with a namedtuple.
>
>> Variables never set to anything do not error until they are used, at
>> least in implementations of Python 2 I have tried. e.g.
>> UnlikelyCondition = False
>> endif=""
>> if UnlikelyCondition:
>> print x
>> endif
>>
>> The above code runs fine until UnlikelyCondition is set to True
> That's because globals and builtins could be created dynamically. It's
> a consequence of not having variable declarations. You'll find a lot
> of editors/linters will flag this, though.
>
>> Changing print from a statement to a function in Python 3 adds no
>> positive value that I can see
> Adds heaps of positive value to a lot of people. You simply haven't
> met the situations where it's better. It's sufficiently better that I
> often use __future__ to pull it in even in 2.7-only projects.
>
>> Lack of a single character in a method to refer to an attribute instead
>> of a local variable, similar to C's "*" for dereferencing a pointer
> Ehh. "self." isn't that long. Python isn't AWK.
>
>> Inability to make simple chained assignments e.g. "a = b = 0"
> Really? Works fine. You can chain assignment like that.
>
>> Conditional expression (<true-value> if <condition> else <false-value>)
>> in Python is less intuitive than in C (<condition> ? <true-value> :
>> <false-value>). Ref PEP308. Why BDFL chose the syntax he did is not at all
>> clear.
> I agree with you on this one - specifically, because the order of
> evaluation is "middle then outside", instead of left-to-right.
>
>> The Ugly:
>> Persisting with the crapulence from C where a non zero integer is true
>> and zero is false - only ever done because C lacked a boolean data type.
>> This is a flagrant violation of PEP 20.2 "Explicit is better than implicit"
>> and should be removed without providing backwards compatibility.
> In Python, *everything* is either true or false. Anything that
> represents "something" is true, and anything that represents "nothing"
> is false. An empty list is false, but a list with items in it is true.
> This is incredibly helpful and most definitely not ugly; Python is not
> REXX.
>
> ChrisA
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
>
>
> ------------------------------
>
> End of Python-ideas Digest, Vol 122, Issue 20
> *********************************************
More information about the Python-ideas
mailing list