[issue32911] Doc strings no longer stored in body of AST

[Ned Deily]

Ned Deily  added the comment:

Based on more recent discussions and indirect feedback from downstream users 
(primarily the recent IPython experience), I am reluctantly re-opening this 
issue for 3.7.0.  I take responsibility for encouraging us earlier in the beta 
phase to continue with the feature as it stood, thereby prioritizing schedule 
over any technical issues.  Although it is now very late in the 3.7.0 cycle, 
with the newly expressed concerns my opinion has changed: I think we owe it to 
our downstream users to think about this one more time.

I agree with Benjamin's remark that it is very late in the 3.7 cycle to be 
considering new or revised APIs for 3.7.0.  So it seems to me we have only two 
practical alternatives at this point:

A. Proceed with 3.7.0rc1 as planned with the docstrings feature as it now 
stands and consider API changes for 3.8.

or

B. Revert the feature now for 3.7.0, retargeting for 3.8, and produce a 3.7.0b5 
on a somewhat shorter cycle to allow downstream users to adapt to the removal.

I don't know how controversial making this decision will be but I think we need 
to move quickly as this is now *the* blocker for 3.7.0.  Coming now at the 
start of a weekend, in some countries a 3-day holiday weekend, I do want to 
make sure that the major stakeholders involved with this issue get a chance to 
"vote", although ultimately it will be up to the release manager (me) to make 
the final decision.  So, to be clear, we will not be deciding here and now what 
the API should be if we were to retarget for 3.8; please save that discussion 
for later.  The only question open right now is a vote for either option A 
(proceed as is) or option B (revert for 3.7 and retarget).  Let's set a limit 
for "voting" until Tuesday 2018-05-29 18:00 UTC (to cover the holiday weekend) 
with the proviso that if a clear consensus one way or the other appears before 
that we may cut the period short and proceed to implemention.

I know this is not a pleasant task especially at this late date.  I apologize 
to everyone, especially to Inada-san, for dragging this out.  I certainly 
appreciate the hard work that has gone into this feature so far and look 
forward to seeing it in either 3.7 or 3.8.

--
priority:  -> release blocker
resolution: wont fix -> 
stage: resolved -> commit review
status: closed -> open

___
Python tracker 

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

[issue33616] typing.NoReturn is undocumented

[miss-islington]

Change by miss-islington :


--
pull_requests: +6748

___
Python tracker 

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

[issue33616] typing.NoReturn is undocumented

[miss-islington]

Change by miss-islington :


--
pull_requests: +6747

___
Python tracker 

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

[issue33351] Support compiling with clang-cl on Windows

[Ethan Smith]

Ethan Smith  added the comment:

After wrangling with some missing compiler intrinsics, I've been able to get 
CPython to build with an almost vanilla clang-cl!

I plan on upstreaming the patches to the LLVM project once I clean them up a 
bit. After that I will clean up the CPython patches and send a PR.

I also ran performance with master built on MSVC compared to my branch on 
clang-cl with computed-goto enabled (I wasn't sure if there are other things 
that may be possible to turn on, computed goto seemed an obvious win). The 
results are decent, but some things, like json loads, are much slower (not sure 
why that is). The full report:


msvc.json
=

Performance version: 0.6.1
Report on Windows-10-10.0.17672-SP0
Number of logical CPUs: 12
Start date: 2018-05-24 03:40:09.082701
End date: 2018-05-24 04:08:57.993717

clang2goto.json
===

Performance version: 0.6.1
Report on Windows-10-10.0.17672-SP0
Number of logical CPUs: 12
Start date: 2018-05-24 04:29:01.214005
End date: 2018-05-24 04:57:08.774299

### 2to3 ###
Mean +- std dev: 675 ms +- 31 ms -> 655 ms +- 32 ms: 1.03x faster
Significant (t=3.55)

### chameleon ###
Mean +- std dev: 19.5 ms +- 0.5 ms -> 18.1 ms +- 0.7 ms: 1.08x faster
Significant (t=13.19)

### chaos ###
Mean +- std dev: 230 ms +- 6 ms -> 209 ms +- 8 ms: 1.10x faster
Significant (t=16.39)

### crypto_pyaes ###
Mean +- std dev: 212 ms +- 8 ms -> 197 ms +- 8 ms: 1.07x faster
Significant (t=9.72)

### deltablue ###
Mean +- std dev: 15.2 ms +- 0.6 ms -> 14.2 ms +- 0.5 ms: 1.07x faster
Significant (t=10.23)

### django_template ###
Mean +- std dev: 222 ms +- 9 ms -> 210 ms +- 8 ms: 1.06x faster
Significant (t=8.10)

### dulwich_log ###
Mean +- std dev: 235 ms +- 13 ms -> 230 ms +- 12 ms: 1.02x faster
Significant (t=2.18)

### fannkuch ###
Mean +- std dev: 905 ms +- 11 ms -> 802 ms +- 15 ms: 1.13x faster
Significant (t=42.95)

### float ###
Mean +- std dev: 226 ms +- 9 ms -> 197 ms +- 8 ms: 1.15x faster
Significant (t=18.71)

### go ###
Mean +- std dev: 485 ms +- 10 ms -> 445 ms +- 8 ms: 1.09x faster
Significant (t=24.60)

### hexiom ###
Mean +- std dev: 19.9 ms +- 0.9 ms -> 18.3 ms +- 0.8 ms: 1.08x faster
Significant (t=9.51)

### html5lib ###
Mean +- std dev: 156 ms +- 9 ms -> 149 ms +- 9 ms: 1.05x faster
Significant (t=4.31)

### json_dumps ###
Mean +- std dev: 23.4 ms +- 1.2 ms -> 23.0 ms +- 1.1 ms: 1.02x faster
Not significant

### json_loads ###
Mean +- std dev: 49.3 us +- 2.2 us -> 93.2 us +- 8.7 us: 1.89x slower
Significant (t=-37.79)

### logging_format ###
Mean +- std dev: 25.3 us +- 1.3 us -> 23.4 us +- 1.2 us: 1.08x faster
Significant (t=8.48)

### logging_silent ###
Mean +- std dev: 368 ns +- 14 ns -> 340 ns +- 21 ns: 1.08x faster
Significant (t=8.69)

### logging_simple ###
Mean +- std dev: 23.1 us +- 1.4 us -> 20.6 us +- 0.9 us: 1.12x faster
Significant (t=11.66)

### mako ###
Mean +- std dev: 36.7 ms +- 1.8 ms -> 36.0 ms +- 1.7 ms: 1.02x faster
Not significant

### meteor_contest ###
Mean +- std dev: 189 ms +- 9 ms -> 175 ms +- 9 ms: 1.08x faster
Significant (t=9.09)

### nbody ###
Mean +- std dev: 274 ms +- 12 ms -> 222 ms +- 8 ms: 1.24x faster
Significant (t=28.22)

### nqueens ###
Mean +- std dev: 198 ms +- 8 ms -> 174 ms +- 8 ms: 1.14x faster
Significant (t=16.67)

### pathlib ###
Mean +- std dev: 343 ms +- 19 ms -> 338 ms +- 18 ms: 1.02x faster
Not significant

### pickle ###
Mean +- std dev: 20.9 us +- 0.8 us -> 19.9 us +- 0.5 us: 1.05x faster
Significant (t=8.91)

### pickle_dict ###
Mean +- std dev: 50.0 us +- 1.9 us -> 51.2 us +- 3.0 us: 1.02x slower
Significant (t=-2.62)

### pickle_list ###
Mean +- std dev: 7.61 us +- 0.32 us -> 7.06 us +- 0.36 us: 1.08x faster
Significant (t=8.92)

### pickle_pure_python ###
Mean +- std dev: 964 us +- 52 us -> 879 us +- 43 us: 1.10x faster
Significant (t=9.72)

### pidigits ###
Mean +- std dev: 257 ms +- 5 ms -> 254 ms +- 9 ms: 1.01x faster
Not significant

### python_startup ###
Mean +- std dev: 69.6 ms +- 8.3 ms -> 69.5 ms +- 6.3 ms: 1.00x faster
Not significant

### python_startup_no_site ###
Mean +- std dev: 57.7 ms +- 6.6 ms -> 58.2 ms +- 6.0 ms: 1.01x slower
Not significant

