[issue34751] Hash collisions for tuples

[Tim Peters]

Tim Peters  added the comment:

Noting that the failure of high-order bits to propagate is one form of 
"avalanche" failure.  A recent 64-bit hash, SeaHash, takes this approach which 
is said to have provably "perfect" avalanche behavior:

Py_uhash_t t = (Py_uhash_t)y;
t *= (Py_uhash_t)0x6eed0e9da4d94a4fULL;
t ^= (t >> 32) >> (t >> 60);
t *= (Py_uhash_t)0x6eed0e9da4d94a4fULL;

The giant constant is just a 63-bit "patternless" prime (for whatever reason, 
the author wants this transformation to be easily invertible, so a prime is 
necessary - this is NOT a "crypto" hash).  The first multiply propagates 
low-order bits left.  Then the next line uses high-order bits to change 
low-order bits.  Extracting a variable shift count from the data itself is a 
clever idea taken from the PCG family of PRNGs - you have to work to contrive 
data where this doesn't "act kinda random".  The last line then propagates the 
- now altered by the high-order bits - lower-order bits left again.

Followed by

x = (x * mult) + t;

this yields a tuple hash that passes all the tests I have.  The only collisions 
are in the new tuple test, which suffers 14.

Better, add the "catastrophic" right-rotate

t = (t >> 3) | (t << 61);

at the start and it's still only the new tuple test that has a collision - it 
rises to 19 then, close to (but still under) its failure cutoff.

