Re: Lists And Missing Commas

[Tim Daneliuk]

On 12/24/19 6:37 AM, Stefan Ram wrote:
>  And you all are aware that this kind of string concatenation
>   happens in C and C++, too, aren't you?
> 
>   main.c
> 
> #include 
> int main( void ){ puts( "a" "b" ); }
> 
>   transcript
> 
> ab

Noting that it has been a long time since I looked at the C specification ...

Is the above an artifact of how puts() is implemented or is it innate in the 
language spec?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Lists And Missing Commas

[Richard Damon]

On 12/24/19 10:45 AM, Tim Daneliuk wrote:

On 12/24/19 6:37 AM, Stefan Ram wrote:

  And you all are aware that this kind of string concatenation
   happens in C and C++, too, aren't you?

   main.c

#include 
int main( void ){ puts( "a" "b" ); }

   transcript

ab

Noting that it has been a long time since I looked at the C specification ...

Is the above an artifact of how puts() is implemented or is it innate in the 
language spec?


The automatic concatenation of adjacent strings is an innate part of the 
C language spec.


One important reason this was included in the C language was so that 
some of the predefined macros with a string value (like the compilation 
time __TIME__) could be built into a string constant.


A second is that C had no equivalent to """ as a multi-line string 
constant, and using line continuation was problematical on some systems 
using fixed length lines, so allowing a constant to be built on multiple 
lines was useful.


--
Richard Damon

--
https://mail.python.org/mailman/listinfo/python-list

Re: [ANN] Retrospective of Python compilation efforts

[Guido van Rossum]

Nice work.

On Tue, Dec 24, 2019 at 2:59 AM Paul Sokolovsky  wrote:

> Hello,
>
> Over the years, the Python community produced many compiler projects for
> the language, second to probably only C and LISP. Majority are of
> course of research and proof of concept quality, but there're a number
> of quite advanced projects.
>
> For some time, I was trying to compile a retrospective of these
> efforts, formatted as a github "awesome" list:
>
> https://github.com/pfalcon/awesome-python-compilers
>
>
> Happy holidays,
> Paul
> --
> Python-announce-list mailing list -- python-announce-l...@python.org
> To unsubscribe send an email to python-announce-list-le...@python.org
> https://mail.python.org/mailman3/lists/python-announce-list.python.org/
>
> Support the Python Software Foundation:
> http://www.python.org/psf/donations/
>


-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

-- 
https://mail.python.org/mailman/listinfo/python-list

RE: Lists And Missing Commas

[Avi Gross via Python-list]

As a purist, it makes people uncomfortable if all 'objects' are not treated
alike.

But I look at the question from a definition and parsing mechanism view.

When an interpreter (or compiler) reads a program, it often does it in
phases and tries to tokenize parts.

So, the definition of something often makes it look ahead or back or even
sideways to see how much of the program text makes up a single entity. 

The definition of a NUMBER is complex but clearly it needs to allow
underscores or designations that make it octal versus decimal or a floating
point number or even scientific notation. The point is it does some looking
ahead to make sure it gets the entire number and then sets it aside as a
token for a single entity.

The definition of a fixed string is also complex as it can be a binary
string or other formats but the focus here is that string literals were
DESIGNED to be able to span multiple lines or be put in piecewise. So the
parser does not stop when it sees "Hello " but continues to see if there is
more that can be used to make a full string literal. It has to skip past
whitespace and see what follows. If what follows is "World!" then it makes
"Hello World!" and keeps scanning beyond more whitespace until something is
found that cannot be considered part of the same literal. Other languages
use this technique such as C++ 

An analogy might be how a compiler in a language that supports constants
will look at a line declaring something like this:

const int volume = 5 * 6 * 7

Would it not be possible that the compiler, knowing this is a constant,
would not pre-calculate the result and act as if you had written:

const int volume = 210

The run time, would not know or care.

So, if the analogy makes sense, in python the early evaluation phase is
required to combine as much as possible into a single string literal. It is
a bit like a regular expression that matches a pattern greedily unless asked
not to. This tokenization probably precedes the point where it sees a series
of commas in a context such as a list definition or function call argument
list. 

Again, a purist might want all objects, within reason, to look alike. There
are other mechanisms to gain this concatenation functionality in strings.
This being Python (which lies about how there should be one unique way to
logically do something) there may be dozens of ways to get this
functionality starting with using a PLUS operator and continuing with one of
5 or so ways to build a string from other objects as well as strategic uses
of the backslash character and so on.

But it is a feature that is there and seems to also be in some other
languages. It is generally easy to avoid using this implicit concatenation
but I think an important point is that you may inadvertently get the wrong
result when accidentally leaving out a comma. That is true. I note this is
an old known issue:

https://www.python.org/dev/peps/pep-3126/

There are some lint programs that check your code and supply warnings and I
see some languages have the option to generate warnings when the two strings
are on the same line. I wonder if a Python lint does that. It may at least
warn of this usage in time to check the code and put back the comma.


-Original Message-
From: Python-list  On
Behalf Of Tim Daneliuk
Sent: Monday, December 23, 2019 11:22 PM
To: python-list@python.org
Subject: Re: Lists And Missing Commas

On 12/23/19 8:35 PM, Chris Angelico wrote:
> On Tue, Dec 24, 2019 at 12:56 PM DL Neil via Python-list 
>  wrote:
>> However, your point involves the fact that whereas:
>>
>> 1 + 2   # 3 is *clearly* addition, and
>> "a" + "b"   # "ab" is *clearly* concatenation
>>
>> "a" "b" # also evaluates to "ab"
>>
>> and is thus, concatenation without any explicit infix operator! Just 
>> one cotton-picking minute - what's going on here?
> 
> 1_2# Clearly concatenation. Right?
> 0_0# Clearly an emoticon
> 
> Just another cotton-picking minute..
> 
> ChrisA
> 

You are excused and required to do 30 days penance writing .NET.
--
https://mail.python.org/mailman/listinfo/python-list

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Lists And Missing Commas

[Ethan Furman]

On 12/24/2019 10:02 AM, Avi Gross via Python-list wrote:


This being Python (which lies about how there should be one unique way to
logically do something)


The koan is:

  There should be one-- and preferably only one --obvious way to do it.

It is not:

- only one way
- one unique way
- the one true way
- the way to end all ways  ;)
- etc


It is also `preferable`, not:

- absolute
- eternal
- fixed
- exclusive

--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list

Re: Most elegant way to do something N times

[Marco Sulla via Python-list]

On Tue, 24 Dec 2019 at 01:07, Chris Angelico  wrote:
> On Tue, Dec 24, 2019 at 10:45 AM Marco Sulla <...> wrote:
> > ??? Excuse me, but why you needed to call the same function SIX times? This
> > seems to me not elegant in primis.
> >
> > Can you give us a practical example?
>
> File parsing. You read a section header and want to ignore that
> section, so you ignore the next 15 lines.

mmap and find?


On Tue, 24 Dec 2019 at 01:35, DL Neil via Python-list
 wrote:
> Taking the top/bottom six from a sorted list of occurrences.

Slicing?
-- 
https://mail.python.org/mailman/listinfo/python-list

Lists And Extra Commas at end

[Avi Gross via Python-list]

Marco,

Python is used by some in an interactive mode but also in more of a batch mode 
such as on a server. The former can possibly see a SyntaxWarning. Do you want 
that as a default or something you set when you start the Python Interpreter or 
perhaps a command within it? I note a brief search to see about Warnings in 
Jupyter keeps talking about how to turn warnings off!  My point is that 
warnings about what is not a real problem tend to make people ignore all 
warnings.

Let me switch gears to the terminal comma situation. Unlike many languages, 
Python decided a dangling comma is perfectly allowable in many situations, 
perhaps all.

>>> a=[1,2,3,]
>>> a
[1, 2, 3]

The above does not work for an empty comma at the beginning or middle or a 
double comma at the end. It is clear why they allowed this as it makes some 
things easier like building up a list in a loop and not needing to figure out 
the special case when you are done and suppressing the last comma. Since a 
function argument list is just a list in Python, the following works fine:

def testink(a,b,): pass

And, of course, you can use the same dangling comma in making a tuple, 
dictionary or set and who knows where else.

So, is that a feature you want warnings about? After all, a dangling comma may 
simply mean you left something out and meant to add later? 

As I see it, languages have tradeoffs and nobody will be completely satisfied 
so you choose and hope. But, warnings you can turn on an off do indeed make 
sense. But at what level? If the main interpreter has to do all kinds of 
testing even for a VALID use of the language so it can warn, that is extra 
overhead each time it is run. I would prefer something less intrusive. Some 
languages have a way of saying "use strict" (such as JavaScript or Perl) or a 
"use warnings" that tells to interpreter to warn about things. Since Python did 
not go this route, with perhaps a tad of that regarding the __future__ setting, 
I figured a good place to do this is in a Lint type of program that can be set 
to look for things that are not so much errors as places to check to make sure 
things are OK. You would not run that every time, just when the code has been 
changed.

And, if you look for a list of places people make mistakes that are often 
maddening to trace, there are so many. Would you like a warning that multiple 
NAMES are almost the same except for capitalization or that you have 
long_variable_1_of_2 as well as long_variable_2_of_2 which only differ by a tad 
deep in the middle?

At some point, you have to take the training wheels off. Not clear what that 
point is, sometimes, so I try to only drive vehicles with 4 or six tires, LOL!

-Original Message-
From: forwarde...@e4ward.com  On Behalf Of Marco Sulla
Sent: Tuesday, December 24, 2019 4:03 PM
To: Avi Gross 
Cc: 
python-list.python.org-mail.python.org.marco.sulla.e4ward@jq38efsu937.reply.e4ward.com
Subject: Re: Lists And Missing Commas

On Tue, 24 Dec 2019 at 19:05, Avi Gross via Python-list 
 wrote:
> There are some lint programs that check your code and supply warnings 
> and I see some languages have the option to generate warnings when the 
> two strings are on the same line. I wonder if a Python lint does that. 
> It may at least warn of this usage in time to check the code and put back the 
> comma.

IMHO it's not something that should be delegated to linter, but to the AST 
compiler itself. A SyntaxWarning should be displayed.

One time I spent HOURS because I forgot one single comma in a list of strings. 
After that, my life is changed. I'm no more an ingenuous, little boy, that 
trusted the stacktrace.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Lists And Extra Commas at end

[Cameron Simpson]

On 24Dec2019 16:48, Avi Gross  wrote:
Let me switch gears to the terminal comma situation. Unlike many 
languages, Python decided a dangling comma is perfectly allowable in 
many situations, perhaps all.



a=[1,2,3,]
a

[1, 2, 3]

[...]
And, of course, you can use the same dangling comma in making a tuple, 
dictionary or set and who knows where else.
So, is that a feature you want warnings about? After all, a dangling 
comma may simply mean you left something out and meant to add later?


To my mind the killer argument for trailing commas is things like 
multiline lists, dicts or parameters. Example:


 def function(
 arg1=None,
 arg2=FOO,
 ):

Imagine this for a comewhat extended set of parameters. Or similar for a 
big list or dict (eg a "table" as part of a class definition).


By always including the trailing comma it is easier to insert or delete 
lines, and it reduces diff noise if you're using revision control (no 
commas flickering on and off in the diff output).


Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

Re: Lists And Extra Commas at end

[Marco Sulla via Python-list]

On Tue, 24 Dec 2019 at 22:51, Avi Gross via Python-list
 wrote:
> So, is that a feature you want warnings about? After all, a dangling comma 
> may simply mean you left something out and meant to add later?

.completely OT. I responded to a topic named "List and missing
commas", and suggested a warning for implicit concatenation between
adjacent strings. I don't really know why you renamed it "Lists And
Extra Commas at end". Have you read the thread and my post?

Cheers.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Lists And Missing Commas

[Marco Sulla via Python-list]

On Tue, 24 Dec 2019 at 19:05, Avi Gross via Python-list
 wrote:
> There are some lint programs that check your code and supply warnings and I
> see some languages have the option to generate warnings when the two strings
> are on the same line. I wonder if a Python lint does that. It may at least
> warn of this usage in time to check the code and put back the comma.

IMHO it's not something that should be delegated to linter, but to the
AST compiler itself. A SyntaxWarning should be displayed.

One time I spent HOURS because I forgot one single comma in a list of
strings. After that, my life is changed. I'm no more an ingenuous,
little boy, that trusted the stacktrace.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: More efficient/elegant branching

[Marco Sulla via Python-list]

I agree with Chris Angelico, branch1 is "the way to go". Maybe you
have to add a default at start, maybe None, and maybe raise an
exception if
res is None. Anyway, despite I'm a pain in the... arse and I usually
activate ALL the possible warnings in the world, I always disable
cyclomatic complexity warnings in all linters, in any language :D

# Off topic - START

I proposed a switch-case some years ago. I was brutally condemned like
an heretic :D It was something like:

when expr match arg1, arg2, :
[...]
match *args:
[...]
[...]
else: # optional
[...]

expr was evaluated, and checked if equal to one of the arguments. At
the first positive check, the relative code was evaluated, and the
when breaks. No break keyword, like if-elif. If no check passed and an
else clause is present, its code will be evaluated.

Anyway this is not helpful in your case, since you have more
complicated checks. Mine was only a suggestion to introduce the simple
C switch-case in Python, for making easier trivial if-elif chains and
for code optimization (C switch-case is optimized by C compilers)

# Of topic - END
-- 
https://mail.python.org/mailman/listinfo/python-list

RE: Lists And Extra Commas at end

[Avi Gross via Python-list]

Cameron,

I am not at all against the feature. I like it as my programming style is
like you describe. One entry per line indented at the same level, in
multiple languages. I often do graphics where I generate an image then
fine-tune additional parameters to get the effect I want. Some functions
take literally hundreds of options to adjust anything from text labels to
line types to colors and the high/low values on axes and so on. In languages
like R, I tend to put in a final entry with no trailing comma that is
something harmless that can be left in position and the same for the first
entry. Then my adding/deleting/editing of fields happens in the middle where
I always have a terminal comma.

My point is the convenience comes with a price for people who make a mistake
and are not told perhaps the dangling comma was a placeholder for something
to add that they forgot or ...

Again, the convenience is in some sense removing a mathematical symmetry,
but so what?

-Original Message-
From: Cameron Simpson  
Sent: Tuesday, December 24, 2019 5:12 PM
To: Avi Gross 
Cc: python-list@python.org
Subject: Re: Lists And Extra Commas at end

On 24Dec2019 16:48, Avi Gross  wrote:
>Let me switch gears to the terminal comma situation. Unlike many 
>languages, Python decided a dangling comma is perfectly allowable in 
>many situations, perhaps all.
>
 a=[1,2,3,]
 a
>[1, 2, 3]
[...]
>And, of course, you can use the same dangling comma in making a tuple, 
>dictionary or set and who knows where else.
>So, is that a feature you want warnings about? After all, a dangling 
>comma may simply mean you left something out and meant to add later?

To my mind the killer argument for trailing commas is things like multiline
lists, dicts or parameters. Example:

  def function(
  arg1=None,
  arg2=FOO,
  ):

Imagine this for a comewhat extended set of parameters. Or similar for a big
list or dict (eg a "table" as part of a class definition).

By always including the trailing comma it is easier to insert or delete
lines, and it reduces diff noise if you're using revision control (no commas
flickering on and off in the diff output).

Cheers,
Cameron Simpson 

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Lists And Extra Commas at end

[Chris Angelico]

On Wed, Dec 25, 2019 at 10:50 AM Avi Gross via Python-list
 wrote:
>
> Cameron,
>
> I am not at all against the feature. I like it as my programming style is
> like you describe. One entry per line indented at the same level, in
> multiple languages. I often do graphics where I generate an image then
> fine-tune additional parameters to get the effect I want. Some functions
> take literally hundreds of options to adjust anything from text labels to
> line types to colors and the high/low values on axes and so on. In languages
> like R, I tend to put in a final entry with no trailing comma that is
> something harmless that can be left in position and the same for the first
> entry. Then my adding/deleting/editing of fields happens in the middle where
> I always have a terminal comma.

IOW you recreate the same feature by having a meaningless line at the
end.  Unideal but sometimes necessary.

> My point is the convenience comes with a price for people who make a mistake
> and are not told perhaps the dangling comma was a placeholder for something
> to add that they forgot or ...

People can learn. It's an extremely common idiom. If it's laid out
vertically, include the trailing comma. It's not exactly hard to
figure out.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Lists And Extra Commas at end

[Marco Sulla via Python-list]

On Wed, 25 Dec 2019 at 00:56, Avi Gross
 wrote:
> I may not be understanding what you are objecting to

I, sir, am objecting that I replied to a topic, and you answered to
me, but in another topic. You could have respond to me in the correct
topic, and then  create this other one (that I'm not really
interested).

Anyway.

About the extra comma, it's da**ed useful:

a = (
42,
1981,
8,
19,
23,
)

If I have to comment out the last line, I can, **without having to
remove the comma before**. And if I have to add another number at the
end, I have not to remember to add the comma before.



The real problem is this one:

a = 1,

Unreadable and prone to subtle errors, because maybe you added the
comma by mistake. Caution: Debugging Nightmares.
The solution, IMHO?

DeprecationWarning, use (1, )

Explicit is better blablabla.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Most elegant way to do something N times

[Marco Sulla via Python-list]

Anyway, from itertools recipes:

def repeatfunc(func, times=None, *args):
"""Repeat calls to func with specified arguments.

