[issue46167] Parse assert (x == y, "Descriptive text") as statement params instead of a tuple

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

I created a PEP to formally propose the change:

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

--

___
Python tracker 

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

[issue46167] Parse assert (x == y, "Descriptive text") as statement params instead of a tuple

[Guido van Rossum]

Guido van Rossum  added the comment:

You don’t have to use the new feature. But people expect it to work.

--

___
Python tracker 

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

[issue46167] Parse assert (x == y, "Descriptive text") as statement params instead of a tuple

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

For very long expression or very long message you can add parentheses around 
the expression or message. Black will format it as:

assert (
very very long
expression
), (
"very very long "
"message"
)

With the proposed feature it will be:

assert (
very very long
expression,
"very very long "
"message",
)

It saves one line, but the border between an expression and a message is blur. 
Since they are separated by a comma at the end of line and all lines have the 
same indentation it looks less readable to me.

Note also that Black adds a comma after message.

--

___
Python tracker 

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

[issue46167] Parse assert (x == y, "Descriptive text") as statement params instead of a tuple

[Pablo Galindo Salgado]

Change by Pablo Galindo Salgado :


--
keywords: +patch
pull_requests: +28465
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/30247

___
Python tracker 

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

[issue46167] Parse assert (x == y, "Descriptive text") as statement params instead of a tuple

[Guido van Rossum]

Guido van Rossum  added the comment:

I like the lookahead. We could also make the comma and the message mandatory 
when inside parentheses:

| 'assert' '(' a=expression ',' b=expression [','] ')' &(NEWLINE | ';')
| 'assert' a=expression b=[',' z=expression { z }]

(And probably add an "invalid" rule to cover tuples with 0, 1, 3 or more 
elements.)

--

___
Python tracker 

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

[issue46167] Parse assert (x == y, "Descriptive text") as statement params instead of a tuple

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

Another possibility is actually handled this in the compiler:

if we see an assert with a tuple of two elements, we can assume is basically in 
the form that we want and proceed as if is in the form
assert A, B

This also feels a bit hacky because the AST is somehow wrong as the assert node 
is already prepared to differentiate these two cases.

--

___
Python tracker 

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

[issue46167] Parse assert (x == y, "Descriptive text") as statement params instead of a tuple

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

We could do this, but feels a bit hacky:

| 'assert' '(' a=expression b=[',' z=expression { z }] ')' &(NEWLINE | ';')
| 'assert' a=expression b=[',' z=expression { z }]

--

___
Python tracker 

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

[issue46167] Parse assert (x == y, "Descriptive text") as statement params instead of a tuple

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

> We managed to do this for 'with' so it should be possible here too, I'd 
> think. The "committing" token would be the newline following the close 
> parenthesis.


I am not so sure is that inmediate. Changing the assert statement from:

 'assert' a=expression b=[',' z=expression { z }]

to

| 'assert' '(' a=expression b=[',' z=expression { z }] ')'
| 'assert' a=expression b=[',' z=expression { z }] 

will render this invalid:

assert (a, b) <= c, "something"

The reason is that it will parse the (a, b) as the assert statement eagerly and 
then it will fail to parse the rest.

--

___
Python tracker 

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

[issue46167] Parse assert (x == y, "Descriptive text") as statement params instead of a tuple

[Guido van Rossum]

Guido van Rossum  added the comment:

We managed to do this for 'with' so it should be possible here too, I'd think. 
The "committing" token would be the newline following the close parenthesis.

Serhiy: the benefit is when you want to split it across two lines, e.g.

assert (a_very_long_condition(),
"A Very Long Message")

I know you can do this using backslash, e..

assert a_very_long_condition(), \
"A Very Long Message"

but there's a strong cultural rejection of backslash for line splitting (it's 
in PEP 8 and engrained in many people's brains) and it's just so natural to use 
parentheses -- they work for 'import', 'with', function calls, 'if', etc.

--

___
Python tracker 

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

[issue46167] Parse assert (x == y, "Descriptive text") as statement params instead of a tuple

[Raymond Hettinger]

Raymond Hettinger  added the comment:

> can we finally get rid of this language wart

Yes, please.  This is a pretty bad pitfall.

I've seen this happen to people who've been conditioned by other languages to 
think of assert() as a macro or function:

assert(sometest, somemessage)

--
nosy: +rhettinger

___
Python tracker 

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

[issue46167] Parse assert (x == y, "Descriptive text") as statement params instead of a tuple

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
nosy: +gvanrossum, serhiy.storchaka

___
Python tracker 

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

[issue46167] Parse assert (x == y, "Descriptive text") as statement params instead of a tuple

[Gregory P. Smith]

Gregory P. Smith  added the comment:

It's not about an advantage, it's about removing the problem of what edit to 
make when working on


assert 
thing_that_has_a_meaningful_name.methods_have_good_names(value_from_somewhere) 
== other_thing_that_is_meaningful, "Description of what the issue is if this 
fails for humans, as if the names weren't enough"

and making that fit within whatever line length limit your codebase has.

put () in the wrong place and it triggers the long standing Python wart or 
parsing as a tuple.

rather than warn about the syntax wart, we should just do the thing code 
authors want in the first place.

--

___
Python tracker 

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

[issue46167] Parse assert (x == y, "Descriptive text") as statement params instead of a tuple

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

I can try to prototype something in the parser to see how it looks and work on 
the pep if everything looks ok.

Parentheses are a bit tricky in general as backtracking ends causing all sorts 
of tricky situations with custom syntax errors as the parser needs to 
distinguish between function calls, tuple construction and grouping so that's 
the only dangerous situation I can think of

--
nosy:  -gvanrossum, serhiy.storchaka

___
Python tracker 

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

[issue46167] Parse assert (x == y, "Descriptive text") as statement params instead of a tuple

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

It does not need any change in parser, it can be done in the code generator 
which currently explicitly warns about such ambiguity.

Although it needs changes in formal grammar which will be more complex.

But what is a benefit? What is an advantage of writing

   assert (thing, description)

instead of

   assert thing, description

?

--
nosy: +gvanrossum, serhiy.storchaka

___
Python tracker 

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

[issue46167] Parse assert (x == y, "Descriptive text") as statement params instead of a tuple

[Sergei Lebedev]

Change by Sergei Lebedev :


--
nosy: +slebedev

___
Python tracker 

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

[issue46167] Parse assert (x == y, "Descriptive text") as statement params instead of a tuple

[Gregory P. Smith]

New submission from Gregory P. Smith :

Now that we have a shiny new parser, can we finally get rid of this language 
wart:

assert thing, description  # works as intended

assert (thing, description)  # always True as non-empty tuples are Truthy

This most often happens when extending thing or description beyond a single 
line on assert statements as () are the natural way to do that and as it is 
with assert being a statement, knowing specifically where to place the ()s to 
not fall into the pit of snakes of unintentionally nerfing your assertion to be 
an always true tuple is hard for human authors.

This would obsolete the pylint error about tuple assertion and enable more 
natural assert use.

py.test framework users would presumably rejoice as well.


This parsing change would need a PEP.  I fail to see any obvious downsides 
though.

--
components: Parser
messages: 409101
nosy: gregory.p.smith, lys.nikolaou, pablogsal
priority: normal
severity: normal
status: open
title: Parse assert (x == y, "Descriptive text") as statement params instead of 
a tuple
versions: Python 3.11

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

[issue43753] [C API] Add Py_Is(x, y) and Py_IsNone(x) functions

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 8d3e7eff0936926554db6162c992af5829dc8160 by Victor Stinner in 
branch 'main':
bpo-43753: _operator.is_() uses Py_Is() (GH-28641)
https://github.com/python/cpython/commit/8d3e7eff0936926554db6162c992af5829dc8160


--

___
Python tracker 

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

[issue43753] [C API] Add Py_Is(x, y) and Py_IsNone(x) functions

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +27009
pull_request: https://github.com/python/cpython/pull/28641

___
Python tracker 

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

[issue44526] Doc typo in "What’s New In Python 3.10" (x/y-axis)