What I haven't tried:  in context it would be nice to eliminate the second 
multiply by the giant constant.  We're doing a multiply anyway to fold `t` into 
`x`, which will propagate the low-order bits left on the next iteration's `x * 
mult`.  That would ruin SeaHash's provable guarantees, but I'm more concerned 
about saving some cycles than purity ;-)  If that added enough collisions to 
push the second tuple test "not much" over the limit, I'd raise its limit.

Gonzo:  "the real" SeaHash duplicates the code above and works on 4 inputs 
simultaneously, designed to keep a modern processor's instruction pipelines as 
busy as possible.  I'd rather not bother (most tuples are short).

So this is principled and, if the SeaHash theory is right, immune to any simple 
kind of catastrophic failure.  Is it worth it?  I'd sleep better, yes ;-)  Note 
that the first multiply by the giant constant can be active at the same time as 
the `x * mult` at the end, so I'm guessing the speed hit would be bearable.

There's no truly _cheap_ way to get good propagation from all bit positions.  
SeaHash has the fastest way to do that I've encountered.

--

___
Python tracker 

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

[issue34859] python core in string substring search

[pashkasan]

New submission from pashkasan :

find substring in string 
its correct behavior?
sample code

str = """
Content-Length: 3192
Connection: close
Cookie: _secure_admin_session_id=2a5dc26329de17ca4eafe;

-1477319126846
Content-Disposition: form-data; name="utf8"
"""
str2 = """


z


tt
"""

if "\r\n" in str:
print ("str found")
else:
print ("str not found")


if "\r\n" in str2:
print ("str2 found")
else:
print ("str2 not found")


if str.find("\n\r"):
print ("str found")
else:
print ("str not found")

output

[root@scw-6ec0de ~]# python a.py
str not found
str2 not found
str found
[root@scw-6ec0de ~]# python3 a.py
str not found
str2 not found
str found
[root@scw-6ec0de ~]# python --version
Python 2.7.15
[root@scw-6ec0de ~]# python3 --version
Python 3.6.4
[root@scw-6ec0de ~]#

--
components: Interpreter Core
messages: 326764
nosy: pashkasan
priority: normal
severity: normal
status: open
title: python core in string substring search
versions: Python 2.7, Python 3.6

___
Python tracker 

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

[issue34844] logging.Formatter enhancement - Checking on style and fmt fields

[Vinay Sajip]

Vinay Sajip  added the comment:

> Checking fmt to match the style in the constructor of logging.Formatter

This seems a reasonable change to want to make. You would need to parse the 
format string for fields using the appropriate style. This should probably be 
via a validate() method in each of the XXXStyle classes, which is passed the 
format string and raises an exception if invalid.

> I would like to have custom fields passed in as an additional (optional) 
> argument into the constructor for logging.Formatter

If this is just a list of custom field names, it could be inferred from the 
passed format string, which will now be being parsed for fields for the 
checking described above. So there should be no need to pass an additional 
argument.

> With this, we can remove the "extra" argument in Logger.makeRecord()

We can't do this, because of the need to maintain backwards compatibility. Note 
also that custom fields can be introduced into a LogRecord in other ways, e.g. 
using Filters.

> the "KeyError" here can be misleading and confusing

It seems reasonable to make a change to re-raise such a KeyError using a more 
informative error message, perhaps as a ValueError.

--

___
Python tracker 

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

[issue34804] Repetition of 'for example' in documentation

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Though stylistically odd, the repeated text is correct.  If Andrew feels like 
amending it, that would be nice; otherwise, I don't think it is worth the 
micro-edit.

--
nosy: +rhettinger
priority: normal -> low

___
Python tracker 

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

[issue34858] MappingProxy objects should JSON serialize just like a dictionary

[Raymond Hettinger]

Raymond Hettinger  added the comment:

IIRC, there was an early decision to handle only exact types and their 
subclasses (plus tuples).  For example, os.environ and instances of 
collections.ChainMap are not JSON serializable.

I believe the reason was that it made encoding faster, more predictable, and 
more likely to match round-trip expectations.  For those wanting more 
generality, there are at least two options.  The simplest option is to coerce 
the input to supported type.  A more complete solution is to write a subclass 
of JSONEncoder to pass into json.dump() as the *cls* argument (there are 
examples of how to do this in the docs).

For the specific case of mappingproxy, there is another issue.  Multiple 
components of a class dict are not all JSON serializable, so you have the same 
problem yet again with getset_descriptor objects, member objects, and various 
slot wrappers.

--
assignee:  -> bob.ippolito
nosy: +bob.ippolito, rhettinger
versions:  -Python 3.4, Python 3.5, Python 3.6, Python 3.7

___
Python tracker 

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

[issue34370] Tkinter scroll issues on macOS

[Terry J. Reedy]

Terry J. Reedy  added the comment:

I just installed 3.7.1rc on current High Sierra and observed same as Vlad.

--
nosy: +terry.reedy

___
Python tracker 

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

[issue34850] Emit a syntax warning for "is" with a literal

[Nathaniel Smith]

Nathaniel Smith  added the comment:

Yeah, something like that. Or sys.enable_chaos_mode(), that pytest or whoever 
could call before running tests.

--

___
Python tracker 

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

[issue34313] IDLE crashes with Tk-related error on macOS with ActiveTcl 8.6

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Since this was opened, I have opened files in the editor, without incident with 
both installed 3.7.0 and 3.7.1rc1 (64 bit).  Should this still stay open?  Does 
anyony have any problems with the current release candidates?

--

___
Python tracker 

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

[issue33065] IDLE debugger: failure stepping through module loading

[ppperry]

ppperry  added the comment:

Line 59 isn't actually executed; the error comes from the trace event that gets 
fired before line 59, which is the first `line` event in the frame containing 
the uninitialized _ModuleLock.

--
nosy: +ppperry

___
Python tracker 

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

[issue34858] MappingProxy objects should JSON serialize just like a dictionary

[Michael Smith]

New submission from Michael Smith :

If a mappingproxy object is a read-only proxy to a mapping, would it make sense 
for them to JSON serialize just like the mapping they come from? Currently, 
json.dumps throws the "I don't know how to serialize this" error:

$ python -c 'import json
> import types
> json.dumps(types.MappingProxyType({}))'
Traceback (most recent call last):
  File "", line 3, in 
  File "/usr/lib64/python3.6/json/__init__.py", line 231, in dumps
return _default_encoder.encode(obj)
  File "/usr/lib64/python3.6/json/encoder.py", line 199, in encode
chunks = self.iterencode(o, _one_shot=True)
  File "/usr/lib64/python3.6/json/encoder.py", line 257, in iterencode
return _iterencode(o, 0)
  File "/usr/lib64/python3.6/json/encoder.py", line 180, in default
o.__class__.__name__)
TypeError: Object of type 'mappingproxy' is not JSON serializable

--
components: Library (Lib)
messages: 326756
nosy: Michael Smith2
priority: normal
severity: normal
status: open
title: MappingProxy objects should JSON serialize just like a dictionary
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

___
Python tracker 

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

[issue34850] Emit a syntax warning for "is" with a literal

[Gregory P. Smith]

Gregory P. Smith  added the comment:

If we were to ship a "chaos" mode in the CPython interpreter itself, I assume 
you envision an interpreter flag and/or env var?  If it required someone 
compiling the interpreter a special way I don't think it would be widely 
adopted within continuous integration testing systems.

I was actually pondering doing a "chaos" mode of sorts at work because I have 
the power to cause everyone's tests to be run that way mode by default.  (I'd 
basically just disable interning and str/int singletons)  But while it's a nice 
idea, it's low on my work priorities.  While we had thousands of is literal 
comparisons that we're about to fix en-masse, they are only a tiny fraction of 
all literal comparisons in our codebase.  And pylint is now more widely used 
which should help prevent new ones.

--

___
Python tracker 

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

[issue34850] Emit a syntax warning for "is" with a literal

[Nathaniel Smith]

Nathaniel Smith  added the comment:

Would it make sense to implement a "chaos" mode (that e.g. testing tools could 
enable unconditionally), that disables the small integer and small string 
caches?

--
nosy: +njs

___
Python tracker 

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

[issue34751] Hash collisions for tuples

[Tim Peters]

Tim Peters  added the comment:

An "aha!" moment for me:  I noted before that replacing the tuple hash loop with

Py_uhash_t t = (Py_uhash_t)y;
t ^= t << 1;
x = (x * mult) + t;

does OK (64-bit build):  most tests had no collisions, but the original tuple 
test had 24 (a modest failure) and the new one 6.

Horrible results with a different scheme prompted me to add one line before the 
shift-xor:

t = (t >> 3) | (t << 61);

That is, merely rotate the input right by 3 bits first.  Disaster!  Almost all 
tests suffered major collisions, and the old test 235424 and the new one 344919.

What's going on?  With hindsight, it's obvious:  multiplication is a horrible 
"mixer" _in this context_.  Because nearly all the tests are slinging little 
integers, almost all the input variation is in the last handful of bits.  
Multiplication is great for spreading low-order bits around.  But rotate them 
to the high end, and multiplication is next to useless:  it only propagates 
them "to the left", and they're already at the left end then.  This part has 
virtually nothing to do with whether + or ^ is used, or with whether 
multiplication is done before or after.  It's actually the multiplication 
that's the weakness, and has nothing to do with which multiplier is used.

This isn't a problem with FNV or DJB when used _as intended_, because their 
output is much wider than their inputs.  The high-order bit of an input for 
them is still a lower-order bit to their much wider multiplication, and 
eventually propagates.  It isn't a problem for "multiplicative hashing" 
algorithms either, because those use a double-width multiply and only retain 
the _high_ half of a double-width product.  We're only retaining the _lower_ 
half.

I also noted before that replacing the shift-xor with the frozenset hash's 
input scrambler:

t = ((t ^ 89869747UL) ^ (t << 16)) * 3644798167UL;

worked great.  But it's equally a disaster if the inputs are rotated right by 3 
first.  Same reason:  it too only propagates "to the left".

So almost all tuple hash schemes on the table, both current and various 
experiments here, are systematic disasters if input hashes vary mostly in the 
high-order bits.  We haven't noticed because the current string hashes vary 
about the same in all bit positions, while contiguous ranges of not-huge ints 
have hashes that vary in the low-order bits.

The only schemes in all these messages that are "obviously immune" are those 
that used a (any) flavor of FNV or DJB as intended, treating each input hash as 
a sequence of unsigned bytes.

--

___
Python tracker 

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

[issue34850] Emit a syntax warning for "is" with a literal

[miss-islington]

miss-islington  added the comment:


New changeset cb0bec37dd8279555bc01fa03a259eaf7dbb6d5d by Miss Islington (bot) 
in branch '3.6':
bpo-34850: Replace is with == in idlelib.iomenu (GH-9649)
https://github.com/python/cpython/commit/cb0bec37dd8279555bc01fa03a259eaf7dbb6d5d


--

___
Python tracker 

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

[issue34850] Emit a syntax warning for "is" with a literal

[miss-islington]

miss-islington  added the comment:


New changeset 214c0b3d153c4bad14086888b9de0826a7abc083 by Miss Islington (bot) 
in branch '3.7':
bpo-34850: Replace is with == in idlelib.iomenu (GH-9649)
https://github.com/python/cpython/commit/214c0b3d153c4bad14086888b9de0826a7abc083


--
nosy: +miss-islington

___
Python tracker 

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

[issue34850] Emit a syntax warning for "is" with a literal

[Terry J. Reedy]

Terry J. Reedy  added the comment:

To me, this issue is about unnecessary dependence on implementation details, 
with the particular example being 'is' versus '=='.  Perhaps PEP8, Programming 
Recommendations, should have a new subsection 'Implementation Dependencies' to 
recommend against such dependency when not necessary.

Although IDLE depends on CPython's tkinter, I agree that it should follow this 
principle.  I extracted the idlelib change to PR9649 to be applied and 
backported regardless of the fate of Serhiy's main proposal.

At least on Windows, "assert (0, 'bad')" raises SyntaxWarning in freshly 
compiled 3.6.7+ but not in 3.7.1+ or 3.8.

[A separate issue (#34857): the warning is not displayed in IDLE and the 
warning in the Shell causes looping.]

--
assignee: terry.reedy -> serhiy.storchaka
components:  -IDLE

___
Python tracker 

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

[issue34850] Emit a syntax warning for "is" with a literal

[miss-islington]

Change by miss-islington :


--
pull_requests: +9042

___
Python tracker 

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

[issue34850] Emit a syntax warning for "is" with a literal

[miss-islington]

Change by miss-islington :


--
pull_requests: +9041

___
Python tracker 

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

[issue34850] Emit a syntax warning for "is" with a literal

[Terry J. Reedy]

Terry J. Reedy  added the comment:


New changeset 5fa247d60d4f3f2b8c8ae8cb57363aca234344c2 by Terry Jan Reedy in 
branch 'master':
bpo-34850: Replace is with == in idlelib.iomenu (GH-9649)
https://github.com/python/cpython/commit/5fa247d60d4f3f2b8c8ae8cb57363aca234344c2


--

___
Python tracker 

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

[issue33533] Provide an async-generator version of as_completed

[Hrvoje Nikšić]

Hrvoje Nikšić  added the comment:

If there is interest in this, I'd like to attempt a PR for a sync/async variant 
of as_completed.

Note that the new docs are *much* clearer, so the first (documentation) problem 
from the description is now fixed. Although the documentation is still brief, 
it now contains the key pieces of information: 1) that the futures are actually 
run in parallel, and 2) that each yielded future produces the next result that 
becomes available. Neither was actually stated in the old docs (!), so this is 
a marked improvement.

--

___
Python tracker 

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

[issue34856] Make the repr of lambda containing the signature and body expression.

[Guido van Rossum]

Guido van Rossum  added the comment:

OTOH the current repr is bounded. Some people write very long lambdas.

On Sun, Sep 30, 2018 at 11:31 AM Serhiy Storchaka 
wrote:

>
> Change by Serhiy Storchaka :
>
>
> --
> keywords: +patch
> pull_requests: +9039
> stage:  -> patch review
>
> ___
> Python tracker 
> 
> ___
>
-- 
--Guido (mobile)

--

___
Python tracker 

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

[issue34848] range.index only takes one argument when it's documented as taking the usual 3

[Dan Snider]

Dan Snider  added the comment:

So I also just happened to notice that the "documentation is wrong" for list, 
tuple, and collections.deque. They use use _PyEval_SliceIndexNotNone whch 
causes this:

>>> s = 'abcde'
>>> s.index('d', 0, None)
3
>>> [*s].index('d', None)
Traceback (most recent call last):
  File "", line 1, in 
[*s].index('d', None)
TypeError: slice indices must be integers or have an __index__ method

In 3.6.0, that error message is:
TypeError: slice indices must be integers or None or have an __index__ 
method

which means someone else was aware of this behavior and switched from 
_PyEval_SliceIndex to _PyEval_SliceIndexNotNone but didn't think these 
inconsistencies were inappropriate?

Anyway, I'll go ahead fix the docs later for accuracy's sake, but I'd much 
rather update operator.indexOf to use a new abstract api function: 
"PySequence_IndexOf" or some such, which is also capable of handling starting 
from the tail like str.rindex. 

If that's something that could be done, after I finish the Python prototype of 
this sequence ChainMap analog and rewrite it in C, I'll have made my own 
abstract sequence index function which I'd happily share.

--

___
Python tracker 

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

[issue34850] Emit a syntax warning for "is" with a literal

[Terry J. Reedy]

Change by Terry J. Reedy :


--
pull_requests: +9040

___
Python tracker 

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

[issue34857] IDLE: SyntaxWarning not handled properly

[Terry J. Reedy]

New submission from Terry J. Reedy :

In 3.6.6, """compile("assert (0, 'bad')", '', 'single')""" in Python or IDLE 
emits "SyntaxWarning: assertion is always true, perhaps remove parentheses?".

In Python,
>>> assert (0, 'bad')
:1: SyntaxWarning: assertion is always true, perhaps remove parentheses?

In IDLE's Shell, the same statement is effectively treated as incomplete in 
that newlines are echoed and IDLE waits for input until something is entered.  
KeyboardInterrupt (^C) or any text terminate the loop.  In the latter case, 
"SyntaxError: multiple statements found while compiling a single statement" is 
printed.

In a file, the statement has no effect, but the warning should be printed in 
the shell.

--
assignee: terry.reedy
components: IDLE
messages: 326745
nosy: terry.reedy
priority: normal
severity: normal
stage: test needed
status: open
title: IDLE: SyntaxWarning not handled properly
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8

___
Python tracker 

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

[issue34850] Emit a syntax warning for "is" with a literal

[Guido van Rossum]

Guido van Rossum  added the comment:

Yet, Greg’s point is that this only works if the developer tests their code
with the new Python version.

I’m not sure that his proposal is better though. I think static checkers
are the better remedy.

On Sun, Sep 30, 2018 at 10:02 AM Serhiy Storchaka 
wrote:

>
> Serhiy Storchaka  added the comment:
>
> There is a large difference with the DeprecationWarning in the md5 and sha
> modules.
>
> A SyntaxWarning is emitted when the compiler compiles Python sources to
> bytecode. Since bytecode is cached in pyc files, you will see it at most
> once at first run of the application. If the application compiles Python
> files at install time, warnings will be emitted at that time, and will be
> not emitted when run the application. If the application is distributed
> with precompiled pyc files, the user will not see warnings at all. If the
> developer installs dependencies that contain this error, his will see a
> warning only once, and can either ignore it (taking the current state), or
> report a bug. Warnings will not annoy him when he debug his code.
>
> In contrary, the DeprecationWarning was emitted every time when you import
> the md5 or sha modules.
>
> Professional applications likely already use checkers which caught this
> error. This warning will help non-professional applications distributed as
> a single script or handful of scripts. Users of such application often seat
> near its author. In many cases the only user is its author.
>
> --
>
> ___
> Python tracker 
> 
> ___
>
-- 
--Guido (mobile)

--

___
Python tracker 

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

[issue34854] Crash in string annotations in lambda with keyword-only argument without default value

[Guido van Rossum]

Guido van Rossum  added the comment:

Should go to @ambv.

On Sun, Sep 30, 2018 at 9:29 AM Serhiy Storchaka 
wrote:

>
> Change by Serhiy Storchaka :
>
>
> --
> keywords: +patch
> pull_requests: +9037
> stage:  -> patch review
>
> ___
> Python tracker 
> 
> ___
>
-- 
--Guido (mobile)

--

___
Python tracker 

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

[issue34854] Crash in string annotations in lambda with keyword-only argument without default value

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

These bugs was found when working on issue34856.

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

[issue34856] Make the repr of lambda containing the signature and body expression.

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
keywords: +patch
pull_requests: +9039
stage:  -> patch review

___
Python tracker 

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

[issue34850] Emit a syntax warning for "is" with a literal

[Barry A. Warsaw]

Barry A. Warsaw  added the comment:

This is a nice approach to the problem.  I completely agree that we cannot 
change `is` semantics.  I'm okay with leaving it to checkers to catch `== None`.

--

___
Python tracker 

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

[issue34771] test_ctypes failing on Linux SPARC64

[Frank Schaefer]

Frank Schaefer  added the comment:

Well, after perusing the ctypes callproc.c code, I found the hacks referenced 
by martin.panter and tried activating them with some SPARC64 #ifdefs:

--- python3.6-3.6.6.orig/Modules/_ctypes/callproc.c
+++ python3.6-3.6.6/Modules/_ctypes/callproc.c
@@ -1041,6 +1041,7 @@ GetComError(HRESULT errcode, GUID *riid,
 #endif
 
 #if (defined(__x86_64__) && (defined(__MINGW64__) || defined(__CYGWIN__))) || \
+(defined(__sparc_v9__) || (defined(__sparc__) && defined(__arch64__))) || \
 defined(__aarch64__)
 #define CTYPES_PASS_BY_REF_HACK
 #define POW2(x) (((x & ~(x - 1)) == x) ? x : 0)


This is based on #ifdef checks in libffi, but somewhat more generalized.  The 
good news is, this appears to resolve all test_ctypes failures.  So I'm 
guessing this is necessary on Linux/SPARC64, though I can't tell if it's 
necessary for Solaris/SPARC64.  I don't even know what built-in compiler 
defines get turned on for Solaris, though someone else might.

It might also be advisable to backport this to Python 2.7, but obviously we 
should also backport the additional ctypes tests if we do that.

My biggest concern is, do these hacks have a purely performance-centric impact, 
or do they potentially degrade functionality as well?

--

___
Python tracker 

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

[issue34854] Crash in string annotations in lambda with keyword-only argument without default value

[miss-islington]

miss-islington  added the comment:


New changeset 0f161b307969f86b4f8f31baf38f53f5462a9874 by Miss Islington (bot) 
in branch '3.7':
bpo-34854: Fix compiling string annotations containing lambdas. (GH-9645)
https://github.com/python/cpython/commit/0f161b307969f86b4f8f31baf38f53f5462a9874


--
nosy: +miss-islington

___
Python tracker 

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

[issue34856] Make the repr of lambda containing the signature and body expression.

[Serhiy Storchaka]

New submission from Serhiy Storchaka :

>>> f = lambda x, y=1: x+y
>>> f


Currently it is less informative: " at 0x7f437cd27890>".

--
components: Interpreter Core
messages: 326738
nosy: gvanrossum, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Make the repr of lambda containing the signature and body expression.
type: enhancement
versions: Python 3.8

___
Python tracker 

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

[issue34854] Crash in string annotations in lambda with keyword-only argument without default value

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset 2a2940e5c3e6d92f4fac5e9d361a1e224bb2f12e by Serhiy Storchaka in 
branch 'master':
bpo-34854: Fix compiling string annotations containing lambdas. (GH-9645)
https://github.com/python/cpython/commit/2a2940e5c3e6d92f4fac5e9d361a1e224bb2f12e


--

___
Python tracker 

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

[issue34854] Crash in string annotations in lambda with keyword-only argument without default value

[miss-islington]

Change by miss-islington :


--
pull_requests: +9038

___
Python tracker 

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

[issue34835] Multiprocessing module update fails with pip3

[Dr_Zaszus]

Dr_Zaszus  added the comment:

Thank you! It's clear now.

--

___
Python tracker 

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

[issue34855] batch file variables

[Eric Lindblad]

New submission from Eric Lindblad :

The development version code can set the variable EXTERNALS_DIR in two .bat 
files, but nowhere in a .bat file is set the variable EXTERNAL_DIR, the latter 
appearing in find_python.bat. I am not a Powershell user and so cannot 
interpret the content of the file .azure-pipelines/windows-steps.yml, where the 
variable EXTERNAL_DIR likewise appears, but, being familiar solely with .bat 
files would question whether a misprint had occurred in the below commit, as 
"%EXTERNAL_DIR%" rather than "%EXTERNALS_DIR%"?

https://github.com/python/cpython/commit/68d663cf85d1ac5eaf83482eed39c0a6f8093601#diff-60f6a0e6e49e5990c3ad465771fff9cd

committed on GitHub Jul 17, 2017

--
components: Build
messages: 326735
nosy: lindblad
priority: normal
severity: normal
status: open
title: batch file variables
versions: Python 3.8

___
Python tracker 

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

[issue21165] Optimize str.translate() for replacement with substrings and non-ASCII strings

[Sergey Fedoseev]

Change by Sergey Fedoseev :


--
nosy: +sir-sigurd

___
Python tracker 

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

[issue34850] Emit a syntax warning for "is" with a literal

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

There is a large difference with the DeprecationWarning in the md5 and sha 
modules.

A SyntaxWarning is emitted when the compiler compiles Python sources to 
bytecode. Since bytecode is cached in pyc files, you will see it at most once 
at first run of the application. If the application compiles Python files at 
install time, warnings will be emitted at that time, and will be not emitted 
when run the application. If the application is distributed with precompiled 
pyc files, the user will not see warnings at all. If the developer installs 
dependencies that contain this error, his will see a warning only once, and can 
either ignore it (taking the current state), or report a bug. Warnings will not 
annoy him when he debug his code.

In contrary, the DeprecationWarning was emitted every time when you import the 
md5 or sha modules.

Professional applications likely already use checkers which caught this error. 
This warning will help non-professional applications distributed as a single 
script or handful of scripts. Users of such application often seat near its 
author. In many cases the only user is its author.

--

___
Python tracker 

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

[issue34851] re.error - for the search function in the re module

[Eric V. Smith]

Eric V. Smith  added the comment:

Perhaps we could improve that error message. If Ronald hand't pointed out the 
actual problem, it would have taken me a while to figure it out, too.

Maybe "bad character range +-* at position 2: starting character is after 
ending character"? Although I'll admit I haven't looked at the code to see if 
it knows enough to produce that kind of message without some serious 
refactoring.

--
nosy: +eric.smith

___
Python tracker 

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

[issue34852] Counter-intuitive behavior of Server.close() / wait_closed()

[Aymeric Augustin]

Aymeric Augustin  added the comment:

For now I will use the following hack:

server.close()
await server.wait_closed()

# Workaround for wait_closed() not quite doing
# what I want.
await asyncio.sleep(0)

# I believe that all accepted connections have reached
# connection_made() at this point.

--

___
Python tracker 

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

[issue34854] Crash in string annotations in lambda with keyword-only argument without default value

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
keywords: +patch
pull_requests: +9037
stage:  -> patch review

___
Python tracker 

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

[issue34850] Emit a syntax warning for "is" with a literal

[Gregory P. Smith]

Gregory P. Smith  added the comment:

The problem with a SyntaxWarning is that the wrong people will see it. It gets 
in the way of users of applications that happen to be written in Python.

scenarios:

(a) A Python interpreter gets upgraded, and suddenly the _users_ of an 
application start seeing nasty warnings when they invoke the tool that happens 
to be implemented in Python. Warnings that they have no power to do anything 
about.

(b) A developer installs the shiny new version of Python with the warning 
feature, then pip install's all of the dependencies for the application they 
are working on.  Some of those contain "is" problems so they're left in a 
situation where they either have to figure out how to fix code from N different 
transitive dependencies libraries that they are not the author of - or not use 
that Python version to ship their code.  Keep in mind that it is common for 
deps to be pinned to ranges of versions instead of "always the latest" so even 
when deps fix their code, many people won't see it for a long time.

These scenarios are real, this is exactly what happened with the 
DeprecationWarning added to the old md5.py and sha.py modules.

A warning raised at import time isn't even one that can be meaningfully caught 
in a well structured application.  Doing so requires importing the warnings 
module first thing and setting up warning filters before any other imports.  
This is ugly boilerplate for anyone to need to resort to.

As much as I want us to do something to ameliorate this anti-pattern in code, I 
don't think a SyntaxWarning is a great way to do it.

--

___
Python tracker 

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

[issue34854] Crash in string annotations in lambda with keyword-only argument without default value

[Serhiy Storchaka]

New submission from Serhiy Storchaka :

Compiling a string annotation containing a lambda with keyword-only argument 
without default value causes a crash.

from __future__ import annotations
def f() -> (lambda *, x: x): pass

The following PR fixes this crash. It also fixes other errors:

* Removes a space between "lambda" and ":" in the representation of lambda 
without argument.

* Removes the final "*" (it is incorrect syntax) in the representation of 
lambda without *args and keyword-only arguments when compile from AST.

--
components: Interpreter Core
messages: 326730
nosy: gvanrossum, lukasz.langa, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Crash in string annotations in lambda with keyword-only argument without 
default value
type: crash
versions: Python 3.7, Python 3.8

___
Python tracker 

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

[issue34850] Emit a syntax warning for "is" with a literal

[Xiang Zhang]

Xiang Zhang  added the comment:

I have catched using `is` to do string equality check in our codebase by 
linters before. Not all my colleagues know what's not suitable here.

The only common and suitable case I can think of is programmers are exploring 
CPython internals, like what stackoverflow Q&As and some Python blogs.

--
nosy: +xiang.zhang

___
Python tracker 

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

[issue34853] Python django cors

[Ammar Askar]

Ammar Askar  added the comment:

Hey Anel, this bug tracker is for issues with the Python language itself, not 
its libraries or usage.

Try the flask-cors issue tracker or stackoverflow for more help-oriented 
questions:

https://github.com/corydolphin/flask-cors

https://stackoverflow.com/

--
nosy: +ammar2
resolution:  -> not a bug
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

[issue12782] Multiple context expressions do not support parentheses for continuation across lines

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

Now that I think about this a bit better, this may be actually a problem as:

 with (yield something) as x:

is a more than valid use case that will be broken with the simple grammar rule 
:(

--

___
Python tracker 

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

[issue12782] Multiple context expressions do not support parentheses for continuation across lines

[Pablo Galindo Salgado]

Change by Pablo Galindo Salgado :


--
pull_requests:  -9036

___
Python tracker 

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

[issue34853] Python django cors

[Anel Hodzic]

New submission from Anel Hodzic :

API call gives the desired response when trying through browser or postman. 

from rest_framework import generics
from django.shortcuts import get_object_or_404
from .jsonserializer import GroupSerializer, SubgroupSerializer, 
ProductsSerializer
from .models import pGroups, pSubgroups, Products
from flask import Flask
from flask_cors import CORS

app = Flask(__name__)
CORS(app)

@app.route("/Group/")
# @cross_origin()

# Create your views here.

class GroupList(generics.ListCreateAPIView):
queryset = pGroups.objects.all()
serializer_class = GroupSerializer

But when i try to make that call using JQuery

let dropdown = $('#locality-dropdown');

dropdown.empty();

dropdown.append('Choose product 
group');
dropdown.prop('selectedIndex', 0);

const url = 'http://127.0.0.1:8000/Group/';

// Populate dropdown with list of provinces
$.getJSON(url, function (data) {
  $.each(data, function (key, entry) {
console.log(entry.name);
dropdown.append($('').attr('value', 
entry.abbreviation).text(entry.name));
  })
});

I get the output :

Failed to load http://127.0.0.1:8000/Group/: No 'Access-Control-Allow-Origin' 
header is present on the requested resource. Origin 'null' is therefore not 
allowed access.

Trying to set up the FLASK-CORS https://flask-cors.readthedocs.io/en/latest/

Im complete beginner in web programming

--
messages: 326726
nosy: Anel Hodzic
priority: normal
severity: normal
status: open
title: Python django cors

___
Python tracker 

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

[issue12782] Multiple context expressions do not support parentheses for continuation across lines

[Pablo Galindo Salgado]

Change by Pablo Galindo Salgado :


--
keywords: +patch
pull_requests: +9036

___
Python tracker 

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

[issue34852] Counter-intuitive behavior of Server.close() / wait_closed()

[Aymeric Augustin]

New submission from Aymeric Augustin :

**Summary**

1. Is it correct for `Server.wait_closed()` (as implemented in asyncio) to be a 
no-op after `Server.close()`?
2. How can I tell that all incoming connections have been received by 
`connection_made()` after `Server.close()`?

**Details**

After calling `Server.close()`, `_sockets is None`, which makes 
`Server.wait_closed()` a no-op: it returns immediately without doing anything 
(as mentioned in https://bugs.python.org/issue33727).

I'm not sure why the docs suggest to call `wait_closed()` after `close()` if 
it's a no-op. My best guess is: "this design supports third-party event loops 
that requires an asynchronous API for closing servers, but the built-in event 
loops don't need that". Does someone know?

I wrote a very simple server that merely accepts connections. I ran experiments 
where I saturate the server with incoming client connections and close it. I 
checked what happens around `close()` (and `wait_closed()` -- but as it doesn't 
do anything after `close()` I'll just say `close()` from now on.)

The current implementation appears to work as documented, assuming an rather 
low level interpretation of the docs of `Server.close()`.

> Stop serving: close listening sockets and set the sockets attribute to None.

Correct -- I'm not seeing any `accept` calls in 
`BaseSelectorEventLoop._accept_connection` after `close()`.

> The sockets that represent existing incoming client connections are left open.

Correct -- if "existing incoming client connections" is interpreted as "client 
connections that have gone through `accept`".

> The server is closed asynchronously, use the wait_closed() coroutine to wait 
> until the server is closed.
 
I'm seeing calls to `connection_made()` _after_ `close()` because 
`BaseSelectorEventLoop._accept_connection2` triggers `connection_made()` 
asynchronously with `call_soon()`.

This is surprising for someone approaching asyncio from the public API rather 
than the internal implementation. `connection_made()` is the first contact with 
new connections. The concept of "an existing incoming client connection for 
which `connection_made()` wasn't called yet" is unexpected.

This has practical consequences.

Consider a server that keeps track of established connections via 
`connection_made` and `connection_lost`. If this server calls `Server.close()`, 
awaits `Server.wait_closed()`, makes a list of established connections and 
terminates them, there's no guarantee that all connections will be closed. 
Indeed, new connections may appear and call `connection_made()` after `close()` 
and `wait_closed()` returned!

`wait_closed()` seems ineffective for this use case.

--
components: asyncio
messages: 326725
nosy: asvetlov, aymeric.augustin, yselivanov
priority: normal
severity: normal
status: open
title: Counter-intuitive behavior of Server.close() / wait_closed()
type: behavior
versions: Python 3.7

___
Python tracker 

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

[issue33727] Server.wait_closed() doesn't always wait for its transports to fihish

[Aymeric Augustin]

Aymeric Augustin  added the comment:

I believe this is by design: the documentation says:

> The sockets that represent existing incoming client connections are left open.

`Server` doesn't keep track of active transports serving requests.

(That said, I haven't figured out what _waiters is here so I could be wrong.)

--
nosy: +aymeric.augustin

___
Python tracker 

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

[issue32808] subprocess.check_output opens an unwanted command line window after fall creator update

[Cheryl Sabella]

Cheryl Sabella  added the comment:

@Christian Heigele  Any additional information re: msg312034?  Thanks!

--
nosy: +cheryl.sabella

___
Python tracker 

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

[issue34850] Emit a syntax warning for "is" with a literal

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Suggestions about the wording of the warning message are welcome.

--

___
Python tracker 

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

[issue34850] Emit a syntax warning for "is" with a literal

[Steven D'Aprano]

Steven D'Aprano  added the comment:

I like this solution of a syntax warning for `is ` and I agree that 
`== None` should not be a warning.

(And for what its worth, I strongly disagree with making `is` a hybrid 
sometimes-check-identity-sometimes-check-equality operator.)

--
nosy: +steven.daprano

___
Python tracker 

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

[issue32947] Support OpenSSL 1.1.1

[Christian Heimes]

Christian Heimes  added the comment:

The release candidates came out a couple of days ago.

--

___
Python tracker 

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

[issue32947] Support OpenSSL 1.1.1

[Kurt Roeckx]

Kurt Roeckx  added the comment:

Do you have any idea when the next release will be? I think python is currently 
our biggest blocker for getting OpenSSL 1.1.1 in Debian testing.

--

___
Python tracker 

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

[issue34851] re.error - for the search function in the re module

[Ronald Oussoren]

Ronald Oussoren  added the comment:

This is not a bug. You are searching for the character range from "+" to "*", 
which is an invalid range because "+" > "*".

--
nosy: +ronaldoussoren
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
type: crash -> behavior

___
Python tracker 

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

[issue34476] asyncio.sleep(0) not documented

[Hrvoje Nikšić]

Hrvoje Nikšić  added the comment:

Agreed about the special case. Minor change suggestion:

``sleep()` always suspends the current task, allowing other tasks to run.

