[issue31742] Default to emitting FutureWarning for provisional APIs

[Nick Coghlan]

Nick Coghlan  added the comment:

Keep in mind that I'm not proposing that we retroactively change our approach 
to managing any currently provisional APIs that were proposed and implemented 
under the current version of PEP 411.

Instead I'm merely suggesting that the policy for any *future* provisional APIs 
be amended to require a runtime feature flag and FutureWarning by default, with 
the possible disposition of such proposals then being:

1. Rejected (as with any proposal)
2. Accepted with the feature flag and runtime warning in place
3. The proposal is reformulated to include both non-provisional and provisional 
parts, with the feature flag and warning applying only to use of the latter 
elements
4. The proposal is reformulated to offer an entirely non-provisional public API 
without a feature flag or warning (perhaps with a private "_machinery" or 
"_internals" submodule to better enable third party tinkering and 
experimentation)
5. The submitter of the proposal successfully makes the case that their 
proposal is simultaneously stable enough that it doesn't need a feature flag or 
runtime warning and *un*stable enough that it shouldn't be expected to offer 
the standard library's usual backwards compatibility guarantees

I personally think the final option will be tricky enough to justify that most 
folks won't even bother trying, and will instead opt for one side or the other 
(i.e. the feature-flag-and-warning, or a non-provisional API)

However, it's an option I'd consider reasonable to retain in recognition of the 
fact that it's been used without problems in the past (e.g. it's plausible that 
pathlib could credibly have made that case, since the provisional status wasn't 
due to potential API stability within pathlib itself, it was due to doubts 
about how well it would be able to integrate with other parts of the standard 
library. It went unprovisional once the introduction of the filesystem path 
protocol allowed those integration concerns to be fully resolved).

--

___
Python tracker 

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

[issue31732] Add TRACE level to the logging module

[pmpp]

pmpp  added the comment:

Sorry, i didn't mean to be rude. Just wanted to pick your attention because i 
think you miss the point:  logging as is it with its levels is perfect for *log 
messages*.
Review the typical usage shown and you'll see that tracing level is for logging 
tracebacks : the debug message is separate. Traces just don't fit on standard 
log output, they clutter and obviously have a format of their own. 
As a user i see TRACE as context for logging.exception when it has nothing to 
do with errors or verbosity.

--

___
Python tracker 

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

[issue30744] Local variable assignment is broken when combined with threads + tracing + closures

[Nick Coghlan]

Nick Coghlan  added the comment:

Aye, what's in PEP 558 is the least invasive implementation change I've been 
able to come up that fixes the reported bug, but Nathaniel's right that it 
would break debuggers (and probably some other things) as currently written.

So the above design comes from asking myself "How can I get the *effect* of PEP 
558, while hiding what's going on internally even from trace function 
implementations?".

While I can't be sure until I've actually implemented it successfully (no ETA 
on that, unfortunately), I think blending my idea with Nathaniel's original 
idea will let us enjoy the benefits of both approaches, without the downsides 
of either of them.

--

___
Python tracker 

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

[issue31509] test_subprocess hangs randomly on AMD64 Windows10 3.x

[Ned Deily]

Ned Deily  added the comment:

I also have seen test_subprocess hangs on both macOS and on Debian Linux on 
both 3.6 and master, as recently as 3.6.3 and 3.7.0a1 but not with current 
heads.  After some experimenting and bisecting, I tracked the fix down to the 
mock os.waitpid fixes for bpo-31178 (git11045c9d8a and gitfae0512e58). So 
perhaps this issue can be closed.

--
nosy: +ned.deily

___
Python tracker 

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

[issue31772] SourceLoader uses stale bytecode in case of equal mtime seconds

[Nick Coghlan]

Nick Coghlan  added the comment:

Increasing the number of stat calls required for a successful import is a good 
reason to close the submitted PR, but I'm not sure it's a good reason to close 
the *issue*, as there may be other ways to solve it that don't result in an 
extra stat call for every successful cache hit.

Restating the problem: the pyc file format currently discards the fractional 
portion of the source file mtime. This means that even if the source filesystem 
offers a better than 1 second timestamp resolution, the bytecode cache doesn't.

So I think it's worth asking ourselves what would happen if, instead of storing 
the source mtime as an integer directly, we instead stored "int(mtime * N) & 
0x".

The source timestamp is stored in a 32-bit field, so the current pyc format is 
technically already subject to a variant of the 2038 epoch problem (i.e. it 
will wrap in 2106 and start re-using timestamps). We just don't care, since the 
only impact is that there's a tiny risk that we'll fail to recompile an updated 
source file if it hasn't changed size and we try importing it at exactly the 
wrong time. That window is currently 1 second every ~136 years.

That means we have a trade-off available between the size of each individual 
"erroneous cache hit" window, and how often we encounter that window. Some 
examples:

N=2: 500 ms window every ~68 years
N=10: 100 ms window every ~13.6 years
N=100: 10 ms window every ~1.36 years
N=1000: 1 ms window every ~7 weeks (~0.136 years)

The odds of a file being in exactly 7 weeks time after it was last compiled 
(down to the millisecond) *and* being different without changing size are going 
to be lower that those of a single (or N) character change being made *right 
now* (e.g. fixing a typo in a variable name that transposed characters, or got 
a letter wrong).

A case where problems with the status quo could be most plausibly encountered 
is when a text editor with autosave configured is combined with a testing web 
service with hot reloading configured.

Don't get me wrong, I think the odds of that actually happening are already 
very low, and the human fix is simple (make another edit, save the source file 
again, and grumble about computers not seeing changes that are right in front 
of them).


However, encountering problems with an N=100 or N=1000 multiplier seems even 
more implausible to me, and in cases where it was deemed a concern, PEP 552's 
hash-based caching seems a solution people should be looking at anyway.

--

___
Python tracker 

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

[issue30632] IDLE: add unittests to test_autocomplete

[Berker Peksag]

Change by Berker Peksag :


--
superseder:  -> IDLE: Add test_autocomplete unittest

___
Python tracker 

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

[issue31732] Add TRACE level to the logging module

[Raymond Hettinger]

Raymond Hettinger  added the comment:

No need to be brusque with me.  Vinay is the decision maker on this.

Overall, this seems rehash and second guess the discussions and decisions made 
15 years ago when PEP 282 was accepted.  At that time, it was decided that five 
levels had advantages for learnability and usability, but that the levels 
should be extendable to cover more specialized uses:

>>> import logging
>>> SEMI_IMPORTANT = 35
>>> logging.addLevelName(SEMI_IMPORTANT, 'SEMI_IMPORTANT')
>>> logging.log(SEMI_IMPORTANT, 'request backlog getting high')
SEMI_IMPORTANT:root:request backlog getting high

This effortless extendability let us avoid adding the whole zoo of names 
sometimes used in other projects (FATAL, TRACE, NOTICE, FINE, FINER, FINEST).  
As far as I can tell, this module has a 15 year track record of success and was 
well thought-out from the outset.  So there is no reason to suddenly be so 
insistent that the module must change to accommodate your world view of how 
everyone else should prioritize their log entries.

As a teacher, project leader, and coach, one thing I really like about Vinay's 
design is that people seem to easily and naturally assign the correct rank 
order to the existing five levels.  Today, I asked some engineers where TRACE 
or NOTICE would fit in and they were unsure.  This indicates that adding new 
levels will impact usability and make users worse off.

--

___
Python tracker 

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

[issue31742] Default to emitting FutureWarning for provisional APIs

[Guido van Rossum]

Guido van Rossum  added the comment:

I am at a loss for words.

On Oct 12, 2017 6:27 PM, "Nick Coghlan"  wrote:

>
> Nick Coghlan  added the comment:
>
> If a proposed standard library API is sufficiently stable that the folks
> proposing it are reluctant to emit a runtime warning about any remaining
> stability risks, then I think it's reasonable to expect them to propose it
> as non-provisional and accept the related backwards compatibility
> obligations.
>
> We have past examples of our being able to cope with that approach, such
> as when contextlib.nested turned out to be broken at a design level, so we
> deprecated it, removed it, and replaced it with a combination of
> contextlib.ExitStack and native support for multiple context managers in
> with statements.
>
> Framing that in different terms: with PEP 411 as currently written, the
> benefits of instability accrue to the API publisher and willing early
> adopters, while the costs appear as negative externalities affecting folks
> that would prefer not to care about the API at all until it is covered by
> the regular backwards compatibility guarantees.
>
> This RFE proposes to internalise some of those costs (in the form of a
> required runtime warning for any future provisional APIs), such that API
> publishers ask themselves "Do I *really* need this whole API to be
> provisional? Can I restructure it so only selected clearly identifiable
> parts are provisional or private, and the rest are covered by regular
> stability guarantees?" and early adopters ask themselves "Do I really want
> to make this a *required* dependency? Perhaps I can make it optional
> somehow, so folks that aren't using these features won't get the warning?"
>
> --
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue31742] Default to emitting FutureWarning for provisional APIs

[Nick Coghlan]

Nick Coghlan  added the comment:

If a proposed standard library API is sufficiently stable that the folks 
proposing it are reluctant to emit a runtime warning about any remaining 
stability risks, then I think it's reasonable to expect them to propose it as 
non-provisional and accept the related backwards compatibility obligations.

We have past examples of our being able to cope with that approach, such as 
when contextlib.nested turned out to be broken at a design level, so we 
deprecated it, removed it, and replaced it with a combination of 
contextlib.ExitStack and native support for multiple context managers in with 
statements.

Framing that in different terms: with PEP 411 as currently written, the 
benefits of instability accrue to the API publisher and willing early adopters, 
while the costs appear as negative externalities affecting folks that would 
prefer not to care about the API at all until it is covered by the regular 
backwards compatibility guarantees.

This RFE proposes to internalise some of those costs (in the form of a required 
runtime warning for any future provisional APIs), such that API publishers ask 
themselves "Do I *really* need this whole API to be provisional? Can I 
restructure it so only selected clearly identifiable parts are provisional or 
private, and the rest are covered by regular stability guarantees?" and early 
adopters ask themselves "Do I really want to make this a *required* dependency? 
Perhaps I can make it optional somehow, so folks that aren't using these 
features won't get the warning?"

--

___
Python tracker 

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

[issue31742] Default to emitting FutureWarning for provisional APIs

[Ned Deily]

Ned Deily  added the comment:

Besides making the provisional warning more noticeable in module doc pages, 
perhaps we should have a "Provisional Package / API" section somewhere in the 
release's docset: a liat of all provisionals and perhaps a list of formerly 
provisional, now stable items that have transitioned since the previous feature 
release.  An obvious place would be in the What's New doc and it could be 
linked to from various places, like the Glossary, the release PEP, and/or the 
Release Notes.

--

___
Python tracker 

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

[issue31761] regrtest: faulthandler.enable() fails with io.UnsupportedOperation: fileno when run from IDLE

[Terry J. Reedy]

Terry J. Reedy  added the comment:

When I import autotest in IDLE's shell, test_code_module fails, test_importlib 
and test_warnings fail, as without IDLE, and test_gc and test_logging are new 
failures.  (Results are easy to see because SystemExit is caught and ignored.)

test test_gc failed -- Traceback (most recent call last):
  File "F:\dev\3x\lib\test\support\__init__.py", line 1855, in wrapper
return func(*args, **kwargs)
  File "F:\dev\3x\lib\test\test_gc.py", line 290, in test_get_count
self.assertLess(a, 5)
AssertionError: 8 not less than 5




test test_logging failed -- Traceback (most recent call last):
  File "F:\dev\3x\lib\test\test_logging.py", line 1960, in test_warnings
"dummy.py:42: UserWarning: Explicit\n  Dummy line\n")
AssertionError: '\nWarning (from warnings module):\n  File[57 chars]it\n' != 
'dummy.py:42: UserWarning: Explicit\n  Dummy line\n'
+ dummy.py:42: UserWarning: Explicit
- 
- Warning (from warnings module):
-   File "dummy.py", line 42
- Dummy line
? --
+   Dummy line
- UserWarning: Explicit

IDLE replaces warnings.show_warnings.  In any case, there are 3 failures in 
Python's shell versus 4 in IDLE's shell.

--

___
Python tracker 

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

[issue31742] Default to emitting FutureWarning for provisional APIs

[Guido van Rossum]

Guido van Rossum  added the comment:

OK, so the Django and Twisted developers had to resist some pressure from their 
users. These are mature projects and if they can't resist pressure from users 
something is wrong with those projects, and just pointing users to PEP 411 
would have been a sufficient answer. (In reality of course, some users come 
across feeling excessively entitled, but that issue goes well beyond this.)

I recall what happened to cattrs (they came to our tracker: 
https://github.com/python/typing/issues/345). Ironically the cattrs package 
itself advertises itself as experimental, so this seems fair game. From 
skimming the issue they took it in stride (also, we fixed it in the next 
release).

I really don't think we should add annoying runtime behavior just to warn off 
to people who don't read the official docs. I don't actually know how that has 
to be done, but surely there are some Sphinx experts in the core-dev group?

Regarding the interpreters package, it feels like something of a different 
magnitude (due to the extensive interpreter changes and the implications for 
3rd party extensions). But I really don't want this thread to be distracted by 
that.

--

___
Python tracker 

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

[issue31761] regrtest: faulthandler.enable() fails with io.UnsupportedOperation: fileno when run from IDLE

[Terry J. Reedy]

Terry J. Reedy  added the comment:

The Python console exits because test.libregrtest.main.Regrtest._main calls 
sys.exit.  test.autotest consists of

from test.libregrtest import main
main()

The main call should be wrapped with try:...except sys.exit: pass

The output also has this variance from the command line result.

0:15:47 [319/407/2] test_subprocess
minkernel\crts\ucrt\src\appcrt\lowio\write.cpp(49) : Assertion failed: 
(_osfile(fh) & FOPEN)
minkernel\crts\ucrt\src\appcrt\lowio\close.cpp(49) : Assertion failed: 
(_osfile(fh) & FOPEN)
minkernel\crts\ucrt\src\appcrt\lowio\close.cpp(49) : Assertion failed: 
(_osfile(fh) & FOPEN)

The list of tests skipped seems to be the same.

By setting sys.argv before importing autotest, I got
==
FAIL: test_ps1 (test.test_code_module.TestInteractiveConsole)
--
Traceback (most recent call last):
  File "F:\dev\3x\lib\test\test_code_module.py", line 35, in test_ps1
self.assertEqual(self.sysmod.ps1, '>>> ')
AssertionError:  != '>>> '

==
FAIL: test_ps2 (test.test_code_module.TestInteractiveConsole)
--
Traceback (most recent call last):
  File "F:\dev\3x\lib\test\test_code_module.py", line 40, in test_ps2
self.assertEqual(self.sysmod.ps2, '... ')
AssertionError:  != '... '

--

==
FAIL: test_missing_filename_main_with_argv (test.test_warnings.CWarnTests)
--
Traceback (most recent call last):
  File "F:\dev\3x\lib\test\test_warnings\__init__.py", line 446, in 
test_missing_filename_main_with_argv
self.assertEqual(w[-1].filename, sys.argv[0])
AssertionError: '__main__' != ''
- __main__
+

and

==
FAIL: test_missing_filename_main_with_argv (test.test_warnings.PyWarnTests)
--
Traceback (most recent call last):
  File "F:\dev\3x\lib\test\test_warnings\__init__.py", line 446, in 
test_missing_filename_main_with_argv
self.assertEqual(w[-1].filename, sys.argv[0])
AssertionError: '__main__' != ''
- __main__

Wneh I start python with python.bat, sys.argv = [''], not ['__main__'].

--

___
Python tracker 

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

[issue30744] Local variable assignment is broken when combined with threads + tracing + closures

[Guido van Rossum]

Guido van Rossum  added the comment:

Wow, nothing here is simple. :-( Even though the examples show that there's 
obviously a bug, I would caution against fixing it rashly without understanding 
how the current behavior may be useful in other circumstances. I've lost what I 
recall from reading PEP 558 so I can't quite fathom the new design, but I wish 
you good luck trying to implement it, and hopefully it will work out as hoped 
for (simpler, solving the issue, keeping the useful behaviors).

--

___
Python tracker 

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

[issue29696] Use namedtuple in string.Formatter.parse iterator response

[Pablo]

Change by Pablo :


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

___
Python tracker 

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

[issue31761] regrtest: faulthandler.enable() fails with io.UnsupportedOperation: fileno when run from IDLE

[Terry J. Reedy]

Terry J. Reedy  added the comment:

0:00:28 [ 25/407] test_asyncio
F:\dev\3x\lib\asyncio\sslproto.py:330: ResourceWarning: unclosed transport 

  source=self)

test_code_module - multiple errors

test test_importlib failed -- Traceback (most recent call last):
  File "F:\dev\3x\lib\test\test_importlib\test_locks.py", line 134, in 
test_all_locks
self.bootstrap._module_locks)
AssertionError: 0 != 1 : {'test.autotest': }