[Pablo Galindo Salgado]

Change by Pablo Galindo Salgado :


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

[issue44526] Doc typo in "What’s New In Python 3.10" (x/y-axis)

[Joannah Nanjekye]

Joannah Nanjekye  added the comment:

I mean intended wording

--

___
Python tracker 

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

[issue44526] Doc typo in "What’s New In Python 3.10" (x/y-axis)

[Joannah Nanjekye]

Joannah Nanjekye  added the comment:

Since this is the intended behavior, we can just close the issue.

--
nosy: +nanjekyejoannah

___
Python tracker 

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

[issue44526] Doc typo in "What’s New In Python 3.10" (x/y-axis)

[Brandt Bucher]

Brandt Bucher  added the comment:

I don’t think this is a typo.

When x is 0, the point resides somewhere upon the vertical y axis. When y is 0, 
the point resides somewhere upon the horizontal x axis.

Try plotting the points (0, 1) and (1, 0), for example.

--

___
Python tracker 

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

[issue44526] Doc typo in "What’s New In Python 3.10" (x/y-axis)

[Brandt Bucher]

Change by Brandt Bucher :


--
nosy: +brandtbucher

___
Python tracker 

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

[issue44526] Doc typo in "What’s New In Python 3.10" (x/y-axis)

[Jack DeVries]

Jack DeVries  added the comment:

@serif2 nice catch!

--

___
Python tracker 

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

[issue44526] Doc typo in "What’s New In Python 3.10" (x/y-axis)

[Jack DeVries]

Change by Jack DeVries :


--
keywords: +patch
nosy: +jack__d
nosy_count: 2.0 -> 3.0
pull_requests: +25511
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/26944

___
Python tracker 

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

[issue44526] Doc typo in "What’s New In Python 3.10" (x/y-axis)

[serif]

New submission from serif :

Page:

What’s New In Python 3.10
https://docs.python.org/3.10/whatsnew/3.10.html

Section:

PEP 634: Structural Pattern Matching
Patterns and classes

In the example code, x and y in the printed messages are swapped.

case Point(x=0, y=y):
print(f"Y={y} and the point is on the y-axis.")
case Point(x=x, y=0):
print(f"X={x} and the point is on the x-axis.")

Should be:

case Point(x=0, y=y):
print(f"Y={y} and the point is on the x-axis.")
case Point(x=x, y=0):
print(f"X={x} and the point is on the y-axis.")

--
assignee: docs@python
components: Documentation
messages: 396640
nosy: docs@python, serif2
priority: normal
severity: normal
status: open
title: Doc typo in "What’s New In Python 3.10" (x/y-axis)
versions: Python 3.10

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

[issue43753] [C API] Add Py_Is(x, y) and Py_IsNone(x) functions

[STINNER Victor]

STINNER Victor  added the comment:

Well, nobody came up with a better definition, so let's go with:

"Test if the x object is the y object, the same as x is y in Python."

Thanks for the feedback and reviews! Py_Is(x, y), Py_IsNone(x), Py_IsTrue(x) 
and Py_IsFalse(x) are now part of Python 3.10 C API.

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

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

[issue43753] [C API] Add Py_Is(x, y) and Py_IsNone(x) functions

[STINNER Victor]

STINNER Victor  added the comment:

Carl:
> Just chiming in to say that for PyPy this API would be extremely useful, 
> because PyPy's "is" is not implementable with a pointer comparison on the C 
> level (due to unboxing we need to compare integers, floats, etc by value). 
> Right now, C extension code that compares pointers is subtly broken and 
> cannot be fixed by us.

Can you come with a sentence that I can put in the documentation to explain 
that Py_Is() is written for interoperability with other Python implementations?

--

___
Python tracker 

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

[issue43753] [C API] Add Py_Is(x, y) and Py_IsNone(x) functions

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 09bbebea163fe7303264cf4069c51d4d2f22fde4 by Victor Stinner in 
branch 'master':
bpo-43753: Add Py_Is() and Py_IsNone() functions (GH-25227)
https://github.com/python/cpython/commit/09bbebea163fe7303264cf4069c51d4d2f22fde4


--

___
Python tracker 

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

[issue43753] [C API] Add Py_Is(x, y) and Py_IsNone(x) functions

[STINNER Victor]

STINNER Victor  added the comment:

> I tried applying this API on an extension, and I found the code to be 
> slightly less readable for the "is not" cases.

FYI you can try upgrade_pythoncapi.py on your project using the following PR to 
update code to use Py_IsNone/Py_IsTrue/Py_IsFalse:
https://github.com/pythoncapi/pythoncapi_compat/pull/8

For example, use "upgrade_pythoncapi.py -o Py_Is directory/" or 
"upgrade_pythoncapi.py -o Py_Is file.c".

--

___
Python tracker 

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

[issue43753] [C API] Add Py_Is(x, y) and Py_IsNone(x) functions

[Erlend Egeberg Aasland]

Erlend Egeberg Aasland  added the comment:

> I would prefer keep the C API small.

Yes, I see the value of that as well.

I tried applying this API on an extension, and I found the code to be slightly 
less readable for the "is not" cases.

--

___
Python tracker 

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

[issue43753] [C API] Add Py_Is(x, y) and Py_IsNone(x) functions

[STINNER Victor]

STINNER Victor  added the comment:

> I'd also prefer a Py_IsNotNone() because it's more explicit than !Py_IsNone()

I would prefer keep the C API small. I don't think that we need to duplicate 
all functions testing for something. We provide PyTuple_Check(obj) but we don't 
provide PyTuple_NotCheck(obj) for example.

IMO !Py_IsNone(obj) makes perfectly sense in Python.

Also, "x == Py_None" is more common than "x != Py_None".

--

___
Python tracker 

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

[issue43753] [C API] Add Py_Is(x, y) and Py_IsNone(x) functions

[Erlend Egeberg Aasland]

Erlend Egeberg Aasland  added the comment:

I'd also prefer a Py_IsNotNone() because it's more explicit than !Py_IsNone(); 
the exclamation mark can be easily missed when reading/writing code, IMO.

Just my 2 cents.

--
nosy: +erlendaasland

___
Python tracker 

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

[issue43753] [C API] Add Py_Is(x, y) and Py_IsNone(x) functions

[STINNER Victor]

STINNER Victor  added the comment:

Mark:
> `is` is not well defined except for a small set of values, so the docs for 
> `Py_Is` would have to so vague as to be worthless, IMO.

I don't propose to change the "is" operator semantic: Py_Is(x, y) is C would 
behave *exaclty* as "x is y" in Python.

Check my implementation: the IS_OP bytecode uses directly Py_Is().

--

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

[issue43753] [C API] Add Py_Is(x, y) and Py_IsNone(x) functions

[STINNER Victor]

STINNER Victor  added the comment:

PR 25227: I reimplemented Py_Is() as a macro and I added unit tests.

Other added functions simply call Py_Is(), example:

#define Py_IsNone(x) Py_Is(x, Py_None)

--

___
Python tracker 

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

[issue43753] [C API] Add Py_Is(x, y) and Py_IsNone(x) functions

[Raymond Hettinger]

Raymond Hettinger  added the comment:

> Just chiming in to say that for PyPy this API would be extremely useful

Thanks for that input. Given that there would be some value add, I withdraw my 
objection.

> I proposed to declare it as a "static inline" function,
> but I'm fine with a macro as well.

Let's use a macro then because inlining in guaranteed and we don't have to be 
on the lookout for failures to inline.

--

___
Python tracker 

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

[issue43753] [C API] Add Py_Is(x, y) and Py_IsNone(x) functions

[Carl Friedrich Bolz-Tereick]

Carl Friedrich Bolz-Tereick  added the comment:

Just chiming in to say that for PyPy this API would be extremely useful, 
because PyPy's "is" is not implementable with a pointer comparison on the C 
level (due to unboxing we need to compare integers, floats, etc by value). 
Right now, C extension code that compares pointers is subtly broken and cannot 
be fixed by us.

