Home Original page

[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