test_warnings failed - multiple errors

crash after summary printed.
I am rerunning in python started from command to see if there is any message 
printed.

--

___
Python tracker 

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

[issue31761] regrtest: faulthandler.enable() fails with io.UnsupportedOperation: fileno when run from IDLE

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Victor, what is your opinion of running 'from test import autotest' in a 
standard python shell window, opened from an icon, as opposed to IDLE's shell?

>  many tests fail just because of IDLE.

We cannot know what to blame on IDLE without a proper control experiment.  I 
updated my Win10 repository, rebuilt python 3.7, ran the tests from the command 
line, and all passed (thank you for making this routine).  I ran autotest in a 
Python console and saw a new resource warning from one of the async tests and 3 
failures.  I cannot say what they were because when the test finished, the 
window closed (crashed), which is a metafailure.  I will rerun and try to 
identify the error as they occur.

Should we reopen this issue or open a new issue, to fix problems not due to 
IDLE, or remove the entire suggestion to use autotest, and remove autotest 
itself?

--
nosy: +terry.reedy

___
Python tracker 

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

[issue31778] ast.literal_eval supports non-literals in Python 3

[David Bieber]

Change by David Bieber :


--
type:  -> behavior

___
Python tracker 

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

[issue31778] ast.literal_eval supports non-literals in Python 3

[David Bieber]

New submission from David Bieber :

# Overview
ast.literal_eval supports some non-literals in Python 3.
The behavior of this function runs contrary to the documented behavior.