--
nosy: +Carl.Friedrich.Bolz

___
Python tracker 

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

[issue43753] [C API] Add Py_Is(x, y) and Py_IsNone(x) functions

[STINNER Victor]

STINNER Victor  added the comment:

> Also, there is too much faith in functions marked as "inline" always being 
> inlined.

I proposed to declare it as a "static inline" function, but I'm fine with a 
macro as well. I mostly care about the API: call "Py_Is()", not really about 
the exact implementation. In practice, for now, Py_Is(x, y) will continue to be 
compiled as "x == y".

--

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

[issue43753] [C API] Add Py_Is(x, y) and Py_IsNone(x) functions

[STINNER Victor]

STINNER Victor  added the comment:

> For any sane design of tagged pointers, `x == y` (in C) will work fine.

I wrote a proof-of-concept for using tagged pointners in CPython:
https://github.com/vstinner/cpython/pull/6

"The PR is large because of the first changes which add Py_IS_NONE(), 
Py_IS_TRUE() and Py_IS_FALSE() macros."

For backward compatibility, I added a function to get a concrete Python object 
from a tagged pointer: the True as a tagged pointer becomes (PyObject 
*)&_Py_TrueStruct concrete object. Py_IS_TRUE() has to check for both values: 
tagged pointer or &_Py_TrueStruct (don't look at my exact implementation, it's 
wrong ;-)).

In a perfect world, there would be no backward compatibility and you would 
never have to create Python objects from a tagged pointer.

The other problem is that the stable ABI exposes "Py_True" as "&_Py_TrueStruct" 
and so C extensions built with the stable ABI uses "&_Py_TrueStruct", not the 
tagged pointer.

See also bpo-39511 which discuss solutions for these problems.

--

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

[issue43753] [C API] Add Py_Is(x, y) and Py_IsNone(x) functions

[Mark Shannon]

Mark Shannon  added the comment:

For any sane design of tagged pointers, `x == y` (in C) will work fine.

`is` is not well defined except for a small set of values, so the docs for 
`Py_Is` would have to so vague as to be worthless, IMO.

--
nosy: +Mark.Shannon

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

[issue43753] [C API] Add Py_Is(x, y) and Py_IsNone(x) functions

[Mark Dickinson]

Change by Mark Dickinson :


--
nosy: +mark.dickinson

___
Python tracker 

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

[issue43753] [C API] Add Py_Is(x, y) and Py_IsNone(x) functions

[hai shi]

Change by hai shi :


--
nosy: +shihai1991

___
Python tracker 

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

[issue43753] [C API] Add Py_Is(x, y) and Py_IsNone(x) functions

[Raymond Hettinger]

Change by Raymond Hettinger :


--
nosy: +pablogsal, tim.peters

___
Python tracker 

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

[issue43753] [C API] Add Py_Is(x, y) and Py_IsNone(x) functions

[Raymond Hettinger]

Raymond Hettinger  added the comment:

> Right now, there is no benefit for CPython.

Please don't this until we have a clear demonstrable benefit.  As it stands 
now, this is all cost and no benefit.

Adding unnecessary abstraction layers just makes it more difficult for people 
to learn to be core devs.  Also, it will likely result in a lot of pointless 
code churn where each change carries a risk of a new bug being introduced.

The notion of pointer comparison is so fundamental to C code that it is counter 
productive to try to abstract it away.  It isn't much different than saying 
that every instance of "a + b" should be abstracted to "add(a, b)" and every 
"a[b]" should be abstracted to "index_lookup(a, b)" on the hope that maybe it 
might someday be helpful for PyPy or HPy even though they have never requested 
such a change.

>From my own point of view, these need abstractions just make it harder to tell 
>what code is actually doing.  Further, it will just lead to wasting everyone's 
>time in code reviews where the reviewer insists on the applying the new inline 
>function and there is confusion about whether two pointers are generic 
>pointers or python object pointers, each with their own comparison technique.

Also, there is too much faith in functions marked as "inline" always being 
inlined. Compilers get to make their own choices and under some circumstances 
will not inline, especially for cross module calls.  This risks taking code 
that is currently obviously fast and occasionally, invisibility slowing it down 
massively — from a step that is 1 cycle at most and is sometimes zero cost to a 
step that involves an actual function call, possibly needing to save and 
restore registers.

Lastly, the API changes aren't just for you or the standard library.  In 
effect, you're telling the entire ecosystem of C extensions that they are doing 
it wrong.  Almost certainly, some will follow this path and some won't, further 
fracturing the ecosystem.

--
nosy: +rhettinger

___
Python tracker 

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

[issue43753] [C API] Add Py_Is(x, y) and Py_IsNone(x) functions

[STINNER Victor]

STINNER Victor  added the comment:

Py_IS_TYPE(obj, type) was added to Python 3.9 by bpo-39573:
https://docs.python.org/dev/c-api/structures.html#c.Py_IS_TYPE

commit d905df766c367c350f20c46ccd99d4da19ed57d8
Author: Dong-hee Na 
Date:   Fri Feb 14 02:37:17 2020 +0900

bpo-39573: Add Py_IS_TYPE() function (GH-18488)

Co-Author: Neil Schemenauer 

It's currently implemented as:

static inline int _Py_IS_TYPE(const PyObject *ob, const PyTypeObject *type) {
return Py_TYPE(ob) == type;
}
#define Py_IS_TYPE(ob, type) _Py_IS_TYPE(_PyObject_CAST_CONST(ob), type)

--

___
Python tracker 

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

[issue43753] [C API] Add Py_IS(x, y) and Py_IsNone(x) functions

[STINNER Victor]

Change by STINNER Victor :


--
title: [C API] Add Py_IS(x, y) macro -> [C API] Add Py_IS(x, y) and 
Py_IsNone(x) functions

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

[issue43753] [C API] Add Py_Is(x, y) and Py_IsNone(x) functions

[STINNER Victor]

Change by STINNER Victor :


--
title: [C API] Add Py_IS(x, y) and Py_IsNone(x) functions -> [C API] Add 
Py_Is(x, y) and Py_IsNone(x) functions

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

[issue43753] [C API] Add Py_IS(x, y) macro

[STINNER Victor]

Change by STINNER Victor :


--
keywords: +patch
pull_requests: +23964
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/25227

___
Python tracker 

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

[issue43753] [C API] Add Py_IS(x, y) macro

[STINNER Victor]

STINNER Victor  added the comment:

Python has more singletons. In C:

* Py_NotImplemented: NotImplemented
* Py_Ellipsis: Ellipsis

But I don't think that "x == NotImplemented" is common enough to justify a new 
function.

--

___
Python tracker 

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

[issue43753] [C API] Add Py_IS(x, y) macro

[STINNER Victor]

New submission from STINNER Victor :

I propose to add at least Py_Is(x, y) function to the Python C API which would 
be simply implemented as:

static inline int Py_Is(PyObject *x, PyObject *y) { return (x == y); }

Right now, there is no benefit for CPython. The idea is to prepare the CPython 
code base for future optimization, like tagged pointers. It may help PyPy. It 
can also help to prepare C extensions to migrate to HPy, since HPy requires to 
use HPy_Is(ctx, x, y): "x == y" (where x and y types is HPy) fails with a 
compiler error with HPy.

--

CPython uses reference counting and singletons like None and False. The "x is 
y" operator in Python is implemented with the IS_OP opcode implemented in 
Python/ceval.c as:

case TARGET(IS_OP): {
PyObject *right = POP();
PyObject *left = TOP();
int res = (left == right)^oparg;
PyObject *b = res ? Py_True : Py_False;
Py_INCREF(b);
SET_TOP(b);
Py_DECREF(left);
Py_DECREF(right);
PREDICT(POP_JUMP_IF_FALSE);
PREDICT(POP_JUMP_IF_TRUE);
DISPATCH();
}

In short, "x is y" in Python simply compares directly PyObject* pointer values 
in C: "x == y" where x and y are PyObject* pointers.

