[issue31192] "return await coro()" SyntaxError despite being "valid syntax" in PEP 492

[Martin Panter]

Martin Panter added the comment:

In 3.5, “await” is an ordinary identifier outside of “async def” functions. You 
have to use the “async def” syntax to enable it as a special keyword.

>>> async def foo():  # “Async def” enables “await” as a keyword
... return await coro()  # Valid syntax
... 
>>> async def coro(): pass
... 
>>> def await(c):
... c.close()  # Avoid RuntimeWarning
... return "Called await({!r})".format(c)
... 
>>> def bar():  # Ordinary non-PEP-492 function
... return await (coro())
... 
>>> bar()
'Called await()'

--
nosy: +martin.panter
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

[issue31147] a suboptimal check in list_extend()

[Raymond Hettinger]

Raymond Hettinger added the comment:

I'm concerned that is would provide near zero benefit but would set us up for 
future bugs by tightly coupling two ideas that I would like to be able to 
reason about separately.  

The logic for list.extend() makes a potential overallocation, fills the list, 
and fixes-up the overallocation if needed (I want that logic should all stay 
together).  And list_resize() should have its own separate logic as well.  

For a course grained operation like extend(), I really don't mind having a code 
path that makes a relatively cheap test that only occasionally useful.

So, thank you for the suggestion, but I'm going to decline on the grounds that 
1) the current code is sometimes useful, 2) it is always cheap, 3) that 
removing it is odds with the principles of loose coupling and high cohesion, 4) 
it creates a risk of introducing unnoticed errors in the future the list_resize 
logic were to change, and 5) no one else has stepped forward to advocate this 
patch.

--
resolution:  -> rejected
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

[issue31186] Support heapfix() and heapremove() APIs in heapq module

[Raymond Hettinger]

Raymond Hettinger added the comment:

-1 I don't think this is the right way to use heaps.  Also, I don't want to 
introduce any O(n) operations for fine-grained changes of a single element 
(part of the point of having a heap is to make fine-grained changes cheap).  

FWIW, it isn't common to change an element and then call heapify.  Instead, the 
usual approach is either mark an entry as invalid or keep a pending deletion 
list or sets.

--
resolution:  -> rejected
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

[issue31192] "return await coro()" SyntaxError despite being "valid syntax" in PEP 492

[Brian]

New submission from Brian:

PEP 492 lists the following under "valid syntax" and yet 3.5.2 raises a 
SyntaxError:

def foo():
return await coro()

but this works:

def bar():
return await (coro())

--
components: Interpreter Core
messages: 300209
nosy: merrellb
priority: normal
severity: normal
status: open
title: "return await coro()" SyntaxError despite being "valid syntax" in PEP 492
type: behavior
versions: Python 3.5

___
Python tracker 

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

[issue31186] Support heapfix() and heapremove() APIs in heapq module

[Raymond Hettinger]

Changes by Raymond Hettinger :


--
assignee:  -> rhettinger

___
Python tracker 

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

[issue31161] Only check for print and exec parentheses cases for SyntaxError, not subclasses

