[issue230077] one-line typo in arraymodule.c

[admin]

Change by admin :


--
github: None -> 33808

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue47133] enhance unittest to show test name and docstring on one line

[Gregory P. Smith]

Gregory P. Smith  added the comment:

A more fundamental issue behind this: unittest's plain text verbose output is 
not intended to be parsable and consumable by machines. It is 22 years old and 
was intended for use in 80 column wide terminals as a progress report while 
watching it run as much it is a final result.  Consider that the legacy use 
case or format if you wish.

Allowing an option for output to one line per test with description could be 
more likely to require horizontal scrolling or reading past a line wrap in CI 
setups where text is scrolling regions embedded in scrolling regions.  Yuck.  
BUT not necessarily bad.  Just different.

The ideas expressed in this thread of making a more clear text format with the 
important PASS/FAIL/ERROR/SKIP status up front and a very clear pastable test 
module.class.test_name seem wise.

I expect most Python projects with nicer test output formatting desires have 
simply adopted pytest and never looked back.

---

Other python unittest derivative concepts to get clear output of results:

We add a reliably machine parsable XML report of test outcomes in absl-py 
https://github.com/abseil/abseil-py/tree/main/absl/testing. It's IMNSHO a 
rather annoying implementation - we wish unittest made plugging in additional 
output formats easier. We use that generated XML format for results from 
unittest systems in all of our languages at work, it is picked up and parsed by 
our internal CI system and used to display nicely formatted results when 
available.

I assume pytest also provides machine parsable reporting capabilities but I 
haven't looked.

--
nosy: +gregory.p.smith

___
Python tracker 
<https://bugs.python.org/issue47133>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue47133] enhance unittest to show test name and docstring on one line

[Steven D'Aprano]

Steven D'Aprano  added the comment:

Rather than an option for this, it would be cleaner to deprecate the 
current output in 3.11, and fix it in 3.12 or 3.13.

Otherwise we have to maintain the old (bad?) output and the new output 
both forever.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue47133] enhance unittest to show test name and docstring on one line

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

This is already the third (at least) issue asking for such feature. Many people 
have problems with the current output. I would prefer to have a full qualified 
name of the test which I can copy by a double click and insert in a command 
that reruns specified tests. And full path to the test's source which I can 
copy to run in editor. pytest output looks more user-friendly to me.

But it may break other's test output parsers so we perhaps need an option for 
this. Options for unittest and libregrtest. I am not sure that it is a task for 
an average new contributor.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue47133] enhance unittest to show test name and docstring on one line

[Steven D'Aprano]

Steven D'Aprano  added the comment:

I have no problem with pinging Python-Dev, or any other forum, asking 
for interested parties. I just don't think we should be intentionally 
spliting the discussion more than it's going to get split organically. 
(If this is interesting to people, they will discuss it on other forums 
no matter what we say or do.)

Aside from the conservative position "If it ain't broke, don't break 
it", also known as "Chesterton's Fence":

https://matt-rickard.com/chestertons-fence/

I'm not specifically opposed to this change. Nor am I in favour.

Why do we print the first line of the doctests in the output of failing 
tests? If we understood the rationale for why we do that, it might give 
some insight into the consequences of removing it. If we don't know why 
it was shown in the first place, maybe we shouldn't remove it until we 
have some idea.

I am -1 on another option flag unless there is no other choice. Each 
boolean flag option doubles the number of tests of unitttest itself 
needed for full coverage.

Another option might be to leave the docstring line alone, and just 
*add* the 'ERROR' to the method name line:

# current output
test_broken_doc (mathlib.testing.test_utils.TestMinmax)
This is a docstring ... ERROR

# enhancement
test_broken_doc (mathlib.testing.test_utils.TestMinmax) ERROR
This is a docstring ... ERROR

That seems to me to be less risky than trying to cram them all on one line.

test_broken_doc (mathlib.testing.test_utils.TestMinmax) This is a docstring 
... ERROR

By the way, I presume we do the same thing for FAIL lines, which have 
the same behaviour as ERROR lines:

test_fail_doc (mathlib.testing.test_utils.TestMinmax)
This is a docstring ... FAIL

test_fail_nodoc (mathlib.testing.test_utils.TestMinmax) ... FAIL

--

___
Python tracker 
<https://bugs.python.org/issue47133>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue47133] enhance unittest to show test name and docstring on one line

[Ethan Furman]

Ethan Furman  added the comment:

I proposed a discussion to python-dev to increase the odds that folks with an 
interest could chime in.  Not everyone follows the new-bugs list.

I find having the output on two lines counter-intuitive -- I was expecting one 
line per test, and indeed my experience seemed to support that (out of hundreds 
of tests showing on one line, it's easy to miss that the rare verbose error is 
on two).  And I'm not the only one, since another developer also thought there 
was a problem and spent most of issue46126 "fixing" it.

Another reason for posting to python-dev is that issue 46126 had been active 
for three months and had a PR merged before another dev mentioned that verbose 
tests with docstrings just printed on two lines instead of one.

Thank you for pointing out the possible disruption caused by unittest output 
changes.

--

___
Python tracker 
<https://bugs.python.org/issue47133>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue47133] enhance unittest to show test name and docstring on one line

[Steven D'Aprano]

Steven D'Aprano  added the comment:

I don't think this change of behaviour should be accepted without discussion, 
and I'm not sure why you think Python-Dev is the right place, rather than here. 

Messing around with unittest and docstrings has already caused issues in the 
past:

https://docs.python.org/3/library/unittest.html#unittest.TestCase.shortDescription

so perhaps we shouldn't break what's not broken?


And frankly, I don't see why the current behaviour is a problem, although maybe 
that's because the way I use unittest is different from the way you use it. 
Grepping the output for errors? Why run verbose mode if you aren't going to 
read the whole output? Seems very odd.

Ethan says: "the test name is easily missed by anyone who isn't aware of that"

Surely the solution to that is education, not changing unittest? Now you are 
aware of it, and the test name is no longer "easily missed".

If it ever was. To me, it is plain as day. Here is some typical output:


[steve ~]$ python3.10 -m unittest -v mathlib/testing/test_utils.py
test_broken_doc (mathlib.testing.test_utils.TestMinmax)
This is a docstring ... ERROR
test_broken_nodoc (mathlib.testing.test_utils.TestMinmax) ... ERROR
test_empty_iterable (mathlib.testing.test_utils.TestMinmax) ... ok
[additional passing tests ommitted for brevity]

==
ERROR: test_broken_doc (mathlib.testing.test_utils.TestMinmax)
This is a docstring
--
Traceback (most recent call last):
  File "/home/steve/Desktop/mathlib/testing/test_utils.py", line 20, in 
test_broken_doc
self.assertEqual(1, x)
NameError: name 'x' is not defined

==
ERROR: test_broken_nodoc (mathlib.testing.test_utils.TestMinmax)
--
Traceback (most recent call last):
  File "/home/steve/Desktop/mathlib/testing/test_utils.py", line 24, in 
test_broken_nodoc
self.assertEqual(1, x)
NameError: name 'x' is not defined

--
Ran 10 tests in 0.004s

FAILED (errors=2)


Errors are listed twice, once in the summary, and the second time in the 
details section showing the traceback. Note that if you just grep for ERROR you 
get the result you want:

[steve ~]$ python3.10 -m unittest -v mathlib/testing/test_utils.py |& grep ERROR
This is a docstring ... ERROR
test_broken_nodoc (mathlib.testing.test_utils.TestMinmax) ... ERROR
ERROR: test_broken_doc (mathlib.testing.test_utils.TestMinmax)
ERROR: test_broken_nodoc (mathlib.testing.test_utils.TestMinmax)


So I am having trouble seeing what the problem here is.

--
nosy: +steven.daprano

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue47133] enhance unittest to show test name and docstring on one line

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Issue14265, issue46126.

--
nosy: +serhiy.storchaka

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue47133] enhance unittest to show test name and docstring on one line

[Itay Yeshaya]

Itay Yeshaya  added the comment:

I would like to work on this.

--
nosy: +itay.yeshaya

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue47133] enhance unittest to show test name and docstring on one line

[Irit Katriel]

Change by Irit Katriel :


--
keywords: +easy

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue47133] enhance unittest to show test name and docstring on one line

[Ethan Furman]

Change by Ethan Furman :


--
assignee:  -> ethan.furman

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue47133] enhance unittest to show test name and docstring on one line

[Ethan Furman]

New submission from Ethan Furman :

When running unittest with the -v flag, if a test has errors, and has a 
docstring, the test name is shown on one line, and the docstring is shown on 
the next line -- and the ERROR word is shown with the docstring.

What this means is that:
- the test name is easily missed by anyone who isn't aware of that (I only 
recently found out when someone else pointed it out to me)
- grepping for ERROR doesn't reveal the test name, necessitating a search 
through the testing code to find the test that failed

There are two possible solutions, and the selection of which one should be 
discussed on python-dev:
- print the name and docstring, and ERROR, all on one line; or
- provide a command-line switch to select that behavior

---

For the experienced developers who see this:  please leave the issue for one of 
the new developers subscribed to core-mentorship.  Thank you.

--
components: Tests
messages: 416090
nosy: ethan.furman
priority: low
severity: normal
stage: needs patch
status: open
title: enhance unittest to show test name and docstring on one line
type: enhancement
versions: Python 3.11

___
Python tracker 
<https://bugs.python.org/issue47133>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46349] inspect.getdoc() should append parent class method docs when encountering a local one line docstring

[Gregory P. Smith]

Gregory P. Smith  added the comment:

>From the context of help(typical_subclass_of_abstract_thing.method), the user 
>isn't told what the base classes are or which one might have documentation.  
>So it could become an exercise in frustration.

and LOL yes the parameter name is silly but that's a separate module wide 
cleanup that could be done - inspect is full of public APIs that shadow object 
as a parameter name.  it is often quite old code.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46349] inspect.getdoc() should append parent class method docs when encountering a local one line docstring

[Steven D'Aprano]

Steven D'Aprano  added the comment:

Many docstrings are only 1 line without being "See base class." And many 
docstrings are multiple lines while also referring the reader to see the parent 
class for further details. So this DWIM heuristic to guess whether or not to 
display a parent class docstring will have a lot of both false positives and 
false negatives.

The false negatives just revert to the status quo, but the false positives will 
be annoying.

I am leery of DWIM code. The reader should be capable of recognising that sort 
of message and calling up help for that class, so I think the benefit here is 
minimal and the failures common.

But if we do go ahead with this, I have a style issue.

At the moment, getdoc shadows `object`, for no good purpose. (I'm fine with 
shadowing builtins if there is a good reason.) This is a minor issue that is 
not worth fixing on its own, but if you do end up touching getdoc to implement 
this, could you please remove the unnecessary shadowing? If we can call the 
function "get *doc*" we can call the parameter *obj* :-)

--
nosy: +steven.daprano

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46349] inspect.getdoc() should append parent class method docs when encountering a local one line docstring

[Gregory P. Smith]

New submission from Gregory P. Smith :

Today `inspect.getdoc()` is quite simple. If a method has any docstring, it 
returns it.

There is one idiom where this is not very useful to our users.  A """See base 
class.""" docstring on a method.

Rather than having to repeat the canonical base class documentation in all 
methods or argue with tooling about not having a docstring in this common 
scenario, a single line docstring being used as a hint to just bring in the 
parent's docstring would be more helpful to the user.

Today's inspect.getdoc() could would turn from:
https://github.com/python/cpython/blob/main/Lib/inspect.py#L850

into something like:

```
...
if doc is None or (isinstance(doc, str) and '\n' not in doc.strip()):
  try:
  parent_doc = _finddoc(object)
  if doc is None:
  doc = parent_doc
  elif isinstance(parent_doc, str):
  doc = f'{doc}\nParent class MRO doc:\n{parent_doc}'
  except (AttributeError, TypeError):
  return doc
   ...
```

Why not just tell people to omit docstrings when they want parent docs?  
Because not all coding styles and linter tooling allows for this as they aim to 
enforce that documentation _is_ written.  Source analysis tooling and IDEs may 
not have a whole transitive dependency view of where the base classes even come 
from and are thus incapable of reliably analyzing whether a parent MRO method 
even exists or has a docstring.  This allows for trivial one line docstrings in 
that situation while still providing better information to the help() user.

This would add value to when using 
help(typical_subclass_of_abstract_thing.method) in notebooks.