### raytrace ###
Mean +- std dev: 1.00 sec +- 0.02 sec -> 0.94 sec +- 0.02 sec: 1.07x faster
Significant (t=21.49)

### regex_compile ###
Mean +- std dev: 335 ms +- 5 ms -> 306 ms +- 10 ms: 1.10x faster
Significant (t=20.75)

### regex_dna ###
Mean +- std dev: 237 ms +- 7 ms -> 266 ms +- 7 ms: 1.13x slower
Significant (t=-23.71)

### regex_effbot ###
Mean +- std dev: 4.42 ms +- 0.17 ms -> 4.82 ms +- 0.20 ms: 1.09x slower
Significant (t=-12.07)

### regex_v8 ###
Mean +- std dev: 45.2 ms +- 15.5 ms -> 39.7 ms +- 2.8 ms: 1.14x faster
Significant (t=2.74)

### richards ###
Mean +- std dev: 152 ms +- 8 ms -> 142 ms +- 9 ms: 1.07x faster
Significant (t=6.19)

### scimark_fft ###
Mean +- std dev: 665 ms +- 12 ms -> 593 ms +- 12 ms: 1.12x faster
Significant (t=32.36)

### scimark_lu ###
Mean +- std dev: 327 ms +- 11 ms -> 

[issue32911] Doc strings no longer stored in body of AST

[Ned Deily]

Ned Deily  added the comment:

For the record, Serhiy commented on this issue today in a thread on the 
python-committers list:

"I have doubts about two issues. I feel the responsibility for them because I 
had the opportunity to solve them before, but I lost it.

1. Changes in the AST. Few third-party projects was broken by it and already 
are fixed. I suppose yet few projects will be changed after 3.7 be released. It 
is interesting that IPython was broken in different way than other projects. It 
was needed to reintroduce the docstring in the list of statements, effectively 
reverting the 3.7 change. IPython allows to enter several statements at prompt, 
and therefore it compiles them with the 'exec' mode instead of 'single' as the 
CPython REPL and IDLE shell. Currently CPython doesn't allow you to paste 
arbitrary script like the following:

if a:
b
if c:
d

You need to add an empty line between top-level complex statements. If one time 
CPython will add support of pasting several statements without empty lines 
between, it might need to add the same hack as IPython. I afraid that we might 
be needed to change AST again, in 3.7.1 or in 3.8.0."

And later:

"Inada's patch looked complex (actually it mostly restored the code before his 
previous change). We didn't know about IPython and we decided that it is not 
worth to change this code at this stage (after beta2). And definitely it will 
be later to do this after rc1."

Full context/content starting here:
https://mail.python.org/pipermail/python-committers/2018-May/005467.html

--

___
Python tracker 

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

[issue32911] Doc strings no longer stored in body of AST

[Benjamin Peterson]

Benjamin Peterson  added the comment:

Regardless of the value of .docstring change, it seems it had some unexpected 
consequences. I think providing a new mode for compile mulitline statements is 
a reasonable way to address those consequences going forward. That said, it's 
extremely late in the lifecycle of 3.7 to be thinking about new APIs. How about 
rolling back the whole .docstring change for 3.7? Then, it can be landed again 
with compile(..., mode='multiline) for 3.8.

--

___
Python tracker 

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

[issue33616] typing.NoReturn is undocumented

[Ivan Levkivskyi]

Change by Ivan Levkivskyi :


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

___
Python tracker 

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

[issue33625] Release GIL for grp.getgr{nam, gid} and pwd.getpw{nam, uid}

[Mariatta Wijaya]

Mariatta Wijaya  added the comment:

In the future please use gender-neutral words such as "everyone", "people", or
"folks" instead of "guys". Thanks.

--
nosy: +Mariatta

___
Python tracker 

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

[issue33642] IDLE: Use variable number of lines in CodeContext

[Terry J. Reedy]

Terry J. Reedy  added the comment:

2 quick thoughts.

1. I am not sure we can/should change the default, as it interacts with the 
recorded user changes for past versions.  The default is that we never change 
defaults.  (Having one user config for all Python/IDLE versions is a curse as 
well as a blessing.  I anticipate having to do something different, sometime.

2. I was thinking for '' instead of a blank line for when CC is on 
but there is no real context.  I think we should try both and see what seems 
better in use while moving down through a file.

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

[issue33610] IDLE: Make multiple improvements to CodeContext

[Cheryl Sabella]

Cheryl Sabella  added the comment:

For item 7 - #33642.

--
dependencies: +IDLE: Use variable number of lines in CodeContext

___
Python tracker 

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

[issue33642] IDLE: Use variable number of lines in CodeContext

[Cheryl Sabella]

Change by Cheryl Sabella :


--
keywords: +patch, patch
pull_requests: +6744, 6745
stage:  -> patch review

___
Python tracker 

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

[issue33642] IDLE: Use variable number of lines in CodeContext

[Cheryl Sabella]

Change by Cheryl Sabella :


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

___
Python tracker 

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

[issue22703] Idle Code Context menu entrie(s)

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Changing title since 'separation' has already been done.  Adding a user 
configuration option is a separate issue.

--
title: Idle Code Context: separate changing current and future editors -> Idle 
Code Context menu entrie(s)

___
Python tracker 

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

[issue33642] IDLE: Use variable number of lines in CodeContext

[Cheryl Sabella]

New submission from Cheryl Sabella :

Item 7 from #33610:
Change fixed # of lines to variable # of lines as needed, up to limit.  About 
15 is limit for 4-space indents in 80 char lines. 

* Change default number of lines to be 15 in config.
* Label in config dialog.
* Initialize context to be one blank line to show it's turned on.
* Remove padding of blank lines.
* Modify tests to show variable number of lines in context text instead of 
lines scrolling out of view.

Tip: For manual tests, help.py works really well in viewing 15 lines.

--
assignee: terry.reedy
components: IDLE
messages: 317649
nosy: cheryl.sabella, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE: Use variable number of lines in CodeContext
type: enhancement
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

[issue22703] Idle Code Context: separate changing current and future editors

[Terry J. Reedy]

Terry J. Reedy  added the comment:

An experienced non-CS computer user I asked does not like 'toggle x' or 'switch 
x', but would like whichever of 'show x' and 'hide x' is appropriate (rather 
than both).  For breakpoints, this would mean one menu entry, either 'set 
breakpoint' or 'clear breakpoint', rather than both (as currently).

A few Menu entries are labelled 'Show x'.  They don't need a 'Hide' menu  
variant as hiding is done otherwise.

Checkmarks are OK, but she would prefer an empty box or circle as an dialogs, 
so that clicking more obviously means 'turn on' when in the 'off' state.

It occurs to me now, after  at least 20 years of using menus,  that the logic 
of 'blank' is that 'blank' means 'do something', so that 'check' means 
'something was done, undo it'.  But I think that clicking 'clear breakpoint', 
for instance, is clearer than clicking 'v breakpoint', where 'v' represents a 
checkmark'.

--

___
Python tracker 

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

[issue33615] test__xxsubinterpreters crashed on x86 Gentoo Refleaks 3.x

[Eric Snow]

Eric Snow  added the comment:

no worries :)

--

___
Python tracker 

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

[issue33615] test__xxsubinterpreters crashed on x86 Gentoo Refleaks 3.x

[STINNER Victor]

STINNER Victor  added the comment:

Oh, I didn't know that it was a 3.8-only issue.

--

___
Python tracker 

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

[issue33615] test__xxsubinterpreters crashed on x86 Gentoo Refleaks 3.x

[Eric Snow]

Eric Snow  added the comment:

Correct.  These failures are only on master.

--

___
Python tracker 

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

[issue32493] UUID Module - FreeBSD build failure

[Ned Deily]

Change by Ned Deily :


--
priority: deferred blocker -> 

___
Python tracker 

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

[issue32493] UUID Module - FreeBSD build failure

[STINNER Victor]

STINNER Victor  added the comment:

Thank you Serhiy Storchaka for the fix! If someone cares about AIX, please open 
a different issue. (AIX has other more important functions that you be fixed, 
IHMO.)

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

[issue32458] test_asyncio: test_start_tls_server_1() fails randomly