That is, replace "switches execution to another [task]" because there might not 
be other tasks or they might not be executable - the idea is to allow them to 
run. Also, replace "pause" with "suspend" (because when delay<=0 there is not 
really a discernible pause).

https://github.com/python/cpython/pull/9643

If you'd still prefer the previous wording, I'll amend the PR.

--

___
Python tracker 

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

[issue34476] asyncio.sleep(0) not documented

[Roundup Robot]

Change by Roundup Robot :


--
keywords: +patch
pull_requests: +9035
stage:  -> patch review

___
Python tracker 

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

[issue34851] re.error - for the search function in the re module

[Bnaya]

New submission from Bnaya :

I was writing the following:
re.search('([+-*])', "54  *  83")

And I got the following runtime error:
Traceback (most recent call last):
  File "", line 1, in 
  File "C:\Users\bnaya\AppData\Local\Programs\Python\Python37-32\lib\re.py", 
line 183, in search
return _compile(pattern, flags).search(string)
  File "C:\Users\bnaya\AppData\Local\Programs\Python\Python37-32\lib\re.py", 
line 286, in _compile
p = sre_compile.compile(pattern, flags)
  File 
"C:\Users\bnaya\AppData\Local\Programs\Python\Python37-32\lib\sre_compile.py", 
line 764, in compile
p = sre_parse.parse(p, flags)
  File 