PyPy doesn't use reference counting and so implements "x is y" differently: 
id(x) == id(y) if I understood correctly. In PyPy, id(obj) is more complex than 
simply getting the object memory address. For example, id(1) is always 17 in 
PyPy (on Linux/x86-64 at least).

At the C API level, using "x == y" to check if y object "is" x object doesn't 
work well with PyPy object models. Moreover, "x == Py_None" doesn't work if 
None is stored as a tagged pointer in CPython.

--

Maybe we can also add functions to check if an object is a singleton:

* Py_IsNone(x): x == Py_None
* Py_IsTrue(x): x == Py_True
* Py_IsFalse(x): x == Py_False

See also bpo-39511 "[subinterpreters] Per-interpreter singletons (None, True, 
False, etc.)" which may need to replace Py_None singleton with Py_GetNone(). 
IMO it makes more sense to call Py_IS_NONE(x) function to express that code is 
run, rather than writing "x == Py_None" as if Py_None is and will always be a 
variable directly accesssible.

Py_IS_TRUE() name sounds like PyObject_IsTrue(). Can it be an issue? Can 
someone come with a better name?

--
components: C API
messages: 390358
nosy: vstinner
priority: normal
severity: normal
status: open
title: [C API] Add Py_IS(x, y) macro
versions: Python 3.10

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

[issue39375] Document os.environ[x] = y and os.putenv() as thread unsafe

[Eryk Sun]

Change by Eryk Sun :


--
type:  -> enhancement
versions: +Python 3.10 -Python 2.7, Python 3.7

___
Python tracker 

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

Re: To check if number is in range(x,y)

[Tim Chase]

On 2020-12-14 21:21, Schachner, Joseph wrote:
> >>> r = range(10)  
> So r is a list containing 0, 1, 2, 3, 4, 5, 6, 7, 8, 9

In Python 3.x, r is *not* a list.  It is a custom object/class.

>   >>> 2 in r  
>   True
> As expected.

I'm not sure what your replies are suggesting here.  I demonstrated
the OP's edge-cases, especially cases that one might experience coming
from other languages.

>   >>> r = range(1, 10, 2)
>   >>> 2 in r  
>   False
>   >>> list(r)  
>   [1, 3, 5, 7, 9]
> Well, yes, because you started the range at 1.  Start at 0 and
> you'd get 0, 2, 4, 6, 8.

Had I done this, for pedagogical value I would have checked for 3
then:

  >>> r = range(0, 10, 2)
  >>> 3 in r
  False

The goal was to demonstrate that the resulting range object, when
given a step-size of something than the default 1, will have holes in
it, and as such, testing for membership in one of those holes would
fail.  Showing successful membership wouldn't add any value.

> "It also doesn't automatically convert from the string inputs
> you're getting from the input() function:
> 
>   >>> s = "5"
>   >>> s in r  
>   False
>   >>> int(s) in r  
>   True"
> You have just discovered that Python, although it is dynamically
> typed, is STRICTLY typed. 

No, not just now discovered something I've long known.  The goal was
to provide an example for the OP of this exact case since their
original code attempted to use the string returned from input() and
used it as-is (without converting to int) for this exact sort of
comparison.

> Another way to say this: you have discovered that Python isn't the
> same as BASIC.

Additionally, (many? all? some?) BASICs have similarly strict typing.
For example, reaching for the BASIC that I used in the 80s:

  ] S$ = "HELLO"
  ] I = 42
  ] PRINT S$ + I
  ?TYPE MISMATCH ERROR

> "Additionally, note that the endpoint of the range is exclusive so
>   >>> r = range(1, 10)
>   >>> 10 in r  
>   False"
> 
> I don't have to note that

My comment was directed at the OP.  Unless you are Bischoop, that's
not you.

> Now suppose that the end integer was not excluded. Each range call
> would produce 11 integers. 

The goal was to show the OP that while some languages (such as the
aforementioned BASIC) have *inclusive* ranges:
  
  ] FOR I = 1 to 3 : PRINT I : NEXT
  1
  2
  3

Python's ranges are exclusive.  Because a language could have either,
the example demonstrated Python's choice.

> I recommend you read Python 101 and when you've done that, read
> Python 201.   I think they are very good "learn Python" books. If
> you're surprised that the end point is not included in range, you
> need to read Python 101.

Your condescending replies bark up the wrong tree.

-tkc






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

Re: To check if number is in range(x,y)

[Dan Stromberg]

On Mon, Dec 14, 2020 at 3:07 PM Dan Stromberg  wrote:

>
> On Mon, Dec 14, 2020 at 1:23 PM Schachner, Joseph <
> joseph.schach...@teledyne.com> wrote:
>
>> >>> r = range(10)
>> So r is a list containing 0, 1, 2, 3, 4, 5, 6, 7, 8, 9
>>
> To get a list of consecutive int's, you can use, for EG:
> r = list(range(10))
>

Oh, and range() returning a (lazy) range is a new thing.  In Python 2.x,
range returned a list and you had to use xrange to get laziness.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: To check if number is in range(x,y)

[Dan Stromberg]

On Mon, Dec 14, 2020 at 1:23 PM Schachner, Joseph <
joseph.schach...@teledyne.com> wrote:

> >>> r = range(10)
> So r is a list containing 0, 1, 2, 3, 4, 5, 6, 7, 8, 9
>
To get a list of consecutive int's, you can use, for EG:
r = list(range(10))
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: To check if number is in range(x,y)

[2QdxY4RzWzUUiLuE]

On 2020-12-14 at 21:21:43 +,
"Schachner, Joseph"  wrote:

> >>> r = range(10)
> So r is a list containing 0, 1, 2, 3, 4, 5, 6, 7, 8, 9

In a number of ways, r behaves as if it were that list, but r is
definitely not that list:

>>> r = range(10)
>>> type(r)

>>> l = [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
>>> type(l)

>>> r == l
False

> You have just discovered that Python, although it is dynamically
> typed, is STRICTLY typed.  Another way to say this: you have
> discovered that Python isn't the same as BASIC ...

Citation needed?  I can't speak for every version of BASIC ever, but the
ones I used had separate namespaces for numeric variables and string
variables:  A was a number, A$ was a string, and never the twain shall
meet.  That's strict typing.
-- 
https://mail.python.org/mailman/listinfo/python-list

RE: To check if number is in range(x,y)

[Schachner, Joseph]

>>> r = range(10)
So r is a list containing 0, 1, 2, 3, 4, 5, 6, 7, 8, 9

  >>> 2 in r
  True
As expected.

  >>> 2.5 in r
  False
Also as expected.  If you did int(floor(2.5)) in 5 that would be true.

  >>> r = range(1, 10, 2)
  >>> 2 in r
  False
  >>> list(r)
  [1, 3, 5, 7, 9]
Well, yes, because you started the range at 1.  Start at 0 and you'd get 0, 2, 
4, 6, 8.

"It also doesn't automatically convert from the string inputs you're getting 
from the input() function:

  >>> s = "5"
  >>> s in r
  False
  >>> int(s) in r
  True"
You have just discovered that Python, although it is dynamically typed, is 
STRICTLY typed.  Another way to say this: you have discovered that Python isn't 
the same as BASIC.  Yes, you have to convert strings to int or float, Python 
does not assume you want to if you did not do it. Similarly, you have to do 
something to convert int or float to text.  Python makes it very simple, but 
you have to do it.


"Additionally, note that the endpoint of the range is exclusive so
  >>> r = range(1, 10)
  >>> 10 in r
  False"

I don't have to note that, I KNOW that (as I've demonstrated above), because I 
read a couple of books on Python.  Python range starts on the number you 
specify and does NOT include the end number.
So: range(0,10) is 0 to 9(note that this is 10 integers)
  range(10,20) is 10 to 19(also 10 integers)
  range(20,30) is 20 to 29   (another 10 integers)

Now suppose that the end integer was not excluded. Each range call would 
produce 11 integers.  10, 20, and 30 would occur twice.  Or you'd have to set 
the range limits differently.