[Yury Selivanov]

Yury Selivanov  added the comment:

Not at my computer right now, can do it tomorrow.

--

___
Python tracker 

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

[issue32493] UUID Module - FreeBSD build failure

[miss-islington]

miss-islington  added the comment:


New changeset 5734f41a9b46b4fd65b6ba90240b108f8a0b7c57 by Miss Islington (bot) 
in branch '3.7':
bpo-32493: Fix uuid.uuid1() on FreeBSD. (GH-7099)
https://github.com/python/cpython/commit/5734f41a9b46b4fd65b6ba90240b108f8a0b7c57


--
nosy: +miss-islington

___
Python tracker 

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

[issue33615] test__xxsubinterpreters crashed on x86 Gentoo Refleaks 3.x

[Ned Deily]

Ned Deily  added the comment:

Victor:

>It would be nice to fix this bug before Python 3.7.0 final: either skip the 
>test, or fix it.

These tests (and failures) are only on master / 3.x, not 3.7, right?  If so, 
they have no bearing on 3.7.0.

--
nosy: +ned.deily
priority: deferred blocker -> 

___
Python tracker 

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

[issue32458] test_asyncio: test_start_tls_server_1() fails randomly

[STINNER Victor]

STINNER Victor  added the comment:

> I'm OK to skip it for now. Writing functional tests is super hard because 
> some buildbots are super slow and unpredictable.

Would you mind to write a PR to skip the PR? So you will feel guilty and will 
try to remind to fix it!

--

___
Python tracker 

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

[issue32458] test_asyncio: test_start_tls_server_1() fails randomly

[Yury Selivanov]

Yury Selivanov  added the comment:

I'm OK to skip it for now. Writing functional tests is super hard because some 
buildbots are super slow and unpredictable.

--

___
Python tracker 

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

[issue32458] test_asyncio: test_start_tls_server_1() fails randomly

[STINNER Victor]

STINNER Victor  added the comment:

It would be nice to fix this bug before Python 3.7.0 final: either skip the 
test, or fix it. Flaky tests can be very annoying. For example, the full test 
suite is run to build a Red Hat package. If a single test fails, the package 
build fails and should be retried whereas it's slow.

I understood that fixing the root cause might require to rewrite the test, so I 
don't expect a quick fix on this test. The issue is open since last December... 
Maybe we can skip the test but fix it in Python 3.7.1?

--
priority: high -> deferred blocker

___
Python tracker 

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

[issue33615] test__xxsubinterpreters crashed on x86 Gentoo Refleaks 3.x

[STINNER Victor]

STINNER Victor  added the comment:

It would be nice to fix this bug before Python 3.7.0 final: either skip the 
test, or fix it.

Since the functions are still private, skipping a single test (until it's 
fixed) should be fine.

--
priority: normal -> deferred blocker

___
Python tracker 

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

[issue22703] Idle Code Context: separate changing current and future editors

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Cheryl, you are right.  The extension-feature conversion made this issue mostly 
obsolete.  Editors start without code context and the menu only toggles the 
current window.

If I had thought about it, I would have closed this or added an update last 
fall.  And I should have retested this yesterday.  The differences from what I 
proposed above are more or less intentional.  So don't write a patch until we 
agree on a list of changes.

I re-read #17535, msg225416, 2014-08-16 17:18, where this started, but not the 
discussions on the tracker and PR about the conversion details.
---

MENU has no checkmark: I noted on msg225416 that the checkmark never indicated 
the current state of the current window and that there was hardly any need to 
keep it and change its meaning, because the current state of the current window 
is plainly visible.  I am currently inclined to leave it off.  Instead, I would 
like to prefix 'Code Context' with 'Toggle'.  What do you think?  Whatever we 
do would be a precedent for other local options, such as a line number toggle, 
both on this menu and a context menu.

Since the effect of 'Code Context' is only local and not global, there should 
at least be a line separator after the global settings entry.  I might even 
like a dummy entry such as 'Current window:' after the line.

Local options should also be on the right-click context menu.  Based on my 
experience with using breakpoints, I want to try replacing the current line 
options 'Set Breakpoint' and 'Clear Breakpoint' with 'Toggle Breakpoint'.  
'Toggle Code Context' would go with this.  
---

Initial presence of CC in new windows: config-extensions.def has
  [CodeContext]
  numlines= 3
  visible= False
'numlines' is read and used.  'visible' is ignored.  To be sure, I added 
'visible=True' to config-extensions.cfg and it made no difference.

To enable CC defaulting to on for new editors, we would add a checkbox "[ ] 
Initially Visible" after the "Context lines   [ ]" box on the General tab, much 
like the "[ ] Bell on Mismatch" above on the same tab.  Saving changes would be 
the same.  The added wiring would be a bit different.

This would not be re-enabling anything that properly worked before the 
conversion.  One had to enable the feature, turn on 'visible' and then either 
never use the toggle or go back through the dialog to turn on 'visible' after 
the toggle turned it off.  Then, once one had CC running, there was the 
tradeoff between too many blank lines and too few real context lines.  I 
suspect most people left CC disabled even after trying it out.

I don't feel it a rush to add this option until it is plausibly something 
someone might do.  The aim of #33610 is to make this be true.  In any case, 
this might be better as a PR separate from fiddling with the menus.


I intentionally did not say 're-enable' 
As I remember, I did not do this because I could not believe that much of 
anyone was intentionally setting visible=True, at least for very long.  using 
this option.  Having too many blank lines



Open editor, no cc. Toggle, cc. Open another editor, no cc.


Close IDLE.  Add the following .idlerc/config-extensions.cff.
[CodeContext]
visible= True
OpenIDLE, open editor, no cc.

--

___
Python tracker 

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

[issue32493] UUID Module - FreeBSD build failure

[miss-islington]

Change by miss-islington :


--
pull_requests: +6743

___
Python tracker 

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

[issue32493] UUID Module - FreeBSD build failure

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 17d8830312d82e7de42ab89739b0771f712645ff by Victor Stinner 
(Serhiy Storchaka) in branch 'master':
bpo-32493: Fix uuid.uuid1() on FreeBSD. (GH-7099)
https://github.com/python/cpython/commit/17d8830312d82e7de42ab89739b0771f712645ff


--

___
Python tracker 

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

[issue33639] Use high-performance os.sendfile() in shutil.copy*

[STINNER Victor]

STINNER Victor  added the comment:

> I'm a bit depressed by the number of issues here that have a good patch 
> waiting to be merged, or even read, and that languish for years.