"C:\Users\bnaya\AppData\Local\Programs\Python\Python37-32\lib\sre_parse.py", 
line 930, in parse
p = _parse_sub(source, pattern, flags & SRE_FLAG_VERBOSE, 0)
  File 
"C:\Users\bnaya\AppData\Local\Programs\Python\Python37-32\lib\sre_parse.py", 
line 426, in _parse_sub
not nested and not items))
  File 
"C:\Users\bnaya\AppData\Local\Programs\Python\Python37-32\lib\sre_parse.py", 
line 816, in _parse
p = _parse_sub(source, state, sub_verbose, nested + 1)
  File 
"C:\Users\bnaya\AppData\Local\Programs\Python\Python37-32\lib\sre_parse.py", 
line 426, in _parse_sub
not nested and not items))
  File 
"C:\Users\bnaya\AppData\Local\Programs\Python\Python37-32\lib\sre_parse.py", 
line 580, in _parse
raise source.error(msg, len(this) + 1 + len(that))
re.error: bad character range +-* at position 2

Note that for different operators order, such as:
re.search('([+*-])', "54  *  83")
or
re.search('([*+-])', "54  *  83")
the function worked just fine.

--
components: Regular Expressions
messages: 326716
nosy: Bnaya, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: re.error - for the search function in the re module
type: crash
versions: Python 3.7