# The Issue
The 
[documentation](https://docs.python.org/3/library/ast.html#ast.literal_eval) 
says of the function "It is not capable of evaluating arbitrarily complex 
expressions, for example involving operators or indexing."

However, literal_eval is capable of evaluating expressions with certain 
operators, particular the operators "+" and "-".

As has been explained previously, the reason for this is to support "complex" 
literals such as 2+3j. However, this has unintended consequences which I 
believe to be indicative of a bug. Examples of the unintended consequences 
include `ast.literal_eval('1+1') == 2` `ast.literal_eval('2017-10-10') == 
1997`. I would expect each of these calls to literal_eval to throw a 
ValueError, as the input string is not a literal. Instead, literal_eval 
successfully evaluates the input string, in the latter case giving an 
unexpected result (since the intent of the string is to represent a 21st 
century date.)

Since issue arose as a [Python Fire 
issue](https://github.com/google/python-fire/issues/97), where the behavior of 
Python Fire was unexpected for inputs such as those described above (1+1 and 
2017-10-10) only in Python 3. For context, Python Fire is a CLI library which 
uses literal_eval as part of its command line argument parsing procedure.

I think the resolution to this issue is having literal_eval raise a ValueError 
if the ast of the input represents anything other than a Python literal, as 
described in the documentation. That is, "The string or node provided may only 
consist of the following Python literal structures: strings, bytes, numbers, 
tuples, lists, dicts, sets, booleans, and None." Additional operations, such as 
the binary operations "+" and "-", unless they explicitly create a complex 
number, should produce a ValueError.

If that resolution is not the direction we take, I also would appreciate 
knowing if there is another built in approach for determining if a string or 
ast node represents a literal.


# Reproducing
The following code snippets produce different behaviors in Python 2 and Python 
3.
```python
import ast
ast.literal_eval('1+1')
```

```python
import ast
ast.literal_eval('2017-10-10')
```


# References
- The Python Fire issue is here: https://github.com/google/python-fire/issues/97
- Prior discussion of a similar issue: https://bugs.python.org/issue22525
- I think is where complex number support was originally added: 
https://bugs.python.org/issue4907
- In this thread, https://bugs.python.org/issue24146, one commenter explains 
that literal_eval's support for "2+3" is an unintentional side effect of 
supporting complex literals.

--
messages: 304294
nosy: David Bieber
priority: normal
severity: normal
status: open
title: ast.literal_eval supports non-literals in Python 3
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

___
Python tracker 

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

[issue13802] IDLE font settings: use multiple character sets in examples

[Terry J. Reedy]

Terry J. Reedy  added the comment:

I pushed new commits to the PR that changed the Korean, Japanese, and Indian 
samples and the help message.

Korea: The line is now the first 10 chars of Dong-hee Na's suggestion.  Thank 
you for helping (and Louie for the cc).

Japan: The line is now the hiragana and katakana versions of the 5 vowels.  As 
far as I know, 'kanji' are a subset of CJK 'hanzi', with different 
pronunciations and possibly different meanings, so I see no need for any here.

India: The second line is now Tamil digits and vowels.

China: I found the chars, with translation, including the one 
simplified/traditional pair, on Wikipedia.  I did not know if more pairs would 
be a good idea or not, and I do not know of others.  Louie, if you have a 
better idea, please post it (with translation ;-).

Dialog size: The height is about 710 pixels, 10% larger than before the 
additions to the General page a month ago.  So it was previously too tall for 
800 x 600 and still fits 1024 x 768.  Further expansion should mostly be in 
width, but there is some vertical room.

Spaces and labels: I initially had neither.  I could hardly stand to look.  The 
label are needed for people who do not recognize the character sets, and I use 
them to make three general points in the help entry: tk uses whatever font it 
can to cover most of the BMP; fixed font sizes for Latin font only apply to 
Latin chars; and right-to-left is handled correctly.

Latin1: I consider the Windows fontchooser to be an anti-model for this issue 
in that it is limited to alphabetic characters and confuses 'language' with 
'character set'.  Western, Central European, Baltic, Turkish, and Vietnamese 
languages all use latin characters.  The non-ascii, decorated versions are 
'covered' by the non-ascii Latin1 line.  Á is already present. Â is intended to 
represent all circumflexed characters, including Ô. I intended the repeated use 
of A as base character to imply that.  I not sure if using a different base for 
each decoration would be better.  Similarly, Ç covers Ş.  I am thinking about 
using fewer symbols and more alphabetic characters.  It might be a good idea to 
add something, such as Ğ, from the Extended block, beyond \u00ff.

User additions: This would be a separate issue, see #31777.

--

___
Python tracker 

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

[issue31777] IDLE: Let users add to font selection

[Terry J. Reedy]

New submission from Terry J. Reedy :

Config dialog Font tab has a sample box.  It currently only contains Ascii 
chars.  #13802 will add characters from extended latin1 and several other 
character sets.  But we cannot show everything.  Hence a spinoff proposal: let 
users augment the sample with things of particular interest.  (There are 
multiple variations of this idea, which I defer to another post.)

--
assignee: terry.reedy
components: IDLE
messages: 304292
nosy: terry.reedy
priority: normal
severity: normal
stage: test needed
status: open
title: IDLE: Let users add to font selection
type: enhancement
versions: 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

[issue31767] Windows Installer fails with error 0x80091007 when trying to install debugging symbols

[Steve Dower]

Steve Dower  added the comment:

FWIW, all your assumptions about how it should work are correct. If you don't 
know how the files got there instead of a randomly generated temporary path, 
then I don't know either. /layout is the only time we download anything to a 
non-temp directory.

--

___
Python tracker 

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

[issue22674] strsignal() missing from signal module

[Antoine Pietri]

Antoine Pietri  added the comment:

Hey everyone,

We would like to have that feature for a project where we have to use ctypes to 
achieve that. I don't know the answers to vajrasky's questions but I just 
wanted to chime in to say having this feature would be greatly appreciated. I 
can also work on the code if you need any help.

Thanks!

--
nosy: +antoine.pietri

___
Python tracker 

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

[issue31742] Default to emitting FutureWarning for provisional APIs

[Ned Deily]

Change by Ned Deily :


--
nosy: +ned.deily

___
Python tracker 

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

[issue30058] Buffer overflow in kqueue.control()

[Serhiy Storchaka]

Change by Serhiy Storchaka :


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

[issue30058] Buffer overflow in kqueue.control()

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset 9aa60245a0ff929e528b4521da7af20dacd4145b by Serhiy Storchaka in 
branch '2.7':
[2.7] bpo-30058: Fixed buffer overflow in select.kqueue.control(). (GH-1095). 
(#3976)
https://github.com/python/cpython/commit/9aa60245a0ff929e528b4521da7af20dacd4145b


--

___
Python tracker 

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

[issue29762] Use "raise from None"

[Pablo]

Change by Pablo :


--
pull_requests: +3954

___
Python tracker 

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

[issue31776] Missing "raise from None" in /Lib/xml/etree/ElementPath.py

[Pablo]

Change by Pablo :


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

___
Python tracker 

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

[issue31776] Missing "raise from None" in /Lib/xml/etree/ElementPath.py

[Pablo]

Change by Pablo :


--
title: Inconsistent exception chaining in /Lib/xml/etree/ElementPath.py -> 
Missing "raise from None" in /Lib/xml/etree/ElementPath.py

___
Python tracker 

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

[issue31776] Inconsistent exception chaining in /Lib/xml/etree/ElementPath.py

[Pablo]

New submission from Pablo :

Based on bpo-29762 
(https://github.com/python/cpython/commit/5affd23e6f42125998724787025080a24839266e),
 there is an inconsistency on one exception chain in 
/Lib/xml/etree/ElementPath.py:

 try:
 selector.append(ops[token[0]](next, token))
 except StopIteration:
raise SyntaxError("invalid path")

should be

  raise SyntaxError("invalid path") from None

--
components: Library (Lib)
messages: 304288
nosy: pablogsal
priority: normal
severity: normal
status: open
title: Inconsistent exception chaining in /Lib/xml/etree/ElementPath.py
type: behavior

___
Python tracker 

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

[issue31768] argparse drops '|'s when the arguments are too long

[paul j3]

paul j3  added the comment:

I've changed your example a bit to clarify some points.

parser.add_argument('n', type=int)
group = parser.add_mutually_exclusive_group()
group.add_argument("-v", "--verbose", action="store_true")
group.add_argument("-q", "--quiet", action="store_true")
group.add_argument("-x", metavar='X', type=str, help="the base", nargs='?')
group.add_argument("-y", metavar='Y', type=str, help="the exponent", 
nargs='?')

for i in range(int(sys.argv[1])):
 group.add_argument("z%s"%i, nargs='?')

With `n=0`, usage is:

usage: PROG [-h] [-v | -q | -x [X] | -y [Y]] n

Notice that the positional is placed last.  That is, regardless of the 
definition order, 'usage' shows optionals first, positionals last.

With 2 'z':

usage: PROG [-h] [-v] [-q] [-x [X]] [-y [Y]] n [z0] [z1]

All the mutually exclusive markings have been dropped.  That's because the 
component actions are not consecutive, having been split up by the reordering 
of positionals.  Marking the group is done only if it can do so in a simple 
minded way.  The group testing is not dependent on being able to format it.  
That's done by a different part of the code.

For 7 'z' it splits the line.  Positionals are printed on a new line.

usage: PROG [-h] [-v] [-q] [-x [X]] [-y [Y]]
n [z0] [z1] [z2] [z3] [z4] [z5] [z6]


I noticed this problem with formating group positional in multiline usage some 
time ago, https://bugs.python.org/issue10984#msg192954


Another thing to watch out for - multiple positionals in a group don't make 
sense.  Only the first one can ever be filled.  I don't see a formal check, but 
it doesn't make logical sense.

If I change the code so it produces multiple optionals:

usage: PROG [-h] [-v | -q | -x X | -y Y | --z0 [Z0] | --z1 [Z1] | --z2 [Z2] 
|
--z3 [Z3] | --z4 [Z4]]
n

the group markings are preserved across lines.  Note again that the positional 
(n) is on its own line.

---

Here's another weird behavior, with just one positional in the group:

1314:~/mypy$ python3 argdev/issue31768.py 1 -v 3
usage: PROG [-h] [-v] [-q] [-x X] [-y Y] n [z0]
PROG: error: unrecognized arguments: 3

It complains about not recognizing the '3', rather than complaining about 'z0' 
not allow with '-v'.  That's because the '?' has already been satisfied with [] 
when parsing the 'n' (see https://bugs.python.org/issue15112).

---

In sum, I think this is pathological case that doesn't need to be fixed.  

Usage is ok if there's a long list of optionals.  Usage (and parsing) with just 
one positional in the group is brittle.  We shouldn't expect it work with many 
positionals in the group.

---

@Louie, you 2nd example interweaves the definitions of two groups.  Except for 
the optionals/positions reordering that I mentioned above, usage does not 
reorder arguments.  Mutually exclusive groups are marked only if they are 
contiguous.  

https://bugs.python.org/issue10984 has a patch that can format groups even if 
the actions don't occur in the right order.  It isn't a trivial fix.

--

___
Python tracker 

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

[issue30058] Buffer overflow in kqueue.control()

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
pull_requests: +3952

___
Python tracker 

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

[issue30058] Buffer overflow in kqueue.control()

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset c923da188bc055e4f3001a6daf1caf54f2b10e40 by Serhiy Storchaka 
(Miss Islington (bot)) in branch '3.6':
[3.6] bpo-30058: Fixed buffer overflow in select.kqueue.control(). (GH-1095) 
(#3973)
https://github.com/python/cpython/commit/c923da188bc055e4f3001a6daf1caf54f2b10e40


--

___
Python tracker 

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

[issue31772] SourceLoader uses stale bytecode in case of equal mtime seconds

[Devin Bayer]

Devin Bayer  added the comment:

Hello Brett, it would be nice if you would discuss this before closing. The 
referenced PEP will not solve my use case, because hash-based checking will not 
become the default.

The issue is that by default the source file loader will be returning stale 
bytecode and that's incorrect behavior.

If you wish to avoid the stat call you could use a higher resolution timestamp 
in the pyc file, or better yet add a second field indicating bytecode 
compilation time.

--

___
Python tracker 

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

[issue31768] argparse drops '|'s when the arguments are too long

[paul j3]

paul j3  added the comment:

As documented in many other issues, the usage formatter is brittle.  It formats 
the individual usages, joins them into a string. Then if too long to fit on one 
line it tries t split into actions, etc.  This split produces an assertion 
error if there are 'wierd' characters in the names (e.g. #[]).

With mutually exclusive groups it gets even worse.  The brackets and | are 
spliced into the original string, and then excess [] and spaces are removed.  
Once recent issue complained about its handling of nested groups (which are 
borderline wrong).

So I"m not surprised that a long group that spans a couple of lines gets messed 
up.   It requires a major rewrite, and even then I there will be formats 
involving groups that fall through the cracks.

--
nosy: +paul.j3

___
Python tracker 

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

[issue14976] queue.Queue() is not reentrant, so signals and GC can cause deadlocks

[Catalin Patulea]

Change by Catalin Patulea :


--
nosy: +Catalin Patulea

___
Python tracker 

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

[issue31640] Document exit() from parse_args

[paul j3]

paul j3  added the comment:

And the actual exit is via `parse.error` and `parse.exit`, which are documented 
in 16.4.5.9.

When run interactively in Ipython, exits (including the help) are captured and 
displayed with:

In [896]: parser.parse_args()
usage: ipython3 [-h] [--one | --two | --six]
ipython3: error: unrecognized arguments: --pylab --nosep --term-title 
--InteractiveShellApp.pylab_import_all=False
An exception has occurred, use %tb to see the full traceback.

SystemExit: 2

The exit makes unittesting a challenge.  'test_argparse.py' resolves this by 
using a subclassed parser, one that changes the error/exit, and also redirects 
output.

--
nosy: +paul.j3

___
Python tracker 

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

[issue30058] Buffer overflow in kqueue.control()

[Roundup Robot]

Change by Roundup Robot :


--
keywords: +patch
pull_requests: +3951

___
Python tracker 

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

[issue30058] Buffer overflow in kqueue.control()

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset de072100775cc29e6cd93a75466cecbd1086f258 by Serhiy Storchaka in 
branch 'master':
bpo-30058: Fixed buffer overflow in select.kqueue.control(). (#1095)
https://github.com/python/cpython/commit/de072100775cc29e6cd93a75466cecbd1086f258


--

___
Python tracker 

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

[issue30767] logging must check exc_info correctly

[Matthew Patton]

Change by Matthew Patton :


--
pull_requests: +3950

___
Python tracker 

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

[issue30058] Buffer overflow in kqueue.control()

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

I have tested it on FreeBSD, found and fixed one bug.

--
assignee:  -> serhiy.storchaka
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

[issue31767] Windows Installer fails with error 0x80091007 when trying to install debugging symbols

[Igor Skochinsky]

Igor Skochinsky  added the comment:

Hi Steve,

 Thanks for the suggestion! I tried that and while it did not succeed it
gave me an idea of what went wrong last time since it complained about lack
of disk space. I have *not* run the /layout but now that I checked I indeed
had core_d.msi and core_pdb.msi (and a few more) in the Downloads
directory, so I think maybe the installer tried to download them but ran
out of space and the download was incomplete.

Another possibility is that the .msi was for the wrong installer - I first
tried installing the x86 version but later changed my mind but since I did
not expect it to download extra files into the same directory I did not
clean them. Also it seems the downloaded .msi files have the original
timestamp (16-09-27) so I did not notice them when sorting my downloads by
date until I tried to look for .msi files specifically.

In the end I guess this could be closed as PEBKAC but I think maybe some
more testing in low-disk-space conditions and/or installing x86 then x64
from the same directory could uncover some real issues.

In general, I found the 3.3 install experience not very straightforward
compared to 2.7 - I expected that the installer contains everything
necessary (since I did *not* pick "webinstall" one) and won't download
extra files (with the exception of the PDB option which did say
"download"). If the .msi files came from the .exe itself, I'd expect them
to be extracted into a unique temporary directory and not next to the exe.

I will work on freeing some space and then try again.

> Steve Dower  added the comment:
>
> Can you try moving the installer exe to its own (empty) directory before
> running it?
>

--

___
Python tracker 

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

[issue31772] SourceLoader uses stale bytecode in case of equal mtime seconds

[Brett Cannon]

Brett Cannon  added the comment:

The problem with that is it will increase the number of stat calls which we 
have always tried to minimize due to performance worries.

https://www.python.org/dev/peps/pep-0552/ has also been accepted which will 
take care of this specific case. So while I appreciate the work on this, Devin, 
I'm going to close this in favour of people who have this problem to use 
deterministic .pyc files instead.

--
nosy: +brett.cannon, eric.snow, ncoghlan
resolution:  -> wont fix
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

[issue31766] Python 3.5 missing from documentation

[Ned Deily]

Ned Deily  added the comment:

> Isn't Python 2.7 in Security Fix only as well ?

No, 2.7 is still being actively maintained (until 2020).
(https://devguide.python.org/#status-of-python-branches)

But, bowing to popular demand, I've restored 3.5 to the switchers for 3.7, 3.6, 
and 2.7.  It should appear again in the on-line docs shortly.  Thanks for all 
of your comments!

--
resolution: not a bug -> fixed
stage: patch review -> resolved
status: open -> closed
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

[issue31766] Python 3.5 missing from documentation

[Ned Deily]

Ned Deily  added the comment:


New changeset 356b68023d6fee5e30d25a4a680ac5b9e4f8dd65 by Ned Deily in branch 
'2.7':
bpo-31766: restore 3.5 to docs version switchers (#3971)
https://github.com/python/cpython/commit/356b68023d6fee5e30d25a4a680ac5b9e4f8dd65


--

___
Python tracker 

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

[issue31766] Python 3.5 missing from documentation

[Ned Deily]

Change by Ned Deily :


--
pull_requests: +3949

___
Python tracker 

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

[issue31766] Python 3.5 missing from documentation

[Ned Deily]

Ned Deily  added the comment:


New changeset f8d42ea0e4341b270f1de71b4ff40cfa18420eed by Ned Deily in branch 
'3.6':
bpo-31766: restore 3.5 to docs version switchers (#3970)
https://github.com/python/cpython/commit/f8d42ea0e4341b270f1de71b4ff40cfa18420eed


--

___
Python tracker 

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

[issue31766] Python 3.5 missing from documentation

[Ned Deily]

Change by Ned Deily :


--
pull_requests: +3948

___
Python tracker 

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

[issue31766] Python 3.5 missing from documentation

[Ned Deily]

Ned Deily  added the comment:


New changeset b7cbfe49e39a7bbd7da20b937735a8a60bbf1872 by Ned Deily in branch 
'master':
bpo-31766: restore 3.5 to docs version switchers (#3969)
https://github.com/python/cpython/commit/b7cbfe49e39a7bbd7da20b937735a8a60bbf1872


--

___
Python tracker 

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

[issue31763] Add NOTICE level to the logging module

[Matthew Patton]

Matthew Patton  added the comment:

syslog(3) is cited in the code as inspiration and has been the goto definition 
for logging levels for 40 years across many, many projects. NOTICE is 
incredibly useful especially to those of us who are sysadmins.

Why would Python not implement the full suite of syslog levels? Admittedly the 
case for ALERT and EMERGENCY might be a stretch. It at least doesn't hobble 
those who want to use them. Without proper coverage one has to settle for 
unnecessary jumbling of Noteworthy items being buried in the torrent of 
Informational but not really interesting items.

eg. INFO for attempting a connection. NOTICE for temporary service 
unavailability or handshake timeout, WARNING (maybe ERROR) for retry exhausted 
depending on what the failure means to the app.

eg. INFO for login attempts. NOTICE for password expiry date approaching, for 
failed logins (bad username/passwords, locked/expired account), for password 
change attempts, for temporary Federated Auth connect failure. None of which 
rise to the level of WARNING.

--

___
Python tracker 

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

[issue31766] Python 3.5 missing from documentation

[Ned Deily]

Change by Ned Deily :


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

___
Python tracker 

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

[issue31761] regrtest: faulthandler.enable() fails with io.UnsupportedOperation: fileno when run from IDLE

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

See issue25588. Currently running tests from IDLE doesn't work, but it worked 
in the past and maybe we can make it working again.

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue31766] Python 3.5 missing from documentation

[Fred L. Drake, Jr.]

Fred L. Drake, Jr.  added the comment:

The 3.5 docs should really remain in the main docs UI via the pulldown as long 
as it's so widely used.  The fact that it won't be changing much just means it 
can be served efficiently.

--
nosy: +fdrake

___
Python tracker 

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

[issue31766] Python 3.5 missing from documentation

[Anthony Flury]

Anthony Flury  added the comment:

Isn't Python 2.7 in Security Fix only as well ?

It seems strange; Python 3.5 probably the most heavily installed Python 3 
release (every Ubuntu installation has Python 3.5 installed by default - and 
neither Python 3.6 or 3.7 are available from the standard ubuntu repository); 
the docs.python.org site is the normal place people are directed to for help - 
and the implication of the removal will be for many people is that Python 3.5 
is obsolete which isn't the case at all.

--
status: pending -> open

___
Python tracker 

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

[issue31761] regrtest: faulthandler.enable() fails with io.UnsupportedOperation: fileno when run from IDLE

[Mariatta Wijaya]

Mariatta Wijaya  added the comment:

Closing this issue, I opened https://github.com/python/devguide/issues/280 so 
that Dev Guide can be updated.

Thanks!

--
nosy: +Mariatta
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

[issue31567] Inconsistent documentation around decorators

[Éric Araujo]

Éric Araujo  added the comment:

Cheers!

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

[issue31567] Inconsistent documentation around decorators

[Éric Araujo]

Éric Araujo  added the comment:


New changeset 205dd4e14de77f9c8ed2903ddebbcf9968bbb6a9 by Éric Araujo (Miss 
Islington (bot)) in branch '3.6':
[3.6] bpo-31567: add or fix decorator markup in docs (GH-3959) (GH-3966)
https://github.com/python/cpython/commit/205dd4e14de77f9c8ed2903ddebbcf9968bbb6a9


--

___
Python tracker 

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

[issue31567] Inconsistent documentation around decorators

[Éric Araujo]

Éric Araujo  added the comment:


New changeset 03b9537dc515d10528f83c920d38910b95755aff by Éric Araujo in branch 
'master':
bpo-31567: more decorator markup fixes in docs (GH-3959) (#3966)
https://github.com/python/cpython/commit/03b9537dc515d10528f83c920d38910b95755aff


--

___
Python tracker 

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

[issue31770] crash and refleaks when calling sqlite3.Cursor.__init__() more than once

[Oren Milman]

Change by Oren Milman :


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

___
Python tracker 

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

[issue31775] Support unbuffered TextIOWrapper

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

What methods still require read1()?

--

___
Python tracker 

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

[issue30767] logging must check exc_info correctly

[Matthew Patton]

Matthew Patton  added the comment:

I believe this diff addresses the failure of formatException() to check it's 
parameter's datatype. I still maintain this should be re-opened since it's 
guaranteed to raise an exception when someone sets 'exc_info=TruthyValue' in 
kwargs. albeit with a more focused PR.


diff --git a/Lib/logging/__init__.py b/Lib/logging/__init__.py
index 00a022039d..5c61cd56a1 100644
--- a/Lib/logging/__init__.py
+++ b/Lib/logging/__init__.py
@@ -533,6 +533,8 @@ class Formatter(object):
 This default implementation just uses
 traceback.print_exception()
 """
+if not isinstance(ei, tuple) or ei[0] is None:
+return ""
 sio = io.StringIO()
 tb = ei[2]
 # See issues #9427, #1553375. Commented out for now.
@@ -584,9 +586,7 @@ class Formatter(object):
 if self.usesTime():
 record.asctime = self.formatTime(record, self.datefmt)
 s = self.formatMessage(record)
-if (isinstance(record.exc_info, tuple) and record.exc_info[0]):
-# Intercept 'Boolean' - causes subscript error if passed to 
formatException,
-# and empty Tuples which emit 'NoneType None' into message.
+if record.exc_info:
 # Cache the traceback text to avoid converting it multiple times
 # (it's constant anyway)
 if not record.exc_text:

--

___
Python tracker 

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

[issue31415] Add -X option to show import time

[STINNER Victor]

STINNER Victor  added the comment:

Ok, the feature was implemented, the Windows clock resolution was fixed as 
well. It's time to close this issue.

If you still have concerns about import time, see open discussions on the 
python-dev mailing list, or open new issues ;-)

Thanks again Naoki INADA for this nice and useful feature!

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

[issue31773] Rewrite _PyTime_GetWinPerfCounter() for _PyTime_t

[STINNER Victor]

STINNER Victor  added the comment:


New changeset cba9a0c6def70549046f1afa6a80e38fe706520e by Victor Stinner in 
branch 'master':
bpo-31773: time.perf_counter() uses again double (GH-3964)
https://github.com/python/cpython/commit/cba9a0c6def70549046f1afa6a80e38fe706520e


--

___
Python tracker 

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

[issue31773] Rewrite _PyTime_GetWinPerfCounter() for _PyTime_t

[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

[issue31775] Support unbuffered TextIOWrapper

[STINNER Victor]

STINNER Victor  added the comment:

Context: I created this issue as a follow-up of the discussion on the -u 
command line option, bpo-28647, which still leaves sys.stdin *buffered* in the 
current master branch.

--

___
Python tracker 

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

[issue31567] Inconsistent documentation around decorators

[Berker Peksag]

Berker Peksag  added the comment:

> That said, staticmethod as a non-decorator has an important use case for
> function injection in tests (using self.func in TestCase classes that work 
> with
> a C module and an equivalent Python version).  Maybe this deserves an extra
> example?

Yes, that would be nice.

--

___
Python tracker 

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

[issue31775] Support unbuffered TextIOWrapper

[STINNER Victor]

STINNER Victor  added the comment:

> The falling back to read() was implemented in issue12591. What methods still 
> require read1()?

I read the Python implementation of TextIOWrapper in _pyio:

* seek() calls buffer.read() "if chars_to_skip:"... not sure that it can happen 
if buffer is a FileIO?
* read(None)  and read(-1) to read "everything" (until EOF): buffer.read()

It seems like read(None) also calls buffer.read() in the C implementation, 
_io_TextIOWrapper_read_impl():

/* Read everything */
PyObject *bytes = _PyObject_CallMethodId(self->buffer, _read, 
NULL);
PyObject *decoded;
if (bytes == NULL)
goto fail;

and in _io_TextIOWrapper_seek_impl():

/* Just like _read_chunk, feed the decoder and save a snapshot. */
PyObject *input_chunk = _PyObject_CallMethodId(
self->buffer, _read, "i", cookie.bytes_to_feed);

--

___
Python tracker 

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

[issue28647] python --help: -u is misdocumented as binary mode

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

> Hum, I propose to mention stdin in -u documentation as: "The option has no 
> effect on stdin." What do you think?

This LGTM too. More precise, it has no effect on stdin buffering. It has effect 
on the line_buffering attribute, but this attribute has no effect on reading.

> The last sentence is wrong and should be removed from sys.stdin 
> documentation, no?

Or correct it, making it related only to stdout and stderr.

--

___
Python tracker 

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

[issue28647] python --help: -u is misdocumented as binary mode

[STINNER Victor]

STINNER Victor  added the comment:

Serhiy: "I think there is no need to mention stdin in the context of the -u 
option at all. -u doesn't affect stdin buffering, whatever that would mean. 
Period."

Hum, I propose to mention stdin in -u documentation as: "The option has no 
effect on stdin." What do you think?

--

___
Python tracker 

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

[issue31775] Support unbuffered TextIOWrapper

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

The falling back to read() was implemented in issue12591. What methods still 
require read1()?

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue31767] Windows Installer fails with error 0x80091007 when trying to install debugging symbols

[Steve Dower]

Steve Dower  added the comment:

Can you try moving the installer exe to its own (empty) directory before 
running it?

The correct file is on the server (I just redownloaded and verified), so the 
most likely cause is that you ran a /layout at some point in the past and are 
getting that file locally. As you saw in the log, we will look in the directory 
the installer is launched from for a matching local file, so that it's possible 
to download all the optional components and then do a full install while 
offline.

--

___
Python tracker 

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

[issue31775] Support unbuffered TextIOWrapper

[STINNER Victor]

STINNER Victor  added the comment:

Oh, currently it's not possible to create an unbuffered read-only TextIOWrapper 
object:

haypo@selma$ python3
Python 3.6.2 (default, Oct  2 2017, 16:51:32) 
>>> open("/etc/issue", "r", 0)
Traceback (most recent call last):
  File "", line 1, in 
ValueError: can't have unbuffered text I/O

--

___
Python tracker 

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

[issue31567] Inconsistent documentation around decorators

[Éric Araujo]

Éric Araujo  added the comment:

I think existing uses of the decorator markup rely on the reader’s 
understanding that it’s syntactic sugar for a call and an assignment, and they 
don’t have decorator+function markup.  The PRs for this ticket follow that.

That said, staticmethod as a non-decorator has an important use case for 
function injection in tests (using self.func in TestCase classes that work with 
a C module and an equivalent Python version).  Maybe this deserves an extra 
example?

--

___
Python tracker 

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

[issue28647] python --help: -u is misdocumented as binary mode

[STINNER Victor]

STINNER Victor  added the comment:

> I think we need to document behavior of stdin somewhere, because current the 
> sys.stdin documentation states:
>
>> When interactive, standard streams are line-buffered. Otherwise, they
>> are block-buffered like regular text files. You can override this value
>> with the -u command-line option.

The last sentence is wrong and should be removed from sys.stdin documentation, 
no?

--

___
Python tracker 

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

[issue31775] Support unbuffered TextIOWrapper

[STINNER Victor]

STINNER Victor  added the comment:

I created this issue because of this comment in create_stdio() of 
Python/pylifecycle.c:
---
/* stdin is always opened in buffered mode, first because it shouldn't
   make a difference in common use cases, second because TextIOWrapper
   depends on the presence of a read1() method which only exists on
   buffered streams.
*/
if (Py_UnbufferedStdioFlag && write_mode)
buffering = 0;
else
buffering = -1;
---

--

___
Python tracker 

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

[issue31567] Inconsistent documentation around decorators

[Éric Araujo]

Change by Éric Araujo :


--
pull_requests: +3945

___
Python tracker 

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

[issue31775] Support unbuffered TextIOWrapper

[STINNER Victor]

New submission from STINNER Victor :

It seems like that some methods of the io.TextIOWrapper class requires that its 
buffer object has the read1() method, whereas the constructor checks if the 
buffer has a read1() method and the TextIOWrapper _read_chunk() method is able 
to call buffer.read() if buffer doesn't have read1().

This issue may help to get fully unbuffered sys.stdin, at least when replaced 
manually:

stdin = sys.stdin
sys.stdin = open(0, "r", buffering=0, encoding=stdin.encoding, 
errors=stdin.errors, newline=stdin.newline)

--
components: IO
messages: 304250
nosy: haypo
priority: normal
severity: normal
status: open
title: Support unbuffered TextIOWrapper
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

[issue28647] python --help: -u is misdocumented as binary mode

[STINNER Victor]

STINNER Victor  added the comment:

Interesting comment in create_stdio() of Python/pylifecycle.c:
---
/* stdin is always opened in buffered mode, first because it shouldn't
   make a difference in common use cases, second because TextIOWrapper
   depends on the presence of a read1() method which only exists on
   buffered streams.
*/
if (Py_UnbufferedStdioFlag && write_mode)
buffering = 0;
else
buffering = -1;
---

stdin is always buffered ;-)

I created bpo-31775: "Support unbuffered TextIOWrapper".

--

___
Python tracker 

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

[issue31490] assertion failure in ctypes in case an _anonymous_ attr appears outside _fields_

[Serhiy Storchaka]

Change by Serhiy Storchaka :


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

[issue24084] pstats: sub-millisecond display

[STINNER Victor]

STINNER Victor  added the comment:

> I concur with Victor. This change likely breaks graphical viewers of pstat 
> data.

I propose to *do* break the format by always displaying percall timings with a 
precision of 6 digits.

--

___
Python tracker 

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

[issue24084] pstats: sub-millisecond display

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

I concur with Victor. This change likely breaks graphical viewers of pstat data.

How gprof and similar tools solve the problem of outputting sub-millisecond 
timings?

--

___
Python tracker 

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

[issue24084] pstats: sub-millisecond display

[Serhiy Storchaka]

Change by Serhiy Storchaka :


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

___
Python tracker 

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

[issue24084] pstats: sub-millisecond display

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

I concur with Victor. This change likely breaks graphical viewers of pstat data.

How gprof and similar tools solve the problem of outputting sub-microsecond 
timings?

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue31567] Inconsistent documentation around decorators

[Berker Peksag]

Berker Peksag  added the comment:

Use of classmethod and staticmethod decorators as functions is still a valid 
use case. I think the old signatures should be kept. It should be possible to 
document both uses in same place:

.. function:: classmethod(function)
.. decorator:: classmethod

   Documentation body.

--
nosy: +berker.peksag

___
Python tracker 

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

[issue31761] regrtest: faulthandler.enable() fails with io.UnsupportedOperation: fileno when run from IDLE

[Denis Osipov]

Denis Osipov  added the comment:

Got it. Thank you for your help.

--

___
Python tracker 

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

[issue31567] Inconsistent documentation around decorators

[Roundup Robot]

Change by Roundup Robot :


--
pull_requests: +3944

___
Python tracker 

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

[issue31490] assertion failure in ctypes in case an _anonymous_ attr appears outside _fields_

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset fb3bb8d5d5d70acaaa0fdec15c137544fdd4463f by Serhiy Storchaka 
(Oren Milman) in branch '2.7':
[2.7] bpo-31490: Fix an assertion failure in ctypes in case an _anonymous_ attr 
is defined only outside _fields_. (GH-3615) (#3952)
https://github.com/python/cpython/commit/fb3bb8d5d5d70acaaa0fdec15c137544fdd4463f


--

___
Python tracker 

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

[issue31567] Inconsistent documentation around decorators

[Éric Araujo]

Éric Araujo  added the comment:


New changeset 0e61e67a57deb4abc677808201d7cf3c38138e02 by Éric Araujo (Daisuke 
Miyakawa) in branch 'master':
bpo-31567: add or fix decorator markup in docs (#3959)
https://github.com/python/cpython/commit/0e61e67a57deb4abc677808201d7cf3c38138e02


--

___
Python tracker 

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

[issue31773] Rewrite _PyTime_GetWinPerfCounter() for _PyTime_t

[STINNER Victor]

Change by STINNER Victor :


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

___
Python tracker 

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

[issue28647] python --help: -u is misdocumented as binary mode

[Berker Peksag]

Berker Peksag  added the comment:

> -u doesn't affect stdin buffering, whatever that would mean.

I think we need to document behavior of stdin somewhere, because current the 
sys.stdin documentation states:

> When interactive, standard streams are line-buffered. Otherwise, they
> are block-buffered like regular text files. You can override this value
> with the -u command-line option.

https://docs.python.org/3/library/sys.html#sys.stdin

--

___
Python tracker 

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

[issue31774] tarfile.open ignores custom bufsize value when creating a new archive

[Charalampos Stratakis]

New submission from Charalampos Stratakis :

Trying to create an archive with the tarfile module, by specifying a different 
blocking factor, doesn't seem to work as only the default value is being used. 
The issue is reproducible on all the active python branches.

Attaching a script to reproduce it.

Original bug report: https://bugzilla.redhat.com/show_bug.cgi?id=1492157

--
components: Library (Lib)
files: tartest.py
messages: 304241
nosy: cstratak, lars.gustaebel
priority: normal
severity: normal
status: open
title: tarfile.open ignores custom bufsize value when creating a new archive
versions: Python 2.7, Python 3.6, Python 3.7
Added file: https://bugs.python.org/file47218/tartest.py

___
Python tracker 

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

[issue28647] python --help: -u is misdocumented as binary mode

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

stdin is mentioned in the documentation of the -u option only due to weird 
internal buffering in Python 2, because user can expect that -u disables it. It 
is documented what methods use internal buffering and how get rid of it. No 
other buffering is mentioned.

This no longer actual in Python 3. I think there is no need to mention stdin in 
the context of the -u option at all. -u doesn't affect stdin buffering, 
whatever that would mean. Period.

Alternatively you can include a lecture about different kinds of buffering and 
how -u doesn't affect them.

--

___
Python tracker 

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

[issue31773] Rewrite _PyTime_GetWinPerfCounter() for _PyTime_t

[STINNER Victor]

New submission from STINNER Victor :

The commit a997c7b434631f51e00191acea2ba6097691e859 of bpo-31415 moved the 
implementation of time.perf_counter() from Modules/timemodule.c to 
Python/pytime.c. The change not only moved the code, but also changed the 
internal type storing time from floatting point number (C double) to integer 
number (_PyTyime_t = int64_t).

The drawback of this change is that time.perf_counter() now converts 
QueryPerformanceCounter() / QueryPerformanceFrequency() double into a _PyTime_t 
(integer) and then back to double. Two useless conversions required by the 
_PyTime_t format used in Python/pytime.c. These conversions introduced a loss 
of precision.

Try attached round.py script which implements the double <=> _PyTime_t 
conversions and checks to check for precision loss. The script shows that we 
loose precision even with a single second for QueryPerformanceFrequency() == 
3579545.

It seems like QueryPerformanceFrequency() now returns 10 ** 7 (10_000_000, 
resolution of 100 ns) on Windows 8 and newer, but returns 3,579,545 (3.6 MHz, 
resolution of 279 ns) on Windows 7. It depends maybe on the hardware clock, I 
don't know. Anyway, whenever possible, we should avoid precision loss of a 
clock.

--
components: Interpreter Core
files: round.py
messages: 304239
nosy: haypo
priority: normal
severity: normal
status: open
title: Rewrite _PyTime_GetWinPerfCounter() for _PyTime_t
type: enhancement
versions: Python 3.7
Added file: https://bugs.python.org/file47217/round.py

___
Python tracker 

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

[issue30767] logging must check exc_info correctly

[Matthew Patton]

Matthew Patton  added the comment:

And the reason to stomp on the "Level " is because by not doing so the message 
that is a single field (regex/awk) has been converted non-deterministically 
into two. This is very bad behavior. If emitting the string/int as-is looks 
wrong then "Level(value)" or some other notation that keeps it a single field 
is how it should print.

--

___
Python tracker 

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

[issue31772] SourceLoader uses stale bytecode in case of equal mtime seconds

[Devin Bayer]

Change by Devin Bayer :


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

___
Python tracker 

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

[issue28647] python --help: -u is misdocumented as binary mode

[STINNER Victor]

STINNER Victor  added the comment:

Serhiy Storchaka:
https://github.com/python/cpython/pull/3961#issuecomment-336136160

"I suggest to continue the discussion on the tracker."

Ok, let's continue here.

"We are fixing the outdated documentation inherited from Python 2. First than 
keep some statement we should consider what it means in the context of Python 2 
and what it means in the context of Python 3."

stdin buffering is a complex thing.

When running the UNIX command "producer | consumer", many users are confused by 
the buffering on the *producer* side.

When running a program in a TTY, the TTY does line buffering for you, you 
cannot get immediately a single character (without changing the default TTY 
configuration).

I don't think that we need to say too much. I just suggest to say "stdin is 
always buffered". That's all.

See my previous messages for the my definition of "buffered" versus 
"unbuffered" read.

Note: Today I learned the UNIX "stdbuf" command, useful to configure the stdin, 
stdout and stderr buffering of C applications using .

--

___
Python tracker 

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

[issue31772] SourceLoader uses stale bytecode in case of equal mtime seconds

[Devin Bayer]

New submission from Devin Bayer :

The current import machinery will use stale cached bytecode if the source is 
modified more than once per second and with equal size.

A straightforward fix is to require the bytecode mtime to be greater than the 
source file mtime. In the unusual case where the file is written twice with the 
precision the filesystem records, this will ignore the cache, but at least we 
aren't behaving incorrectly.

--
components: Interpreter Core
messages: 304236
nosy: akvadrako
priority: normal
severity: normal
status: open
title: SourceLoader uses stale bytecode in case of equal mtime seconds
type: behavior
versions: Python 3.7

___
Python tracker 

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

[issue30767] logging must check exc_info correctly

[Matthew Patton]

Matthew Patton  added the comment:

Additionally (probably should have separate PR) the _checkLevel was full of 
holes.
First, it's allowing any Integer which if you're claiming to "check" things is 
rather silly. At least bounds-check it to GE to NOTSET and LE to CRITICAL (or 
MAX or something handy in that regard).

Second, why is a string representation of an Integer a problem that needs to 
force the caller to fix his code? Same with lowercase of a recognized value. 
"Be liberal in what you accept" would seem to apply here. If it can be 
trivially reduced to an integer or upcased() to get a match then just do it, 
and send the corrected value back to the caller.

--

___
Python tracker 

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

[issue31771] tkinter geometry string +- when window ovelaps left or top of screen

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Tkinter is just a wrapper around the Tk library. It returns what Tk returns. 
See Tk documentation:

https://www.tcl.tk/man/tcl8.6/TkCmd/winfo.htm#M15
https://www.tcl.tk/man/tcl8.6/TkCmd/wm.htm#M42

If you want to improve Tkinter documentation, patches are welcome.

--
assignee:  -> docs@python
components: +Documentation
nosy: +docs@python, serhiy.storchaka
type: behavior -> enhancement
versions: +Python 2.7, Python 3.6, Python 3.7 -Python 3.5

___
Python tracker 

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

[issue31771] tkinter geometry string +- when window ovelaps left or top of screen

[Peter J]

New submission from Peter J :

the root.geometry() top-level window method returns strings like 
"212x128+-9+-8" when the window is located in the top left corner. The 
documentation only describes geometry strings containing + or - location 
coordinates. If this is correct behaviour, the documentation should provide a 
better description of the syntax - perhaps a regular expression such as: 
"\d+x\d+(\+|-|\+-)\d+(\+|-|\+-)\d+" and some text indicating that a +- 
coordinate indicates a value to the left of or above the screen.

Tested Linux Mint 18, Python 3.5.3, tkinter 8.6

Behaviour is consistent with python 2.7 Tkinter 8.6

--
components: Tkinter
messages: 304232
nosy: 8baWnoVi
priority: normal
severity: normal
status: open
title: tkinter geometry string +- when window ovelaps left or top of screen
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