--
components: Library (Lib)
messages: 410335
nosy: gregory.p.smith
priority: normal
severity: normal
stage: needs patch
status: open
title: inspect.getdoc() should append parent class method docs when 
encountering a local one line docstring
type: enhancement
versions: Python 3.11

___
Python tracker 
<https://bugs.python.org/issue46349>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: One line sort

[Christian Gollwitzer]

Am 15.11.21 um 14:10 schrieb ast:

A curiosity:

q = lambda x: x and q([i for i in x[1:] if i < x[0]]) + [x[0]] + q([i 
for i in x[1:] if i >= x[0]])


 >>> q([7, 5, 9, 0])
[0, 5, 7, 9]


That seems to be a translation of the classic Haskell quicksort example:

qsort [] = []
qsort (x:xs) = qsort [a | a <- xs, a < x]
  ++ [x] ++
   qsort [b | b <- xs, b >= x]


The Haskell version is a bit clearer IMHO due to the pattern matching, 
but that results in a 2 liner :)


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

Re: One line sort

[Chris Angelico]

On Tue, Nov 16, 2021 at 5:58 AM ast  wrote:
>
> A curiosity:
>
> q = lambda x: x and q([i for i in x[1:] if i < x[0]]) + [x[0]] + q([i
> for i in x[1:] if i >= x[0]])
>
>  >>> q([7, 5, 9, 0])
> [0, 5, 7, 9]

A nicely obfuscated quicksort. Although the "one line" part falls down
a bit if it has to get wrapped for the mailing list post.

(Horribly inefficient, but it's clear what the intention is.)

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

[issue44474] inspect.getsourceslines() consider lambda of one line only

[Wel Griv]

New submission from Wel Griv :

When lambda expression is more than one line or contain a line break, 
getsourcelines() from inspect package only return the first line. Code example:

import inspect


def foo(param, lambda_ref):
_ = param
print(str(inspect.getsourcelines(lambda_ref)))


foo(param=0,
lambda_ref=lambda:
40 + 2)

output:

(['lambda_ref=lambda:\n'], 10)

expected output:

(['foo(lambda_ref=lambda:\n', '40 + 2)\n'], 10)

`param` is not necessary to make the bug appears but makes more sense in a real 
use-case scenario.
Beside, I checked the inspect.py code (see github: 
https://github.com/python/cpython/blob/3.9/Lib/inspect.py couldn't include link 
in the form for some reason), the guilty code is in the tokeneater() method in 
the BlockFinder class. A commentary explicitly mention "# lambdas always end at 
the first NEWLINE" (line 957 of inspect.py in python 3.9, line 1078 in python 
3.10). EndOfBlock is raised after the first newline in case the block is a 
lambda.
Moreover, a similar issue was raised, and closed for strange reason in python 2 
back in 2013, see here: https://bugs.python.org/issue17631

--
components: Extension Modules, Library (Lib), Windows
messages: 396245
nosy: Welgriv, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: inspect.getsourceslines() consider lambda of one line only
type: behavior
versions: Python 3.10, Python 3.9

___
Python tracker 
<https://bugs.python.org/issue44474>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39275] Traceback off by one line when

[Facundo Batista]

Facundo Batista  added the comment:

This is a duplicate of https://bugs.python.org/issue16482 -- closing it.

--
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39275] Traceback off by one line when

[Terry J. Reedy]

Change by Terry J. Reedy :


--
versions:  -Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39275] Traceback off by one line when

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

This looks similar to issue35405 . See also issue16482 with a patch.

--
nosy: +xtreak

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39275] Traceback off by one line when

[Facundo Batista]

New submission from Facundo Batista :

When using pdb to debug, the traceback is off by one line.

For example, this simple script:

```
print("line 1")
import pdb;pdb.set_trace()
print("line 2")
print("line 3", broken)
print("line 4")
```

...when run produces the following traceback (after hitting 'n' in pdb, of 
course):

```
Traceback (most recent call last):
  File "/home/facundo/foo.py", line 3, in 
print("line 2")
NameError: name 'broken' is not defined
```

--
messages: 359678
nosy: facundobatista
priority: normal
severity: normal
status: open
title: Traceback off by one line when
versions: Python 3.6, Python 3.9

___
Python tracker 
<https://bugs.python.org/issue39275>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21063] Touch up one-line descriptions of modules for module index

[Brett Cannon]

Brett Cannon  added the comment:


New changeset 2f2489310d89f589a091aa09ac1eb973d9a383d8 by Brett Cannon (Miss 
Islington (bot)) in branch '3.7':
bpo-21063: Improve module synopsis for distutils (GH-17363) (#17381)
https://github.com/python/cpython/commit/2f2489310d89f589a091aa09ac1eb973d9a383d8


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21063] Touch up one-line descriptions of modules for module index

[miss-islington]

miss-islington  added the comment:


New changeset 089387ed1f47d9443b5f28bb1863294eeac2de08 by Miss Islington (bot) 
in branch '3.8':
bpo-21063: Improve module synopsis for distutils (GH-17363)
https://github.com/python/cpython/commit/089387ed1f47d9443b5f28bb1863294eeac2de08


--
nosy: +miss-islington

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21063] Touch up one-line descriptions of modules for module index

[miss-islington]

Change by miss-islington :


--
pull_requests: +16865
pull_request: https://github.com/python/cpython/pull/17383

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21063] Touch up one-line descriptions of modules for module index

[Brett Cannon]

Change by Brett Cannon :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21063] Touch up one-line descriptions of modules for module index

[miss-islington]

Change by miss-islington :


--
pull_requests: +16864
pull_request: https://github.com/python/cpython/pull/17382

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21063] Touch up one-line descriptions of modules for module index

[miss-islington]

Change by miss-islington :


--
pull_requests: +16863
pull_request: https://github.com/python/cpython/pull/17381

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21063] Touch up one-line descriptions of modules for module index

[Brett Cannon]

Brett Cannon  added the comment:


New changeset f8a6316778faff3991144c3aec4fa92d7b30a72b by Brett Cannon (Sanchit 
Khurana) in branch 'master':
bpo-21063: Improve module synopsis for distutils (GH-17363)
https://github.com/python/cpython/commit/f8a6316778faff3991144c3aec4fa92d7b30a72b


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21063] Touch up one-line descriptions of modules for module index

[Sanchit Khurana]

Change by Sanchit Khurana :


--
pull_requests: +16848
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/17363

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: multiple lines in one line

[DL Neil]

On 31/08/19 8:26 AM, tascioglu.ta...@gmail.com wrote:

Hello,I working on some file operations with python.I have 2 text file which is 
consist of lines such as apple_pie 0.3434 0.6767 0.2312 and other text file has 
apple 0.2334 0.3412 0.123
pie 0.976 0.75654 0.2312
I want to append lines like apple_pie 0.3434 0.6767 0.2312 0.2334 0.3412 
0.123(values for apple) 0.976 0.75654 0.2312(values for pie) in one line. does 
anybody know how to do it ?Thanks...



This is a very broad question. Is it a homework assignment?


First find a consistent relationship between the three words: 
"apple_pie", "apple", and "pie" - is the first always a combination of 
the others? ... always separated by an under-score/under-line? ...always 
in the same sequence of words?


Are the two files sorted in a 1:1 relationship, ie so that the 
nth-record from one 'matches' the nth-record from the other - or is 
record-matching part of the problem?



To solve any ComSc problem think about how it can be split into 
sub-problems. The analogy that is often used, talks about peeling-back 
the successive layers of an onion. Reduce the size of the problem being 
considered, until each sub-problem is small-enough for you to 
(understand how to) solve.


Below, are several functions addressing possible sub-problems. Solving 
one sub-problem can then feed its 'answer' into solving a 'larger' 
problem...



Possibly useful functions:

- take a string and split it into 'first word' and 'rest of line'

- take a two-word string and split it into the two separate words

- take a two-part record and given the two independent words, split it, 
and return its two components


(plus, building sub-problem solutions as Python functions enables us to 
thoroughly test each function separately - to ensure it 'does the job', 
before moving-on to the next, ie before things become ever-more complex 
and testing 'the whole thing' reveals an error without giving ideas as 
to 'when/where' things went-wrong!)



If you come back to us, please add more data examples (otherwise the 
answer becomes: find( "apple" )!), plus sample code showing the progress 
you've made to-date...

--
Regards =dn
--
https://mail.python.org/mailman/listinfo/python-list

multiple lines in one line

[tascioglu . tansu]

Hello,I working on some file operations with python.I have 2 text file which is 
consist of lines such as apple_pie 0.3434 0.6767 0.2312 and other text file has 
apple 0.2334 0.3412 0.123
pie 0.976 0.75654 0.2312
I want to append lines like apple_pie 0.3434 0.6767 0.2312 0.2334 0.3412 
0.123(values for apple) 0.976 0.75654 0.2312(values for pie) in one line. does 
anybody know how to do it ?Thanks...
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Syntax for one-line "nonymous" functions in "declaration style"

[Alexey Muranov]

On mer., Apr 3, 2019 at 6:00 PM, python-list-requ...@python.org wrote:
On Wed, Apr 3, 2019 at 3:55 AM Alexey Muranov 
 wrote:

 I clarified what i meant by an assignment, and i believe it to be a
 usual meaning.

   1. `def` is not an assignment, there is no left-hand side or
 right-hand side. I was talking about the normal assignment by which
 anyone can bind any value to any variable.


Actually, a 'def' statement DOES perform assignment. It does a bit
more than that, but it definitely is assignment. You can easily check
the CPython disassembly:


A command that performs an assignment among other things is not an 
assignment command itself.


Alexey.


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

Re: Syntax for one-line "nonymous" functions in "declaration style"

[Chris Angelico]

On Wed, Apr 3, 2019 at 3:55 AM Alexey Muranov  wrote:
> I clarified what i meant by an assignment, and i believe it to be a
> usual meaning.
>
>   1. `def` is not an assignment, there is no left-hand side or
> right-hand side. I was talking about the normal assignment by which
> anyone can bind any value to any variable.

Actually, a 'def' statement DOES perform assignment. It does a bit
more than that, but it definitely is assignment. You can easily check
the CPython disassembly:

>>> import dis
>>> def f():
... def g(x): return x * 3 + 1
...
>>> dis.dis(f)
  2   0 LOAD_CONST   1 (", line 2>)
  2 LOAD_CONST   2 ('f..g')
  4 MAKE_FUNCTION0
  6 STORE_FAST   0 (g)
  8 LOAD_CONST   0 (None)
 10 RETURN_VALUE

[disassembly of g() omitted as it's irrelevant]

At run time, the statement "def g(x): ..." means "grab this code
object and this name, make a function, *and assign it to the name g*".

Your other points, I agree on.

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

Re: Syntax for one-line "nonymous" functions in "declaration style"

[Alexey Muranov]

On mar., Apr 2, 2019 at 6:00 PM, python-list-requ...@python.org wrote:
On Tue, Apr 2, 2019 at 1:43 AM Alexey Muranov 


wrote:


 > On Mon, Apr 1, 2019 at 3:52 PM Alexey Muranov  gmail.com>
 > wrote:
 > >
 > > I only see a superficial analogy with `super()`, but perhaps it 
is

 > > because you did not give much details of you suggestion.
 >
 > No, it's because the analogy was not meant to be anything more 
than

 > superficial. Both are constructs of syntactic magic that aid
 > readability at
 > a high level but potentially obscure the details of execution (in
 > relatively unimportant ways) when examined at a low level.

 Since i understand that the "super() magic" is just evaluation in a
 predefined environment, it does not look so very magic.


It's the reason why this doesn't work:

superduper = super

class A:
def f(self):
return 42

class B(A):
def f(self):
return superduper().f()


 B().f()

Traceback (most recent call last):
  File "", line 1, in 
  File "", line 3, in f
RuntimeError: super(): __class__ cell not found

But this does:

class C(A):
def f(self):
return superduper().f()
not super


 C().f()

42

I don't know, seems magical to me.

 Moreover, without this "magic", `super()` would have just produced 
an
 error.  So this magic did not change behaviour of something that 
worked

 before, it made "magically" work something that did not work before
 (but i am still not excited about it).


I'm curious how you feel about this example then (from the CPython 
3.7.2
REPL; results from different Python implementations or from scripts 
that

comprise a single compilation unit may vary)?


 372 is 372

True

 b = 372; b is 372

True

 b = 372
 b is 372

False


 > Maybe it was from my talk of implementing this by replacing the
 > assignment
 > with an equivalent def statement in the AST. Bear in mind that 
the def
 > statement is already just a particular kind of assignment: it 
creates

 > a
 > function and assigns it to a name. The only difference between the
 > original
 > assignment and the def statement that replaces it is in the 
__name__
 > attribute of the function object that gets created. The proposal 
just

 > makes
 > the direct lambda assignment and the def "assignment" to be fully
 > equivalent.

 `def` is not an assignment, it is more than that.


def is an assignment where the target is constrained to a single 
variable

and the expression is constrained to a newly created function object
(optionally "decorated" first with one or more composed function 
calls).

The only ways in which:

@decorate
def foo(blah):
return stuff

is more than:

foo = decorate(lambda blah: stuff)

are: 1) the former syntactically allows statements inside the function
body, not just expressions; 2) the former syntactically allows 
annotations
on the function; and 3) the former syntactically sets a function name 
and
the latter doesn't. In other words, all of the differences ultimately 
boil