I recommend you read Python 101 and when you've done that, read Python 201.   I 
think they are very good "learn Python" books.
If you're surprised that the end point is not included in range, you need to 
read Python 101.

--- Joseph S.



-Original Message-
From: Tim Chase 
Sent: Saturday, December 12, 2020 11:51 AM
To: Bischoop 
Cc: Bischoop ; python-list@python.org
Subject: Re: To check if number is in range(x,y)

On 2020-12-12 15:12, Bischoop wrote:
> I need to check if input number is 1-5. Whatever I try it's not
> working. Here are my aproaches to the problem: https://bpa.st/H62A
>
> What I'm doing wrong and how I should do it?

A range is similar to a list in that it contains just the numbers
listed:

  >>> r = range(10)
  >>> 2 in r
  True
  >>> 2.5 in r
  False
  >>> r = range(1, 10, 2)
  >>> 2 in r
  False
  >>> list(r)
  [1, 3, 5, 7, 9]

It also doesn't automatically convert from the string inputs you're getting 
from the input() function:

  >>> s = "5"
  >>> s in r
  False
  >>> int(s) in r
  True

Additionally, note that the endpoint of the range is exclusive so

  >>> r = range(1, 10)
  >>> 10 in r
  False
  >>> list(r)
  [1, 2, 3, 4, 5, 6, 7, 8, 9]

If you want numeric-range checks, Python provides the lovely double-comparison 
syntax:

  >>> x = 5
  >>> 2 < x < 10
  True
  >>> x = 5.5
  >>> 2 < x < 10
  True
  >>> s = "5"
  >>> 2 < s < 10
  Traceback…
  >>> 2 < int(s) < 10
  True

Hopefully this gives you the hints that you need to troubleshoot.

-tkc






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

Re: To check if number is in range(x,y)

[Bischoop]

On 2020-12-12, Tim Chase  wrote:
>
> Hopefully this gives you the hints that you need to troubleshoot.
>
> -tkc
>
>
>
>

Yes it explains a lot.

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

Re: To check if number is in range(x,y)

[2QdxY4RzWzUUiLuE]

On 2020-12-12 at 10:51:00 -0600,
Tim Chase  wrote:

> If you want numeric-range checks, Python provides the lovely
> double-comparison syntax:
> 
>   >>> x = 5
>   >>> 2 < x < 10
>   True

Not just numbers:

>>> 'm' < 'n' < 'o'
True

>>> 'one' < 'one point five' < 'two'
True

Okay, so the second one is a trap, but you get the idea.  ;-)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: To check if number is in range(x,y)

[Tim Chase]

On 2020-12-12 15:12, Bischoop wrote:
> I need to check if input number is 1-5. Whatever I try it's not
> working. Here are my aproaches to the problem: https://bpa.st/H62A
> 
> What I'm doing wrong and how I should do it?

A range is similar to a list in that it contains just the numbers
listed:

  >>> r = range(10)
  >>> 2 in r
  True
  >>> 2.5 in r
  False
  >>> r = range(1, 10, 2)
  >>> 2 in r
  False
  >>> list(r)
  [1, 3, 5, 7, 9]

It also doesn't automatically convert from the string inputs you're
getting from the input() function:

  >>> s = "5"
  >>> s in r
  False
  >>> int(s) in r
  True

Additionally, note that the endpoint of the range is exclusive so

  >>> r = range(1, 10)
  >>> 10 in r
  False
  >>> list(r)
  [1, 2, 3, 4, 5, 6, 7, 8, 9]

If you want numeric-range checks, Python provides the lovely
double-comparison syntax:

  >>> x = 5
  >>> 2 < x < 10
  True
  >>> x = 5.5
  >>> 2 < x < 10
  True
  >>> s = "5"
  >>> 2 < s < 10
  Traceback…
  >>> 2 < int(s) < 10
  True

Hopefully this gives you the hints that you need to troubleshoot.

-tkc




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

Re: To check if number is in range(x,y)

[Bischoop]

Got it solved here: https://bpa.st/BFJA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: To check if number is in range(x,y)

[Oscar]

In article ,
Bischoop   wrote:
>
>I need to check if input number is 1-5. Whatever I try it's not working.
>Here are my aproaches to the problem: https://bpa.st/H62A
>
>What I'm doing wrong and how I should do it?

You need to learn about types. ;-)

Input returns a string. That string is not in the range you compare it
to. You need to convert it to an int:

choice = int(input.. )

This is assuming you want a whole number. You compare it against the
list of numbers [1, 2, 3, 4, 5]. If 2.4 is also a valid number, you need
a different comparison. 2.4 is not in this list. 

So first you should get your requirements straight.. ;-)
-- 
[J|O|R] <- .signature.gz
-- 
https://mail.python.org/mailman/listinfo/python-list

To check if number is in range(x,y)

[Bischoop]

I need to check if input number is 1-5. Whatever I try it's not working.
Here are my aproaches to the problem: https://bpa.st/H62A

What I'm doing wrong and how I should do it?

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

Re: To check if number is in range(x,y)

[Bischoop]

I've also convert the choice to int() but doesn't help.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: To check if number is in range(x,y)

[Bischoop]

On 2020-12-12, Oscar  wrote:
> In article ,
> Bischoop   wrote:
>>I've also convert the choice to int() but doesn't help.
>
> Oh.. did not read this yet. How did you do this? In both places after
> the input or during the comparison? If so, in which version? Only the
> first version would work. The other two are just plain wrong.

after the input, https://bpa.st/BFJA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: To check if number is in range(x,y)

[Oscar]

In article ,
Bischoop   wrote:
>I've also convert the choice to int() but doesn't help.

Oh.. did not read this yet. How did you do this? In both places after
the input or during the comparison? If so, in which version? Only the
first version would work. The other two are just plain wrong.
-- 
[J|O|R] <- .signature.gz
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue41428] PEP 604 -- Allow writing union types as X | Y

[Guido van Rossum]

Change by Guido van Rossum :


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

[issue41428] PEP 604 -- Allow writing union types as X | Y

[Guido van Rossum]

Guido van Rossum  added the comment:


New changeset 8e1dd55e63d18d40e78d941fc9233d2c77bcd3de by Fidget-Spinner in 
branch 'master':
bpo-41428: Documentation for PEP 604  (gh-22517)
https://github.com/python/cpython/commit/8e1dd55e63d18d40e78d941fc9233d2c77bcd3de


--
nosy: +gvanrossum

___
Python tracker 

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

[issue41428] PEP 604 -- Allow writing union types as X | Y

[Ken Jin]

Change by Ken Jin :


--
nosy: +kj
nosy_count: 4.0 -> 5.0
pull_requests: +21526
pull_request: https://github.com/python/cpython/pull/22517

___
Python tracker 

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

[issue41428] PEP 604 -- Allow writing union types as X | Y

[STINNER Victor]

STINNER Victor  added the comment:

> Now that PR 21515 is landed, we should consider what sections of the 
> docs/spec needs to be updated.

Any update on the documentation?

--

___
Python tracker 

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

[issue41428] PEP 604 -- Allow writing union types as X | Y

[STINNER Victor]

STINNER Victor  added the comment:


New changeset d73cf7ca85fb60b739e671597aabe72cc36d397a by Victor Stinner in 
branch 'master':
bpo-41428: Fix compiler warning in unionobject.c (GH-22416)
https://github.com/python/cpython/commit/d73cf7ca85fb60b739e671597aabe72cc36d397a


--

___
Python tracker 

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

[issue41428] PEP 604 -- Allow writing union types as X | Y

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +21453
pull_request: https://github.com/python/cpython/pull/22416

___
Python tracker 

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

[issue41428] PEP 604 -- Allow writing union types as X | Y

[STINNER Victor]

STINNER Victor  added the comment:


New changeset d67de0a30d76c6a28056bae22fd7d13f2e111b77 by Victor Stinner in 
branch 'master':
bpo-41428: Fix compiler warnings in unionobject.c (GH-22388)
https://github.com/python/cpython/commit/d67de0a30d76c6a28056bae22fd7d13f2e111b77