___
Python tracker 

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

[issue34850] Emit a syntax warning for "is" with a literal

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

It also fixes an incorrect use of "is" with an empty string in IDLE.

--
assignee:  -> terry.reedy
components: +IDLE
nosy: +terry.reedy

___
Python tracker 

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

[issue34850] Emit a syntax warning for "is" with a literal

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
keywords: +patch
pull_requests: +9034
stage:  -> patch review

___
Python tracker 

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

[issue34850] Emit a syntax warning for "is" with a literal

[Serhiy Storchaka]

New submission from Serhiy Storchaka :

Gregory have noticed that the "is" and "is not" operator sometimes is used with 
string and numerical literals. This code "works" on CPython by accident, 
because of caching on different levels (small integers and strings caches, 
interned strings, deduplicating constants at compile time). But it shouldn't 
work on other implementations, and can not work even on early or future CPython 
versions.

https://discuss.python.org/t/demoting-the-is-operator-to-avoid-an-identity-crisis/86

I think that the adequate solution of this issue is not demoting the "is" 
operator, but emitting a syntax warning. In general, this is a work for 
third-party checkers. But many people don't use checkers for their one-time 
scripts, using "is" with a literal is always a mistake, and it is easy to add a 
check for this in the compiler.

Currently the compiler emits SyntaxWarning only for parenthesis in assert: 
`assert(x, "msg")`. But in earlier versions there were more warnings (they are 
errors). In 3.8 yet one SyntaxWarning will be added instead of 
DeprecationWarning for unknown escape sequences in string literals.