down to syntax.


Sorry, i do not feel like continuing this discussion for much longer, 
or we need to concentrate on some specific statement on which we 
disagree.


I clarified what i meant by an assignment, and i believe it to be a 
usual meaning.


 1. `def` is not an assignment, there is no left-hand side or 
right-hand side. I was talking about the normal assignment by which 
anyone can bind any value to any variable.


 2. If i execute an assignment statement

foo = ...

and instead of evaluating the right-hand side and assigning the 
value to "foo" variable Python does something else, i consider the 
assignment operation ( = ) broken, as it does not do 
assignment (and only assignment). I've said more on this in previous 
messages.


 3. About the examples with `372 is 372`, Python gives no garanties 
about the id's of numerical objects, and about id's of many other types 
of immutable objects. The user is not supposed to rely on their 
equality or inequality.


Anytime Python's interpreter encounter two immutable objects that 
it finds identical, it is free to allocate a single object for both, 
this does not change the guaranteed semantics of the program.


The '__name__' attribute of an object, as well as most (or all) 
other attributes, is a part of object's value/contents, no analogies 
with the id's.


I am sorry, but except maybe for one or two more very specific 
questions, I am probably not going to continue.


Alexey.



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

Re: Syntax for one-line "nonymous" functions in "declaration style"

[Ian Kelly]

On Tue, Apr 2, 2019 at 1:43 AM Alexey Muranov 
wrote:
>
> > On Mon, Apr 1, 2019 at 3:52 PM Alexey Muranov  > gmail.com>
> > wrote:
> > >
> > > I only see a superficial analogy with `super()`, but perhaps it is
> > > because you did not give much details of you suggestion.
> >
> > No, it's because the analogy was not meant to be anything more than
> > superficial. Both are constructs of syntactic magic that aid
> > readability at
> > a high level but potentially obscure the details of execution (in
> > relatively unimportant ways) when examined at a low level.
>
> Since i understand that the "super() magic" is just evaluation in a
> predefined environment, it does not look so very magic.

It's the reason why this doesn't work:

superduper = super

class A:
def f(self):
return 42

class B(A):
def f(self):
return superduper().f()

>>> B().f()
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 3, in f
RuntimeError: super(): __class__ cell not found

But this does:

class C(A):
def f(self):
return superduper().f()
not super

>>> C().f()
42

I don't know, seems magical to me.

> Moreover, without this "magic", `super()` would have just produced an
> error.  So this magic did not change behaviour of something that worked
> before, it made "magically" work something that did not work before
> (but i am still not excited about it).

I'm curious how you feel about this example then (from the CPython 3.7.2
REPL; results from different Python implementations or from scripts that
comprise a single compilation unit may vary)?

>>> 372 is 372
True
>>> b = 372; b is 372
True
>>> b = 372
>>> b is 372
False

> > Maybe it was from my talk of implementing this by replacing the
> > assignment
> > with an equivalent def statement in the AST. Bear in mind that the def
> > statement is already just a particular kind of assignment: it creates
> > a
> > function and assigns it to a name. The only difference between the
> > original
> > assignment and the def statement that replaces it is in the __name__
> > attribute of the function object that gets created. The proposal just
> > makes
> > the direct lambda assignment and the def "assignment" to be fully
> > equivalent.
>
> `def` is not an assignment, it is more than that.

def is an assignment where the target is constrained to a single variable
and the expression is constrained to a newly created function object
(optionally "decorated" first with one or more composed function calls).
The only ways in which:

@decorate
def foo(blah):
return stuff

is more than:

foo = decorate(lambda blah: stuff)

are: 1) the former syntactically allows statements inside the function
body, not just expressions; 2) the former syntactically allows annotations
on the function; and 3) the former syntactically sets a function name and
the latter doesn't. In other words, all of the differences ultimately boil
down to syntax.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Syntax for one-line "nonymous" functions in "declaration style"

[Alexey Muranov]

On Mon, Apr 1, 2019 at 3:52 PM Alexey Muranov gmail.com>

wrote:
>
> I only see a superficial analogy with `super()`, but perhaps it is
> because you did not give much details of you suggestion.

No, it's because the analogy was not meant to be anything more than
superficial. Both are constructs of syntactic magic that aid 
readability at

a high level but potentially obscure the details of execution (in
relatively unimportant ways) when examined at a low level.


Since i understand that the "super() magic" is just evaluation in a 
predefined environment, it does not look so very magic.  I do not know 
if Python can already manipulate blocks of code and environments as 
first-class objects, but in any case this does not look to be too far 
from the its normal behaviour/semantics.


Moreover, without this "magic", `super()` would have just produced an 
error.  So this magic did not change behaviour of something that worked 
before, it made "magically" work something that did not work before 
(but i am still not excited about it).


On the contrary, i have no idea of how in the current semantics 
executing an assignment can mutate the assigned value.



> On the other hand, i do use assignment in Python, and you seem to
> propose to get rid of assignment or to break it.

I thought the proposal was clear and succinct. "When [lambda 
expressions]
are directly assigned to a variable, Python would use the variable 
name as
the function name." That's all. I don't know where you got the idea I 
was

proposing "to get rid of assignment".


I suppose we use the term "assignment operation" differently.  By 
assignment i mean evaluating the expressions in the right-hand side and 
assigning (binding?) the value to the variable or location described in 
the left-hand side. I believed this was the usual meaning of 
"assignment"...


The behaviour you describe cannot happen during assignment in this 
sense.


Maybe it was from my talk of implementing this by replacing the 
assignment

with an equivalent def statement in the AST. Bear in mind that the def
statement is already just a particular kind of assignment: it creates 
a
function and assigns it to a name. The only difference between the 
original

assignment and the def statement that replaces it is in the __name__
attribute of the function object that gets created. The proposal just 
makes

the direct lambda assignment and the def "assignment" to be fully
equivalent.


`def` is not an assignment, it is more than that.

Alexey.


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

Re: Syntax for one-line "nonymous" functions in "declaration style"

[Chris Angelico]

On Tue, Apr 2, 2019 at 6:04 PM Ian Kelly  wrote:
> > Note that
> >
> > foo.bar = baz
> >
> > and
> >
> > foo[bar] = baz
>
> I wrote "directly assigned to a variable", not to an attribute or an item.
> These are not part of the suggestion.

So what's the advantage over just using def?

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

Generator definition syntax (was: Syntax for one-line "nonymous" functions)

[Alexey Muranov]

On mar., Apr 2, 2019 at 4:31 AM, python-list-requ...@python.org wrote:
Re: ">> Neither i like how a function magically turns into a 
generator if the

 keyword `yield` appears somewhere within its definition.


 I agree, there should have been a required syntactic element on the 
"def"
 line as well to signal it immediately to the reader. It won't stop 
me from using them, though."


One way to save people looking at the code from having to look 
through a function for a yield statement to see if it is a generator 
would be to add a """doc string""" immediately after the function 
def, saying that it is a generator
and describing what it does.  I realize I'm calling on the programmer 
to address this issue by adding doc strings.  Nonetheless adding doc 
strings is a good habit to get in to.

--- Joseph S.


And even if Python did not have docstrings, the programmer could still 
use comments to tell a fellow programmer what kind of code the fellow 
programmer is looking at. Even languages like Brainfuck have comments 
:).


Alexey.


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

Re: Syntax for one-line "nonymous" functions in "declaration style"

[Ian Kelly]

On Mon, Apr 1, 2019 at 3:52 PM Alexey Muranov 
wrote:
>
> I only see a superficial analogy with `super()`, but perhaps it is
> because you did not give much details of you suggestion.

No, it's because the analogy was not meant to be anything more than
superficial. Both are constructs of syntactic magic that aid readability at
a high level but potentially obscure the details of execution (in
relatively unimportant ways) when examined at a low level.

> On the other hand, i do use assignment in Python, and you seem to
> propose to get rid of assignment or to break it.

I thought the proposal was clear and succinct. "When [lambda expressions]
are directly assigned to a variable, Python would use the variable name as
the function name." That's all. I don't know where you got the idea I was
proposing "to get rid of assignment".

Maybe it was from my talk of implementing this by replacing the assignment
with an equivalent def statement in the AST. Bear in mind that the def
statement is already just a particular kind of assignment: it creates a
function and assigns it to a name. The only difference between the original
assignment and the def statement that replaces it is in the __name__
attribute of the function object that gets created. The proposal just makes
the direct lambda assignment and the def "assignment" to be fully
equivalent.

> Note that
>
> foo.bar = baz
>
> and
>
> foo[bar] = baz

I wrote "directly assigned to a variable", not to an attribute or an item.
These are not part of the suggestion.

> Do you propose to desugar it into a method/function call and to get rid
> of assignments in the language completely? Will the user be able to
> override this method? Something like:
>
> setvar("foo", bar)  # desugaring of foo = bar

No, this is entirely unrelated to what I suggested.

> I am so perplexed by the proposed behaviour of `f = lambda...`, that i
> need to ask the followng: am i right to expact that

I'm not going to address what these would do because I haven't developed
the idea to this level of detail, nor do I intend to. It was just an idea
put forth to address the complaint that lambda functions assigned to
variables don't get properly named, as well as the obstacle that the
proposed "f(x) = ..." syntax not only explicitly refuses to address this,
but potentially makes the problem worse by making lambda assignment more
attractive without doing anything to actually name them. I have no
expectation of writing a PEP for it.

> I suppose in any case that
>
> return lambda x: 
>
> and
>
> result = lambda x: 
> return result
>
> would not return the same result, which is not what i want.

Correct, the first would return a function with the name "" (as it
does now), while the second would return a function with the name "result".
Whether or not that is more useful than "" in this case is up to
the reader.

> I tried to imagine what semantics of the language could cause your
> proposed behaviour of `f = lambda...` and couldn't think of anything
> short of breaking the language.

I'm fairly sure the language would continue to function just fine. It
creates a gotcha to be sure, but it's far from being the only one, or even
the biggest one that has to do with lambdas (that award surely goes to the
behavior of lambda closures created in a loop, which comes up on this list
with some regularity).
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Syntax for one-line "nonymous" functions in "declaration style"

[Alexey Muranov]

On lun., avril 1, 2019 at 6:00 PM, python-list-requ...@python.org wrote:
On Sun, Mar 31, 2019 at 1:09 PM Alexey Muranov 


wrote:


 On dim., Mar 31, 2019 at 6:00 PM, python-list-requ...@python.org 
wrote:

 > On Sat, Mar 30, 2019, 5:32 AM Alexey Muranov
 > 
 > wrote:
 >
 >>
 >>  On ven., Mar 29, 2019 at 4:51 PM, python-list-requ...@python.org
 >> wrote:
 >>  >
 >>  > There could perhaps be a special case for lambda expressions 
such

 >>  >  that,
 >>  > when they are directly assigned to a variable, Python would 
use

 >> the
 >>  > variable name as the function name. I expect this could be
 >>  >  accomplished by
 >>  > a straightforward transformation of the AST, perhaps even by 
just

 >>  >  replacing
 >>  > the assignment with a def statement.
 >>
 >>  If this will happen, that is, if in Python assigning a
 >> lambda-defined
 >>  function to a variable will mutate the function's attributes, or
 >> else,
 >>  if is some "random" syntactically-determined cases
 >>
 >>  f = ...
 >>
 >>  will stop being the same as evaluating the right-hand side and
 >>  assigning the result to "f" variable, it will be a fairly good 