--

___
Python tracker 

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

[issue41428] PEP 604 -- Allow writing union types as X | Y

[STINNER Victor]

Change by STINNER Victor :


--
keywords: +patch
nosy: +vstinner
nosy_count: 3.0 -> 4.0
pull_requests: +21430
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/22388

___
Python tracker 

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

[issue41428] PEP 604 -- Allow writing union types as X | Y

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

Now that PR 21515 is landed, we should consider what sections of the docs/spec 
needs to be updated.

--

___
Python tracker 

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

[issue41428] PEP 604 -- Allow writing union types as X | Y

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:


New changeset 1b4552c5e8e925f24c15f707050f22c977171125 by Maggie Moss in branch 
'master':
bpo-41428: Implementation for PEP 604 (GH-21515)
https://github.com/python/cpython/commit/1b4552c5e8e925f24c15f707050f22c977171125


--
nosy: +pablogsal

___
Python tracker 

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

[issue39375] Document os.environ[x] = y and os.putenv() as thread unsafe

[Daniel Martin]

Daniel Martin  added the comment:

See also https://bugs.python.org/issue40961 - that bug is not about thread 
safety, but another quirk around env. variable setting that needs to be 
documented in the documentation for os.putenv and os.getenv, and so anyone 
addressing this bug should probably address that one at the same time.

--
nosy: +Daniel Martin

___
Python tracker 

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

[issue41428] PEP 604 -- Allow writing union types as X | Y

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
nosy: +xtreak

___
Python tracker 

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

[issue41428] PEP 604 -- Allow writing union types as X | Y

[Maggie Moss]

New submission from Maggie Moss :

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

--
messages: 374535
nosy: maggiemoss
priority: normal
pull_requests: 20811
severity: normal
status: open
title: PEP 604 -- Allow writing union types as X | Y
type: behavior
versions: Python 3.10

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

[issue39375] Document os.environ[x] = y and os.putenv() as thread unsafe

[Joannah Nanjekye]

Change by Joannah Nanjekye :


--
nosy: +nanjekyejoannah

___
Python tracker 

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

[issue39375] Document os.environ[x] = y and os.putenv() as thread unsafe

[Eryk Sun]

Eryk Sun  added the comment:

> no need to remove that message.  

I was discussing the wrong API. It's not directly relevant that Windows API 
functions that access the process environment are protected by the PEB lock. 
Python primarily uses [_w]environ, a copy of the process environment that's 
managed by the C runtime library (ucrt). os.putenv modifies this environment 
via _wputenv. (Ultimately this syncs with the process environment by calling 
SetEnvironmentVariableW.)

Functions that modify and read ucrt's environment are protected by a lock. But 
there's still a concern if multithreaded code reads or modifies [_w]environ 
concurrent to a _[w]putenv call. Also, [_w]getenv returns a pointer to the 
value in [_w]environ, so it has the same problem. A significant difference, 
however, is that _[w]putenv in ucrt is not POSIX compliant, since it copies the 
caller's string. Also, ucrt has safer [_w]getenv_s and _[w]dupenv_s functions 
that return a copy.

--

___
Python tracker 

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

[issue39375] Document os.environ[x] = y and os.putenv() as thread unsafe

[Gregory P. Smith]

Gregory P. Smith  added the comment:

fwiw, no need to remove that message.  We'll want to make the docs clear that 
this does not apply to Windows.  :)

--

___
Python tracker 

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

[issue39375] Document os.environ[x] = y and os.putenv() as thread unsafe

[Eryk Sun]

Change by Eryk Sun :


--
Removed message: https://bugs.python.org/msg360245

___
Python tracker 

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

[issue39375] Document os.environ[x] = y and os.putenv() as thread unsafe

[Eryk Sun]

Eryk Sun  added the comment:

The warning would not apply to Windows. The environment block is part of the 
Process Environment Block (PEB) record, which is protected by a 
critical-section lock. The runtime library acquires the PEB lock before 
accessing mutable PEB values. For example:

Getting an environment variable:

>>> win32api.GetEnvironmentVariable('foo')

Breakpoint 0 hit
ntdll!RtlQueryEnvironmentVariable:
7ffc`d737a2f0 48895c2408  mov qword ptr [rsp+8],rbx
ss:0094`ec9ef470=

RtlQueryEnvironmentVariable acquires the PEB lock (i.e. ntdll!FastPebLock) 
before getting the value. The lock is passed to RtlEnterCriticalSection in 
register rcx:

0:000> be 2; g

Breakpoint 2 hit
ntdll!RtlEnterCriticalSection:
7ffc`d737b400 4883ec28sub rsp,28h

0:000> kc 3
Call Site
ntdll!RtlEnterCriticalSection
ntdll!RtlQueryEnvironmentVariable
KERNELBASE!GetEnvironmentVariableW

0:000> ?? @rcx == (_RTL_CRITICAL_SECTION *)@@(ntdll!FastPebLock)
bool true

Setting an environment variable:

>>> win32api.SetEnvironmentVariable('foo', 'eggs')

Breakpoint 1 hit
ntdll!RtlSetEnvironmentVar:
7ffc`d73bc7d0 4c894c2420  mov qword ptr [rsp+20h],r9 
ss:0094`ec9ef488=

RtlSetEnvironmentVar acquires the PEB lock before setting the environment 
variable:

0:000> be 2; g

Breakpoint 2 hit
ntdll!RtlEnterCriticalSection:
7ffc`d737b400 4883ec28sub rsp,28h

0:000> kc 3
Call Site
ntdll!RtlEnterCriticalSection
ntdll!RtlSetEnvironmentVar
KERNELBASE!SetEnvironmentVariableW

0:000> ?? @rcx == (_RTL_CRITICAL_SECTION *)@@(ntdll!FastPebLock)
bool true

--
nosy: +eryksun

___
Python tracker 

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

[issue39375] Document os.environ[x] = y and os.putenv() as thread unsafe

[Gregory P. Smith]

Gregory P. Smith  added the comment:

https://bugs.python.org/issue39376 tracks possible interpreter behavior changes.

--

___
Python tracker 

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

[issue39375] Document os.environ[x] = y and os.putenv() as thread unsafe

[Gregory P. Smith]

New submission from Gregory P. Smith :

The underlying API calls made by os.putenv() and os.environ[name] = value 
syntax are not thread safe on POSIX systems.  POSIX _does not have_ any thread 
safe way to access the process global environment.

In a pure Python program, the GIL prevents this from being an issue.  But when 
embedded in a C/C++ program or using extension modules that launch their own 
threads from C, those threads could also make the invalid assumption that they 
can safely _read_ the environment.  Which is a race condition when a Python 
thread is doing a putenv() at the same time.

We should document the danger.

CPython's os module snapshots a copy of the environment into a dict at import 
time (during CPython startup).  But os.environ[] assignment and os.putenv() 
modify the actual process global environment in addition to updating this dict. 
 (If an embedded interpreter is launched from a process with other threads 
already running, even that initial environment reading could be unsafe if the 
larger application has a thread that wrongly assumes it has exclusive 
environment access)

For people modifying os.environ so that the change is visible to child 
processes, we can recommend using the env= parameter on subprocess API calls to 
supply a new environment.

A broader issue of should we be modifying the process global environment state 
at all from os.putenv() and os.environ[] assignment still exists.  I'll track 
that in another issue (to be opened).

--
assignee: docs@python
components: Documentation
messages: 360221
nosy: docs@python, gregory.p.smith
priority: normal
severity: normal
status: open
title: Document os.environ[x] = y and os.putenv() as thread unsafe
versions: Python 2.7, Python 3.7, Python 3.8, Python 3.9

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

[issue29674] Use GCC __attribute__((alloc_size(x, y))) on PyMem_Malloc() functions

[STINNER Victor]

Change by STINNER Victor :


--
resolution:  -> out of date
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

Re: acircle.getCenter() to (x,y) coordinates in Python