[Steven D'Aprano]

Steven D'Aprano added the comment:

> > Perhaps the check needs to be limited to just the exact type.
> Looks reasonable to me. Do you want to provide a PR Martijn?

You realise that is making the current traceback *less* informative 
instead of more informative? I think that's going backwards -- useful 
information about the syntax errors are being discarded. "Practicality 
beats purity" -- the current behaviour is helpful, even if it mixes 
information about two errors into one traceback.

--

___
Python tracker 

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

[issue31183] `Dis` module doesn't know how to disassemble async generator or coroutine objects

[George Collins]

George Collins added the comment:

Makes sense. I'll update the PR in a bit, and if anyone is hitting this 
repeatedly and thinks it should be added to 3.6 they can advocate for a policy 
change in the maintaining-consistency-with-previous-new-features corner case.

Thanks, all!

--

___
Python tracker 

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

[issue31191] Fix grammar in threading.Barrier docs

[Saurabh Chaturvedi]

Changes by Saurabh Chaturvedi :


--
nosy: schedutron
priority: normal
pull_requests: 3121
severity: normal
status: open
title: Fix grammar in threading.Barrier docs
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

[issue5001] Remove assertion-based checking in multiprocessing

[drallensmith]

Changes by drallensmith :


--
pull_requests: +3120

___
Python tracker 

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

[issue31190] ./configure: add ability to build and install only shared library (without static libpython3.a)

[Дилян Палаузов]

New submission from Дилян Палаузов:

diff --git a/Makefile.pre.in b/Makefile.pre.in
--- a/Makefile.pre.in
+++ b/Makefile.pre.in
@@ -578,7 +578,7 @@ sharedmods: $(BUILDPYTHON) pybuilddir.txt Modules/_math.o
 
 # Build static library
 # avoid long command lines, same as LIBRARY_OBJS
-$(LIBRARY): $(LIBRARY_OBJS)
+libpython$(LDVERSION).a: $(LIBRARY_OBJS)
-rm -f $@
$(AR) $(ARFLAGS) $@ Modules/getbuildinfo.o
$(AR) $(ARFLAGS) $@ $(PARSER_OBJS)
diff --git a/configure.ac b/configure.ac
--- a/configure.ac
+++ b/configure.ac
@@ -987,9 +987,9 @@ esac
 
 AC_SUBST(LIBRARY)
 AC_MSG_CHECKING(LIBRARY)
-if test -z "$LIBRARY"
+if test -z "$LIBRARY" -a "x$enable_static" != "xno"
 then
-   LIBRARY='libpython$(VERSION)$(ABIFLAGS).a'
+   LIBRARY='libpython$(LDVERSION).a'
 fi
 AC_MSG_RESULT($LIBRARY)
 
@@ -1086,6 +1086,16 @@ then
 fi
 AC_MSG_RESULT($enable_shared)
 
+AC_MSG_CHECKING(for --disable-static)
+AC_ARG_ENABLE(static,
+  AS_HELP_STRING([--disable-static], [disable building static 
python library]))
+AC_MSG_RESULT($enable_static)
+
+if test "x$enable_static" == "xno" -a "x$enable_shared" == "xno"
+then
+   AC_MSG_ERROR(["Both static and shared library disabled"])
+fi
+
 AC_MSG_CHECKING(for --enable-profiling)
 AC_ARG_ENABLE(profiling,
   AS_HELP_STRING([--enable-profiling], [enable C-level code 
profiling]))

--
components: Build
messages: 300206
nosy: dilyan.palauzov
priority: normal
severity: normal
status: open
title: ./configure: add ability to build and install only shared library 
(without static libpython3.a)

___
Python tracker 

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

[issue31189] README.rst: installing multiple versions: typo

[Дилян Палаузов]

New submission from Дилян Палаузов:

It speaks about pythonX.Y but means python3.${subversion}

diff --git a/README.rst b/README.rst
--- a/README.rst
+++ b/README.rst
@@ -190,7 +190,7 @@ script) you must take care that your primary python 
executable is not
 overwritten by the installation of a different version.  All files and
 directories installed using ``make altinstall`` contain the major and minor
 version and can thus live side-by-side.  ``make install`` also creates
-``${prefix}/bin/python3`` which refers to ``${prefix}/bin/pythonX.Y``.  If you
+``${prefix}/bin/python3`` which refers to ``${prefix}/bin/python3.X``.  If you
 intend to install multiple versions using the same prefix you must decide which
 version (if any) is your "primary" version.  Install that version using ``make
 install``.  Install all other versions using ``make altinstall``.

--
assignee: docs@python
components: Documentation
messages: 300205
nosy: dilyan.palauzov, docs@python
priority: normal
severity: normal
status: open
title: README.rst: installing multiple versions: typo
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

[issue31188] Makefile.pre.in: commoninstall: reformat