The proposed PR makes the compiler emitting a SyntaxWarning when the "is" or 
"is not" operators are used with a constant (except singletons None, False, 
True and ...). A warning will be replaced with a SyntaxError if the warnings 
system is configured to raise errors. This is because SyntaxError contains more 
information and provides better traceback. The same change was made for 
"assert(...)". Added tests, including tests for "assert(...)".

Barry have noted that using the "==" operator with None can be also classified 
as an error. But I think that in this case there may be legal uses of this, and 
the compiler should not complain. It is a work for third-party checkers, which 
can provide configuration options for enabling and disabling particular kinds 
of checks.

--
components: Interpreter Core
messages: 326714
nosy: barry, gregory.p.smith, gvanrossum, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Emit a syntax warning for "is" with a literal
type: enhancement
versions: Python 3.8

___
Python tracker 

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

[issue34476] asyncio.sleep(0) not documented

[Andrew Svetlov]

Andrew Svetlov  added the comment:

Adding "`asyncio.sleep()` always pauses the current task and switches execution 
to another one" sounds totally reasonable to me (without mentioning zero 
`delay` special case).

Would you make a pull request?

--

___
Python tracker 

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

[issue32892] Remove specific constant AST types in favor of ast.Constant

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Yesterday I submitted a PR that should fix astroid in Python 3.8: 
https://github.com/PyCQA/astroid/issues/616

--

___
Python tracker 

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

[issue30672] PEP 538: Unexpected locale behaviour on *BSD (including Mac OS X)

[Nick Coghlan]

Change by Nick Coghlan :


--
keywords: +patch
pull_requests: +9033
stage: test needed -> patch review

___
Python tracker 

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

[issue32892] Remove specific constant AST types in favor of ast.Constant

[Nathaniel Smith]

Nathaniel Smith  added the comment:

As a point of information, this did in fact break pylint/astroid: 
https://github.com/PyCQA/astroid/issues/617

--
nosy: +njs

___
Python tracker 

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

[issue30672] PEP 538: Unexpected locale behaviour on *BSD (including Mac OS X)

[Nick Coghlan]

Nick Coghlan  added the comment:

Putting back to normal, as the difference between the C locale and the POSIX 
locale is that you never get the latter by default - you have to explicitly 
request it.

The underlying fix for this is in the PR for bpo-34589.

--
dependencies: +Py_Initialize() and Py_Main() should not enable C locale coercion
priority: critical -> normal

___
Python tracker 

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