extra

 >>  reason for me to go away from Python.
 >>
 >
 > Is there a particular reason you don't like this? It's not too
 > different
 > from the syntactic magic Python already employs to support the
 > 0-argument
 > form of super().

 I do not want any magic in a programming language i use, especially 
if

 it breaks simple rules.

 I do not like 0-argument `super()` either, but at least I do not 
have

 to use it.


Well, you wouldn't have to use my suggestion either, since it only 
applies

to assignments of the form "f = lambda x: blah". As has already been
stated, the preferred way to do this is with a def statement. So just 
use a
def statement for this, and it wouldn't affect you (unless you 
*really*

want the function's name to be "" for some reason).


I only see a superficial analogy with `super()`, but perhaps it is 
because you did not give much details of you suggestion.


Not only i do not have to use `super()` (i do not have to use Python 
either), but the magic behaviour of `super` is explained by special 
implicit environments in which some blocks of code are executed.  
Though this looks somewhat hackish, it gives me no clue of how your 
idea of mutating objects during assignment is supposed to work.


On the other hand, i do use assignment in Python, and you seem to 
propose to get rid of assignment or to break it.


Note that

   foo.bar = baz

and

   foo[bar] = baz

are not assignments but method calls, but

   foo = bar

it an assignment (if i understand the current model correctly).

Do you propose to desugar it into a method/function call and to get rid 
of assignments in the language completely? Will the user be able to 
override this method? Something like:


   setvar("foo", bar)  # desugaring of foo = bar

Would the assignment operation remain in the language under a different 
name?  Maybe,


   foo <- bar

?

I am so perplexed by the proposed behaviour of `f = lambda...`, that i 
need to ask the followng: am i right to expact that


 1.

 f = lambda x: x,
 g = lambda x: x*x

 2.

 (f, g) = (lambda x: x, lambda x: x*x)

 3.

 (f, g) = _ = (lambda x: x, lambda x: x*x)

 4.

 f = (lambda x: x)(lambda x: x)
 g = (lambda x: x)(lambda x: x*x)

Will all have the same net effect?

I suppose in any case that

   return lambda x: 

and

   result = lambda x: 
   return result

would not return the same result, which is not what i want.

I tried to imagine what semantics of the language could cause your 
proposed behaviour of `f = lambda...` and couldn't think of anything 
short of breaking the language.



That said, that's also the reason why this probably wouldn't happen. 
Why go

to the trouble of fixing people's lambda assignments for them when the
preferred fix would be for them to do it themselves by replacing them 
with

def statements?


It is not fixing, it is breaking.

Alexey.


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

RE: Syntax for one-line "nonymous" functions in "declaration style"

[Schachner, Joseph]

Re: ">> Neither i like how a function magically turns into a generator if the 
>> keyword `yield` appears somewhere within its definition.

> I agree, there should have been a required syntactic element on the "def"
> line as well to signal it immediately to the reader. It won't stop me from 
> using them, though."

One way to save people looking at the code from having to look through a 
function for a yield statement to see if it is a generator would be to add a 
"""doc string""" immediately after the function def, saying that it is a 
generator
and describing what it does.  I realize I'm calling on the programmer to 
address this issue by adding doc strings.  Nonetheless adding doc strings is a 
good habit to get in to.
--- Joseph S.
-Original Message-
From: Ian Kelly  
Sent: Sunday, March 31, 2019 3:45 PM
To: Python 
Subject: Re: Syntax for one-line "nonymous" functions in "declaration style"

On Sun, Mar 31, 2019 at 1:09 PM Alexey Muranov 
wrote:
>
> On dim., Mar 31, 2019 at 6:00 PM, python-list-requ...@python.org wrote:
> > On Sat, Mar 30, 2019, 5:32 AM Alexey Muranov 
> > 
> > wrote:
> >
> >>
> >>  On ven., Mar 29, 2019 at 4:51 PM, python-list-requ...@python.org
> >> wrote:
> >>  >
> >>  > There could perhaps be a special case for lambda expressions 
> >> such  >  that,  > when they are directly assigned to a variable, 
> >> Python would use the  > variable name as the function name. I 
> >> expect this could be  >  accomplished by  > a straightforward 
> >> transformation of the AST, perhaps even by just  >  replacing  > 
> >> the assignment with a def statement.
> >>
> >>  If this will happen, that is, if in Python assigning a 
> >> lambda-defined  function to a variable will mutate the function's 
> >> attributes, or else,  if is some "random" syntactically-determined 
> >> cases
> >>
> >>  f = ...
> >>
> >>  will stop being the same as evaluating the right-hand side and  
> >> assigning the result to "f" variable, it will be a fairly good 
> >> extra  reason for me to go away from Python.
> >>
> >
> > Is there a particular reason you don't like this? It's not too 
> > different from the syntactic magic Python already employs to support 
> > the 0-argument form of super().
>
> I do not want any magic in a programming language i use, especially if 
> it breaks simple rules.
>
> I do not like 0-argument `super()` either, but at least I do not have 
> to use it.

Well, you wouldn't have to use my suggestion either, since it only applies to 
assignments of the form "f = lambda x: blah". As has already been stated, the 
preferred way to do this is with a def statement. So just use a def statement 
for this, and it wouldn't affect you (unless you *really* want the function's 
name to be "" for some reason).

That said, that's also the reason why this probably wouldn't happen. Why go to 
the trouble of fixing people's lambda assignments for them when the preferred 
fix would be for them to do it themselves by replacing them with def statements?

> Neither i like how a function magically turns into a generator if the 
> keyword `yield` appears somewhere within its definition.

I agree, there should have been a required syntactic element on the "def"
line as well to signal it immediately to the reader. It won't stop me from 
using them, though.

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

Re: Syntax for one-line "nonymous" functions in "declaration style"

[Ian Kelly]

On Sun, Mar 31, 2019 at 1:09 PM Alexey Muranov 
wrote:
>
> On dim., Mar 31, 2019 at 6:00 PM, python-list-requ...@python.org wrote:
> > On Sat, Mar 30, 2019, 5:32 AM Alexey Muranov
> > 
> > wrote:
> >
> >>
> >>  On ven., Mar 29, 2019 at 4:51 PM, python-list-requ...@python.org
> >> wrote:
> >>  >
> >>  > There could perhaps be a special case for lambda expressions such
> >>  >  that,
> >>  > when they are directly assigned to a variable, Python would use
> >> the
> >>  > variable name as the function name. I expect this could be
> >>  >  accomplished by
> >>  > a straightforward transformation of the AST, perhaps even by just
> >>  >  replacing
> >>  > the assignment with a def statement.
> >>
> >>  If this will happen, that is, if in Python assigning a
> >> lambda-defined
> >>  function to a variable will mutate the function's attributes, or
> >> else,
> >>  if is some "random" syntactically-determined cases
> >>
> >>  f = ...
> >>
> >>  will stop being the same as evaluating the right-hand side and
> >>  assigning the result to "f" variable, it will be a fairly good extra
> >>  reason for me to go away from Python.
> >>
> >
> > Is there a particular reason you don't like this? It's not too
> > different
> > from the syntactic magic Python already employs to support the
> > 0-argument
> > form of super().
>
> I do not want any magic in a programming language i use, especially if
> it breaks simple rules.
>
> I do not like 0-argument `super()` either, but at least I do not have
> to use it.

Well, you wouldn't have to use my suggestion either, since it only applies
to assignments of the form "f = lambda x: blah". As has already been
stated, the preferred way to do this is with a def statement. So just use a
def statement for this, and it wouldn't affect you (unless you *really*
want the function's name to be "" for some reason).

That said, that's also the reason why this probably wouldn't happen. Why go
to the trouble of fixing people's lambda assignments for them when the
preferred fix would be for them to do it themselves by replacing them with
def statements?

> Neither i like how a function magically turns into a generator if the
> keyword `yield` appears somewhere within its definition.

I agree, there should have been a required syntactic element on the "def"
line as well to signal it immediately to the reader. It won't stop me from
using them, though.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Syntax for one-line "nonymous" functions in "declaration style"

[Alexey Muranov]

On dim., Mar 31, 2019 at 6:00 PM, python-list-requ...@python.org wrote:
On Sat, Mar 30, 2019, 5:32 AM Alexey Muranov 


wrote:



 On ven., Mar 29, 2019 at 4:51 PM, python-list-requ...@python.org 
wrote:

 >
 > There could perhaps be a special case for lambda expressions such
 >  that,
 > when they are directly assigned to a variable, Python would use 
the

 > variable name as the function name. I expect this could be
 >  accomplished by
 > a straightforward transformation of the AST, perhaps even by just
 >  replacing
 > the assignment with a def statement.

 If this will happen, that is, if in Python assigning a 
lambda-defined
 function to a variable will mutate the function's attributes, or 
else,

 if is some "random" syntactically-determined cases

 f = ...

 will stop being the same as evaluating the right-hand side and
 assigning the result to "f" variable, it will be a fairly good extra
 reason for me to go away from Python.



Is there a particular reason you don't like this? It's not too 
different
from the syntactic magic Python already employs to support the 
0-argument

form of super().


I do not want any magic in a programming language i use, especially if 
it breaks simple rules.


I do not like 0-argument `super()` either, but at least I do not have 
to use it. I am suspicious of `__class__` too. But here only 
identifiers are hacked, not the assignment operator. (I suppose the 
hack can be unhacked by using your own meta-class with a custom 
`__prepare__`.)


Neither i like how a function magically turns into a generator if the 
keyword `yield` appears somewhere within its definition.


Those are the things i don't like the most in Python.

Alexey.


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

Re: Syntax for one-line "nonymous" functions in "declaration style"

[Ian Kelly]

On Sat, Mar 30, 2019, 5:32 AM Alexey Muranov 
wrote:

>
> On ven., Mar 29, 2019 at 4:51 PM, python-list-requ...@python.org wrote:
> >
> > There could perhaps be a special case for lambda expressions such
> >  that,
> > when they are directly assigned to a variable, Python would use the
> > variable name as the function name. I expect this could be
> >  accomplished by
> > a straightforward transformation of the AST, perhaps even by just
> >  replacing
> > the assignment with a def statement.
>
> If this will happen, that is, if in Python assigning a lambda-defined
> function to a variable will mutate the function's attributes, or else,
> if is some "random" syntactically-determined cases
>
> f = ...
>
> will stop being the same as evaluating the right-hand side and
> assigning the result to "f" variable, it will be a fairly good extra
> reason for me to go away from Python.
>

Is there a particular reason you don't like this? It's not too different
from the syntactic magic Python already employs to support the 0-argument
form of super().
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Syntax for one-line "nonymous" functions in "declaration style"

[Alexey Muranov]

On ven., Mar 29, 2019 at 4:51 PM, python-list-requ...@python.org wrote:
On Thu, Mar 28, 2019 at 2:30 PM Alexey Muranov 


wrote:


 On jeu., mars 28, 2019 at 8:57 PM, Terry Reedy  
wrote:

 > Throwing the name away is foolish.  Testing functions is another
 > situation in which function names are needed for proper report.

 My idea however was to have it as an exact synonyme of an 
assignment of

 a lambda. Assignment is an assignment, it should not modify the
 attributs of the value that is being assigned.


There could perhaps be a special case for lambda expressions such 
that,

when they are directly assigned to a variable, Python would use the
variable name as the function name. I expect this could be 
accomplished by
a straightforward transformation of the AST, perhaps even by just 
replacing

the assignment with a def statement.


If this will happen, that is, if in Python assigning a lambda-defined 
function to a variable will mutate the function's attributes, or else, 
if is some "random" syntactically-determined cases


   f = ...

will stop being the same as evaluating the right-hand side and 
assigning the result to "f" variable, it will be a fairly good extra 
reason for me to go away from Python.


Since this could just as easily be applied to lambda though, I'm 
afraid it

doesn't offer much of a case for the "f(x)" syntactic sugar.


I did not get this. My initial idea was exactly about introducing a 
syntactic sugar for better readability. I've already understood that 
the use cases contradict PEP 8 recommendations.


Alexey.




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

Re: Syntax for one-line "nonymous" functions in "declaration style"

[Antoon Pardon]