I'm really sorry about that. We, core developers, are doing our best, but we 
are 34 active core developers who merged 5000 pull requests in 1 year. We don't 
scale well :-(

We are working on getting more people onboard.

--

___
Python tracker 

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

[issue33640] uuid: endian of the bytes argument is not documented

[STINNER Victor]

STINNER Victor  added the comment:

At least, the UUID.bytes *attribute* is documented as using big endian:
https://docs.python.org/dev/library/uuid.html#uuid.UUID.bytes

--

___
Python tracker 

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

[issue33629] test_importlib creates a coredump on AMD64 FreeBSD 10.x Shared 3.7

[STINNER Victor]

Change by STINNER Victor :


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

[issue33354] Python2: test_ssl fails on non-ASCII path

[STINNER Victor]

STINNER Victor  added the comment:

Thanks Pablo for your fix!

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

[issue33354] Python2: test_ssl fails on non-ASCII path

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 19f6bd06af3c7fc0db5f96878aaa68f5589ff13e by Victor Stinner (Pablo 
Galindo) in branch '2.7':
bpo-33354: Fix test_ssl when a filename cannot be encoded (GH-6613)
https://github.com/python/cpython/commit/19f6bd06af3c7fc0db5f96878aaa68f5589ff13e


--

___
Python tracker 

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

[issue33641] Add links to RFCs

[Serhiy Storchaka]

Change by Serhiy Storchaka :


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

___
Python tracker 

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

[issue33639] Use high-performance os.sendfile() in shutil.copy*

[desbma]

desbma  added the comment:

Honestly, whatever gets this thing moving forward is good with me.

I'm a bit depressed by the number of issues here that have a good patch waiting 
to be merged, or even read, and that languish for years.

I haven't read your patch in detail, but if others agree that it is better than 
mine and can be merged, let's do it.

--

___
Python tracker 

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

[issue33641] Add links to RFCs

[Serhiy Storchaka]

New submission from Serhiy Storchaka :

The proposed PR replaces "RFC XYZ" with ":rfc:`XYZ`". This adds hyperlinks to 
RFC documents. Actually 85% of all RFC references already use this markup, the 
PR change the rest 15% written as plain text.

--
assignee: docs@python
components: Documentation
messages: 317629
nosy: docs@python, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Add links to RFCs
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

[issue25156] shutil.copyfile should internally use os.sendfile when possible

[STINNER Victor]

STINNER Victor  added the comment:

Different implementation: bpo-33639.

--
nosy: +vstinner

___
Python tracker 

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

[issue33639] Use high-performance os.sendfile() in shutil.copy*

[Giampaolo Rodola']

Giampaolo Rodola'  added the comment:

Oh! I got confused by the fact that #25063 was rejected due to concerns about 
copyfileobj() otherwise I would have commented on your patch which I totally 
missed. Yes, this overlaps with #25156 patch but it uses the same logic of 
socket.sendfile() which IMO is more robust. If you agree I'd close #25156 and 
continue in here, and I'm more than happy to co-author the contribution if 
that's OK with you.

--

___
Python tracker 

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

[issue33640] uuid: endian of the bytes argument is not documented

[STINNER Victor]

New submission from STINNER Victor :

I don't understand what is the endian of the 'bytes' parameter of the uuid.UUID 
constructor:
https://docs.python.org/dev/library/uuid.html#uuid.UUID

According to examples, it seems like the endian is big endian, but I'm not sure.

Related issue: bpo-32493.

--
assignee: docs@python
components: Documentation
messages: 317626
nosy: docs@python, vstinner
priority: normal
severity: normal
status: open
title: uuid: endian of the bytes argument is not documented
versions: Python 2.7, 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

[issue32374] Document that m_traverse for multi-phase initialized modules can be called with m_state=NULL

[miss-islington]

miss-islington  added the comment:


New changeset fc0356d2a34719df517a5056bf1a3709850776cf by Miss Islington (bot) 
in branch '3.6':
bpo-33629: Prevent coredump in test_importlib (GH-7090)
https://github.com/python/cpython/commit/fc0356d2a34719df517a5056bf1a3709850776cf


--

___
Python tracker 

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

[issue33629] test_importlib creates a coredump on AMD64 FreeBSD 10.x Shared 3.7

[miss-islington]

miss-islington  added the comment:


New changeset fc0356d2a34719df517a5056bf1a3709850776cf by Miss Islington (bot) 
in branch '3.6':
bpo-33629: Prevent coredump in test_importlib (GH-7090)
https://github.com/python/cpython/commit/fc0356d2a34719df517a5056bf1a3709850776cf


--

___
Python tracker 

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

[issue33354] Python2: test_ssl fails on non-ASCII path

[STINNER Victor]

STINNER Victor  added the comment:

Oh. I approved the PR but it's not merged yet :-/

--

___
Python tracker 

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

[issue33639] Use high-performance os.sendfile() in shutil.copy*

[desbma]

desbma  added the comment:

Duplicate of https://bugs.python.org/issue25156 ?

--

___
Python tracker 

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

[issue32374] Document that m_traverse for multi-phase initialized modules can be called with m_state=NULL

[miss-islington]

miss-islington  added the comment:


New changeset d9eb22c67c38b45764dd924801c72092770d200f by Miss Islington (bot) 
in branch '3.7':
bpo-33629: Prevent coredump in test_importlib (GH-7090)
https://github.com/python/cpython/commit/d9eb22c67c38b45764dd924801c72092770d200f


--

___
Python tracker 

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

[issue33629] test_importlib creates a coredump on AMD64 FreeBSD 10.x Shared 3.7

[miss-islington]

miss-islington  added the comment:


New changeset d9eb22c67c38b45764dd924801c72092770d200f by Miss Islington (bot) 
in branch '3.7':
bpo-33629: Prevent coredump in test_importlib (GH-7090)
https://github.com/python/cpython/commit/d9eb22c67c38b45764dd924801c72092770d200f


--
nosy: +miss-islington

___
Python tracker 

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

[issue31453] Debian Sid/Buster: Cannot enable TLS 1.0/1.1 with PROTOCOL_TLS

[Kurt Roeckx]

Kurt Roeckx  added the comment:

The effect is the same as calling SSL_CTX_set_min_proto_version().

--

___
Python tracker 

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

[issue31453] Debian Sid/Buster: Cannot enable TLS 1.0/1.1 with PROTOCOL_TLS

[Christian Heimes]

Christian Heimes  added the comment:

Thanks Kurt,

which API are you using to disable TLS 1.0 and 1.1? Is it the old 
SSL_CTX_set_options() or the new SSL_CTX_set_min/max_proto_version() API?

--

___
Python tracker 

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

[issue33622] Fix errors handling in the garbage collector

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset 9044cd675902b438bc500908e410382ff48299d8 by Serhiy Storchaka in 
branch '2.7':
[2.7] bpo-33622: Fix issues with handling errors in the GC. (GH-7078) (#7096)
https://github.com/python/cpython/commit/9044cd675902b438bc500908e410382ff48299d8


--

___
Python tracker 

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

[issue32374] Document that m_traverse for multi-phase initialized modules can be called with m_state=NULL

[STINNER Victor]

STINNER Victor  added the comment:

MultiPhaseExtensionModuleTests.test_bad_traverse() of 
Lib/test/test_importlib/extension/test_loader.py runs the following code:
---
import importlib.util as util
spec = util.find_spec('_testmultiphase')
spec.name = '_testmultiphase_with_bad_traverse'
m = spec.loader.create_module(spec)
---

And then check that the Python "failed": that the exit code is non-zero...

That's a weak test: if the script fails before calling 
spec.loader.create_module(), the test also pass. If the function raises an 
exception but don't crash, the test pass as well.

More generally, I'm not sure about the idea of making sure that doing bad stuff 
with traverse does crash. What is the purpose of the test?

In the meanwhile, I fixed bpo-33629 by adding 
test.support.SuppressCrashReport().

I'm not asking to do something. Maybe it's fine to keep the current test.

--

___
Python tracker 

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

[issue32374] Document that m_traverse for multi-phase initialized modules can be called with m_state=NULL

[miss-islington]

Change by miss-islington :


--
pull_requests: +6741

___
Python tracker 

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

[issue33629] test_importlib creates a coredump on AMD64 FreeBSD 10.x Shared 3.7

[miss-islington]

Change by miss-islington :


--
pull_requests: +6740

___
Python tracker 

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

[issue32374] Document that m_traverse for multi-phase initialized modules can be called with m_state=NULL

[miss-islington]

Change by miss-islington :


--
pull_requests: +6739

___
Python tracker 

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

[issue33629] test_importlib creates a coredump on AMD64 FreeBSD 10.x Shared 3.7

[miss-islington]

Change by miss-islington :


--
pull_requests: +6738

___
Python tracker 

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

[issue32374] Document that m_traverse for multi-phase initialized modules can be called with m_state=NULL

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 483000e164ec68717d335767b223ae31b4b720cf by Victor Stinner in 
branch 'master':
bpo-33629: Prevent coredump in test_importlib (GH-7090)
https://github.com/python/cpython/commit/483000e164ec68717d335767b223ae31b4b720cf


--

___
Python tracker 

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

[issue33629] test_importlib creates a coredump on AMD64 FreeBSD 10.x Shared 3.7

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 483000e164ec68717d335767b223ae31b4b720cf by Victor Stinner in 
branch 'master':
bpo-33629: Prevent coredump in test_importlib (GH-7090)
https://github.com/python/cpython/commit/483000e164ec68717d335767b223ae31b4b720cf


--

___
Python tracker 

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

[issue33612] Assertion failure in PyThreadState_Clear

[STINNER Victor]

STINNER Victor  added the comment:

> Thank you for fixing this Victor!

You're welcome. It's always a pleasure to remove code!

--

___
Python tracker 

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

[issue33639] Use high-performance os.sendfile() in shutil.copy*

[Giampaolo Rodola']

Change by Giampaolo Rodola' :


--
keywords: +patch
pull_requests: +6737

___
Python tracker 

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

[issue33639] Use high-performance os.sendfile() in shutil.copy*

[Giampaolo Rodola']

New submission from Giampaolo Rodola' :

This is a follow up of #25063 and similar to socket.sendfile() (#17552). It 
provides a 20/25% speedup when copying files with shutil.copyfile(), 
shutil.copy() and shutil.copy2(). Differently from #25063 this is used for 
filesystem files only and copyfileobj() is left alone.

Unmerged #26826 is also related to this. I applied #26826 patch and built a 
wrapper around copy_file_range() and the speedup is basically the same. 
Nevertheless, even when #26826 gets merged it probably makes sense to rely on 
sendfile() in case copy_file_range() is not available (it was introduced in 
2016) or the UNIX platform supports file-to-file copy via sendfile(2) (even 
though I'm not aware of any, so this would basically be Linux-only).

Some benchmarks:

$ dd if=/dev/urandom of=/tmp/f1 bs=1K count=128
$ time ./python -m timeit -s 'import shutil; p1 = "/tmp/f1"; p2 = 
"/tmp/f2"' 'shutil.copyfile(p1, p2)'

128K copy
=

--- without patch:

2000 loops, best of 5: 160 usec per loop

real0m2.353s
user0m0.454s
sys 0m1.435s

--- with patch:

2000 loops, best of 5: 187 usec per loop

real0m2.724s
user0m0.627s
sys 0m1.634s

8MB copy


$ dd if=/dev/urandom of=/tmp/f1 bs=1M count=8

--- without patch:

50 loops, best of 5: 9.51 msec per loop

real0m3.392s
user0m0.343s
sys 0m2.478s

--- with patch:

50 loops, best of 5: 7.75 msec per loop

real0m2.878s
user0m0.105s
sys 0m2.187s

512MB copy
==

--- without patch:

1 loop, best of 5: 872 msec per loop

real0m5.574s
user0m0.402s
sys 0m3.115s

--- with patch:

1 loop, best of 5: 646 msec per loop

real0m5.475s
user0m0.037s
sys 0m2.959s

--
components: Library (Lib)
messages: 317611
nosy: StyXman, desbma, facundobatista, giampaolo.rodola, martin.panter, 
ncoghlan, neologix, petr.viktorin, python-dev, r.david.murray, vstinner
priority: normal
severity: normal
stage: patch review
status: open
title: Use high-performance os.sendfile() in shutil.copy*
type: performance
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

[issue33634] Buildbot configuration issue on Windows7 buildbots

[Zachary Ware]

Zachary Ware  added the comment:

This was fixed by https://github.com/python/buildmaster-config/pull/36

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

[issue31453] Debian Sid/Buster: Cannot enable TLS 1.0/1.1 with PROTOCOL_TLS

[Kurt Roeckx]

Kurt Roeckx  added the comment:

Note that the version in experimental only supports TLS 1.2 and 1.3 with the 
default config. It's moved from fixed in the code, to the default config file. 
I expect to upload that to unstable "soon", at which point people will be 
affected by this again.

--
nosy: +kroeckx

___
Python tracker 

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

[issue22703] Idle Code Context: separate changing current and future editors

[Terry J. Reedy]

Terry J. Reedy  added the comment:

[In #33610, msg317601, Cheryl Sabella wrote, copying here:]

I've started looking at #22703, more specifically, I've been trying to recreate 
it.  Since the config changes in 3.6/3.7 where the flag was removed from config 
dialog, the code context needs to be turned on explicitly for each editor.  3.5 
has the old behavior.

So, I think the current change would be to add it back to config but with the 
behavior defined in #22703.  

I hope to have a PR within the next few days.

[ I will respond in a new message after investigating the current situation, 
versus 3 1/2 years ago.]

--
nosy: +cheryl.sabella
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

[issue33638] condition lock not re-acquired

[christof]

christof  added the comment:

In my previous comment, what I want to implement is not a timeout for a task to 
complete but more precisely a timeout triggered if the coroutine was not wake 
up by a notify on the condition.

--

___
Python tracker 

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

[issue33629] test_importlib creates a coredump on AMD64 FreeBSD 10.x Shared 3.7

[Brett Cannon]

Change by Brett Cannon :


--
nosy: +ncoghlan, petr.viktorin

___
Python tracker 

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

[issue30773] async generator receives wrong value when shared between coroutines

[Yury Selivanov]

Yury Selivanov  added the comment:

Thanks, I'll look into adding ag_running properly.

--

___
Python tracker 

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

[issue33355] Windows 10 buildbot: 15 min timeout on test_mmap.test_large_filesize()

[David Bolen]

David Bolen  added the comment:

For my buildbots, I suspect win8/win10 should be ok at this point.  Among any 
other changes their local disk appears to be an SSD now, which makes a big 
difference.  I observed steady 250-300MB/s write I/O for the duration of the 
mmap test, for example, so no wonder that test highlights any I/O bottlenecks.  

Those two buildbots are independent so it's more a question of running the 
tests at all versus just on one.

On the other hand, win7/winxp compete on the same host, with traditional disks. 
 So including winxp as a slow windows build together with win7 couldn't hurt, 
although as 2.7 only, winxp runs far fewer tests nowadays.

--

___
Python tracker 

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

[issue30773] async generator receives wrong value when shared between coroutines

[Nathaniel Smith]

Nathaniel Smith  added the comment:

My thoughts: https://bugs.python.org/issue32526#msg309783

--

___
Python tracker 

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

[issue33638] condition lock not re-acquired

[christof]

New submission from christof :

Hello,

I have a simple code which triggers a timeout if a task did not complete

import asyncio

async def task_timeout():
condition = asyncio.Condition()
with await condition:
try:
await asyncio.wait_for(condition.wait(), timeout=4)
except asyncio.TimeoutError as e:
 
print("timeout reached")
# uncomment this line to make the code work
# await asyncio.sleep(0)


f = asyncio.ensure_future(task_timeout())

loop= asyncio.get_event_loop()
loop.run_until_complete(f)

It throws an exception when leaving the scope for the condition because it 
expects the lock to be acquired:

RuntimeError: Lock is not acquired.

If you uncomment the line to sleep, it will work because it will continue in 
the coroutine Condition.wait and call:
 yield from self.acquire() => locks.py line 355

I think this is a bug and that this behaviour is not the expected one.

--
components: asyncio
messages: 317604
nosy: asvetlov, christof, yselivanov
priority: normal
severity: normal
status: open
title: condition lock not re-acquired
type: behavior
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

[issue30773] async generator receives wrong value when shared between coroutines

[Yury Selivanov]

Change by Yury Selivanov :


--
assignee:  -> yselivanov
components: +Interpreter Core -asyncio
priority: normal -> high
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

[issue30773] async generator receives wrong value when shared between coroutines

[Yury Selivanov]

Yury Selivanov  added the comment:

Thanks Jan. Thanks a lot for a short script to reproduce this bug.

The actual problem here is that asynchronous generators don't control their 
'asend' and 'athrow' coroutines in any way. So if you have two of them 
iterating *in parallel* they will cause their asynchronous generator to be in 
an inconsistent state.

The most obvious solution to this problem is to prohibit iterating 
'asend'/'athrow' objects in parallel by throwing an exception.  

Nathaniel, what are your thoughts on this?

--
nosy: +njs

___
Python tracker 

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

[issue33623] Fix possible SIGSGV when asyncio.Future is created in __del__

[Yury Selivanov]

Yury Selivanov  added the comment:

> Then we should find what callable is NULL and fix the place where it is 
> called. _PyObject_FastCallDict() should never be called with NULL.

My understanding is that the interpreter is being shutdown and half of the 
objects are freed. We're still holding a reference to *something* in Python 
space and try calling it.  The obvious fix for that is simply avoid capturing 
tracebacks if a Future object is created during finalization of the interpreter 
(it's pointless to capture it anyways at that point).

--

___
Python tracker 

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

[issue33610] IDLE: Make multiple improvements to CodeContext

[Cheryl Sabella]

Cheryl Sabella  added the comment:

I've started looking at #22703, more specifically, I've been trying to recreate 
it.  Since the config changes in 3.6/3.7 where the flag was removed from config 
dialog, the code context needs to be turned on explicitly for each editor.  3.5 
has the old behavior.

So, I think the current change would be to add it back to config but with the 
behavior defined in #22703.  

I hope to have a PR within the next few days.

--

___
Python tracker 

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

[issue33637] pip cannot build extensions for debug Python

[Ivan Pozdeev]

Ivan Pozdeev  added the comment:

>one will see all the variables and call hierarchy

and be able to step through the code. With optimizations, the current line 
jumps unpredictably, and some lines can't be visited because they're optimized 
away.

--

___
Python tracker 

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

[issue33610] IDLE: Make multiple improvements to CodeContext

[Terry J. Reedy]

Terry J. Reedy  added the comment:

With #33628 merged, I consider the next priorities to be 5. #22703 (overt bug, 
highest), 7, and 8, to make the feature more usable.

10. is a vague speculative feature that would use get_indent_firstword but 
would actually be for the editor.  Update problem: It requires a representation 
of the structure of the entire code, and any edit could change that.  The 
saving grace of code context is that it only maintains information about the 
invisible lines above the cursor.

More feasible than item 10 would be

14. Block structure navigation: As near as I can tell, Alt-arrowkey is 
currently the same as arrowkey.  Have Alt-Up and Alt-Down move to the next 
block line above or below with the same indent and Alt-Left, Alt-Right move up 
and out (smaller indent) or down and in (larger indent).

15. (Instead of 4b. One font loop for class.) Replace font loop with 
font-change notification by the editor when the editor gets such a notification 
(which is very rare).

16. (Instead of 4a. One font loop for class.)  The current loops update every 
window 10 times a second, which is about the upper limit for a great typist or 
normal scroller.  But only an active editor window needs updating, and there is 
at most 1.  Most checks are wasted.

16A. Replace update loop with notification of visible display changes.  Pro: We 
already monitor key and mouse actions.  Anti: the event loop is simple.

16B. Only run update loop in active window.  Anti: I don't think we currently 
monitor window focus.  Pro: if we don't, we will need to for a multipane, 
multitab IDLE.  (Stopping should be easy: check status before after call in 
callback.  This automatically does a last update after focus gone.)

--

___
Python tracker 

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

[issue33614] Compilation of Python fails on AMD64 Windows8.1 Refleaks 3.x

[Ned Deily]

Ned Deily  added the comment:

Sorry, I *did* close the issue prematurely; thanks for noticing!

--

___
Python tracker 

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

[issue33614] Compilation of Python fails on AMD64 Windows8.1 Refleaks 3.x

[Steve Dower]

Steve Dower  added the comment:

Considering we didn't change anything in the sources, I wouldn't expect it to 
be fixed.

It doesn't have to block 3.7 if Ned's okay with it, but I'd like to keep this 
open and fix the build scripts.

--
resolution: fixed -> 
stage: resolved -> needs patch
status: closed -> open
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

[issue33636] Unexpected behavior with * and arrays

[Steven D'Aprano]

Steven D'Aprano  added the comment:

Nathan, the bug tracker is not the place to debate Python behaviour. For 
the purposes of the bug tracker, all we need say is that it is 
documented behaviour and not a bug. If you want to change that 
behaviour, there is a process to follow, and asking snarky questions on 
the tracker isn't part of it.

The principle of having multiple references to the same object is 
fundamental to Python, and very often useful. It's how objects are 
passed to functions, it is used for many forms of shared data. Your 
description of object sharing as "nonsense" and having no use-case is 
way off the mark.

But if it makes you feel better, the SPECIFIC example you ran into:

[[]]*5  # makes 5 references to the same [] object

is rarely directly useful itself. It is certainly a "gotcha" that most 
Python programmers will stumble against at one time or another. But the 
behaviour follows from some fundamental designs of the language.

Copying objects is expensive, and often unnecessary. The Python 
interpreter does not automatically make copies of objects. The 
list.__mul__ method cannot know whether you require shallow copies, or 
deep copies, and for the majority of use-cases for list replication, 
copying would be unnecessary. So the * operator simply duplicates 
references. If you want copies, you have to copy the objects yourself.

--

___
Python tracker 

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

[issue33612] Assertion failure in PyThreadState_Clear

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Thank you for fixing this Victor!

--

___
Python tracker 

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

[issue33614] Compilation of Python fails on AMD64 Windows8.1 Refleaks 3.x

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

I think the underlying issue is not fixed still. Adding new symbols in 
python3.def will break this buildbot (as well as users worktrees) again.

--

___
Python tracker 

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

[issue33636] Unexpected behavior with * and arrays

[R. David Murray]

R. David Murray  added the comment:

I wrote up a response before Mark closed the issue, so despite his excellent no 
discussion suggestion I'm going to post it for the edification of anyone 
reading the issue later rather than waste the work :)

Nathan: this is *long* established behavior of python.  It is baked in to the 
language.  Even if we thought it was a good idea to change it, that cannot be 
done for backward compatibility reasons.

As for why it works the way it does, consider the following (potentially 
useful!) cases:

  > [1, 2] * 5
  [1, 2, 1, 2, 1, 2, 1, 2, 1, 2]
  > [(1, 2)] * 5
  [(1, 20), (1, 20), (1, 20), (1, 20), (1, 20)]

What Python is doing is filling the created list with *copies of the pointers 
to the listed values*, which is much more sensible than creating, say, multiple 
copies in memory of the integers 1 and 2.  That is, you are observing a 
specific, non-intuitive and rarely useful result of a general rule that *is* 
useful and intuitive.  Also note that *even if* we wanted to try to make 
exceptions for "mutable" verses "non-mutable" elements when doing this 
replication, we can't, because there's a difference between 'copy' and 
'deepcopy' in Python, and Python refuses to guess.  So, if you want copies of a 
list, *you* have to make the correct kind of copies for your application.  
Python just copies the pointers like it does for every other type of object 
multiplied into a list.

By the way, when a core dev closes an issue, the convention is that you can 
present an argument for it being reopened, but you don't reopen it yourself.  
(No way for you to know that that is our convention, which is why I'm telling 
you :)  

But as should be clear by now, this is a closed issue and further discussion 
here would be counter-productive for all of us.

--
nosy: +r.david.murray

___
Python tracker 

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

[issue32493] UUID Module - FreeBSD build failure

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

PR 7099 is an alternate solution. I uses uuid_enc_be() which is not part of the 
DCE 1.1 RPC specification but exists on all *BSD.


Both solutions gives the same result on *BSD and AIX. I have no idea what 
solution is appropriate for little-endian non-BSD platform (if there is such 
platform supporting uuid_create()).

--

___
Python tracker 

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

[issue32493] UUID Module - FreeBSD build failure

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
pull_requests: +6736

___
Python tracker 

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

[issue33174] error building the _sha3 module with Intel 2018 compilers

[William Scullin]

William Scullin  added the comment:

Hi Kenneth:

I can recreate this issue on Haswell, Skylake-X, and KNL running SLES 12, Clear 
Linux, and Centos 7.5. I've tried 18.1 and 18.2. It's still present across the 
board with Intel C/C++ 18.0.2.199. On the Centos 7.5.1804 image, the build will 
seemingly complete, but since _sha3 didn't actually compile, the regression 
tests will fail with errors of the form:

$ /dev/shm/testinstall/icc/python/3.6.5/bin/python3 -m test
ERROR:root:code for hash sha3_224 was not found.
Traceback (most recent call last):
  File "/dev/shm/testinstall/icc/python/3.6.5/lib/python3.6/hashlib.py", line 
121, in __get_openssl_constructor
f = getattr(_hashlib, 'openssl_' + name)
AttributeError: module '_hashlib' has no attribute 'openssl_sha3_224'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/dev/shm/testinstall/icc/python/3.6.5/lib/python3.6/hashlib.py", line 
243, in 
globals()[__func_name] = __get_hash(__func_name)
  File "/dev/shm/testinstall/icc/python/3.6.5/lib/python3.6/hashlib.py", line 
128, in __get_openssl_constructor
return __get_builtin_constructor(name)
  File "/dev/shm/testinstall/icc/python/3.6.5/lib/python3.6/hashlib.py", line 
113, in __get_builtin_constructor
raise ValueError('unsupported hash type ' + name)
ValueError: unsupported hash type sha3_224
ERROR:root:code for hash sha3_256 was not found.
Traceback (most recent call last):
  File "/dev/shm/testinstall/icc/python/3.6.5/lib/python3.6/hashlib.py", line 
121, in __get_openssl_constructor
f = getattr(_hashlib, 'openssl_' + name)
AttributeError: module '_hashlib' has no attribute 'openssl_sha3_256'

...

Searching about, it looks like you may have seen something similar in EasyBuild:

https://github.com/easybuilders/easybuild-easyconfigs/pull/5086

but it doesn't look like the root cause was sussed out.

- William

--

___
Python tracker 

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

[issue33636] Unexpected behavior with * and arrays

[Mark Dickinson]

Mark Dickinson  added the comment:

@nanthil: If you want to discuss the reasons behind this design decision 
further, I'd suggest asking on one of the mailing lists, e.g. 
https://mail.python.org/mailman/listinfo/python-list

This is not the right forum for this discussion. Please don't re-open this 
issue.

--
nosy: +mark.dickinson
status: open -> closed

___
Python tracker 

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

[issue33637] pip cannot build extensions for debug Python

[Ivan Pozdeev]

New submission from Ivan Pozdeev :

(the output is for 2.7 head; for master, it's the same save for paths, library 
versions and DeprecationWarning's)

>python.bat -m ensurepip
Running Debug|x64 interpreter...
Looking in links: c:\users\sasha\appdata\local\temp\tmpiysoby
Collecting setuptools
Collecting pip
Installing collected packages: setuptools, pip
Successfully installed pip-10.0.1 setuptools-39.0.1
>python.bat -m pip install scandir
Running Debug|x64 interpreter...
Collecting scandir
  Using cached 
https://files.pythonhosted.org/packages/13/bb/e541b74230bbf7a20a3949a2ee6631be299378a784f5445aa5d0047c192b/scandir-1.7.tar.gz
Installing collected packages: scandir
  Running setup.py install for scandir ... error
Complete output from command 
C:\Users\Sasha\Documents\cpython\PCBuild\amd64\python_d.exe -u -c "import 
setuptools, 
tokenize;__file__='c:\\users\\sasha\\appdata\\local\\temp\\pip-install-xafnbn\\scandir\\setup.py';f=getattr(tokenize,
 'open', open)(__file__);code=f.read().replace('\r\n', 
'\n');f.close();exec(compile(code, __file__, 'exec'))" install --record 
c:\users\sasha\appdata\local\temp\pip-record-gbe0kk\install-record.txt 
--single-version-externally-managed --compile:
running install
running build
running build_py
creating build
creating build\lib.win-amd64-2.7-pydebug
copying scandir.py -> build\lib.win-amd64-2.7-pydebug
running build_ext
building '_scandir' extension
creating build\temp.win-amd64-2.7-pydebug
creating build\temp.win-amd64-2.7-pydebug\Release
c:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\amd64\cl.exe /c 
/nologo /Ox /MD /W3 /GS- /DNDEBUG -IC:\Users\Sasha\Documents\cpython\include 
-IC:\Users\Sasha\Documents\cpython\PC /Tc_scandir.c 
/Fobuild\temp.win-amd64-2.7-pydebug\Release\_scandir.obj
_scandir.c
c:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\amd64\link.exe 
/DLL /nologo /INCREMENTAL:NO /LIBPATH:C:\Users\Sasha\Documents\cpython\libs 
/LIBPATH:C:\Users\Sasha\Documents\cpython\PCbuild\amd64 
/LIBPATH:C:\Users\Sasha\Documents\cpython\PC\VS9.0\amd64 /EXPORT:init_scandir 
build\temp.win-amd64-2.7-pydebug\Release\_scandir.obj 
/OUT:build\lib.win-amd64-2.7-pydebug\_scandir.pyd 
/IMPLIB:build\temp.win-amd64-2.7-pydebug\Release\_scandir.lib 
/MANIFESTFILE:build\temp.win-amd64-2.7-pydebug\Release\_scandir.pyd.manifest
LINK : fatal error LNK1104: cannot open file 'python27.lib'
error: command 'c:\\Program Files (x86)\\Microsoft Visual Studio 
9.0\\VC\\BIN\\amd64\\link.exe' failed with exit status 1104


Command "C:\Users\Sasha\Documents\cpython\PCBuild\amd64\python_d.exe -u -c 
"import setuptools, 
tokenize;__file__='c:\\users\\sasha\\appdata\\local\\temp\\pip-install-xafnbn\\scandir\\setup.py';f=getattr(tokenize,
 'open', open)(__file__);code=f.read().replace('\r\n', 
'\n');f.close();exec(compile(code, __file__, 'exec'))" install --record 
c:\users\sasha\appdata\local\temp\pip-record-gbe0kk\install-record.txt 
--single-version-externally-managed --compile" failed with error code
1 in c:\users\sasha\appdata\local\temp\pip-install-xafnbn\scandir\



The cause is that distutils' `build_ext` looks at the --debug switch instead of 
the running Python to decide which Python runtime to link against.

A workaround is thus to run setup.py by hand with the --debug switch.


Suggested fix is to split compiler options into optimization options and 
linking options and:

* for debug Python, build without optimizations and against debug C runtime + 
Python runtime regardless of --debug
* for release Python,
* build without optimizations but against release C runtime + Python 
runtime with --debug


Rationale:

* It doesn't make sense to try to build against a different runtime than the 
running Python -- this will always fail because include/lib paths, preprocessor 
directives and such that build_ext generates is for the running Python.
* Must build against the same C runtime that Python uses in any case since 
using two different runtimes will break things, especially in 2.7 that relies 
on stdio.
* Building an extension without optimizations will allow to diagnose problems 
in it. Debug facilities of the runtime like malloc tracking and probably 
tracing will not work, but at least one will see all the variables and call 
hierarchy.

--
components: Distutils
messages: 317589
nosy: Ivan.Pozdeev, dstufft, eric.araujo
priority: normal
severity: normal
status: open
title: pip cannot build extensions for debug Python
type: behavior
versions: Python 2.7, 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

[issue33633] smtplib msg['To] = appends instead of assigning

[R. David Murray]

R. David Murray  added the comment:

smtplib doesn't define any behavior for messages.  I presume you are talking 
about the email library?

Vis the print behavior, dict-style lookup is defined to return the first 
matching header.  If you want to see all of them, you can use get_all.  For 
debugging, you should print the whole message, which would show the duplicate 
headers:

>>> from email.message import Message
>>> msg = Message()
>>> msg['To'] = 'a...@xyz.com'
>>> msg['To'] = 'x...@abc.com'
>>> print(msg)
To: a...@xyz.com
To: x...@abc.com



With the new API this is better, at least in terms of debugging:

>>> from email.message import EmailMessage
>>> msg = EmailMessage()
>>> msg['To'] = 'a...@xyz.com'
>>> print(msg)
To: a...@xyz.com


>>> msg['To'] = 'x...@abc.com'
Traceback (most recent call last):
  File "", line 1, in 
  File "/home/rdmurray/python/p38/Lib/email/message.py", line 408, in 
__setitem__
"in a message".format(max_count, name))
ValueError: There may be at most 1 To headers in a message


This can't be changed in the old API for backward compatibility reasons.

--
nosy: +r.david.murray
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

___
Python tracker 

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

[issue33355] Windows 10 buildbot: 15 min timeout on test_mmap.test_large_filesize()

[Ned Deily]

Ned Deily  added the comment:

The Windows7 buildbot now runs the test suite with the "largefile" resource 
disabled and no longer timed out on test_mmap.  So that immediate problem is 
now resolved.  Before closing the issue, it would be good to discuss whether we 
should do the same for some of the other Windows buildbots (perhaps allow 
"largefile" only on the buildbot with the most capacity?) and/or disabling 
"largefile" on all Windows CI tests (if not done already).

--
priority: deferred blocker -> high

___
Python tracker 

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

[issue33396] IDLE: Improve and document help doc viewer

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Point 1 is #33397.

--

___
Python tracker 

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

[issue33611] Fatal Python error: Py_Initialize: unable to load the file system codec

[Ned Deily]

Ned Deily  added the comment:

>  PYTHONPATH=/usr/local/lib/python2.7/site-packages

That looks pretty suspicious right there. It's pulling in 2.7 modules. Normally 
you should never need to set PYTHONPATH in a shell initialization script, like 
.profile, rarely elsewhere.

--

___
Python tracker 

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

[issue33611] Fatal Python error: Py_Initialize: unable to load the file system codec

[s]

s  added the comment:

:)
sure. if you want to close it - it's up to you.
if you however, want to fix it, please tell me what information do you need
me to provide.
I don't think my tone was bad/offensive. ...and it's still  a bug,
regardless of my tone or anything else.
and by the way, I don't like yours tone.

I used brew and pip

bash --version
GNU bash, version 4.4.12(1)-release (x86_64-apple-darwin16.3.0)
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 

which python
/usr/bin/python

env
_system_type=Darwin
OPT=/opt
LANG=en_US.UTF-8
XPC_FLAGS=0x0
DISPLAY=/private/tmp/com.apple.launchd.XNIGqOXCBz/org.macosforge.xquartz:0
rvm_bin_path=/Users//.rvm/bin
TERM_SESSION_ID=781A3902-E266-48B2-8BDF-0114DE0CAC97
rvm_version=1.26.11 (latest)
RUBY_VERSION=ruby-2.2.3
GEM_HOME=/Users//.rvm/gems/ruby-2.2.3
JAVA_HOME=/usr
SSH_AUTH_SOCK=/private/tmp/com.apple.launchd.tIfMUtKKFM/Listeners
GVM_ROOT=/Users//.gvm
STDLIB=/usr/local/lib
USER=
RBENV_SHELL=bash
GOPATH=/Users//working/golang/projects
PWD=/Users//working/python/scripts/passman/db
_system_version=10.13
HOME=/Users/
GOROOT=/usr/local/go
LC_CTYPE=en_US.UTF-8
_system_name=OSX
rvm_user_install_flag=1
TERM_PROGRAM=Apple_Terminal
TERM_PROGRAM_VERSION=404
Apple_PubSub_Socket_Render=/private/tmp/com.apple.launchd.zL9jzzDVzY/Render
_system_arch=x86_64
GEM_PATH=/Users//.rvm/gems/ruby-2.2.3:/Users//.rvm/gems/ruby-2.2.3@global
TMPDIR=/var/folders/g8/xflwp75s5nv0lc4wmhz2t270gn/T/
rvm_stored_umask=0022
rvm_loaded_flag=1
rvm_path=/Users//.rvm
XPC_SERVICE_NAME=0
SHELL=/bin/bash
TERM=xterm-256color
SECURITYSESSIONID=186a7
rvm_prefix=/Users/
SHLVL=2
PYENV_SHELL=bash
PYTHONPATH=/usr/local/lib/python2.7/site-packages
LOGNAME=
LDFLAGS=/usr/local/opt/bison/lib
GOBIN=/usr/local/go/bin
STDINCLUDE=/usr/local/include
MY_RUBY_HOME=/Users//.rvm/rubies/ruby-2.2.3
PATH=/opt/:/usr/local/lib:/usr/local/include:/usr/local/opt/bison/bin:/usr/local/opt/e2fsprogs/sbin:/Users//.pyenv/shims:/Users//.rvm/gems/ruby-2.2.3/bin:/Users//.rvm/gems/ruby-2.2.3@global
/bin:/Users//.rvm/rubies/ruby-2.2.3/bin:/Users//.rbenv/shims:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/go/bin:/opt/X11/bin:/Library/Frameworks/Mono.framework/Versions/Current/Commands:/Applications/Wireshark.app/Contents/MacOS:/Applications/Postgres.app/Contents/Versions/latest/bin/:/Users//.rvm/bin:/usr/local/go/bin:/Users//working/golang/projects:/usr/local/go/bin:/usr/local/include:/opt:/usr/local/lib:/Users//.rvm/bin:/usr/local/go/bin:/usr/local:/opt
IRBRC=/Users//.rvm/rubies/ruby-2.2.3/.irbrc
GOROOT_BOOTSTRAP=/usr/local/go
_=/usr/bin/env

On Thu, May 24, 2018 at 7:27 AM, STINNER Victor 
wrote:

>
> STINNER Victor  added the comment:
>
> Slava doesn't seem to want to provide any useful information to debug his
> event, whereas Naoki asked multiple times gently. I also dislike Slava's
> tone in answers, trolling Python 3 doesn't help to fix your issue...
>
> There are millions of Python 3 users on Windows, and it's the first time
> that I see this bug on Windows. So it's likely something very specific to
> your setup.
>
> It's very unlikely a bug in the Windows installer of Python, so I close
> the issue.
>
> --
> resolution:  -> not a bug
> stage:  -> resolved
> status: open -> closed
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue33636] Unexpected behavior with * and arrays

[nathan rogers]

nathan rogers  added the comment:

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

How is it expected behavior  in python, that

when I update position 0, 

it decides to update positions 1-infinity as well?

That is nonsense, and there is not a use case for this behavior. If you have 
already created the value, you have the value locally, and don't need 
N-REFERENCES to that thing. When calling functions as well, there will never be 
a time when you need more than 1 reference to the thing. 

How is this useful, and in what context could this ever be intuitive? If this 
is not a bug, it countermands the zen of python on almost every alternate line.

--
status: closed -> open

___
Python tracker 

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

[issue32493] UUID Module - FreeBSD build failure

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
stage: needs patch -> patch review

___
Python tracker 

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

[issue32493] UUID Module - FreeBSD build failure

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Is AIX big-endian?

On *BSD systems uuid_t is a structure of integers with platform-depending 
endianess. Thus on little-endian platform UUID should be called with the 
bytes_le argument. This doesn't fix test on OpenBSD and NetBSD, but at least 
the result is stable (version=4).

Using bytes_le on Linux breaks tests. Seems uuid_generate_time_safe() always 
returns bytes in big-endian order.

PR 7098 adds _uuid.little_endian which is true on little-endian platforms using 
uuid_create(), and false otherwise. Actually there are many ways of solving 
this problem, the choice of this design was arbitrary. 
_uuid.generate_time_safe() could return a 3-tuple instead of 2-tuple, or there 
could be two separate functions: _uuid.generate_time_safe() and _uuid.create().

--
stage: patch review -> needs patch

___
Python tracker 

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

[issue32493] UUID Module - FreeBSD build failure

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
keywords: +patch
pull_requests: +6735
stage: needs patch -> patch review

___
Python tracker 

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

[issue33636] Unexpected behavior with * and arrays

[nathan rogers]

nathan rogers  added the comment:

Can anyone give me a legitimate answer as to why this would be expected 
behavior? When at any point would you ever need that? 

If the list is local, you already have the thing. If it isn't local, you can 
pass it to a function by reference. So then, why would you ever need N 
references to the same thing?

Are you going to run out? 

Are your functions buying tickets to the reference of my thing show, and you're 
afraid those tickets will run out?

What is this?

--

___
Python tracker 

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

[issue33530] Implement Happy Eyeball in asyncio

[STINNER Victor]

Change by STINNER Victor :


--
nosy: +njs

___
Python tracker 

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

[issue33630] test_posix: TestPosixSpawn fails on PPC64 Fedora 3.x

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests:  -6734

___
Python tracker 

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

[issue33636] Unexpected behavior with * and arrays

[Steven D'Aprano]

Steven D'Aprano  added the comment:

This is not a bug, it is the documented behaviour: the * operator does not copy 
the lists, it duplicates references to the same list. There's even a FAQ for it:

https://docs.python.org/3/faq/programming.html#how-do-i-create-a-multidimensional-list

--
nosy: +steven.daprano
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

[issue33627] test-complex of test_numeric_tower.test_complex() crashes intermittently on Ubuntu buildbots

[STINNER Victor]

STINNER Victor  added the comment:

> Do we have builds with Adress Sanatizer or Undefined Behavior Sanitizer?

Gregory recently added new USBan builders. Example:
http://buildbot.python.org/all/#/builders/135

It's something very new, there are millions of logged warnings :-)

--

___
Python tracker 

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