[MRAB]

On 2017-12-25 02:42, G Yu wrote:

Ah, I get it now.  I have to store the acircle.getCenter() in a point Point, 
and then access Point.getX() and Point.getY() separately.  It was just that 
middle step that I was missing.  Thanks so much!

It's not strictly true that you _have to_ store the result of 
acircle.getCenter().


You could call it twice:

(acircle.getCenter().getX(), acircle.getCenter().getY())

or you could write a function for it:

def as_cartesian(point):
return point.getX(), point.getY()

and call it:

as_cartesian(acircle.getCenter())

Just pick whatever way makes the most sense.
--
https://mail.python.org/mailman/listinfo/python-list

Re: acircle.getCenter() to (x,y) coordinates in Python

[G Yu]

Ah, I get it now.  I have to store the acircle.getCenter() in a point Point, 
and then access Point.getX() and Point.getY() separately.  It was just that 
middle step that I was missing.  Thanks so much!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: acircle.getCenter() to (x,y) coordinates in Python

[MRAB]

On 2017-12-24 02:31, G Yu wrote:

But your code has:

 moving_circle.move(P_to_R/P_to_E, E_to_R/P_to_E)

so won't that move the circle and change what:

 moving_circle.getCenter()

returns?


Yes, moving the circle changes the value of moving_circle.getCenter(). The problem is 
interpreting the output. The command gives , and I don't know how to determine the x-coordinate of the 
center from that output. This is my problem. I can't translate the .getCenter() 
output to Cartesian coordinates.



The initial point won't change, but that's just where the circle was 
originally.


Are you sure that it doesn't change? Have you printed out 
moving_circle.getCenter().getX() and moving_circle.getCenter().getY() 
and seen that they aren't changing?


Distinguish between the circle's center and the initial center point I declared. My 
program can output the former, but it's in a format that I don't understand: 
.

As for the initial center point (I'll call it moving_circle_*initial*_center 
instead), it won't change at all throughout the program execution.

I need to know the x- and y-coordinates of moving_circle.getCenter() at any 
point in time. I can't use the center of the circle *before* it started moving, 
because that value is static (in other words, 
moving_circle_initial_center.getX() and moving_circle_initial_center.getY() 
never change).


I have already told you how to get the x and y coordinates.

moving_circle.getCenter() returns the centre as a Point object.

That Point object has .getX() and .getY() methods, which return the x 
and y coordinates respectively.

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

Re: acircle.getCenter() to (x,y) coordinates in Python

[Irv Kalb]

> On Dec 23, 2017, at 11:44 AM, G Yu  wrote:
> 
> My program has two circles: one stationary circle, drawn at a random 
> location; and one moving circle, consistently drawn in the same place in the 
> graphics window.
> 
> 
> 
> Currently, acircle.getCenter() outputs this:
> 
> 
> 
> 
> I don't understand/can't use the format that the locations are printed in.
> 
> How do I convert the above format to "usable" Cartesian coordinates?  Or is 
> there a simpler way to solve this problem?
> 
> Thanks!
> -- 
> https://mail.python.org/mailman/listinfo/python-list
> 

I found this document that looks like it described the "graphics" module that 
you are using (it does describe the getCenter call that you showed):

  http://mcsp.wartburg.edu/zelle/python/graphics/graphics.pdf 


If this is the module, then Points are objects, and what you are seeing is the 
memory address of those points.  Section 3.1 of the document describes how you 
can call the getX() and getY() methods on any point to get the x and y values:
getX() Returns the x coordinate of a point. Example: xValue = aPoint.getX()

getY() Returns the y coordinate of a point. Example: yValue = aPoint.getY() 

Therefore, it sounds like you need to take the Point object that you have, and 
call the getX method and alto the getY method to get the coordinates you want.

Hope that helps,

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

Re: acircle.getCenter() to (x,y) coordinates in Python

[Gregory Ewing]

G Yu wrote:

The command gives , and I don't know how to determine the x-coordinate of
the center from that output.


Try this in an interactive session:

   p = circle.getCenter()
   help(p)

This should give you a page of text showing all the attributes
and methods your point object has. Somewhere in there will almost
certainly be something that tells you the coordinates.

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

Re: acircle.getCenter() to (x,y) coordinates in Python

[G Yu]

> But your code has:
> 
>  moving_circle.move(P_to_R/P_to_E, E_to_R/P_to_E)
> 
> so won't that move the circle and change what:
> 
>  moving_circle.getCenter()
> 
> returns?

Yes, moving the circle changes the value of moving_circle.getCenter(). The 
problem is interpreting the output. The command gives , and I don't know how to determine the x-coordinate of the 
center from that output. This is my problem. I can't translate the .getCenter() 
output to Cartesian coordinates.



> The initial point won't change, but that's just where the circle was 
> originally.

> Are you sure that it doesn't change? Have you printed out 
> moving_circle.getCenter().getX() and moving_circle.getCenter().getY() 
> and seen that they aren't changing?

Distinguish between the circle's center and the initial center point I 
declared. My program can output the former, but it's in a format that I don't 
understand: .

As for the initial center point (I'll call it moving_circle_*initial*_center 
instead), it won't change at all throughout the program execution.

I need to know the x- and y-coordinates of moving_circle.getCenter() at any 
point in time. I can't use the center of the circle *before* it started moving, 
because that value is static (in other words, 
moving_circle_initial_center.getX() and moving_circle_initial_center.getY() 
never change).
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: acircle.getCenter() to (x,y) coordinates in Python

[MRAB]

On 2017-12-23 21:30, G Yu wrote:

I did try that.  The problem is that I already declared a point 
moving_object_center = (-555,-555), because that's the point I used as the 
center to draw the moving_object circle itself.  So the 
moving_object_center.getX() will return -555 no matter what I do.


But your code has:

moving_circle.move(P_to_R/P_to_E, E_to_R/P_to_E)

so won't that move the circle and change what:

moving_circle.getCenter()

returns?


That's why I need to calculate the center using some attribute of the circle, 
not the center point - because the circle moves, but the point that I declared 
as the initial center point will never change.

The initial point won't change, but that's just where the circle was 
originally.


Are you sure that it doesn't change? Have you printed out 
moving_circle.getCenter().getX() and moving_circle.getCenter().getY() 
and seen that they aren't changing?



I'm not totally sure what you mean by "graphics library", but these are all the 
import statements I'm using at the beginning.

from graphics import *
import datetime
import random
from math import *

As far as I know, "graphics" isn't part of the standard CPython 
distribution from www.python.org. At least, I have CPython 3.6 for 
Windows, and "graphics" doesn't appear to be present.

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

Re: acircle.getCenter() to (x,y) coordinates in Python

[G Yu]

I did try that.  The problem is that I already declared a point 
moving_object_center = (-555,-555), because that's the point I used as the 
center to draw the moving_object circle itself.  So the 
moving_object_center.getX() will return -555 no matter what I do.

That's why I need to calculate the center using some attribute of the circle, 
not the center point - because the circle moves, but the point that I declared 
as the initial center point will never change.

I'm not totally sure what you mean by "graphics library", but these are all the 
import statements I'm using at the beginning.

from graphics import *
import datetime
import random
from math import *
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: acircle.getCenter() to (x,y) coordinates in Python

[MRAB]

On 2017-12-23 19:44, G Yu wrote:

My program has two circles: one stationary circle, drawn at a random location; 
and one moving circle, consistently drawn in the same place in the graphics 
window.

The moving circle moves towards the stationary one.  However, when the moving 
circle hits the stationary one (when the x-coordinates of the circles' centers 
are equal), I want the moving circle to stop moving and then disappear.

I tried the command acircle.getCenter() to determine when the centers are equal, but it 
doesn't work; I suspect because the centers are never truly equal, and only come within 
something like .01 pixels of each other.  So to account for the approximation, I used 
the math function "isclose":