[Дилян Палаузов]

New submission from Дилян Палаузов:

When @FRAMEWORKALTINSTALLLAST@ expands to "", the last line of recipe 
commoninstall in the resulting Makefile consists solely of two tabs, for which 
emacs complains as "suspicious line".


diff --git a/Makefile.pre.in b/Makefile.pre.in
--- a/Makefile.pre.in
+++ b/Makefile.pre.in
@@ -1069,8 +1069,7 @@ altinstall: commoninstall
 
 commoninstall:  @FRAMEWORKALTINSTALLFIRST@ \
altbininstall libinstall inclinstall libainstall \
-   sharedinstall oldsharedinstall altmaninstall \
-   @FRAMEWORKALTINSTALLLAST@
+   sharedinstall oldsharedinstall altmaninstall 
@FRAMEWORKALTINSTALLLAST@
 
 # Install shared libraries enabled by Setup
 DESTDIRS=  $(exec_prefix) $(LIBDIR) $(BINLIBDEST) $(DESTSHARED)

--
components: Build
messages: 300204
nosy: dilyan.palauzov
priority: normal
severity: normal
status: open
title: Makefile.pre.in: commoninstall: reformat
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

[issue31169] Unknown-source assertion failure in multiprocessing/managers.py

[Antoine Pitrou]

Antoine Pitrou added the comment:

Now fixed in git master thanks to drallensmith.

--
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
versions:  -Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6

___
Python tracker 

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

[issue5001] Remove assertion-based checking in multiprocessing

[Antoine Pitrou]

Antoine Pitrou added the comment:


New changeset 48d9823a0ebde4dfab8bc154bb6df462fb2ee403 by Antoine Pitrou (Allen 
W. Smith, Ph.D) in branch 'master':
bpo-5001, bpo-31169: Fix two uninformative asserts in 
multiprocessing/managers.py (#3078)
https://github.com/python/cpython/commit/48d9823a0ebde4dfab8bc154bb6df462fb2ee403


--

___
Python tracker 

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

[issue31169] Unknown-source assertion failure in multiprocessing/managers.py

[Antoine Pitrou]

Antoine Pitrou added the comment:


New changeset 48d9823a0ebde4dfab8bc154bb6df462fb2ee403 by Antoine Pitrou (Allen 
W. Smith, Ph.D) in branch 'master':
bpo-5001, bpo-31169: Fix two uninformative asserts in 
multiprocessing/managers.py (#3078)
https://github.com/python/cpython/commit/48d9823a0ebde4dfab8bc154bb6df462fb2ee403


--

___
Python tracker 

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

[issue31183] `Dis` module doesn't know how to disassemble async generator or coroutine objects

[Nick Coghlan]

Nick Coghlan added the comment:

While I agree the line is blurry, extending automatic disassembly to cover new 
types is currently still considered a new feature in the dis module rather than 
a bug in the addition of those new types to the language.

Whether or not that's the *right* policy, or if we should consider tweaking it 
so that oversights in `dis` and `inspect` are treated as bugs in the addition 
of affected types, would be a question for python-dev (fortunately, the new 
cherry-pick based workflow means the current PR review can proceed 
independently of that question).

--
versions:  -Python 3.6

___
Python tracker 

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

[issue31169] Unknown-source assertion failure in multiprocessing/managers.py

[drallensmith]

drallensmith added the comment:

Pull request equivalent for the patch submitted. This will not, of course, fix 
this particular bug, but it should help others with debugging such errors.

--

___
Python tracker 

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

[issue31169] Unknown-source assertion failure in multiprocessing/managers.py

[drallensmith]

Changes by drallensmith :


--
pull_requests: +3118

___
Python tracker 

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

[issue5001] Remove assertion-based checking in multiprocessing

[drallensmith]

Changes by drallensmith :


--
pull_requests: +3117

___
Python tracker 

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

[issue1732367] Document the constants in the socket module

[Ammar Askar]

Ammar Askar added the comment:

That makes sense, listing availability for exceptions would certainly make 
everything more succinct. How do you propose we mention that certain options 
don't actually do anything on Windows. Currently I have a footnote in the table 
that links to the MSDN documentation here: 
https://msdn.microsoft.com/en-us/library/windows/desktop/ms740532(v=vs.85).aspx



control+f for "SO_RCVLOWAT" for example

--

___
Python tracker 

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

[issue5001] Remove assertion-based checking in multiprocessing

[drallensmith]

drallensmith added the comment:

Patches (for 2.7 and 3.5; the code is identical, only the line numbers changed) 
for the portion I commented on can be found in issue 31169.

--

___
Python tracker 

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

[issue5001] Remove assertion-based checking in multiprocessing

[Antoine Pitrou]

Antoine Pitrou added the comment:

@drallensmith, the patch you commented on is very old and probably doesn't 
apply anymore.  It would be useful to make an updated patch (or rather PR, as 
we are using Github for development now: see 
https://devguide.python.org/pullrequest/).

--

___
Python tracker 

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

[issue31147] a suboptimal check in list_extend()

[Oren Milman]

Changes by Oren Milman :


--
title: a mostly useless check in list_extend() -> a suboptimal check in 
list_extend()

___
Python tracker 

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

[issue31183] `Dis` module doesn't know how to disassemble async generator or coroutine objects

[George Collins]

George Collins added the comment:

Hm--either/both? I encountered it as a bug ("dis works on my generator object 
and my async generator function, why does it break on my async generator 
object?") but strictly speaking it's a new feature (just as issue21947 was). To 
my mind, adding this level of indirection (finding the code object) for 
generators was a bit of a design decision but once it's in for generators it 
should be in for async generators and coroutines by analogy.

--

___
Python tracker 

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

[issue31187] suboptimal code in Py_ReprEnter()

[Oren Milman]

New submission from Oren Milman:

in Objects/object.c, Py_ReprEnter() does the following:
- try to retrieve the Py_Repr list from the thread-state dict.
- in case the list is not in the dict, add it to the dict as an empty list.
- check whether the received object is in the Py_Repr list, even in case the
  list was just created, and guaranteed to be empty.


I propose to put this check inside an else clause, so that it wouldn't take
place in case the list is guaranteed to be empty, i.e.:
list = _PyDict_GetItemId(dict, _Py_Repr);
if (list == NULL) {
list = PyList_New(0);
...
}
else {
i = PyList_GET_SIZE(list);
while (--i >= 0) {
if (PyList_GET_ITEM(list, i) == obj)
return 1;
}
}

I ran the test suite, and it seems that this change doesn't break anything, so
I would be happy to open a PR for it.

--
components: Interpreter Core
messages: 300193
nosy: Oren Milman
priority: normal
severity: normal
status: open
title: suboptimal code in Py_ReprEnter()
type: performance
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

[issue1732367] Document the constants in the socket module

[Martin Panter]

Martin Panter added the comment:

The general rule for documenting availability seems to be to only list the 
special cases. Many of the socket options are specified by Posix, and seem to 
be available on Linux, Windows, BSD and other OSes. If you say “Availability: 
Linux, Windows”, it could imply that the API is specific to those two 
platforms, and not available on Free BSD or other platforms in general.

--

___
Python tracker 

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

[issue30747] _Py_atomic_* not actually atomic on Windows with MSVC

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
resolution:  -> fixed
stage: patch review -> backport needed
status: open -> closed

___
Python tracker 

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

[issue30747] _Py_atomic_* not actually atomic on Windows with MSVC

[Antoine Pitrou]

Antoine Pitrou added the comment:


New changeset e664d7f89d2b9960d9049237136396e824795cac by Antoine Pitrou (Pär 
Björklund) in branch 'master':
bpo-30747: Attempt to fix atomic load/store (#2383)
https://github.com/python/cpython/commit/e664d7f89d2b9960d9049237136396e824795cac


--

___
Python tracker 

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