On 27/03/19 09:21, Alexey Muranov wrote:
> Whey you need a simple function in Python, there is a choice between a
> normal function declaration and an assignment of a anonymous function
> (defined by a lambda-expression) to a variable:
>
>    def f(x): return x*x
>
> or
>
>    f = lambda x: x*x
>
> It would be however more convenient to be able to write instead just
>
>    f(x) = x*x 

I have mixed feelings about this. I think anonymous functions only have a
place as arguments to a function. So f(x) = x * x, doesn't look like an 
anonymous function but just an other way to have a named fuction. (as
others have already pointed out)

If we really want an alternative for the lambda expresion, I would go
for the following.

f = x -> x*x (or maybe we could have the λ instead of lambda)

If we want haskell like patterns for defining functions I would go
for the following:

fac(0) -> 1
fac(n) -> n * fac(n - 1)

Which seems incompatible with the proposal for an alternative lambda. 

-- 
Antoon Pardon.

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

Re: Syntax for one-line "nonymous" functions in "declaration style"

[Terry Reedy]

On 3/28/2019 12:29 PM, Alexey Muranov wrote:

On jeu., Mar 28, 2019 at 5:00 PM, python-list-requ...@python.org wrote:


So my opinion is that lambda expressions should only be used within 
larger expressions and never directly bound.



It would be however more convenient to be able to write instead just

    f(x) = x*x


Given my view above, this is, standing alone, strictly an abbreviation 
of the equivalent def statement.  I am presuming that a proper 
implementation would result in f.__name__ == 'f'.




No, after some thought, i think it should be an abbreviation of "f = 
lambda x: x*x", f.__name__ would still be ''.


Throwing the name away is foolish.  Testing functions is another 
situation in which function names are needed for proper report.  I wrote 
and use a test function something like the following, simplified and 
adapted for use with unittest:


def ftest(func, io_pairs):
errors = []
for input, expected in io_pairs:
actual = func(input)
if actual != expected:
errors.append(
f"Func: {func.__name__}, input: {input}, "
f"expected: {expected}, actual: {actual}.")
return errors if errors else None

(Then "self.assertNone(ftest(func, io_pairs))" will test all pairs and 
list at least part of the error list.)


If all the names were '', not very useful.  (The workaround 
would be to require the caller to know a name and pass it separately, 
without mis-typing.)


for unittest, a


But i see your point about never assigning lambdas directly, it makes 
sense.  But sometimes i do assign short lambdas directly to variable.


Is the convenience and (very low) frequency of applicability worth the 
inconvenience of confusing the meaning of '=' and complicating the 
implementation?



I do not see any conflicts with the existing syntax.


It heavily conflicts with existing syntax.  The current meaning of
  target_expression = object_expression
is
1. Evaluate object_expression in the existing namespace to an object, 
prior to any new bindings and independent of the target_expression.
2. Evaluate target_expression in the existing namespace to one or more 
targets.

3. Bind object to target or iterate target to bind to multiple targets.


I do not thick so.  In "x = 42" the variable x is not evaluated.

All examples of the proposed syntax i can think of are currently 
illegal, so i suppose there is no conflicts. (I would appreciate a 
counterexample, if any.)


You are talking about syntax conflicts, I am talking about semantic 
conflict, which is important for human understanding.



Thanks for the reference to PEP 8, this is indeed an argument against.


The situation in which assigning lambda expressions is more tempting is 
when assigning to attributes or dicts.


def double(x): return x*x
C.double = double
d['double'] = double
versus

C.double = lambda x: x*x
d['double'] = lambda x: x*x

For attributes, "def C.double(x): return x*x" has been proposed but not 
accepted.



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

Re: Syntax for one-line "nonymous" functions in "declaration style"

[Chris Angelico]

On Fri, Mar 29, 2019 at 7:29 AM Alexey Muranov  wrote:
> My idea however was to have it as an exact synonyme of an assignment of
> a lambda. Assignment is an assignment, it should not modify the
> attributs of the value that is being assigned.

Assigning lambda functions to names generally shouldn't be done. Just
use def. You're asking for another way to do a bad thing that has a
better alternative.

There have periodically been proposals for the opposite, which would
take care of some of the alternatives:

def op["double"](x): return x * x

This kind of proposal has its own issues, but I think it has a much
better chance of being accepted than a way of creating and assigning
lambda functions.

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

Re: Syntax for one-line "nonymous" functions in "declaration style"

[Ian Kelly]

On Thu, Mar 28, 2019 at 2:30 PM Alexey Muranov 
wrote:
>
> On jeu., mars 28, 2019 at 8:57 PM, Terry Reedy  wrote:
> > Throwing the name away is foolish.  Testing functions is another
> > situation in which function names are needed for proper report.
>
> My idea however was to have it as an exact synonyme of an assignment of
> a lambda. Assignment is an assignment, it should not modify the
> attributs of the value that is being assigned.

There could perhaps be a special case for lambda expressions such that,
when they are directly assigned to a variable, Python would use the
variable name as the function name. I expect this could be accomplished by
a straightforward transformation of the AST, perhaps even by just replacing
the assignment with a def statement.

Since this could just as easily be applied to lambda though, I'm afraid it
doesn't offer much of a case for the "f(x)" syntactic sugar.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Syntax for one-line "nonymous" functions in "declaration style"

[Alexey Muranov]

On jeu., mars 28, 2019 at 5:00 PM, python-list-requ...@python.org wrote:

So documentation of that syntax would 100% be required


Regarding documentation, i believe there would be 3 line to add:


() = 

is a syntactic sugar for

 = lambda : 


Alexey.


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

Re: Syntax for one-line "nonymous" functions in "declaration style"

[Alexey Muranov]

On jeu., mars 28, 2019 at 8:57 PM, Terry Reedy  wrote:

On 3/28/2019 12:29 PM, Alexey Muranov wrote:
On jeu., Mar 28, 2019 at 5:00 PM, python-list-requ...@python.org 
wrote:


So my opinion is that lambda expressions should only be used within 
larger expressions and never directly bound.


It would be however more convenient to be able to write instead 
just


f(x) = x*x


Given my view above, this is, standing alone, strictly an 
abbreviation of the equivalent def statement.  I am presuming 
that a proper implementation would result in f.__name__ == 'f'.




No, after some thought, i think it should be an abbreviation of "f = 
lambda x: x*x", f.__name__ would still be ''.


Throwing the name away is foolish.  Testing functions is another 
situation in which function names are needed for proper report.


My idea however was to have it as an exact synonyme of an assignment of 
a lambda. Assignment is an assignment, it should not modify the 
attributs of the value that is being assigned.




But i see your point about never assigning lambdas directly, it 
makes sense.  But sometimes i do assign short lambdas directly to 
variable.


Is the convenience and (very low) frequency of applicability worth 
the inconvenience of confusing the meaning of '=' and 
complicating the implementation?



I do not see any conflicts with the existing syntax.


It heavily conflicts with existing syntax.  The current meaning of
  target_expression = object_expression
is
1. Evaluate object_expression in the existing namespace to an 
object, prior to any new bindings and independent of the 
target_expression.
2. Evaluate target_expression in the existing namespace to one or 
more targets.
3. Bind object to target or iterate target to bind to multiple 
targets.


I do not thick so.  In "x = 42" the variable x is not evaluated.

All examples of the proposed syntax i can think of are currently 
illegal, so i suppose there is no conflicts. (I would appreciate a 
counterexample, if any.)


You are talking about syntax conflicts, I am talking about semantic 
conflict, which is important for human understanding.


Thanks for the reference to PEP 8, this is indeed an argument 
against.


The situation in which assigning lambda expressions is more tempting 
is when assigning to attributes or dicts.


def double(x): return x*x
C.double = double
d['double'] = double
versus

C.double = lambda x: x*x
d['double'] = lambda x: x*x


These are some of examples i had in mind as well:

   C.double(x) = x*x
   d['double'](x) = x*x

Alexey.


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

Re: Syntax for one-line "nonymous" functions in "declaration style"

[Alexey Muranov]

On jeu., mars 28, 2019 at 8:57 PM, Terry Reedy  wrote:


But i see your point about never assigning lambdas directly, it 
makes sense.  But sometimes i do assign short lambdas directly to 
variable.


Is the convenience and (very low) frequency of applicability worth 
the inconvenience of confusing the meaning of '=' and 
complicating the implementation?



I do not see any conflicts with the existing syntax.


It heavily conflicts with existing syntax.  The current meaning of
  target_expression = object_expression
is
1. Evaluate object_expression in the existing namespace to an 
object, prior to any new bindings and independent of the 
target_expression.
2. Evaluate target_expression in the existing namespace to one or 
more targets.
3. Bind object to target or iterate target to bind to multiple 
targets.


I do not thick so.  In "x = 42" the variable x is not evaluated.

All examples of the proposed syntax i can think of are currently 
illegal, so i suppose there is no conflicts. (I would appreciate a 
counterexample, if any.)


You are talking about syntax conflicts, I am talking about semantic 
conflict, which is important for human understanding.


I believe there is no semantic conflict either, or could you be more 
specific?


Alexey.


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

Re: Syntax for one-line "nonymous" functions in "declaration style"

[Alexey Muranov]

On jeu., mars 28, 2019 at 5:00 PM, python-list-requ...@python.org wrote:

On 2019-03-27 10:42 a.m., Paul Moore wrote:
 On Wed, 27 Mar 2019 at 12:27, Alexey Muranov 
 wrote:
 On mer., mars 27, 2019 at 10:10 AM, Paul Moore 


 wrote:

 On Wed, 27 Mar 2019 at 08:25, Alexey Muranov
  wrote:

  Whey you need a simple function in Python, there is a choice
 between a
  normal function declaration and an assignment of a anonymous
 function
  (defined by a lambda-expression) to a variable:

  def f(x): return x*x

  or

  f = lambda x: x*x

  It would be however more convenient to be able to write instead 
just


  f(x) = x*x
 Why? Is saving a few characters really that helpful? So much so 
that
 it's worth adding a *third* method of defining functions, which 
would

 need documenting, adding to training materials, etc, etc?

 Because i think i would prefer to write it this way.

 That's not likely to be sufficient reason for changing a language
 that's used by literally millions of people.


 (Almost no new documentation or tutorials would be needed IMHO.)
 Documentation would be needed to explain how the new construct 
worked,

 for people who either wanted to use it or encountered it in other
 people's code. While it may be obvious to you how it works, it 
likely
 won't be to others, and there will probably be edge cases you 
haven't

 considered that others will find and ask about.


For what it's worth, if I encountered "f(x) = x * x" in code, my first
thought would be that Python somehow added a way to return an 
assignable
reference from a function, rather than this being an anonymous 
function

declaration.

So documentation of that syntax would 100% be required

Alex



The thing to the right of the assignment symbol represents a value (an 
object), but the thing to the left does not represent a value, it 
represents a place for a value.


What would an "assignable reference" mean? Say, variable "x" holds an 
"assignable reference", what can be done next?


Alexey.


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

Re: Syntax for one-line "nonymous" functions in "declaration style"

[Ian Kelly]

On Wed, Mar 27, 2019 at 3:13 AM Paul Moore  wrote:
>
> On Wed, 27 Mar 2019 at 08:25, Alexey Muranov 
wrote:
> >
> > Whey you need a simple function in Python, there is a choice between a
> > normal function declaration and an assignment of a anonymous function
> > (defined by a lambda-expression) to a variable:
> >
> > def f(x): return x*x
> >
> > or
> >
> > f = lambda x: x*x
> >
> > It would be however more convenient to be able to write instead just
> >
> > f(x) = x*x
>
> Why? Is saving a few characters really that helpful? So much so that
> it's worth adding a *third* method of defining functions, which would
> need documenting, adding to training materials, etc, etc?

Well, it does seem a bit silly to have more ways of formatting strings than
of defining functions. We have four of the former, so clearly we need to
address this by adding two more of the latter.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Syntax for one-line "nonymous" functions in "declaration style"

[Alexey Muranov]

On jeu., Mar 28, 2019 at 5:00 PM, python-list-requ...@python.org wrote:


So my opinion is that lambda expressions should only be used within 
larger expressions and never directly bound.



It would be however more convenient to be able to write instead just

f(x) = x*x


Given my view above, this is, standing alone, strictly an 
abbreviation of the equivalent def statement.  I am presuming that a 
proper implementation would result in f.__name__ == 'f'.




No, after some thought, i think it should be an abbreviation of "f = 
lambda x: x*x", f.__name__ would still be ''.


