[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

Re: Proposed new syntax

[Jussi Piitulainen]

Marko Rauhamaa writes:

> Marko Rauhamaa :
>
>> Jussi Piitulainen :
>>
>>> But what is "set comprehension" in French, German, or Finnish?
>>
>> [...]
>>
>> Myself, I might propose the word "koonta" as a simple Finnish
>> translation for "comprehension".
>
> And maybe "culling" or "gleaning" could work in English.

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

Re: Recent Spam problem

[J. Clarke]

In article , 
skybuck2...@hotmail.com says...
> 
> I see two solutions:
> 
> 1. We build new architecture or adept current one so it's more like a 
> blockchain, have to calculate some hash before being able to post and upload 
> and such.
> 
> or
> 
> 2. We counter-attack by installing a special tool, so we all denial of 
> service attack the source of the message, I am not sure if the source is 
> genuine information, what you make of it:
> 
> NNTP-Posting-Host: 39.52.70.224
> 
> 
> Now the first solution would require a lot of work.
> 
> The second solution would be easy to do.
> 
> My question to you is:
> 
> What solution do you pick of any ? =D

It would be really nice if someone could convince radical Islam that 
spammers are offensive to Mohammed.  After a few of them got hunted down 
and blown up, the rest might take the hint.


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

[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

Re: Proposed new syntax

[Glenn Linderman]

On 8/12/2017 9:12 AM, MRAB wrote:

On 2017-08-12 09:54, Marko Rauhamaa wrote:

Jussi Piitulainen :


Rustom Mody writes:

[ My conjecture: The word ‘comprehension’ used this way in English is
meaningless and is probably an infelicious translation of something
which makes sense in German]


From a Latin word for "taking together", through Middle French,


Metaphors' galore:

English: understand < stand under something


Its etymology is here:

http://www.etymonline.com/index.php?term=understand


French:  comprendre < take something in
German:  verstehen  < stand in front of something
Finnish: ymmärtää   < surround something

all mean the same thing.

I really don't think that "comprehension" in English, in the manner used 
for Python set manipulation, is equivalent at all to the English word 
"understand". For the Python comprehension, the word is more related to 
"complete", or "exhaustive", as in "comprehensive" (covering all 
possibilities). While a comprehensive explanation of something might 
lead to an understanding of that something, teaching is not really a 
requirement of being comprehensive. Being comprehensive is sometimes a 
good attribute of teaching, or understanding, however. One might think 
they understand something, but they only understand in part, they might 
not have a comprehensive understanding. An example of this is Newtonian 
physics gives an understanding of various physical phenomena, but 
Einstein's theory of relativity shows that Newtonian physics is only a 
partial understanding, not a comprehensive one. And maybe someday 
there'll be a theory that demonstrates that relativity is only a partial 
understanding as well (someone chime in if that is already true!).


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

[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

Re: Proposed new syntax

[Marko Rauhamaa]

Marko Rauhamaa :

> Jussi Piitulainen :
>
>> But what is "set comprehension" in French, German, or Finnish?
>
> [...]
>
> Myself, I might propose the word "koonta" as a simple Finnish
> translation for "comprehension".

And maybe "culling" or "gleaning" could work in English.


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

[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

Re: Proposed new syntax

[MRAB]

On 2017-08-12 09:54, Marko Rauhamaa wrote:

Jussi Piitulainen :


Rustom Mody writes:

[ My conjecture: The word ‘comprehension’ used this way in English is
meaningless and is probably an infelicious translation of something
which makes sense in German]


From a Latin word for "taking together", through Middle French,


Metaphors' galore:

English: understand < stand under something


Its etymology is here:

http://www.etymonline.com/index.php?term=understand


French:  comprendre < take something in
German:  verstehen  < stand in front of something
Finnish: ymmärtää   < surround something

all mean the same thing.


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

Re: Proposed new syntax

[Marko Rauhamaa]

Jussi Piitulainen :

> But what is "set comprehension" in French, German, or Finnish?

The comprehension principle has to do with the assumption in Naive Set
Theory that for any logical predicate, there is a corresponding set. To
put it in plain English, every adjective is equivalent to a collection
and vice versa.

[I'm sure you know this, Jussi, but not everybody might.]

The Finnish Wikipedia entry uses the term "abstraktioskeema" (Engl.
"abstraction scheme", https://fi.wikipedia.org/wiki/Joukko-oppi#Aksiomaattinen_joukko-oppi>).
I have not heard that term before, and Google doesn't find other hits
for it.

Myself, I might propose the word "koonta" as a simple Finnish
translation for "comprehension".


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

[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

Re: cpython version

[Larry Martell]

On Sat, Aug 12, 2017 at 10:09 AM, Chris Angelico  wrote:
> On Sat, Aug 12, 2017 at 10:24 PM, Larry Martell  
> wrote:
>> On Sat, Aug 12, 2017 at 8:22 AM, Larry Martell  
>> wrote:
>>> For the first time in my 30+ year career I am, unfortunately, working
>>> on Windows.  A package I need, rpy2, comes in various flavors for
>>> different cpython versions:
>>>
>>> rpy2‑2.7.8‑cp27‑none‑win32.whl
>>> rpy2‑2.7.8‑cp27‑none‑win_amd64.whl
>>> rpy2‑2.7.8‑cp34‑none‑win32.whl
>>> rpy2‑2.7.8‑cp34‑none‑win_amd64.whl
>>> rpy2‑2.7.8‑cp35‑none‑win32.whl
>>> rpy2‑2.7.8‑cp35‑none‑win_amd64.whl
>>> rpy2‑2.8.6‑cp35‑cp35m‑win32.whl
>>> rpy2‑2.8.6‑cp35‑cp35m‑win_amd64.whl
>>> rpy2‑2.8.6‑cp36‑cp36m‑win32.whl
>>> rpy2‑2.8.6‑cp36‑cp36m‑win_amd64.whl
>>>
>>> I am running python version 2.7.13. How can I find out my cpython version?
>>
>> Never mind - not enough sleep or coffee. Obviously cp27 for python 2.7.
>
> Correct. I'd take it one further, though, and suggest that you
> shouldn't need to match it yourself; just use pip to download and
> install the right wheel. It'll match versions, architectures, and
> anything else it needs to match.

Problem is that rpy2 will not install with pip. It gets:

Error: Tried to guess R's HOME but no command 'R' in the PATH.

Even though R's HOME is in the PATH.

Googling this I found it's a very common problem, with no solution I
could find. I finally found a post by the author of rpy that says
"There is no official support for Windows,". and he refers people to
this site http://www.lfd.uci.edu/~gohlke/pythonlibs/#rpy2 that has
'unofficial and unstable' prebuilt windows binaries for it.

If anyone is interested as to why I am embarking on this very
unpleasant task, I have a django app that runs in linux. I have
successfully deployed it with Docker, vagrant/VirtualBox, VMware, kvm,
and on bare metal. But now I have prospective client that refuses to
run linux, even in a VM. So I am tying to get my app running on
Windows Server 2016, piece by painful piece.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: cpython version

[Chris Angelico]

On Sat, Aug 12, 2017 at 10:24 PM, Larry Martell  wrote:
> On Sat, Aug 12, 2017 at 8:22 AM, Larry Martell  
> wrote:
>> For the first time in my 30+ year career I am, unfortunately, working
>> on Windows.  A package I need, rpy2, comes in various flavors for
>> different cpython versions:
>>
>> rpy2‑2.7.8‑cp27‑none‑win32.whl
>> rpy2‑2.7.8‑cp27‑none‑win_amd64.whl
>> rpy2‑2.7.8‑cp34‑none‑win32.whl
>> rpy2‑2.7.8‑cp34‑none‑win_amd64.whl
>> rpy2‑2.7.8‑cp35‑none‑win32.whl
>> rpy2‑2.7.8‑cp35‑none‑win_amd64.whl
>> rpy2‑2.8.6‑cp35‑cp35m‑win32.whl
>> rpy2‑2.8.6‑cp35‑cp35m‑win_amd64.whl
>> rpy2‑2.8.6‑cp36‑cp36m‑win32.whl
>> rpy2‑2.8.6‑cp36‑cp36m‑win_amd64.whl
>>
>> I am running python version 2.7.13. How can I find out my cpython version?
>
> Never mind - not enough sleep or coffee. Obviously cp27 for python 2.7.

Correct. I'd take it one further, though, and suggest that you
shouldn't need to match it yourself; just use pip to download and
install the right wheel. It'll match versions, architectures, and
anything else it needs to match.

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

Re: Proposed new syntax

[Tim Chase]

On 2017-08-11 00:28, Steve D'Aprano wrote:
> What would you expect this syntax to return?
> 
> [x + 1 for x in (0, 1, 2, 999, 3, 4) while x < 5]

[1, 2, 3]

I would see this "while-in-a-comprehension" as a itertools.takewhile()
sort of syntactic sugar:

>>> [x + 1 for x in takewhile(lambda m: m < 5, (0,1,2,999,3,4))]
[1, 2, 3]



> For comparison, what would you expect this to return?
[snip]
> [x + y for x in (0, 1, 2, 999, 3, 4) while x < 5 for y in (100,
> 200)]

This one could make sense as either

[100, 200, 101, 201, 102, 202]

or

[100, 101, 102]

(I think the default evaluation order of nested "for"s in a
comprehension would produce the former rather than the latter)

Thus it would be good to define behavior for both of these cases:

[x + y for x in (0, 1, 2, 999, 3, 4) while x < 5 for y in (100, 200)]

vs.

[x + y for x in (0, 1, 2, 999, 3, 4) for y in (100, 200) while x < 5]

-tkc



Things would get even weirder when you have nested loopings like
that and one of the sources is an iterator.

-tkc




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

[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

Re: cpython version

[Larry Martell]

On Sat, Aug 12, 2017 at 8:22 AM, Larry Martell  wrote:
> For the first time in my 30+ year career I am, unfortunately, working
> on Windows.  A package I need, rpy2, comes in various flavors for
> different cpython versions:
>
> rpy2‑2.7.8‑cp27‑none‑win32.whl
> rpy2‑2.7.8‑cp27‑none‑win_amd64.whl
> rpy2‑2.7.8‑cp34‑none‑win32.whl
> rpy2‑2.7.8‑cp34‑none‑win_amd64.whl
> rpy2‑2.7.8‑cp35‑none‑win32.whl
> rpy2‑2.7.8‑cp35‑none‑win_amd64.whl
> rpy2‑2.8.6‑cp35‑cp35m‑win32.whl
> rpy2‑2.8.6‑cp35‑cp35m‑win_amd64.whl
> rpy2‑2.8.6‑cp36‑cp36m‑win32.whl
> rpy2‑2.8.6‑cp36‑cp36m‑win_amd64.whl
>
> I am running python version 2.7.13. How can I find out my cpython version?

Never mind - not enough sleep or coffee. Obviously cp27 for python 2.7.
-- 
https://mail.python.org/mailman/listinfo/python-list

cpython version

[Larry Martell]

For the first time in my 30+ year career I am, unfortunately, working
on Windows.  A package I need, rpy2, comes in various flavors for
different cpython versions:

rpy2‑2.7.8‑cp27‑none‑win32.whl
rpy2‑2.7.8‑cp27‑none‑win_amd64.whl
rpy2‑2.7.8‑cp34‑none‑win32.whl
rpy2‑2.7.8‑cp34‑none‑win_amd64.whl
rpy2‑2.7.8‑cp35‑none‑win32.whl
rpy2‑2.7.8‑cp35‑none‑win_amd64.whl
rpy2‑2.8.6‑cp35‑cp35m‑win32.whl
rpy2‑2.8.6‑cp35‑cp35m‑win_amd64.whl
rpy2‑2.8.6‑cp36‑cp36m‑win32.whl
rpy2‑2.8.6‑cp36‑cp36m‑win_amd64.whl

I am running python version 2.7.13. How can I find out my cpython version?
-- 
https://mail.python.org/mailman/listinfo/python-list

[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

Re: Proposed new syntax

[Rustom Mody]

On Saturday, August 12, 2017 at 5:25:43 PM UTC+5:30, Peter Otten wrote:
> Rustom Mody wrote:
> 
> > [ My conjecture: The word ‘comprehension’ used this way in English is
> > meaningless and is probably an infelicious translation of something which
> > makes sense in German]
> 
> The meaning of comprehension is probably closer to "comprise" than 
> "comprehend".
> 
> https://en.wiktionary.org/wiki/comprise
> """
> ...from Latin comprehendere...
> 
> ...To be made up of; to consist of...
> """

Yeah… I guessed something like that

1,2,3,4
is ‘just’ a set
which, when we put brackets round them
{1,2,3,4}
is, well, 'comprised' :-)

Sounds silly… Less so if we say it as “The set comprising of…"

[In all probability when Zermelo/Fraenkel were doing their stuff 
they did not really distinguish between what today python calls
a set-literal and a set-comprehension]
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Proposed new syntax

[Peter Otten]

Rustom Mody wrote:

> [ My conjecture: The word ‘comprehension’ used this way in English is
> meaningless and is probably an infelicious translation of something which
> makes sense in German]

The meaning of comprehension is probably closer to "comprise" than 
"comprehend".

https://en.wiktionary.org/wiki/comprise
"""
...from Latin comprehendere...

...To be made up of; to consist of...
"""


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

[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

Re: Proposed new syntax

[Jussi Piitulainen]

Marko Rauhamaa writes:

> Jussi Piitulainen writes:
>
>> Rustom Mody writes:
>>> [ My conjecture: The word ‘comprehension’ used this way in English is
>>> meaningless and is probably an infelicious translation of something
>>> which makes sense in German]
>>
>> From a Latin word for "taking together", through Middle French,
>
> Metaphors' galore:
>
>English: understand < stand under something
>French:  comprendre < take something in
>German:  verstehen  < stand in front of something
>Finnish: ymmärtää   < surround something
>
> all mean the same thing.

English also has "comprehend" (in English it seems to me opaque).

Finnish also has "käsittää" 'understand' < 'get a hold of', from "käsi"
'hand' (at least it looks to me like it might be so derived).

But what is "set comprehension" in French, German, or Finnish?
-- 
https://mail.python.org/mailman/listinfo/python-list

[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

Re: Proposed new syntax

[Marko Rauhamaa]

Jussi Piitulainen :

> Rustom Mody writes:
>> [ My conjecture: The word ‘comprehension’ used this way in English is
>> meaningless and is probably an infelicious translation of something
>> which makes sense in German]
>
> From a Latin word for "taking together", through Middle French,

Metaphors' galore:

   English: understand < stand under something
   French:  comprendre < take something in
   German:  verstehen  < stand in front of something
   Finnish: ymmärtää   < surround something

all mean the same thing.


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

Re: Proposed new syntax

[Jussi Piitulainen]

Rustom Mody writes:

> [ My conjecture: The word ‘comprehension’ used this way in English is
> meaningless and is probably an infelicious translation of something
> which makes sense in German]

From a Latin word for "taking together", through Middle French,
according to this source, which has further details:

https://en.wiktionary.org/wiki/comprehension
https://en.wiktionary.org/wiki/comprehensio#Latin
https://en.wiktionary.org/wiki/comprehendo#Latin
-- 
https://mail.python.org/mailman/listinfo/python-list