[Python-ideas] Python Reviewed

[Simon Lovell]

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 

Re: [Python-ideas] Python Reviewed

[Chris Angelico]

On Mon, Jan 9, 2017 at 10:25 PM, Simon Lovell  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-l...@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 ( if  else )
> in Python is less intuitive

Re: [Python-ideas] Python reviewed

[Simon Lovell]

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-requ...@python.org wrote:

Send Python-ideas mailing list submissions to
python-ideas@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-requ...@python.org

You can reach the person managing the list at
python-ideas-ow...@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 
To: "Stephen J. Turnbull" 
Cc: Victor Stinner , python-ideas

Subject: Re: [Python-ideas] PEP 540: Add a new UTF-8 mode
Message-ID:

Content-Type: text/plain; charset=UTF-8

On Sun, Jan 8, 2017 at 1:47 AM, Stephen J. Turnbull
 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 
To: python-ideas@python.org
Subject: [Python-ideas

Re: [Python-ideas] Python reviewed

[Matthias Bussonnier]

On Mon, Jan 9, 2017 at 2:50 PM, Simon Lovell  wrote:
> 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?
>

The distinction and the explanation of this is the first result of the
google search

"Python process file line by line"

http://stackoverflow.com/questions/11130312/line-by-line-file-processing-for-loop-vs-with

You probably haven't came across that because you think and search
using C terms.
Once you get used to context managers they are incredibly useful.
I would advise to watch talks like "Beyond Pep 8" [1], comparing the same
program in Python and Java.

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

I use to like end markers. Though not having them make the code quite shorted.
When you have 1 line condition, or context manager or loop, it
literally adds 50%
more line to your condition/loop/contextmanager.

As the next line is anyway de-indented, you see your block anyway.

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

Things are true-ish or false-ish, if you prefer. This allows idioms like

if mycontainer:
   process_my_container(mycontainer)

And you can process it only if you have items and it is not none.
Your own object can raise if they get casted to bools, so if you really
like your object to not behave like a bool, you can.

It's not because they are truthy or falsy that they compare equal:

>>> if [] == False:
... print('[] equals False')
... else:
... print('[] not equals...')
...
[] not equals...
>>> if not []:print('[] is Falsy')
...
[] is Falsy


Also Boolean in Python are singletons (like None) , so you will see
comparison by identity `... is None` ( `... is False`, `... is True`
rarely) if you really care about only being in boolean context you
can.

Also Python is "ducktyped", if it quack and walks like a duck , then
it's a duck.
If an object defines how to behave as a bool then that's great.
You can then use your own object that are truthy-falsy and carry more
information by still using other libraries.

if not allowed:
   raise OhNoooe('You can't because', allowed.reason)

-- 
M

[1]:https://www.youtube.com/watch?v=wf-BqAjZb8M

Sorry Simon for double Mail, I forgot to reply-all.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Python reviewed

[Stephen J. Turnbull]

Simon Lovell writes:

 > Hmm, Thanks Chris. I thought I was posting this to the correct
 > place.

Well, you didn't actually make any specific suggestions, and you
describe it as a "review" rather than an RFE.

 > I've never seen that "for line in open ..." after googling it many 
 > times! Why is this question so often asked then?

Lot of C programmers out there, I guess.  It's in all the textbooks
and references I have, and in the tutorial:
https://docs.python.org/3/tutorial/inputoutput.html#methods-of-file-objects

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

You should take a look at SQLAlchemy and other Python database
managers.  I don't know what your "untackable it" is so I can't be
more specific.

Note that PEP 249 is not intended to provide an API for ordinary
Python programmers' use.  It was expected that convenient management
modules would be provided on top of the DBAPI.  PEP 249 is intended to
provide an API between the backend drivers and the database manager
modules, so that any manager could easily interface with any driver.

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

There's only a point in arguing it if you think that data types are
fundamentally mutually exclusive.  But they're not in object-oriented
languages like Python.  Something can be object, boolean, and str all
at the same time.  (The presence of a type called boolean is a red
herring here.  True and False are merely the representative boolean
values, a convenience for programmers who want them.)

In Python, all data is boolean, unambiguously being interpreted as
"true" or "false" in boolean contexts.  As far as boolean contexts are
concerned, there are an infinite number of objects equivalent to True
and another bunch (currently not infinite) equivalent to False.

It could be argued that this leads to programmers making bugs, but I
personally haven't found it so, in Python or Lisp, and I find the lack
of it very annoying when I'm writing Scheme since it's so similar to
Lisp.

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

I seem to recall that this has to do with an implementation
requirement, that the syntax be parseable with an LL parser.

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

It could, but won't.  That's a pragma, and Guido hates pragmas.  It's
certainly not worth a keyword.

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

Aside: I really find those suite terminators gratuitous; if I need
something "stronger" than a dedent, an empty line is much prettier
than they are IMO.

Actually the accepted loop-and-a-half idiom is

f = open(file)
line = f.readline()
while line:
process(line)
line = f.readline()

"for line in f" makes that unnecessary in this case, but there do
remain cases where loop-and-a-half is needed because of the lack of an
assignment expression.

 > > else keyword at the end of while loops is not obvious to those
 > > not familiar with it. Something more like whenFalse would be
 > > clearer

Keywords are expensive in that every Python programmer needs to know
all of them to avoid using one as an identifier.  So it is a general
design principle of Python to avoid adding new ones where possible.
It turns out that for ... else is rarely used even by experts, and the
main use case is extremely idiomatic, so probably no harm is done.

 > > Changing print from a statement to a function in Python 3 adds no
 > > positive value that I can see

It eliminates a keyword, makes it possible to experiment with
different implementations, and allows printing in the middle of
expressions (although since print() always returns None, that's not as
useful as it could be).

 > > Upper delimiters being exclusive while lower delimiters are
 > > inclusive. This is very counter intuitive.

If you say so.  But it is convenient because list == list[:n] +
list[n:].

 > > Conditional expression ( if  else
 > > ) in Python is less intuitive than in C (
 > > ?   : ). Ref PEP308. Why BDFL chose the
 > > syntax he did is not at all clear.

I seem to recall that ?: was out because Guido at the time was
adamantl

Re: [Python-ideas] Python Reviewed

[Steven D'Aprano]

On Mon, Jan 09, 2017 at 07:25:45PM +0800, Simon Lovell wrote:

> 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

Python has a `with` statement.

As a newcomer to this community, and apparently the language as well, do 
you understand how obnoxious and arrogant it comes across for you to 
declare what is and isn't "good" and "bad" about the language, 
particularly when you appear to know the language very well?

Most of your comments aren't even a little bit objective, they're 
subjective judgements based on (I expect) what you are used to, and 
nothing more. Matters of taste, at best, and yet you're stating them as 
objective fact. So if you feel that my response is a tad blunt or even 
brusque, perhaps you can understand why.



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

This is the first time I've heard this ridiculous explanation for the 
use of colons! Where did you get it from? It sounds like the sort of 
nonsense that gets highly voted on StackOverflow.

The reason for colons is a FAQ:

https://docs.python.org/3/faq/design.html#why-are-colons-required-for-the-if-while-def-class-statements



> No end required for if/while/for blocks. 

Thank you Guido, for avoiding needing all those redundant and 
unnecessary "end" statements that other languages waste my time with.


> 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

Assignment is not and should not be an expression, at very least not 
using the same = (pseudo-)operator which is used as an assignment 
statement. It may be acceptible with some other syntax that cannot be 
easily mistyped when you want == equality, but not = alone.

But what is that obfuscated code meant to do? Operate on the file, 
one line at a time? This is simpler:

with open(file) as f:
for line in f:
process(line)

and it has the advantage of also automatically closing the file when the 
`with` block gets exited.



> Inadequacy of PEP249 - Python Database Specification.
[...]

I cannot comment on this.


> Variables never set to anything do not error until they are used, 

Fair enough, that is a minor annoyance occasionally.


> No do-while construct

What do you mean by "do-while" and how do you expect it to differ from 
"while"?



> else keyword at the end of while loops is not obvious to those not 
> familiar with it. Something more like whenFalse would be clearer

Indeed. 

for...else and while...else are much more accurately described as 
for...then, while...then.

The code in the "else" block is *unconditionally* executed following the 
for... or while... block, which makes the block a "then" rather than 
"else". To avoid that block, you have to jump out of the entire 
compound block, using "break", "return" or "raise".

But we're stuck with the name now.



> Changing print from a statement to a function in Python 3 adds no 
> positive value that I can see

Consistency: print doesn't need to be a special cased statement. It does 
nothing special that a function can't do. So why make it a statement?

As a function, it can be passed around as a first class value, used as a 
callback, monkey-patched or shadowed or mocked as needed. None of 
these things are possible with a statement.

It can use the same ordinary syntax as other functions, instead of the 
bizarre and ugly special case syntax used as a statement:


# Python 3
print(value, end='', file=sys.stderr)

# Python 2
print >>sys.stderr, value,  # note the magical trailing comma


If Python was invented today, what arguments could anyone make for 
having print be a statement instead of a function? "It saves typing two 
parentheses." Anything else?



> Upper delimiters being exclusive while lower delimiters are 
> inclusive.

Dijkstra explained it well:

http://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EWD831.html

Half-open ranges are much superior for avoiding off-by-one errors than 
closed ranges.


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

It is true th

Re: [Python-ideas] Python Reviewed

[Chris Kaynor]

On Mon, Jan 9, 2017 at 11:40 AM, Steven D'Aprano  wrote:
> On Mon, Jan 09, 2017 at 07:25:45PM +0800, Simon Lovell wrote:
>> Lack of a with statement which only obscures the code
>Python has a `with` statement.

I suspect Simon means similar to the VB with statement, which allows
an object to become the default namespace.

Basically, rather than:
object.alpha()
object.beta()

you can do:
with object:
alpha()
beta()

or some slight variant thereof. Both cases do the same thing.

Personally, I vastly prefer the explicit naming of self, and it should
be noted that the style guides I have seen for C/C++ code have
required member variable names to be prefixed with something like "m_"
or just "_" to keep them from getting confused with local variables.
Python solves this problem by requiring the object reference, and
generally, I have found that much of the time it does not add that
much extra to the code to have the explicit references, while making
it very clear what is intended.

>> No do-while construct
>
> What do you mean by "do-while" and how do you expect it to differ from
> "while"?

This one is somewhat common in other languages, and a do-while
executes at least once (checks the condition at the end), while while
executes at least zero times (checks the condition at the start).

In C:
do
{
..block..
} while (condition);

is the same as:

..block..
while (condition)
{
..block..
}

where both "..block.." are the same. The exact same result can be
gotten with (in Python):

while True:
..block..
if condition:
break

That said, I've only occasionally had use for the construct, and the
most common case I've seen for it is multi-line macros in C/C++ where
it is needed to get proper handling to require a semicolon at the end
of the macro invocation and handle the optional braces in the flow
control structures.

Almost always, if checking the condition at the start is not good
enough, I almost always want to check the condition somewhere in the
middle instead, so the "while True:" works better.

>> 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.
>
> It is true that starting counting at zero takes a bit of getting used
> to, and there are times when it is more convenient to start at one. But
> no one solution is ideal all the time, and we have to pick one system or
> the other, or else we end up with an overly complex syntax with marginal
> utility.

I've had to deal with mixed zero-based and one-based in coding before
(and still often), and it was a huge pain. Zero-based works much
better for many practical programming tasks, but can be difficult to
get used to. I work in game development, so it is not uncommon to have
mixed (artists and designers like one-based as they are generally
non-technical). It is pretty annoying when may variable names have to
be post fixed by "number" or "index" to try to keep it straight (and
that fails half the time). The worst I had to deal with regarding it
was in code that was crossing C++ and LUA, where C++ is zero-based and
LUA is one-based - it was extremely difficult to remember all the
needed +1s and -1s in the boundary code...

>> 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
>
> The lack of single-character syntax for many things helps prevents
> Python code looking like line noise.

I would not recommend this, however it should be noted that Python
assigns no special meaning to the name "self", and the variable could
be named anything you want in your methods, including single character
names. You would still need to type a minimum of two characters
though.

This is perfectly valid Python code, though would be against many (if
not most) style guides:

class MyObject:
def __init__(s, myArg1, myArg2):
s.myArg1 = myArg1
s.myArg2 = myArg2

a = MyObject(1, 2)
print(a.myArg1, a.myArg2) # prints "1 2"

If the variable "s" were renamed to "self", you would get the exact
same result, however the code would match most style guides, and
linters will likely stop complaining.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Python Reviewed

[Ned Batchelder]

On 1/9/17 8:31 AM, Chris Angelico wrote:

> On Mon, Jan 9, 2017 at 10:25 PM, Simon Lovell  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-l...@python.org, where you'll
> find plenty of people happy to discuss why Python is and/or shouldn't
> be the way it is.
I think this is the only reasonable response to this posting on this
mailing list.

Simon: quoting from the Python-Ideas info page: "This list is to contain
discussion of speculative language ideas for Python for possible
inclusion into the language."  Your comments, while interesting, don't
make specific proposals for changes to Python.

python-l...@python.org is good for general discussion.  If you do intend
to make specific proposals, you'll have to put a lot more work into
them.  Proposals should be focused and specific; one thread with a dozen
ideas makes discussion impossible.

It helps to understand the language and its history.  Many of your
reactions to Python have been expressed many times before, so there are
well-documented discussions and rationales for Python being the way it
is.  Doing some research beforehand can save you some work.

Finally, backward compatibility is a serious consideration.  Proposals
containing new keywords, for example, are nearly impossible to get approved.

Welcome to the community,

--Ned.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Python Reviewed

[Mikhail V]

On 9 January 2017 at 12:25, Simon Lovell  wrote:

> Python Reviewed
>
> The Good :
> ...
> The Bad:
> ...

I agree with many points, but:

> No end required for if/while/for blocks. .. Makes the code less readable

Nope, it makes code significantly better readable.
I'm sort of past master in such questions
so there is very little chance of BSing me.
In some cases I'd want some space after
the block, so probably future IDEs will allow
placing small vertical indents to help with that.

> No do-while construct

I don't think it is needed much, I never came
up with thoughts that I want it. If I'd design a
syntax from scratch, there would be only infinite loop
and break.

> Conditional expression in Python is less intuitive than in C

Probably, but conditional expressions are IMO not needed
and I'd remove them just not to pollute the syntax.


Mikhail
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Python Reviewed

[Steven D'Aprano]

On Tue, Jan 10, 2017 at 06:40:34AM +1100, Steven D'Aprano wrote:

> particularly when you appear to know the language very well?

Of course I mean "don't appear".


-- 
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Python reviewed

[Simon Lovell]

Thanks for the feedback guys. A few quick comments:

Re: Colons. I'm sure I've seen that FAQ before. I may be arrogant but I 
can't take it seriously. Being "slightly" easier to read is hardly a 
reason for a mandatory structure.


Re: PEP249. I thought I'd detailed quite a bit of what I thought should 
be possible. Is there a forum for advancing this?


Re: do-while - that a is a loop construct that executes once before 
evaluating the condition. Supported by most languages.


Re: Counters starting at zero vs one, Fortran has a neat solution to 
this for arrays if not strings - allow the programmer to select the 
starting index. I've seen -1 and 1000, for example. I can't say I'm 
convinced by Dijkstra's argument but it is somewhat esoteric because it 
isn't changing. When I've programmed for loops in C, sometimes you want 
zero based and sometimes one based, while most times you don't really 
care. To make it readable I would wherever possible write either:

for (i=0;ihttps://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Python reviewed

[Chris Barker]

not even sure why Im engaging, but

Note 1) Many of these issues have been widely discussed all over the
internet -- I don't think I've seen anything new here. So it would have
been nice to do some more research before posting.

Now into the fray!

 > Re:Everything being true of false. I don't see the value of
>  > that. Only boolean data should be valid in boolean contexts.


I actually agree with that -- but there are a lot of nice conveniences from
Python's idea of "truthiness", too.


>  > > 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".
>
> I seem to recall that this has to do with an implementation
> requirement, that the syntax be parseable with an LL parser.


I don't so -- but I DO think that this was a usability issue that was
investigated early in PYthon's development. (Or maybe even ABC's
development) -- in fact, I suspect is is one of the few programming
language syntax decisions (in any language)  that went through any kind of
formal usability testing.

I didn't bring it up -- so I'll leave the googling to others.

 > Actually the accepted loop-and-a-half idiom is

>
> f = open(file)
> line = f.readline()
> while line:
> process(line)
> line = f.readline()
>

I used to write that style, but I've never liked it, so went with:

f = open(file)
while True:
line = f.readline()
if not f:
break
process(line)

the while True and check for a break is kinda ugly, but I think less ugly
than two separate calls to readline()

and, of course, we now have:

for line in f:
   process(line)

which is cleaner an easier than anything I've seen in any other language

-- so WHAT exactly was the original complaint???

 > > else keyword at the end of while loops is not obvious to those
>  > > not familiar with it. Something more like whenFalse would be
>  > > clearer
>

I've kinda wanted an "do-until" loop of some sort sometimes, but frankly,
not that badly :-)


>  > > Changing print from a statement to a function in Python 3 adds no
>  > > positive value that I can see
>

yeah, yeah yeah -- PLEASE go read an number of py3 justifications and
rants! This is really a dead horse.



>  > > Upper delimiters being exclusive while lower delimiters are
>  > > inclusive. This is very counter intuitive.
>

but SO much better than the alternative!

This was also tested som, I think maybe by Dijkstra of C++ fame.

but these identities are REALLY, REALLY useful:

s[:n] + s[n:] == s
len(s[:n]) == n
len(s[:-n]) == n
len(s[n:i]) == i - n

(maybe a few others?)
These prevent a HUGE number of off by one errors and ecta code adding and
subtracting one all over the place -- this is almost as important to
Pythons' usability as the significant indentation :-)

 > > Conditional expression ( if  else
>  > > ) in Python is less intuitive than in C (
>  > > ?   : ).


Ha Ha Ha Ha!!!  I could read and understand Python's version the first time
I saw it -- I still have to look up the C version (not much of C
programmer). maybe you think it's wordy -- but it's very readable.

-CHB



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Python reviewed

[Alexander Belopolsky]

On Mon, Jan 9, 2017 at 8:12 PM, Simon Lovell  wrote:

> Re: Colons. I'm sure I've seen that FAQ before. I may be arrogant but I
> can't take it seriously. Being "slightly" easier to read is hardly a reason
> for a mandatory structure.
>

"Readability counts."  Did you notice that you placed a redundant ":"s in
every comment of yours after "Re"?  I don't think your message would look
better without them.

Another advantage of having : is that it allows smart editors to detect and
highlight errors sooner and to better perform auto-indentation.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Python reviewed

[Chris Barker]

On Mon, Jan 9, 2017 at 5:12 PM, Simon Lovell  wrote:

> Re: Counters starting at zero vs one, Fortran has a neat solution to this
> for arrays if not strings - allow the programmer to select the starting
> index.


I liked that back in the day, but I think it's really better if it's always
the same.

and see my other note for why the zero-based and open ended slicing is
fabulous -- indexing really needs to match slicing.

ONe more:

since you mentioned Fortran -- it's a common use-case for an array to model
some sort of regular spaced grid, so:

x = start_x + i*delta_x

really easy and logical math for figuring out where you are on a grid (and
the reverse calculation) -- this is a pain with 1-based indexing

(of course, C does this for pointer math for the same reason...)

When I've programmed for loops in C, sometimes you want zero based and
> sometimes one based, while most times you don't really care. To make it
> readable I would wherever possible write either:
> for (i=0;i for (i=1;i<=j;i++)  // In both cases always executing j times
>

in pyton, you never right that code anyway. most of the time, it's

for item in sequence:

no indexes at all.

or:

for i in range(N):
  ...

indexes, but you dont care

or

for i, item in enumerate(seq):
...

or for item1, item2 in zip(sequence):
...

i.e you almost never care what the starting index is!

-CHB





> Rgds
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Python Reviewed

[Chris Barker]

I just noticed a logical inconsistency here:

The Good:
> Syntactically significant indenting



> The Bad:
> Colons at the end of if/while/for blocks.
>


> No end required for if/while/for blocks.


Huh? if you have Syntactically significant indenting, then an "end"
indicator is redundant. and right above, you say you don't like the
redundant colon

which is it??

 It also is a potential problem with tab expansion tricking the programmer.


I do wish tabs had been banned from indentation from the beginning


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Python Reviewed

[Chris Barker]

Oh,

Here is the history of the colon:

http://python-history.blogspot.com/2009/02/early-language-design-and-development.html

-CHB


On Mon, Jan 9, 2017 at 5:30 PM, Chris Barker  wrote:

> I just noticed a logical inconsistency here:
>
> The Good:
>> Syntactically significant indenting
>
>
>
>> The Bad:
>> Colons at the end of if/while/for blocks.
>>
>
>
>> No end required for if/while/for blocks.
>
>
> Huh? if you have Syntactically significant indenting, then an "end"
> indicator is redundant. and right above, you say you don't like the
> redundant colon
>
> which is it??
>
>  It also is a potential problem with tab expansion tricking the programmer.
>
>
> I do wish tabs had been banned from indentation from the beginning
>
>
> --
>
> Christopher Barker, Ph.D.
> Oceanographer
>
> Emergency Response Division
> NOAA/NOS/OR&R(206) 526-6959   voice
> 7600 Sand Point Way NE   (206) 526-6329   fax
> Seattle, WA  98115   (206) 526-6317   main reception
>
> chris.bar...@noaa.gov
>



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Python reviewed

[Alexander Belopolsky]

On Mon, Jan 9, 2017 at 8:19 PM, Chris Barker  wrote:
>
> I think maybe by Dijkstra of C++ fame.

Dijkstra is famous for many things, but C++ is another Dutchman's fault.

Dijkstra's famous works include "GOTO Considered Harmful" [1] and "How do
we tell truths that might hurt?" [2].

[1]: http://wiki.c2.com/?GotoConsideredHarmful
[2]: http://www.cs.utexas.edu/users/EWD/transcriptions/EWD04xx/EWD498.html
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Python reviewed

[Simon Lovell]

Also in Python you can use:

for x in range (1,j+1):


to loop j times. Although it does read as though it is looping j+1 times 
to those not familiar.



One more comment I wanted to make about end blocks, is that a 
respectable editor will add them for you, together with the indentation 
of the next line. EditPlus 2 did it best in my experience although I 
think I just haven't seen a well configured alternative. I very rarely 
forget the block closer but I do sometimes forget the colon.



Regarding the logical inconsistency of my argument, well I am saying 
that I would prefer my redundancy at the end of the loop rather than the 
beginning. To say that the status quo is better is to say that you 
prefer your redundancy at the beginning. Fair enough, I'm happy to 
respect your opinion there. I still struggle to see why it should be 
mandatory though? For those who prefer to have the block closing 
delimiters this way, is the need for a keyword (could be a command line 
option) really the objection?



I'll have a detailed look at your colon link a bit later.


On 10/01/17 09:26, Chris Barker wrote:
On Mon, Jan 9, 2017 at 5:12 PM, Simon Lovell > wrote:


Re: Counters starting at zero vs one, Fortran has a neat solution
to this for arrays if not strings - allow the programmer to select
the starting index.


I liked that back in the day, but I think it's really better if it's 
always the same.


and see my other note for why the zero-based and open ended slicing is 
fabulous -- indexing really needs to match slicing.


ONe more:

since you mentioned Fortran -- it's a common use-case for an array to 
model some sort of regular spaced grid, so:


x = start_x + i*delta_x

really easy and logical math for figuring out where you are on a grid 
(and the reverse calculation) -- this is a pain with 1-based indexing


(of course, C does this for pointer math for the same reason...)

When I've programmed for loops in C, sometimes you want zero based
and sometimes one based, while most times you don't really care.
To make it readable I would wherever possible write either:
for (i=0;imailto:Python-ideas@python.org>
https://mail.python.org/mailman/listinfo/python-ideas

Code of Conduct: http://python.org/psf/codeofconduct/





--

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov 


___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Python reviewed

[Ned Batchelder]

On 1/9/17 8:44 PM, Simon Lovell wrote:
>
> Also in Python you can use:
>
> for x in range (1,j+1):
>
> to loop j times. Although it does read as though it is looping j+1
> times to those not familiar.
>
> One more comment I wanted to make about end blocks, is that a
> respectable editor will add them for you, together with the
> indentation of the next line. EditPlus 2 did it best in my experience
> although I think I just haven't seen a well configured alternative. I
> very rarely forget the block closer but I do sometimes forget the colon.
>
> Regarding the logical inconsistency of my argument, well I am saying
> that I would prefer my redundancy at the end of the loop rather than
> the beginning. To say that the status quo is better is to say that you
> prefer your redundancy at the beginning. Fair enough, I'm happy to
> respect your opinion there. I still struggle to see why it should be
> mandatory though? For those who prefer to have the block closing
> delimiters this way, is the need for a keyword (could be a command
> line option) really the objection?
>

Can you clarify something for us? Are you proposing to add end-block
syntax?  You've said you prefer it, and that you miss it. But you
haven't said, "I am proposing that Python should change."  This list is
about proposing changes to Python.  Are you proposing that Python change
in this way?

You understand that this is a significant shift from a syntax that has
been in place for a quarter century? Perhaps you should give yourself
time to get used to Python as Python is.

--Ned.

>
> I'll have a detailed look at your colon link a bit later.
>
>
> On 10/01/17 09:26, Chris Barker wrote:
>> On Mon, Jan 9, 2017 at 5:12 PM, Simon Lovell > > wrote:
>>
>> Re: Counters starting at zero vs one, Fortran has a neat solution
>> to this for arrays if not strings - allow the programmer to
>> select the starting index.
>>
>>
>> I liked that back in the day, but I think it's really better if it's
>> always the same.
>>
>> and see my other note for why the zero-based and open ended slicing
>> is fabulous -- indexing really needs to match slicing.
>>
>> ONe more:
>>
>> since you mentioned Fortran -- it's a common use-case for an array to
>> model some sort of regular spaced grid, so:
>>
>> x = start_x + i*delta_x
>>
>> really easy and logical math for figuring out where you are on a grid
>> (and the reverse calculation) -- this is a pain with 1-based indexing
>>
>> (of course, C does this for pointer math for the same reason...)
>>
>> When I've programmed for loops in C, sometimes you want zero
>> based and sometimes one based, while most times you don't really
>> care. To make it readable I would wherever possible write either:
>> for (i=0;i> for (i=1;i<=j;i++)  // In both cases always executing j times
>>
>>
>> in pyton, you never right that code anyway. most of the time, it's 
>>
>> for item in sequence:
>>
>> no indexes at all.
>>
>> or:
>>
>> for i in range(N):
>>   ...
>>
>> indexes, but you dont care
>>
>> or 
>>
>> for i, item in enumerate(seq):
>> ...
>>
>> or for item1, item2 in zip(sequence):
>> ...
>>
>> i.e you almost never care what the starting index is!
>>
>> -CHB
>>
>>
>>
>>  
>>
>> Rgds
>>
>> ___
>> Python-ideas mailing list
>> Python-ideas@python.org 
>> https://mail.python.org/mailman/listinfo/python-ideas
>> 
>> Code of Conduct: http://python.org/psf/codeofconduct/
>> 
>>
>>
>>
>>
>> -- 
>>
>> Christopher Barker, Ph.D.
>> Oceanographer
>>
>> Emergency Response Division
>> NOAA/NOS/OR&R(206) 526-6959   voice
>> 7600 Sand Point Way NE   (206) 526-6329   fax
>> Seattle, WA  98115   (206) 526-6317   main reception
>>
>> chris.bar...@noaa.gov 
>
>
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Python reviewed

[Chris Angelico]

On Tue, Jan 10, 2017 at 12:44 PM, Simon Lovell  wrote:
> Regarding the logical inconsistency of my argument, well I am saying that I
> would prefer my redundancy at the end of the loop rather than the beginning.
> To say that the status quo is better is to say that you prefer your
> redundancy at the beginning. Fair enough, I'm happy to respect your opinion
> there. I still struggle to see why it should be mandatory though? For those
> who prefer to have the block closing delimiters this way, is the need for a
> keyword (could be a command line option) really the objection?

Actually, Python does have a way to enable optional block closing
directives. They're a little more compact than "endfor" and "endwhile"
etc, and they're optional, so the compiler won't require you to use
them (that would break heaps of libraries), but try this:

-- cut --
import sys

for arg in sys.argv:
if arg == "hello":
print("Hello, sir/madam")
#if
#for
-- cut --

Okay, okay, that's a bit of a cheat, but still, if you really truly
want "endfor", all you have to do is spell it "#for" and it'll be
accepted. Don't expect experienced Python programmers to accept this
at code review though.

(And if you insist on a command line option, "python3 -X hashblockend"
will do that for you. It won't actually DO anything though.)

ChrisA
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Python reviewed

[Erik]

On 10/01/17 01:44, Simon Lovell wrote:

Regarding the logical inconsistency of my argument, well I am saying
that I would prefer my redundancy at the end of the loop rather than the
beginning. To say that the status quo is better is to say that you
prefer your redundancy at the beginning.


It's not really that one prefers redundancy anywhere. It's more a 
question of:


a) Does the redundancy have any (however small) benefit?
b) How "expensive" is the redundancy (in this case, that equates to 
mandatory characters typed and subsequent screen noise when reading the 
code).


I don't understand how a "redundancy" of a trailing colon in any 
statement that will introduce a new level of indentation is worse than 
having to remember to type "end" when a dedent (which is zero 
characters) does that.


Trailing colon "cost": 1 * (0.n)
Block end "cost": (len("end") + len(statement_text)) * 1.0


I still struggle to see why it should be
mandatory though?


That looks like a statement, but you've ended it with a question mark. 
Are you asking if you still struggle? I can't tell. Perhaps it's just 
the correct use of punctuation that you're objecting to ;)


> One more comment I wanted to make about end blocks, is that a
> respectable editor will add them for you,

You are now asking me to write code with what you describe as a 
"respectable" editor. I use vim, which is very respectable, thank you. 
You'd like me to use "EditPlus 2" or equivalent. I struggle to see why 
that should be mandatory.


Thanks for starting an entertaining thread, though ;)

E.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Python Reviewed

[Simon Lovell]

Hi Kyle,

I don't see the harm caused from having a do-while construct. Not the 
most used construct but it is sometimes useful and not having it means 
you need to either have a first time through marker or a break at the 
end of a "while True:" loop.



I would say that None should also be non-boolean. Otherwise you are 
saying that things which might be None would be True if not None.



Re: SQLAlchemy, this does not resolve the issues satisfactorily to me.


Re: half-loop. The idea that you have the same code before entry and at 
the end of the loop is really ugly and raises the potential for errors. 
I can remember doing something similarly ugly with this for looping 
through a cursor but I can't recall why I couldn't just do a .fetchall() 
and then loop through the results. Maybe I ultimately changed it to do 
precisely that. Perhaps you have too big a data set to load into memory 
all at once though and can't do it that way. Anyway, the SQL processing 
is all too difficult in Python and Java and nearly all modern languages.



Re: Conditional expression. You could have: " = if  
then  else requires more concentration than it should. However, this means another 
keyword*.


* General comment: I posted this because Googling didn't give me a 
satisfactory answer to why Python is the way that it is. I think I see 
it now. Guido hates keywords. I don't find this particularly logical but 
it is what it is and it also isn't going to change. That seems also to 
explain the else keyword at the end of the while loop.



Anyway, I think this discussion has reached its natural conclusion here.

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Python reviewed

[Simon Lovell]

Oh one last thing (I hope), the argument for having the current slice 
notation by Dijkstra, that it looks messy to have a loop where the 
contents are never executed or can no longer be executed is ridiculous! 
That *should* look messy. for range(1,1): means executing once to me. If 
you had 1 based, two of four of the other idioms would work the same:


s[:n] + s[n:] == s// doesn't work. I don't think it should work though
len(s[:n]) == n   // works
len(s[:-n]) == n  // rather independent but would still work if 
language is otherwise unchanged.

len(s[n:i]) == i - n  // doesn't work. Does it need to?

Rgds
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Python Reviewed

[Ethan Furman]

On 01/09/2017 09:18 PM, Simon Lovell wrote:

[snip]

This is not the place for this conversation.  Please take it to Python List.

--
~Ethan~
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Python reviewed

[Steven D'Aprano]

On Tue, Jan 10, 2017 at 09:44:31AM +0800, Simon Lovell wrote:
> Also in Python you can use:
> 
> for x in range (1,j+1):
> 
> to loop j times. Although it does read as though it is looping j+1 times 
> to those not familiar.

*shrug*

To those "not familiar", most language features are mysterious and it is 
easy to guess wrong.

What's the difference between foo[x+1] and foo(x+1)? 

In Python, the first is a key or index lookup and the second is a 
function call; but in Mathematica, the first is a function call and the 
second is foo multiplied by x+1.

Python prides itself in having a much easier learning curve than many 
languages, with syntax that is close to "executable pseudo-code", but 
that doesn't mean that there is *nothing* to learn.

 
> One more comment I wanted to make about end blocks,
[...]


If I never have to see code like:

end
end
end
end
end
end

again, it will be too soon.

 
> I still struggle to see why it should be 
> mandatory though? For those who prefer to have the block closing 
> delimiters this way, is the need for a keyword (could be a command line 
> option) really the objection?

It's not mandatory -- there are dozens of other languages you can use 
that will satisfy your urge for a redundant "end" block marker.

But for *Python*, it is mandatory because it is Guido's language, not 
yours. When you design your own language, you can design it to be as 
complicated or simple, as baroque or plain as you like.

Think about what you are asking for: a command-line option that controls 
whether or not the interpreter requires "end" after each block. Now 
every single library module needs to be written twice, once with "end", 
once without. Otherwise, it won't even compile for half the users.

If all you care about is something physically at the end of the block, 
without the compiler enforcing it, then Python already supports this, 
using your choice of keyword:

with open(filename) as f:
for line in f:
if condition:
while something:
spam(line)
#end
#finish
#done
#conclusion

Problem solved.



-- 
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Python Reviewed

[Rob Cliffe]

On 10/01/2017 05:18, Simon Lovell wrote:

Hi Kyle,

I don't see the harm caused from having a do-while construct. Not the 
most used construct but it is sometimes useful and not having it means 
you need to either have a first time through marker or a break at the 
end of a "while True:" loop.



I would say that None should also be non-boolean. Otherwise you are 
saying that things which might be None would be True if not None.



Re: SQLAlchemy, this does not resolve the issues satisfactorily to me.


Re: half-loop. The idea that you have the same code before entry and 
at the end of the loop is really ugly and raises the potential for 
errors. I can remember doing something similarly ugly with this for 
looping through a cursor but I can't recall why I couldn't just do a 
.fetchall() and then loop through the results. Maybe I ultimately 
changed it to do precisely that. Perhaps you have too big a data set 
to load into memory all at once though and can't do it that way. 
Anyway, the SQL processing is all too difficult in Python and Java and 
nearly all modern languages.



Re: Conditional expression. You could have: " = if  
then  else requires more concentration than it should. However, this means 
another keyword*.


* General comment: I posted this because Googling didn't give me a 
satisfactory answer to why Python is the way that it is. I think I see 
it now. Guido hates keywords.

That last sentence is a ridiculous (and insulting) statement.
Adding a keyword to Python means that all Python code ever written 
potentially becomes incompatible with the next Python release (if it 
might use that keyword as an identifier).

So the bar for adding a *new* keyword is necessarily very high.
I don't find this particularly logical but it is what it is and it 
also isn't going to change. That seems also to explain the else 
keyword at the end of the while loop.



Anyway, I think this discussion has reached its natural conclusion here.

Rob Cliffe


___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/



___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Python Reviewed

[Ryan Gonzalez]

I just want to point ONE thing out:


On Jan 9, 2017 11:18 PM, "Simon Lovell"  wrote:

* General comment: I posted this because Googling didn't give me a
satisfactory answer to why Python is the way that it is. I think I see it
now. Guido hates keywords. I don't find this particularly logical but it is
what it is and it also isn't going to change. That seems also to explain
the else keyword at the end of the while loop.


No, it's because every new keyword that you add has the potential to break
code that uses that as a variable name. Python is used by thousands of
places across the globe right now. It would be suicidal to break half of
that because someone felt the need for a new keyword.

I feel like there are two things you're missing:

1. The stark majority of the "review" you made is taking about stuff that
simply isn't going to change. Again, too much code to break.

2. The entirety of the "review" is your opinion. You may love the `end`
keyword and enjoy using it (for some reason), but that doesn't mean it's
*objectively* better. It just means it's better for you. Python is the way
it is because that's the way it is, and we like it that way.


___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/



--
Ryan (ライアン)
Yoko Shimomura > ryo (supercell/EGOIST) > Hiroyuki Sawano >> everyone else
http://kirbyfan64.github.io/
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Python reviewed

[Chris Barker - NOAA Federal]

 for range(1,1): means executing once to me.

The indexing/slicing approach was designed for indexing and slicing. Then
it made sense to have range() match. But range() is not part of the for
construction. It is a convenience function for providing an iterable of
integers. And you are welcome to write your own range-like iterable if you
want.

But if you want to look once, you'd use range(1), not range(1,2) anyway.
Clear as day.

And if you use: range(n, n+I), it is very clear that you will loop i times.

s[:n] + s[n:] == s// doesn't work. I don't think it should work though


Have you ever used a 1-based and closed-end indexing language that
supported slicing? I have (matlab), and these kinds of constructions are
really ugly and prone to error. It's not that you want to be able to divide
a sequence and immediately put it back together, it's that you often want
to do one thing with the first part of a sequence, and another with the
second part, and you don't want them to overlap.

len(s[:n]) == n   // works
len(s[:-n]) == n  // rather independent but would still work if
language is otherwise unchanged.
len(s[n:i]) == i - n  // doesn't work. Does it need to?


It's not that it HAS to - it's that it's much less likely that you will
make off by one errors if it does.

-CHB
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/