But i see your point about never assigning lambdas directly, it makes 
sense.  But sometimes i do assign short lambdas directly to variable.


Is the convenience and (very low) frequency of applicability worth 
the inconvenience of confusing the meaning of '=' and complicating 
the implementation?



I do not see any conflicts with the existing syntax.


It heavily conflicts with existing syntax.  The current meaning of
  target_expression = object_expression
is
1. Evaluate object_expression in the existing namespace to an object, 
prior to any new bindings and independent of the target_expression.
2. Evaluate target_expression in the existing namespace to one or 
more targets.
3. Bind object to target or iterate target to bind to multiple 
targets.


I do not thick so.  In "x = 42" the variable x is not evaluated.

All examples of the proposed syntax i can think of are currently 
illegal, so i suppose there is no conflicts. (I would appreciate a 
counterexample, if any.)


Thanks for the reference to PEP 8, this is indeed an argument against.

Alexey.



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

Re: Syntax for one-line "nonymous" functions in "declaration style"

[Antoon Pardon]

On 27/03/19 22:25, Terry Reedy wrote:
> ...
>
> Before 3.8, I would stop here and say no to the proposal.  But we now
> have assignment expressions in addition to assignment statements.
>
> >>> int(s:='42'+'742')
> 42742
> >>> s
> '42742'
>
> To me, function assignment expressions, as a enhanced replacement for
> lambda expressions, is more inviting than function assignment
> statements as an abbreviation for function definition statements.
>
> In other words, replace
>
>   map(lambda x: x*x, range(10))
>
> with
>
>   map(square(x):=x*x, range(10))
>
> or, if one does not want a specific name,
>
>   map(_(x):=x*x, range(10))
>
> Many people dislike lambda expressions, to the point that Guido
> considered leaving them out of 3.x.  So this replacement might get
> more traction.  It would make assignment expressions much more useful.

I think map is not a good example, since I would just replace them with 
Since we are talking python 3.8 why not just use a generator here: (x*x for x 
in range(10))
instead of map? 

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

Re: Syntax for one-line "nonymous" functions in "declaration style"

[Ben Finney]

Alexey Muranov  writes:

> It would be however more convenient to be able to write instead just
>
>f(x) = x*x

That's not an anonymous function then, is it? You want to assign a name
to that function, and (to be useful in development tools, such as a
stack trace) the function needs to know its own name.

The way to do that is, as you point out, the ‘def’ statement:

def f(x):
return (x * x)

What does that prevent you from doing? It will need to be pretty
significant improvement to be considered as a change to language syntax.

> Have this idea been discussed before?

Too many times to count :-)