Example:  repeatfunc(random.random)
"""
if times is None:
return starmap(func, repeat(args))
return starmap(func, repeat(args, times))

On Tue, 24 Dec 2019 at 21:41, Marco Sulla  wrote:
>
> On Tue, 24 Dec 2019 at 01:07, Chris Angelico  wrote:
> > On Tue, Dec 24, 2019 at 10:45 AM Marco Sulla <...> wrote:
> > > ??? Excuse me, but why you needed to call the same function SIX times? 
> > > This
> > > seems to me not elegant in primis.
> > >
> > > Can you give us a practical example?
> >
> > File parsing. You read a section header and want to ignore that
> > section, so you ignore the next 15 lines.
>
> mmap and find?
>
>
> On Tue, 24 Dec 2019 at 01:35, DL Neil via Python-list
>  wrote:
> > Taking the top/bottom six from a sorted list of occurrences.
>
> Slicing?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Lists And Extra Commas at end

[Cameron Simpson]

On 25Dec2019 01:20, mail.python@marco.sulla.e4ward.com 
 wrote:

About the extra comma, it's da**ed useful:

[...]

The real problem is this one:

a = 1,

Unreadable and prone to subtle errors, because maybe you added the
comma by mistake. Caution: Debugging Nightmares.


Hoo, yes. Only the other week I spent _way_ too long debugging exactly 
that mistake because I'd cut/pasted a parameter into some inline code.  
Suddenly a int was a tuple.


With luck I'll recognise that mistake faster next time.

Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list