move_moving_circle = True

 while move_moving_circle:
 moving_circle.move(P_to_R/P_to_E, E_to_R/P_to_E)
 time.sleep(0.01)

 if isclose(moving_circle.getCenter(), stationary_circle.getCenter(), 
rel_tol=1e-4, abs_tol=0.0):
 move_moving_circle= False

 else:
 move_moving_circle = True


But this doesn't work.  Apparently isclose can't be applied to points - only 
floating-point decimals.


So now, I want to convert the output of "acircle.getCenter()" to Cartesian 
(x,y) coordinates for both circles.  Then I can use the two circle centers' x-coordinates 
in the if statement.

Currently, acircle.getCenter() outputs this:




I don't understand/can't use the format that the locations are printed in.

How do I convert the above format to "usable" Cartesian coordinates?  Or is 
there a simpler way to solve this problem?

You didn't say what graphics library you're using, but from a quick 
search on the internet I think the answer is to use the .getX and .getY 
methods of the Point object.
You could calculate the distance between the 2 points, which is sqrt((x1 
- x2) ** 2 + (y1 - y2) ** 2). You can speed it up a little by omitting 
the sqrt and just remember that you're working with the square of the 
distance.


Another point: why do they need to be so close to each other? 
Personally, I'd just say they collide when round(distance) < 1 or 
round(distance ** 2) < 1.

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

acircle.getCenter() to (x,y) coordinates in Python

[G Yu]

My program has two circles: one stationary circle, drawn at a random location; 
and one moving circle, consistently drawn in the same place in the graphics 
window.

The moving circle moves towards the stationary one.  However, when the moving 
circle hits the stationary one (when the x-coordinates of the circles' centers 
are equal), I want the moving circle to stop moving and then disappear.

I tried the command acircle.getCenter() to determine when the centers are 
equal, but it doesn't work; I suspect because the centers are never truly 
equal, and only come within something like .01 pixels of each other.  So to 
account for the approximation, I used the math function "isclose":

move_moving_circle = True

while move_moving_circle:
moving_circle.move(P_to_R/P_to_E, E_to_R/P_to_E)
time.sleep(0.01)

if isclose(moving_circle.getCenter(), stationary_circle.getCenter(), 
rel_tol=1e-4, abs_tol=0.0):
move_moving_circle= False

else:
move_moving_circle = True


But this doesn't work.  Apparently isclose can't be applied to points - only 
floating-point decimals.


So now, I want to convert the output of "acircle.getCenter()" to Cartesian 
(x,y) coordinates for both circles.  Then I can use the two circle centers' 
x-coordinates in the if statement.

Currently, acircle.getCenter() outputs this:




I don't understand/can't use the format that the locations are printed in.

How do I convert the above format to "usable" Cartesian coordinates?  Or is 
there a simpler way to solve this problem?

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

Re: What is the difference between x[:]=y and x=y[:]?

[jfong]

Peter Otten at 2017/4/12 UTC+8 PM 8:13:53 wrote:
> I should add that you can write
> 
>  lr = [[1], [0]]
>  lx = []
>  for i in range(len(lr)):
> > ... lx = lr[i][:]
> > ... lx.append(0)
> > ... lr[i].append(1)
> > ... lr.append(lx)
> > ...
>  lr
> >[[1, 1], [0, 1], [1, 0], [0, 0]]
> > 
> 
> idiomatially as
> 
> >>> lr = [[1], [0]]
> >>> [inner + tail for tail in [[1], [0]] for inner in lr]
> [[1, 1], [0, 1], [1, 0], [0, 0]]
> 
> Note that there is a difference -- the resulting list does not share any 
> lists with the original `lr` as concatenating two lists produces a new one:
> 
> >>> a = [1]
> >>> b = [2]
> >>> c = a + b
> >>> a is c
> False
> >>> b is c
> False

I was a little embarrassed when looking at my codes. It may take me a long time 
to get used to thinking in the "Pythonic" way:-( But definitely I have learned 
much from this forum:-)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What is the difference between x[:]=y and x=y[:]?

[Peter Otten]

jf...@ms4.hinet.net wrote:

> Peter Otten at 2017/4/12 UTC+8 PM 4:41:36 wrote:
>> jf...@ms4.hinet.net wrote:
>> 
>> Assuming both x and y are lists
>> 
>> x[:] = y
>> 
>> replaces the items in x with the items in y while
>> 
>> 
>> x = y[:]
>> 
>> makes a copy of y and binds that to the name x. In both cases x and y
>> remain different lists, but in only in the second case x is rebound. This
>> becomes relevant when initially there are other names bound to x.
>> Compare:
>> 
>> 
>> >>> z = x = [1, 2]
>> >>> y = [10, 20, 30]
>> >>> x[:] = y # replace the values, z affected
>> >>> z
>> [10, 20, 30]
>> 
>> 
>> >>> z = x = [1, 2]
>> >>> y = [10, 20, 30]
>> >>> x = y[:] # rebind. x and z are now different lists
>> >>> z
>> [1, 2]
> 
> Thank you Peter, I think I know the problem now. The append(lx) method
> actually append a link to the name lx, not append a copy of lx. When use
> lx[:]=lr[i]. the lx's content changes and it also reflected to the lr.
> When use lx=lr[i][:], a new lx was created and it will not affect the old
> one linked in the lr.
> 
> Anyway it seems as better to use append(lx[:]) for this sake:-)

I should add that you can write

>>>> lr = [[1], [0]]
>>>> lx = []
>>>> for i in range(len(lr)):
> ... lx = lr[i][:]
> ... lx.append(0)
> ... lr[i].append(1)
> ... lr.append(lx)
> ...
>>>> lr
>[[1, 1], [0, 1], [1, 0], [0, 0]]
> 

idiomatially as

>>> lr = [[1], [0]]
>>> [inner + tail for tail in [[1], [0]] for inner in lr]
[[1, 1], [0, 1], [1, 0], [0, 0]]

Note that there is a difference -- the resulting list does not share any 
lists with the original `lr` as concatenating two lists produces a new one:

>>> a = [1]
>>> b = [2]
>>> c = a + b
>>> a is c
False
>>> b is c
False


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

Re: What is the difference between x[:]=y and x=y[:]?

[jfong]

Peter Otten at 2017/4/12 UTC+8 PM 4:41:36 wrote:
> jf...@ms4.hinet.net wrote:
> 
> Assuming both x and y are lists
> 
> x[:] = y 
> 
> replaces the items in x with the items in y while
> 
> 
> x = y[:]
> 
> makes a copy of y and binds that to the name x. In both cases x and y remain 
> different lists, but in only in the second case x is rebound. This becomes 
> relevant when initially there are other names bound to x. Compare:
> 
> 
> >>> z = x = [1, 2]
> >>> y = [10, 20, 30]
> >>> x[:] = y # replace the values, z affected
> >>> z
> [10, 20, 30]
> 
> 
> >>> z = x = [1, 2]
> >>> y = [10, 20, 30]
> >>> x = y[:] # rebind. x and z are now different lists
> >>> z
> [1, 2]

Thank you Peter, I think I know the problem now. The append(lx) method actually 
append a link to the name lx, not append a copy of lx. When use lx[:]=lr[i]. 
the lx's content changes and it also reflected to the lr. When use lx=lr[i][:], 
a new lx was created and it will not affect the old one linked in the lr. 

Anyway it seems as better to use append(lx[:]) for this sake:-)

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

Re: What is the difference between x[:]=y and x=y[:]?

[Peter Otten]

jf...@ms4.hinet.net wrote:

Assuming both x and y are lists

x[:] = y 

replaces the items in x with the items in y while


x = y[:]

makes a copy of y and binds that to the name x. In both cases x and y remain 
different lists, but in only in the second case x is rebound. This becomes 
relevant when initially there are other names bound to x. Compare:


>>> z = x = [1, 2]
>>> y = [10, 20, 30]
>>> x[:] = y # replace the values, z affected
>>> z
[10, 20, 30]


>>> z = x = [1, 2]
>>> y = [10, 20, 30]
>>> x = y[:] # rebind. x and z are now different lists
>>> z
[1, 2]


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