-- 
 \   “Theology is the effort to explain the unknowable in terms of |
  `\ the not worth knowing.” —Henry L. Mencken |
_o__)  |
Ben Finney

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

Re: Syntax for one-line "nonymous" functions in "declaration style"

[Terry Reedy]

On 3/27/2019 4:21 AM, Alexey Muranov wrote:
Whey you need a simple function in Python, there is a choice between a 
normal function declaration and an assignment of a anonymous function 
(defined by a lambda-expression) to a variable:


    def f(x): return x*x

or

    f = lambda x: x*x


PEP 8 properly recommends against this the latter as functionally it has 
no advantage and the disadvantage that f.__name__ becomes the generic 
'' instead of the specific 'f'.  This is not useful for code 
that expects specific names.  Tracebacks are one example.  Here is 
another intended to list callable objects and their types.


def call_clas(container):
for item in vars(container).values():
if hasattr(item, '__call__'):
yield item.__name__, item.__class__

def print_cc(container):
for name, clas in call_clas(container):
print(f'{name:30s}{clas}')

# Examples.
print_cc(int)
from idlelib import pyshell
print_cc(pyshell)

Multiple output lines of '   function' defeat the 
purpose.


So my opinion is that lambda expressions should only be used within 
larger expressions and never directly bound.



It would be however more convenient to be able to write instead just

    f(x) = x*x


Given my view above, this is, standing alone, strictly an abbreviation 
of the equivalent def statement.  I am presuming that a proper 
implementation would result in f.__name__ == 'f'.


Is the convenience and (very low) frequency of applicability worth the 
inconvenience of confusing the meaning of '=' and complicating the 
implementation?



I do not see any conflicts with the existing syntax.


It heavily conflicts with existing syntax.  The current meaning of
  target_expression = object_expression
is
1. Evaluate object_expression in the existing namespace to an object, 
prior to any new bindings and independent of the target_expression.
2. Evaluate target_expression in the existing namespace to one or more 
targets.

3. Bind object to target or iterate target to bind to multiple targets.

Part of step 2 is making calls, because calls cannot be targets.  This 
is why 'f(a+b)[c] = d' can work.  Note that 'a+b' makes calls to 
a.__add__ or b.__radd__ or both.


In the proposal, the treatment of the object expression would depend on 
the target expression and the alternative would be to quote it as code; 
compile the code in a manner that depends on the target expression to 
mark local names versus global names; and finally make a function 
instance, presumably taking __name__ from the target.


This would have the advantage over lambda assignment of getting the name 
right, but I don't think one should be doing lambda assignment anyway. 
There is a good reason to have a separate syntax.


Before 3.8, I would stop here and say no to the proposal.  But we now 
have assignment expressions in addition to assignment statements.


>>> int(s:='42'+'742')
42742
>>> s
'42742'

To me, function assignment expressions, as a enhanced replacement for 
lambda expressions, is more inviting than function assignment statements 
as an abbreviation for function definition statements.


In other words, replace

  map(lambda x: x*x, range(10))

with

  map(square(x):=x*x, range(10))

or, if one does not want a specific name,

  map(_(x):=x*x, range(10))

Many people dislike lambda expressions, to the point that Guido 
considered leaving them out of 3.x.  So this replacement might get more 
traction.  It would make assignment expressions much more useful.


--
Terry Jan Reedy


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

Re: Syntax for one-line "nonymous" functions in "declaration style"

[Alexey Muranov]

On mer., Mar 27, 2019 at 5:00 PM, python-list-requ...@python.org wrote:

On 27/03/19 09:21, Alexey Muranov wrote:
 Whey you need a simple function in Python, there is a choice 
between a
 normal function declaration and an assignment of a anonymous 
function

 (defined by a lambda-expression) to a variable:

def f(x): return x*x

 or

f = lambda x: x*x

 It would be however more convenient to be able to write instead just

f(x) = x*x

 (like in Haskell and such).

 Have this idea been discussed before?

 I do not see any conflicts with the existing syntax.   The following
 would also work:


I don't know. Something like the following is already legal:

f(x)[n] = x * n

And it does something completly different.



Thanks for pointing out this example, but so far i do not see any issue 
with this.


Of course assignment (to an identifier) is a completely different type 
of operation than in-place mutation (of an object) with __setitem__, 
etc.


In

   <...> [<...>] = <...>

the part to the left of "[<...>]=" is an expression that is to be 
evaluated, and only its value matters.  Here "[]=" can be viewed as a 
method call, which is distinguished by the context from "[]" method 
call (__getitem__).


In

= <...>

the  is not evaluated.

I still think that

   ()...() = <...>

is unambiguous.  The following seems possible too:

   a[m][n](x)(y) = m*x + n*y

It would be the same as

   a[m][n] = lambda x: lambda y: m*x + n*y

Here a[m] is evaluated, and on the result the method "[]=" 
(__setitem__) is called.


Basically, "()...()=" seems to technically fit all contexts where "=" 
fits...


Alexey.


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

Re: Syntax for one-line "nonymous" functions in "declaration style"

[Alexandre Brault]

On 2019-03-27 10:42 a.m., Paul Moore wrote:
> On Wed, 27 Mar 2019 at 12:27, Alexey Muranov  wrote:
>> On mer., mars 27, 2019 at 10:10 AM, Paul Moore 
>> wrote:
>>> On Wed, 27 Mar 2019 at 08:25, Alexey Muranov
>>>  wrote:
  Whey you need a simple function in Python, there is a choice
 between a
  normal function declaration and an assignment of a anonymous
 function
  (defined by a lambda-expression) to a variable:

  def f(x): return x*x

  or

  f = lambda x: x*x

  It would be however more convenient to be able to write instead just

  f(x) = x*x
>>> Why? Is saving a few characters really that helpful? So much so that
>>> it's worth adding a *third* method of defining functions, which would
>>> need documenting, adding to training materials, etc, etc?
>> Because i think i would prefer to write it this way.
> That's not likely to be sufficient reason for changing a language
> that's used by literally millions of people.
>
>> (Almost no new documentation or tutorials would be needed IMHO.)
> Documentation would be needed to explain how the new construct worked,
> for people who either wanted to use it or encountered it in other
> people's code. While it may be obvious to you how it works, it likely
> won't be to others, and there will probably be edge cases you haven't
> considered that others will find and ask about.

For what it's worth, if I encountered "f(x) = x * x" in code, my first
thought would be that Python somehow added a way to return an assignable
reference from a function, rather than this being an anonymous function
declaration.

So documentation of that syntax would 100% be required

Alex

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

Re: Syntax for one-line "nonymous" functions in "declaration style"

[Rhodri James]

On 27/03/2019 16:15, Bev in TX wrote:



On Mar 27, 2019, at 10:41 AM, Antoon Pardon  wrote:

I don't know. Something like the following is already legal:

f(x)[n] = x * n

And it does something completly different.


Where would I find information on what this does in the documentation?


Nowhere in particular, it's a consequence of putting things together. 
The part that Antoon isn't mentioning is that he's presuming the 
function f(x) returns a list or something similar that we can then 
index.  You're more likely to see that sort of code written as:


a = f(x)
a[n] = x *n

which makes it look a lot less magical.

--
Rhodri James *-* Kynesim Ltd
--
https://mail.python.org/mailman/listinfo/python-list

Re: Syntax for one-line "nonymous" functions in "declaration style"

[Bev in TX]

> On Mar 27, 2019, at 10:41 AM, Antoon Pardon  wrote:
> 
> I don't know. Something like the following is already legal:
> 
> f(x)[n] = x * n
> 
> And it does something completly different.

Where would I find information on what this does in the documentation?
Bev in TX




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

Re: Syntax for one-line "nonymous" functions in "declaration style"

[Antoon Pardon]

On 27/03/19 09:21, Alexey Muranov wrote:
> Whey you need a simple function in Python, there is a choice between a
> normal function declaration and an assignment of a anonymous function
> (defined by a lambda-expression) to a variable:
>
>    def f(x): return x*x
>
> or
>
>    f = lambda x: x*x
>
> It would be however more convenient to be able to write instead just
>
>    f(x) = x*x
>
> (like in Haskell and such).
>
> Have this idea been discussed before?
>
> I do not see any conflicts with the existing syntax.   The following
> would also work:

I don't know. Something like the following is already legal:

f(x)[n] = x * n

And it does something completly different.

-- 
Antoon Pardon.

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

Re: Syntax for one-line "nonymous" functions in "declaration style"

[Paul Moore]

On Wed, 27 Mar 2019 at 12:27, Alexey Muranov  wrote:
>
> On mer., mars 27, 2019 at 10:10 AM, Paul Moore 
> wrote:
> > On Wed, 27 Mar 2019 at 08:25, Alexey Muranov
> >  wrote:
> >>
> >>  Whey you need a simple function in Python, there is a choice
> >> between a
> >>  normal function declaration and an assignment of a anonymous
> >> function
> >>  (defined by a lambda-expression) to a variable:
> >>
> >>  def f(x): return x*x
> >>
> >>  or
> >>
> >>  f = lambda x: x*x
> >>
> >>  It would be however more convenient to be able to write instead just
> >>
> >>  f(x) = x*x
> >
> > Why? Is saving a few characters really that helpful? So much so that
> > it's worth adding a *third* method of defining functions, which would
> > need documenting, adding to training materials, etc, etc?
>
> Because i think i would prefer to write it this way.

That's not likely to be sufficient reason for changing a language
that's used by literally millions of people.

> (Almost no new documentation or tutorials would be needed IMHO.)

Documentation would be needed to explain how the new construct worked,
for people who either wanted to use it or encountered it in other
people's code. While it may be obvious to you how it works, it likely
won't be to others, and there will probably be edge cases you haven't
considered that others will find and ask about.

Your interest in improving the language is great, but there are a
great many practical considerations in any change, and if you actually
want your idea to progress, you'll need to be prepared to address
those.

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

Re: Syntax for one-line "nonymous" functions in "declaration style"

[Alexey Muranov]

On mer., mars 27, 2019 at 10:10 AM, Paul Moore  
wrote:
On Wed, 27 Mar 2019 at 08:25, Alexey Muranov 
 wrote:


 Whey you need a simple function in Python, there is a choice 
between a
 normal function declaration and an assignment of a anonymous 
function

 (defined by a lambda-expression) to a variable:

 def f(x): return x*x

 or

 f = lambda x: x*x

 It would be however more convenient to be able to write instead just

 f(x) = x*x


Why? Is saving a few characters really that helpful? So much so that
it's worth adding a *third* method of defining functions, which would
need documenting, adding to training materials, etc, etc?



Because i think i would prefer to write it this way.

(Almost no new documentation or tutorials would be needed IMHO.)

Alexey.


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

Re: Syntax for one-line "nonymous" functions in "declaration style"

[Paul Moore]

On Wed, 27 Mar 2019 at 08:25, Alexey Muranov  wrote:
>
> Whey you need a simple function in Python, there is a choice between a
> normal function declaration and an assignment of a anonymous function
> (defined by a lambda-expression) to a variable:
>
> def f(x): return x*x
>
> or
>
> f = lambda x: x*x
>
> It would be however more convenient to be able to write instead just
>
> f(x) = x*x

Why? Is saving a few characters really that helpful? So much so that
it's worth adding a *third* method of defining functions, which would
need documenting, adding to training materials, etc, etc?

-1 on this.

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

Syntax for one-line "nonymous" functions in "declaration style"

[Alexey Muranov]

Whey you need a simple function in Python, there is a choice between a 
normal function declaration and an assignment of a anonymous function 
(defined by a lambda-expression) to a variable:


   def f(x): return x*x

or

   f = lambda x: x*x

It would be however more convenient to be able to write instead just

   f(x) = x*x

(like in Haskell and such).

Have this idea been discussed before?

I do not see any conflicts with the existing syntax.   The following 
would also work:


   incrementer(m)(n) = n + m

instead of

   incrementer = lambda m: lambda n: n + m

Alexey.


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

Re: what is the difference between one-line-operation and 2-line-operation

[Gary Herron]

On 04/25/2016 07:13 AM, oyster wrote:

for a simple code
[code]
vexList = [1, 2, 3]
print('vexList', list(vexList))

vexList=map(lambda e: e+1, vexList)
print('vexList', list(vexList))

vexList = list(vexList)
print('vexList', list(vexList))

vexList=map(lambda e: e*2,vexList)
print('vexList', list(vexList))
[/code]


py27 says
[quote]
('vexList', [1, 2, 3])
('vexList', [2, 3, 4])
('vexList', [2, 3, 4])
('vexList', [4, 6, 8])
[/quote]

but py34 says
[quote]
vexList [1, 2, 3]
vexList [2, 3, 4]
vexList []
vexList []
[/quote]


The difference in behaviour between Python2 and Python3 is the map 
function.  In P2 it returned a list, while in P3 it returns an 
iterator.  Your code runs through that iterator twice with the list() 
function.  The first time it gets the elements of the list as expected, 
but the second time, the iterator is exhausted and returns no objects.


A simpler example: "b" is a map object (iterator), then list(b) is run 
twice.


>>> a = [1,2,3]
>>> b = map(lambda e: e+1, a)
>>> b

>>> list(b)
[2, 3, 4]
>>> list(b)
[]


I hope that helps.

Gary Herron

--
Dr. Gary Herron
Professor of Computer Science
DigiPen Institute of Technology
(425) 895-4418

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

Re: what is the difference between one-line-operation and 2-line-operation

[Michael Torrie]

On 04/25/2016 08:13 AM, oyster wrote:
> so, what produces this difference between py2 and py3 in nature? is
> there more examples? where can I find the text abiut his difference?

One thing I see is that both your py2 and py3 examples are treating
print as a function.  It's only a function in Py3. By default in Py2
it's a statement.  You passed it a tuple, and that's what it prints.  If
you add:

from __future__ import print_function

then py2 and py3 will behave the same in regards to print.

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

Re: what is the difference between one-line-operation and 2-line-operation

[Jussi Piitulainen]

oyster writes:

- -

> I found
> type(map(lambda e: e, vexList))  is  in py2
> type(map(lambda e: e, vexList)) is  in py3
>
> so, what produces this difference between py2 and py3 in nature? is
> there more examples? where can I find the text abiut his difference?

Yes, there are more ways obtain objects that behave like the map and
filter objects on Python 3. One similar to map and filter is enumerate.

Try iter('foo'), iter((1,2,4)), ..., iter(range(3)). This is used
implicitly by certain Python constructions. Note that range objects
themselves are different.

Open a file for reading: open('example.txt'). You get lines out.

A generator expression: ( "{}".format(x) for x in (1,2,3) ), where the
outer parentheses are for grouping and not always needed.

Define and call a generator function:

def foo(o):
   yield '('
   yield o
   yield ')'

x = foo(31)

'(-31-)' == '-'.join(foo('31'))

You can ask for the next element from any of these, or collect their
remaining elements in a list or tuple, or otherwise iterate or map over
them. They will be consumed when you do so, otherwise they just wait.

They can be huge, even infinite. Best not to collect their contents in a
data structure if they are huge. They trade space for time.
-- 
https://mail.python.org/mailman/listinfo/python-list

what is the difference between one-line-operation and 2-line-operation

[oyster]

for a simple code
[code]
vexList = [1, 2, 3]
print('vexList', list(vexList))

vexList=map(lambda e: e+1, vexList)
print('vexList', list(vexList))

vexList = list(vexList)
print('vexList', list(vexList))

vexList=map(lambda e: e*2,vexList)
print('vexList', list(vexList))
[/code]


py27 says
[quote]
('vexList', [1, 2, 3])
('vexList', [2, 3, 4])
('vexList', [2, 3, 4])
('vexList', [4, 6, 8])
[/quote]

but py34 says
[quote]
vexList [1, 2, 3]
vexList [2, 3, 4]
vexList []
vexList []
[/quote]

if I change the above code in to one line
[code]
vexList = [1, 2, 3]
print('vexList', list(vexList))

vexList=list(map(lambda e: e+1, vexList))
print('vexList', list(vexList))


vexList=map(lambda e: e*2,vexList)
print('vexList', list(vexList))
[/code]

then py27 and py34 get same verList
[quote]
('vexList', [1, 2, 3])
('vexList', [2, 3, 4])
('vexList', [4, 6, 8])
[/quote]

I found 'filter' function behaves likely

I found
type(map(lambda e: e, vexList))  is  in py2
type(map(lambda e: e, vexList)) is  in py3

so, what produces this difference between py2 and py3 in nature? is
there more examples? where can I find the text abiut his difference?

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

Re: Is there a way to set several list elements a same value with one line code

[Denis McMahon]

On Thu, 03 Dec 2015 16:30:25 -0800, Robert wrote:

> Hi,
> 
> I remember that there is a way to set several list elements a same value
> with
>  one line code. Excuse me, I don't remember the accurate syntax on the
>  code snippet. But the basic format looks like this.
> 
> 1. There is a four-element list, such as:
>bb=[[[]],[[]],[[]],[[]]]
> 2. An assignment line is here:
>bb[0]='a'
> 3. Then, all 4 element of bb is set with the above value.
>bb=[['a'],['a'],['a'],['a']]
> 
> The above three line codes are what I guess (I forgot the original
> tutorial
>  now). Do you remember there is such a list application?

bb = [ for i in range()]

will create bb as a list of size whatever elements each of which is 


eg:

>>> bb = [ ['a'] for i in range(4)]
>>> bb
[['a'], ['a'], ['a'], ['a']]
>>> bb = [ 0 for i in range(5)]
>>> bb
[0, 0, 0, 0, 0]
>>> 

-- 
Denis McMahon, denismfmcma...@gmail.com
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Is there a way to set several list elements a same value with one line code

[MRAB]

On 2015-12-04 00:30, Robert wrote:

Hi,

I remember that there is a way to set several list elements a same value with
  one line code. Excuse me, I don't remember the accurate syntax on the code
  snippet. But the basic format looks like this.

1. There is a four-element list, such as:
bb=[[[]],[[]],[[]],[[]]]
2. An assignment line is here:
bb[0]='a'
3. Then, all 4 element of bb is set with the above value.
bb=[['a'],['a'],['a'],['a']]

The above three line codes are what I guess (I forgot the original tutorial
  now). Do you remember there is such a list application?


Do you mean this behaviour:


bb=[[[]]] * 4
print(bb)

[[[]], [[]], [[]], [[]]]

bb[0][0]='a'
print(bb)

[['a'], ['a'], ['a'], ['a']]

?

That's because the bb contains 4 references to the same list.

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

Is there a way to set several list elements a same value with one line code

[Robert]

Hi,

I remember that there is a way to set several list elements a same value with
 one line code. Excuse me, I don't remember the accurate syntax on the code
 snippet. But the basic format looks like this.

1. There is a four-element list, such as: 
   bb=[[[]],[[]],[[]],[[]]]
2. An assignment line is here:
   bb[0]='a'
3. Then, all 4 element of bb is set with the above value.
   bb=[['a'],['a'],['a'],['a']]

The above three line codes are what I guess (I forgot the original tutorial
 now). Do you remember there is such a list application?


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

Re: Is there a way to set several list elements a same value with one line code

[Robert]

On Thursday, December 3, 2015 at 7:59:16 PM UTC-5, MRAB wrote:
> On 2015-12-04 00:30, Robert wrote:
> > Hi,
> >
> > I remember that there is a way to set several list elements a same value 
> > with
> >   one line code. Excuse me, I don't remember the accurate syntax on the code
> >   snippet. But the basic format looks like this.
> >
> > 1. There is a four-element list, such as:
> > bb=[[[]],[[]],[[]],[[]]]
> > 2. An assignment line is here:
> > bb[0]='a'
> > 3. Then, all 4 element of bb is set with the above value.
> > bb=[['a'],['a'],['a'],['a']]
> >
> > The above three line codes are what I guess (I forgot the original tutorial
> >   now). Do you remember there is such a list application?
> >
> Do you mean this behaviour:
> 
> >>> bb=[[[]]] * 4
> >>> print(bb)
> [[[]], [[]], [[]], [[]]]
> >>> bb[0][0]='a'
> >>> print(bb)
> [['a'], ['a'], ['a'], ['a']]
> 
> ?
> 
> That's because the bb contains 4 references to the same list.

Yes! What you post is I want. Thanks.
-- 
https://mail.python.org/mailman/listinfo/python-list

If One Line

[JC]

Hello,

Is it possible in python:

if ((x = a(b,c)) == 'TRUE'):
print x

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

Re: If One Line

[Fetchinson .]

 Is it possible in python:

 if ((x = a(b,c)) == 'TRUE'):
   print x

Nope. Assignment is not allowed in a conditional.

Cheers,
Daniel


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



-- 
Psss, psss, put it down! - http://www.cafepress.com/putitdown
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: If One Line

[Ian Kelly]

On Thu, Dec 25, 2014 at 8:18 AM, JC chalao.a...@gmail.com wrote:

 Hello,

 Is it possible in python:

 if ((x = a(b,c)) == 'TRUE'):
 print x

No, assignments in Python are statements, not expressions.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: If One Line

[Jacob Kruger]

One line assignment is ok, but, seems like you can't perform actions.

#the following will work:
I = 1 if True else 2

#but the following will generate an error:
if I == 1: print(one)

And, not sure if/how to work around that second one myself.

Stay well

Jacob Kruger
Blind Biker
Skype: BlindZA
Roger Wilco wants to welcome you...to the space janitor's closet...

- Original Message - 
From: JC chalao.a...@gmail.com

Newsgroups: comp.lang.python
To: python-list@python.org
Sent: Thursday, December 25, 2014 5:18 PM
Subject: If One Line



Hello,

Is it possible in python:

if ((x = a(b,c)) == 'TRUE'):
print x

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


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

Re: If One Line

[Jacob Kruger]

One line assignment is ok, but, seems like you can't perform actions.

#the following will work:
I = 1 if True else 2

#but the following will generate an error:
if I == 1: print(one)

And, not sure if/how to work around that second one myself.

Stay well

Jacob Kruger
Blind Biker
Skype: BlindZA
Roger Wilco wants to welcome you...to the space janitor's closet...

- Original Message - 
From: JC chalao.a...@gmail.com

Newsgroups: comp.lang.python
To: python-list@python.org
Sent: Thursday, December 25, 2014 5:18 PM
Subject: If One Line



Hello,

Is it possible in python:

if ((x = a(b,c)) == 'TRUE'):
print x

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


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

Re: If One Line

[Skip Montanaro]

I don't get an error.

 I = 1 if True else 2
 if I == 1: print(one)
...
one


What error did you get?

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

Re: If One Line

[Rick Johnson]

On Thursday, December 25, 2014 10:16:54 AM UTC-6, Jacob Kruger wrote:
 One line assignment is ok, but, seems like you can't perform actions.
 
 #the following will work:
 I = 1 if True else 2
 
 #but the following will generate an error:
 if I == 1: print(one)

Only if I is undefined.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: If One Line

[Rick Johnson]

On Thursday, December 25, 2014 9:19:25 AM UTC-6, JC wrote:
 Hello,
 
 Is it possible in python:
 
 if ((x = a(b,c)) == 'TRUE'):
   print x
 
 Thanks.

Could you not simply rephrase:

result = foo()
if result == 'TRUE':
do_something()

Of course, another oddity is fact that you're seemingly using a string to 
represent what should be a Boolean value. 

You may want to check out the contextlib, which allows you to create custom 
context managers utilizing the with statement.

path = 'C:\d\e\f\g.txt
with open(path) as f:
do_something()
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: If One Line

[Jacob Kruger]

Actually more that in the interpreter, it's prompting me with ... as if I had 
left out a closing ) or something, but, suppose it could work fine in an actual 
imported bit of code?

Stay well

Jacob Kruger
Blind Biker
Skype: BlindZA
Roger Wilco wants to welcome you...to the space janitor's closet...

  - Original Message - 
  From: Skip Montanaro 
  To: Jacob Kruger 
  Cc: Python 
  Sent: Thursday, December 25, 2014 6:26 PM
  Subject: Re: If One Line


  I don't get an error.


   I = 1 if True else 2
   if I == 1: print(one)
  ... 
  one
   


  What error did you get?


  Skip



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

Re: If One Line

[Skip Montanaro]

 Actually more that in the interpreter, it's prompting me with ... as if I
had left out a closing ) or something, but, suppose it could work fine in
an actual imported bit of code?

That's how it's supposed to work. Given that Python block structure is
determined by indentation, you need some way to tell the interactive
interpreter that the block is ended.

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

Re: If One Line

[Jacob Kruger]

Ok, makes sense - just slipped same one line if: action bit of code inside a 
function, and worked fine.

Stay well

Jacob Kruger
Blind Biker
Skype: BlindZA
Roger Wilco wants to welcome you...to the space janitor's closet...

  - Original Message - 
  From: Skip Montanaro 
  To: Jacob Kruger 
  Cc: Python 
  Sent: Thursday, December 25, 2014 7:45 PM
  Subject: Re: If One Line



   Actually more that in the interpreter, it's prompting me with ... as if I 
had left out a closing ) or something, but, suppose it could work fine in an 
actual imported bit of code?

  That's how it's supposed to work. Given that Python block structure is 
determined by indentation, you need some way to tell the interactive 
interpreter that the block is ended.

  Skip

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

Re: If One Line

[Jacob Kruger]

Ok, makes sense - just slipped same one line if: action bit of code inside a 
function, and worked fine.

Stay well

Jacob Kruger
Blind Biker
Skype: BlindZA
Roger Wilco wants to welcome you...to the space janitor's closet...

  - Original Message - 
  From: Skip Montanaro 
  To: Jacob Kruger 
  Cc: Python 
  Sent: Thursday, December 25, 2014 7:45 PM
  Subject: Re: If One Line



   Actually more that in the interpreter, it's prompting me with ... as if I 
had left out a closing ) or something, but, suppose it could work fine in an 
actual imported bit of code?

  That's how it's supposed to work. Given that Python block structure is 
determined by indentation, you need some way to tell the interactive 
interpreter that the block is ended.

  Skip

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

Re: If One Line

[alex23]

On 26/12/2014 1:18 AM, JC wrote:

Is it possible in python:

if ((x = a(b,c)) == 'TRUE'):
print x


One approach is to use a function in the condition to do the assignment:

x = None

def assign_to_x(val):
global x
x = val
return val

def a(x, y):
return 'TRUE'

b, c = 'foo', 'bar'

if assign_to_x(a(b,c)) == 'TRUE':
print(x)

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

Re: If One Line

[Steven D'Aprano]

JC wrote:

 Hello,
 
 Is it possible in python:
 
 if ((x = a(b,c)) == 'TRUE'):
 print x

Fortunately, no. Assignment as an expression is an anti-pattern and a bug
magnet.

The above is best written as:

if a(b,c) == 'TRUE':
print 'TRUE'


If you need the result of calling the a() function, possibly because you
also have an else clause:

x = a(b,c)
if x == 'TRUE':
print x
else:
print x, 'is not equal to a TRUE string.'


Your subject line is misleading, since this has nothing to do with If. You
*can* write an If one liner:


if condition() == 'FLAG': print condition equals flag


What you can't do is assignment as an expression:


# None of these work
if (x = func()) == 'RESULT': ...
for item in (x = func()) or sequence: ...
vars = [1, 2, 3, (x = func()), 4]




-- 
Steven

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

Re: If One Line

[Steven D'Aprano]

alex23 wrote:

 On 26/12/2014 1:18 AM, JC wrote:
 Is it possible in python:

 if ((x = a(b,c)) == 'TRUE'):
 print x
 
 One approach is to use a function in the condition to do the assignment:

Let me fix that for you:

/s/approach/bad idea/

All you have done is replace one anti-pattern (assignment as an expression)
with another (use of global variables). Your approach needs to have the
name of the variable hard-coded, if you have three such variables you have
to write three functions, you can't use local variables, and it has all the
disadvantages of global state.

And you don't even save any lines! Instead of a one-liner, you have six
lines!


  x = None
  def assign_to_x(val):
  global x
  x = val
  return val
[...]
  if assign_to_x(a(b,c)) == 'TRUE':
  print(x)

Just because a programming language allows something doesn't make it a good
idea.




-- 
Steven

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

Re: If One Line

[alex23]

On 26/12/2014 1:37 PM, Steven D'Aprano wrote:

One approach is to use a function in the condition to do the assignment:


Let me fix that for you:

/s/approach/bad idea/


I never said it was a _good_ approach ;)


And you don't even save any lines! Instead of a one-liner, you have six
lines!


While I'm _definitely_ not going to advocate for this approach as a 
valid solution, I have to disagree with this being an issue.  While it's 
more lines in the given example, if there were dozens of such 
assignment-within-conditional calls in the same code, the additional 
LOCs become negligible.



Just because a programming language allows something doesn't make it a good
idea.


This is true. But conversely, just because I think something is a bad 
idea doesn't mean someone else can't have found a valid use for it.


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

[issue21063] Touch up one-line descriptions of modules for module index

[Brett Cannon]

Brett Cannon added the comment:

Just the synopsis lines for the modules.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21063
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21063] Touch up one-line descriptions of modules for module index

[Angad Singh]

Angad Singh added the comment:

Interested in taking this up as my first patch -
@brett - are you only talking about the :synopsis: or the occurrence of This 
module at the beginning of the description as well?
-angad

--
nosy: +angad

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21063
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21063] Touch up one-line descriptions of modules for module index

[Angad Singh]

Angad Singh added the comment:

Not a lot of occurrences if I only look at the synopsis. Attaching a diff.
Also saw a weird This subpackage in apiref.rst line 1767. Fix that too?

--
keywords: +patch
Added file: http://bugs.python.org/file34639/this_module_doc_fix.patch

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21063
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21063] Touch up one-line descriptions of modules for module index

[Brett Cannon]

Brett Cannon added the comment:

Sure, if you are just looking for This module you won't find very many 
instances. The bug is more about doing a sweep through *every* module's 
synopsis and just cleaning them up to read better. The this module instance 
for linecache is just an example of why a cleanup would be good to do.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21063
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21063] Touch up one-line descriptions of modules for module index

[Brett Cannon]

New submission from Brett Cannon:

E.g. linecache says This module provides random access to individual lines 
from text files. That's a big awkward and could just drop This module to 
read more easily.

--
assignee: docs@python
components: Documentation
keywords: easy
messages: 214834
nosy: brett.cannon, docs@python
priority: low
severity: normal
stage: needs patch
status: open
title: Touch up one-line descriptions of modules for module index
versions: Python 3.5

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21063
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: How to break long method name into more than one line?

[Herman]

I followed the rule because it was a very good advice. For example,
def test_plus_1Plus1_2(self):
If this test fails, you immediately know that it's testing the plus
method, with 1  and 1 as the arguments, and expect to return 2.
Sticking this rule also means your test cases are small enough, so you
clearly know what you are testing on. Most of the time, the method
name is what you first see when your test fails. Another alternative
is to put meaningful string in each of the assert, which is probably
not practical. You are right, only people who really follow the TDD
method know the good things about it. This naming rule served me very
well.

Tests method should have meaningful name, and the advice by the book
is a meaningful one. I said it's the TDD book because I forgot the
exact title. It's actually called Test Driven: TDD and Acceptance TDD
for Java Developers. I thought it should be popular enough that most
people learned TDD may have heard it also used this naming advice, but
look like i was wrong.

 *The* TDD book? There's only one? Surely not.

 That rule sounds utterly impractical. I can't think of anything to
 recommend it. Like any other function, method or class, tests should have
 meaningful names, but reading the name alone should not necessarily tell
 you *everything* about the function.

 We have len, not len_sequence_or_mapping_int, and similarly it is
 perfectly reasonable to have test_len_empty rather than
 test_len_emptylist_emptystr_emptyunicode_emptydict_emptyset_emptytuple_zero.

 I expect that naming rule was invented by either people who have heard of
 test driven development, but never actually done it, or by people so
 anally-retentive that if they make seven short car trips over an hour,
 they check the tyre pressure, oil and water seven times because the
 manual says to check before *every* trip.

 No offence.

 My advice is to moderate the naming convention of your tests with a good
 dose of common sense and aim for names which are readable rather than
 names that contain everything including the kitchen sink. Imagine you are
 in a technical meeting with some of your fellow programmers, and need to
 ask for help with a failing test. Imagine saying the name of the test
 aloud in a sentence. Does it add clarity to the discussion, or obfuscate
 it?

 People's short term memory can only hold so much (allegedly seven plus
 or minus two), and if the name itself hits that limit, you leave nothing
 left for the rest of the sentence.

 http://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two

 Names should be practically, rather than conforming to some naming rule
 that hurts readability and obfuscates the tests.


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

Re: How to break long method name into more than one line?

[Terry Reedy]

On 3/14/2012 4:53 PM, Herman wrote:

I followed the rule because it was a very good advice. For example,
def test_plus_1Plus1_2(self):


Suppose you want to test that a function call returns a particular 
300-char multiline string?



If this test fails, you immediately know that it's testing the plus
method, with 1  and 1 as the arguments, and expect to return 2.


If you use unittest and the right assert method, the message will say 
more than pass/fail. I believe .AssertEqual(a,b, 'optional message') 
will say that a is not equal to b, and print the optional message.


In addition, if first and second are the exact same type and one of 
list, tuple, dict, set, frozenset or str or any type that a subclass 
registers with addTypeEqualityFunc() the type-specific equality function 
will be called in order to generate a more useful default error message 
(see also the list of type-specific methods).


For instance
assertMultiLineEqual(first, second, msg=None)
Test that the multiline string first is equal to the string second. When 
not equal a diff of the two strings highlighting the differences will be 
included in the error message. This method is used by default when 
comparing strings with assertEqual().



Sticking this rule also means your test cases are small enough,


To me, it makes them too small. I think a test of addition should have 
multiple input-output pairs. Besides that, a single test output object 
may need to pass multiple conditions to pass. Putting them all in a 
single large conjuction would obscure which is not passing.


However, anything is better than no tests.

--
Terry Jan Reedy

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

Re: How to break long method name into more than one line?

[Jean-Michel Pichavant]

Chris Angelico wrote:

Just never treat them as laws of physics (in
Soviet Physics, rules break you!).

ChrisA
  


hum ...
I wonder how this political message is relevant to the OP problem.

JM

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