[issue31571] Redundand information on Doc/reference/lexical_analysis.rst

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Guido, in 60f2f0cf8e10c94693dfea8937b7feabeffe5744 you added the phrase "Note 
that numeric literals do not include a sign; ..." in the "Numeric literals" 
section. Did you mean moving it from the "Floating point literals" section or 
creating a duplicate?

--

___
Python tracker 

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

[issue31475] Bug in argparse - not supporting utf8

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
status: open -> pending

___
Python tracker 

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

[issue31145] PriorityQueue.put() fails with TypeError if priority_number in tuples of (priority_number, data) are the same.

[Nick Coghlan]

Nick Coghlan added the comment:

My rationale for asking "What if we just changed heapq back to working closer 
to the way it used to work?" is that it's a case where arbitrarily ordering 
unorderable tuples made sense, and reverting it to the old behaviour is 
reasonably safe:

- some Py3 heapq code that previously raised TypeError would start using an 
arbitrary ordering instead
- Py2 heapq code would get a *different* arbitrary ordering in Py3, but it 
would still get an arbitrary ordering

I don't feel especially strongly about that though, so if you prefer the 
approach of defining a new more explicit idiom to replace the old "make a 
tuple" one, I think a new wrapper type is a reasonable way to go, but using 
"Prioritize" as a name is probably too specific to the PriorityQueue use case.

As a more generic name, "KeyedItem" might work:

```
@functools.total_ordering
class KeyedItem:

def __init__(self, key, item):
self.key = key
self.item = item

def __eq__(self, other):
return self.key == other.key

def __lt__(self, other):
return self.key < other.key
```

So applying an arbitrary key function would look like:

decorated = [KeyedItem(key(v), v) for v in values]

And if it was a tuple subclass, it would also work with APIs like the dict 
constructor.

--

___
Python tracker 

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

[issue31475] Bug in argparse - not supporting utf8

[INADA Naoki]

INADA Naoki added the comment:

ping?
May I close this issue and pull request?

--

___
Python tracker 

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

[issue31131] asyncio.wait_for() TimeoutError doesn't provide full traceback

[Surenkumar Nihalani]

Surenkumar Nihalani added the comment:

this'd be useful to me as well. I'd propose we pass the future in the exception 
object.

Can write a write a tiny patch for this if someone would approve.

--
nosy: +snihalani

___
Python tracker 

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

[issue28754] Argument Clinic for bisect.bisect_left

[Raymond Hettinger]

Raymond Hettinger added the comment:

FWIW, the itertools module has many functions that can have the ArgumentClinic 
applied without any fundamental problems (pretty much all of the functions will 
work except for repeat(), accumulate(), and islice()).

--

___
Python tracker 

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

[issue30995] Support logging.getLogger(style='{')

[Raymond Hettinger]

Raymond Hettinger added the comment:

> logger.info( f" {logger.name:s} {logger.module:s} " ) 
>
> this could be supported with full backward compatibility 
> with very little effort.   
>
> Am I missing something?

One issue is that some of that data isn't known until the logging.info() call 
is made. And accessing the data before the call would bypass the internal 
locks, potentially causing race conditions.

Another issue is that having to use an attribute lookup for every variable 
isn't fast and doesn't look very nice (making this feature awkward to use when 
the whole goal is to improve usability).

FWIW, you can already use f-strings for all of your local data.  The logging 
internal data tends to be already set upsteam in the configuration format 
(which is only done once):

# Formatting is only done once so %-formatting isn't problematic
logging.basicConfig(
level = logging.INFO,
format = '%(levelname)-8s | %(asctime)s | %(message)s',
filename = 'demo.log',
)

# In the body of the code, use f-strings for your local data:
logging.info(f'There are {active_users} in {session_name}')

--

___
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

[INADA Naoki]

INADA Naoki added the comment:

I don't have any good idea for it.

I usually run `python -X importtime -c 'import functools'` several times to 
ensure pyc files are created and it is cached by OS.

On Linux, `strace -c` and `time` command can be used.
But I don't know cross platform way to do it.

$ strace -c python -c 'import asyncio'
% time seconds  usecs/call callserrors syscall
-- --- --- - - 
  0.000.00   0   244   read
  0.000.00   0   160 2 open
  0.000.00   0   161   close
  0.000.00   0   52746 stat
  0.000.00   0   266   fstat
  0.000.00   016   lstat
  0.000.00   0   114 6 lseek
  0.000.00   0   109   mmap

$ /usr/bin/time python -c 'import asyncio'
0.12user 0.00system 0:00.13elapsed 98%CPU (0avgtext+0avgdata 17004maxresident)k
0inputs+0outputs (0major+2613minor)pagefaults 0swaps

--

___
Python tracker 

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

[issue31145] PriorityQueue.put() fails with TypeError if priority_number in tuples of (priority_number, data) are the same.

[Raymond Hettinger]

Raymond Hettinger added the comment:

We already have recommendations in the heapq documentation on how to do a 
work-around.   I'm looking at the more general problem of how can we make it 
easy once again to decorate a value with a sort value (not just for heaps but 
for anyplace where comparisons are made).

I would like our preferred answer to be something better than, "take all your 
existing functions that use comparisons and make new variants that compute and 
cache key functions".   Instead, I would rather, "keep your existing functions 
simple and just wrap your data in something that specifies comparison values 
that are computed just once". 

The old Schwartzian transform (decorate-compare-undecorate) had broad 
applicability but was effectively killed when a simple tuple no longer served 
for decoration.  

FWIW, the DataClass discussion has also ventured into this territory (the field 
definitions can specify whether or not a field is included in the rich 
comparison methods).

--

___
Python tracker 

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

[issue31553] Extend json.tool to handle jsonlines (with a flag)

[Raymond Hettinger]

Raymond Hettinger added the comment:

Eric, did you want to write the PR yourself or would you like for Lisa to bring 
it to fruition?   If you're going to do it yourself, Lisa will serve as the 
primary reviewer (with either Ezio or me doing the final sign-off).

--
assignee:  -> lisroach
nosy: +lisroach

___
Python tracker 

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

[issue31356] Add context manager to temporarily disable GC

[Raymond Hettinger]

Raymond Hettinger added the comment:

Assigning this to Lisa for a C implementation, docs, and tests.

--
assignee:  -> lisroach
nosy: +lisroach

___
Python tracker 

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

[issue31145] PriorityQueue.put() fails with TypeError if priority_number in tuples of (priority_number, data) are the same.

[Nick Coghlan]

Nick Coghlan added the comment:

The main downside I see to that approach is that it would still require quite a 
few client code changes to restore compatibility for folks upgrading from 2.7, 
and even though six could add a "six.Prioritize" backport, it would still be 
difficult for automated tools to work out *where* such a wrapper would be 
appropriate.

So I'm wondering whether it might be worth defining a heapq.compareitem helper 
that special cases tuples, such that heapq switched to using a slightly 
modified definition of tuple comparisons:

def compareitem(lhs, rhs):
"""<= variant that ensures all tuples are orderable"""
is not isinstance(lhs, tuple) or not isinstance(rhs, tuple):
return lhs <= rhs
# Compare tuples up to first unequal pair
for lhs_item, rhs_item in zip(lhs, rhs):
if lhs_item != rhs_item:
try:
return lhs_item < rhs_item
except TypeError:
pass
break
# All item pairs equal, or unorderable pair found
return len(lhs) <= len(rhs)

The key difference would be that if the heap-centric tuple comparison 
encounters a non-equal, unorderable pair of items, it would fall back to just 
comparing the tuple lengths (just as regular tuple comparison does when all 
item pairs are equal), rather than letting the TypeError propagate the way the 
default tuple comparison operator does.

The heap invariant would change slightly such that 
"storage.sort(key=heapq.compareitem)" would reliably preserve the heap 
invariant without raising an exception, while "storage.sort()" might instead 
fail with TypeError.

--

___
Python tracker 

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

[issue31351] ensurepip discards pip's return code which leads to broken venvs

[Nick Coghlan]

Nick Coghlan added the comment:

And done - thanks for the report and PRs, Igor!

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

[issue31351] ensurepip discards pip's return code which leads to broken venvs

[Nick Coghlan]

Nick Coghlan added the comment:


New changeset cf7197ae43767c4346864e5b41246f628edd9b51 by Nick Coghlan (Igor 
Filatov) in branch '2.7':
[2.7] bpo-31351: Set return code in ensurepip when pip fails (GH-3734)
https://github.com/python/cpython/commit/cf7197ae43767c4346864e5b41246f628edd9b51


--

___
Python tracker 

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

[issue30947] Update embeded copy of libexpat from 2.2.1 to 2.2.3

[Larry Hastings]

Larry Hastings added the comment:


New changeset f2492bb6aae061aea47e21fc7e56b7ab9bfdf543 by larryhastings (Victor 
Stinner) in branch '3.5':
[3.5][Security] bpo-30947, bpo-31170: Update expat from 2.2.1 to 2.2.4 (#3354)
https://github.com/python/cpython/commit/f2492bb6aae061aea47e21fc7e56b7ab9bfdf543


--

___
Python tracker 

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

[issue31170] Update to expat 2.2.4 (expat: utf8_toUtf8 cannot properly handle exhausting buffer)

[Larry Hastings]

Larry Hastings added the comment:


New changeset f2492bb6aae061aea47e21fc7e56b7ab9bfdf543 by larryhastings (Victor 
Stinner) in branch '3.5':
[3.5][Security] bpo-30947, bpo-31170: Update expat from 2.2.1 to 2.2.4 (#3354)
https://github.com/python/cpython/commit/f2492bb6aae061aea47e21fc7e56b7ab9bfdf543


--

___
Python tracker 

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

[issue31561] difflib pathological behavior with mixed line endings

[Tim Peters]

Tim Peters added the comment:

The text/binary distinction you have in mind doesn't particularly apply to 
difflib:  it compares sequences of hashable objects.  "Text files" are 
typically converted by front ends to lists of strings, but, e.g., the engine is 
just as happy comparing tuples of floats.

File comparison interfaces typically do this at _two_ levels:  first, viewing 
files as lists of strings (one string per file line).  Then, when two blocks of 
mismatching lines are encountered, viewing the lines as sequences of 
characters.  The only role "line endings" play in any of this is in how the 
_input_ to the difference engine is created:  all decisions about how a file is 
broken into strings are made before the difference engine is consulted.  This 
preprocessing can choose to normalize line endings, leave them exactly as-is 
(typical), or remove them entirely from the strings it presents to the 
difference engine - or anything else it feels like doing.  The engine itself 
has no concept of "line termination sequences" - if there happen to be \r\n, 
\n, \r, or \0 substrings in strings passed to it, they're treated exactly the 
same as any other characters.

If the input processing creates lists of lines A and B for two files, where the 
files have different line-end terminators which are left in the strings, then 
no exact match whatsoever is possible between any line of A and a line in B.  
You suggest to just skip over both then, but the main text-file-comparison 
"front end" in difflib works hard to try to do better than that.  That's "a 
feature", albeit a potentially expensive one.  Viewing the file lines as 
sequences of characters, it computes a "similarity score" for _every_ line in A 
compared to _every_ line in B.  So len(A)*len(B) such scores are computed.  The 
pair with the highest score (assuming it exceeds a cutoff value) is taken as 
being the synch point, and then it can go on to show the _intra_line 
differences between those two lines.

That's why, e.g., given the lists of "lines":

A = ["eggrolls", "a a a", "b bb"]
B = ["ccc", "dd d", "egg rolls"]

it can (and does) tell you that the `egg rolls` in B was plausibly obtained 
from the `eggrolls` in A by inserting a blank.  This is often much more helpful 
than just giving up, saying "well, no line in A matched any line in B, so we'll 
just say A was entirely replaced by B".  That would be "correct" too - and much 
faster - but not really helpful.

Of course there's nothing special about the blank character in that.  Exactly 
the same applies if the line terminators differ between the files, and input 
processing leaves them in the strings.  difflib doesn't give up just because 
there are no exact line-level matches, and the same expensive "similarity 
score" algorithm kicks in to find the "most similar" lines despite the lack of 
exact matches.

Since that's a feature (albeit potentially expensive), I agree with Raymond 
closing this.  You can, of course, avoid the expense by ensuring your files all 
use the same line terminator sequence to begin with.  Which is the one obvious 
& thoroughly sane approach ;-)  Alternatively, talk to the `icdiff` author(s).  
I noticed it opens files for reading in binary mode, guaranteeing that 
different line-end conventions will be visible.  It's possible they could be 
talked into opening text files (or add an option to do so) using Python's 
"universal newline" mode, which converts all instances of \n, \r\n, and \r to 
\n on input.  Then lines that are identical except for line-end convention 
would in fact appear identical to difflib, and so skip the expensive similarity 
computations whenever that's so.

--

___
Python tracker 

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

[issue31561] difflib pathological behavior with mixed line endings

[Raymond Hettinger]

Raymond Hettinger added the comment:

> Of course I can understand if all this is out of the scope of difflib and not 
> an endeavor worth taking up.

I agree with that sentiment.  Data normalization for comparability belongs 
upstream from difflib (i.e. normalizing line-endings, unicode normalization, 
case folding, etc).  Difflib's job is to compute a diff.

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

[issue31415] Add -X option to show import time

[Raymond Hettinger]

Raymond Hettinger added the comment:

Naoki, is it possible to separate out how much of this is I/O vs CPU time?

If the I/O dominates, optimizations tend toward zipimports, faster drives, disk 
caching etc.  If the CPU time is dominant, different techniques are used (lazy 
evaluation, splitting-out parts of a package, etc).

--

___
Python tracker 

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

[issue23702] docs.python.org/3/howto/descriptor.html still refers to "unbound methods"

[Raymond Hettinger]

Changes by Raymond Hettinger :


--
keywords: +patch
pull_requests: +3725
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

[issue28754] Argument Clinic for bisect.bisect_left

[Raymond Hettinger]

Raymond Hettinger added the comment:

After more thought, I'm going to close this one because the Argument Clinic and 
signature objects aren't yet a good fit for this API.  The bisect module isn't 
broken (its API has been successfully living in the wild for a very long time). 
 I do welcome Argument Clinic patches where there is a good fit but don't think 
this is the place.  Each of the proposed patches makes the module worst in one 
way or another.

--
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

___
Python tracker 

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

[issue31153] Update docstrings of itertools functions

[Raymond Hettinger]

Raymond Hettinger added the comment:

Marking this as closed.  1) is being fixed elsewhere, 2) don't want to make 
func=None an official part of the API (it was a convenience for letting func 
default to the equivalent of operator.add), 3) already fixed, and 4) already 
fixed.

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

[issue31299] Add "ignore_modules" option to TracebackException.format()

[Dmitry Kazakov]

Dmitry Kazakov added the comment:

Yes, a public built-in facility to modify a traceback would certainly be 
useful, although there should be a standard way to "hide" unwanted frames 
without mutating the traceback, too, and the traceback module seems a perfect 
place to add it.

I have no objections to the `filter` argument, though filtering out frames 
based on modules to me feels by far more common a task than anything else 
`filter` would be capable of.

I can update the PR if there's a consensus that `filter` is favored over 
`ignore_modules`.

--

___
Python tracker 

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

[issue31568] Configure thinks it finds python3.5 but doesn't

[Larry Hastings]

Larry Hastings added the comment:


New changeset 70c630a7316f9f6063557786442e3c56502fe8ea by larryhastings (Victor 
Stinner) in branch '3.5':
bpo-31568, Travis CI: Fix python3.5 (#3737)
https://github.com/python/cpython/commit/70c630a7316f9f6063557786442e3c56502fe8ea


--

___
Python tracker 

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

[issue31571] Redundand information on Doc/reference/lexical_analysis.rst

[Guido van Rossum]

Guido van Rossum added the comment:

Is there anything here that requires my attention?

--

___
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

[Guido van Rossum]

Guido van Rossum added the comment:

@rhettinger
> Guido, is this something you want?

I think it is useful given how much debate there has been around startup time 
in various contexts (not just pure interpreter startup time but also startup 
time when using specific libraries, packages or applications).

> Historically, we've shown a lot of restraint when it comes to adding
> command-line options.

But this is hardly a new command-line option; -X already exists. I think it's 
reasonable to add it here.

> Also, I'm not sure we want to induce people to start moving their imports
> inside function calls. [...]

That's a big leap from collecting the data to suggesting a specific solution. I 
don't think that making it harder to get the data really is the right approach 
to discouraging a debatable practice (plus, there are many situations where the 
practice *is* useful -- just as there are many situations where it's 
counterproductive). Consenting adults.

--

___
Python tracker 

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

[issue27385] itertools.groupby has misleading doc string

[Raymond Hettinger]

Changes by Raymond Hettinger :


--
pull_requests: +3724

___
Python tracker 

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

[issue30995] Support logging.getLogger(style='{')

[Steven Warwick]

Steven Warwick added the comment:

sorry, I meant the following:

logger.info( " {:s} {:s} ".format(logger.name, logger.module ) )

or 

logger.info( f" {logger.name:s} {logger.module:s} " ) 

this could be supported with full backward compatibility with very little 
effort.   

Am I missing something?

--

___
Python tracker 

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

[issue31568] Configure thinks it finds python3.5 but doesn't

[STINNER Victor]

STINNER Victor added the comment:

The Travis CI error is:
---
python3.5 ./Objects/typeslots.py \

< ./Include/typeslots.h \

./Objects/typeslots.inc

pyenv: python3.5: command not found

pyenv: python3.5: command not found

The `python3.5' command exists in these Python versions:

pyenv: python3.5: command not found

  3.5

  3.5.3

make: *** [regen-opcode] Error 127

make: *** Waiting for unfinished jobs
---

It looks like this Travis CI bug:
https://github.com/travis-ci/travis-ci/issues/8363

I wrote https://github.com/python/cpython/pull/3737 which should works around 
the Travis CI. Change inspired by:
https://github.com/pre-commit/pre-commit/commit/e3ab8902692e896da9ded42bd4d76ea4e1de359d

--

___
Python tracker 

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

[issue31568] Configure thinks it finds python3.5 but doesn't

[STINNER Victor]

Changes by STINNER Victor :


--
keywords: +patch
pull_requests: +3723
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

[issue30085] Discourage operator.__dunder__ functions

[Terry J. Reedy]

Terry J. Reedy added the comment:


New changeset d38caf68bb417232fb0ccecb5558d7d0ca4a9507 by Terry Jan Reedy (Miss 
Islington (bot)) in branch '3.6':
[3.6] bpo-30085: Improve documentation for operator (GH-1171) (#3736)
https://github.com/python/cpython/commit/d38caf68bb417232fb0ccecb5558d7d0ca4a9507


--

___
Python tracker 

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

[issue30085] Discourage operator.__dunder__ functions

[Roundup Robot]

Changes by Roundup Robot :


--
pull_requests: +3722

___
Python tracker 

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

[issue31566] assertion failure in _warnings.warn() in case of a bad __name__ global

[Serhiy Storchaka]

Serhiy Storchaka added the comment:


New changeset 415cc1fa57710614ed3384d0cafc58ccf7adee8c by Serhiy Storchaka 
(Miss Islington (bot)) in branch '3.6':
[3.6] bpo-31566: Fix an assertion failure in _warnings.warn() in case of a bad 
__name__ global. (GH-3717) (#3730)
https://github.com/python/cpython/commit/415cc1fa57710614ed3384d0cafc58ccf7adee8c


--

___
Python tracker 

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

[issue30826] More details in reference 'Looping through a list in Python and modifying it'

[Terry J. Reedy]

Terry J. Reedy added the comment:

I agree that the tutorial For section needs be updated to include 
non-sequences. A dict example will help with that.

I agree that the unrealistic insert mis-directs attention and like Raymond's 
replacement.  ['users.copy()' should be 'users.copy().items']

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

[issue31507] email.utils.parseaddr has no docstring

[Rohit Balasubramanian]

Changes by Rohit Balasubramanian <98bro...@gmail.com>:


--
pull_requests: +3721

___
Python tracker 

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

[issue31351] ensurepip discards pip's return code which leads to broken venvs

[Igor Filatov]

Changes by Igor Filatov :


--
pull_requests: +3720
stage: backport needed -> patch review

___
Python tracker 

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

[issue31507] email.utils.parseaddr has no docstring

[Rohit Balasubramanian]

Changes by Rohit Balasubramanian <98bro...@gmail.com>:


--
pull_requests: +3719

___
Python tracker 

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

[issue30995] Support logging.getLogger(style='{')

[Raymond Hettinger]

Raymond Hettinger added the comment:

[Vinay Sajip]
> I don't think the ways of doing this are bulletproof and 
> require too much cooperation between third-party libraries.

I concur with all of Vinay's comments.  

If logging were being redesigned from scratch, it would likely use new-style 
formatting everywhere.  But, it is already deployed and widely adopted.  Trying 
to make it support two-ways-to-do-it would likely create more problems than it 
solves.

Vinay, do you want to reject and close this proposal?

--
assignee:  -> vinay.sajip
nosy: +rhettinger

___
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

[Raymond Hettinger]

Raymond Hettinger added the comment:

Guido, is this something you want?

Historically, we've shown a lot of restraint when it comes to adding 
command-line options.  

Also, I'm not sure we want to induce people to start moving their imports 
inside function calls.  Just because we sometimes adopt constipated programming 
practices in the standard library doesn't mean we think everyone should do it.  
(This is doubly true because sometimes the savings is a false savings if the 
import eventually occurs downstream and because there is currently work being 
done on lazy imports that would make the technique irrelevant).

--
assignee:  -> gvanrossum
nosy: +gvanrossum, rhettinger

___
Python tracker 

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

[issue31561] difflib pathological behavior with mixed line endings

[Mahmoud Al-Qudsi]

Mahmoud Al-Qudsi added the comment:

@tim.peters

No, `icdiff` is not part of core and probably should be omitted from the 
remainder of this discussion.

I just checked and it's actually not a mix of line endings in each file, it's 
just that one file is \n and the other is \r\n

You can actually just duplicate this bug by taking _any_ file and copying it, 
then executing `unix2dos file1; dos2unix file2` - you'll have to perfectly 
"correct" files2 that difflib will struggle to handle.

(as a preface to what follows, I've written a binary diff and incremental 
backup utility, so I'm familiar with the intricacies and pitfalls when it comes 
to diffing. I have not looked at difflib's source code, however. Looking at the 
documentation for difflib, it's not clear whether or not it should be 
considered a naive binary diffing utility, since it does seem to have the 
concept of "lines".)

Given that _both_ input files are "correct" without line ending errors, I think 
the correct optimization here would be for difflib to "realize" that two chunks 
are "identical" but with different line endings (aka just plain different, not 
asking for this to be treated as a special case) but instead of going on to 
search for a match to either buffer, it should assume that no better match will 
be found later on and simply move on to the next block/chunk.

Of course, in the event where file2 has a line from file1 that is first present 
with a different line ending then repeated with the same line ending, difflib 
will not choose the correct line.. but that's probably not something worth 
fretting over (like you said, mixed line endings == recipe for disaster).

Of course I can understand if all this is out of the scope of difflib and not 
an endeavor worth taking up.

--

___
Python tracker 

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

[issue18558] Iterable glossary entry needs clarification

[Raymond Hettinger]

Changes by Raymond Hettinger :


--
keywords: +patch
pull_requests: +3718
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

[issue18558] Iterable glossary entry needs clarification

[Raymond Hettinger]

Raymond Hettinger added the comment:

I'll follow David Murray's suggestion here.  The glossary definition of 
iterable is already very good, it just needs to clarify that the __getitem__() 
method needs to implement sequence semantics.  Anything further is beyond the 
scope of a glossary entry.

Also, I'll amend the docs on collections.abc.Iterable() to be more specific 
about what it is does and doesn't recognize.

FWIW, the topic is also discussed in other places:

* https://docs.python.org/3/library/functions.html#iter
* https://docs.python.org/3/reference/datamodel.html#object.__getitem__
* https://docs.python.org/3/reference/datamodel.html#object.__iter__

--

___
Python tracker 

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

[issue31572] Avoid suppressing all exceptions in PyObject_HasAttr()

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
pull_requests: +3717

___
Python tracker 

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

[issue31351] ensurepip discards pip's return code which leads to broken venvs

[Mariatta Wijaya]

Mariatta Wijaya added the comment:

Thanks :) 
Since Miss Islington couldn't backport this, I'll leave it to the patch author 
or the core dev who merged the PR ;)

--

___
Python tracker 

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

[issue30085] Discourage operator.__dunder__ functions

[Terry J. Reedy]

Changes by Terry J. Reedy :


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

[issue30085] Discourage operator.__dunder__ functions

[Terry J. Reedy]

Terry J. Reedy added the comment:


New changeset 5b9299d8c72aeadccadd77e4b8132094ba9a1f96 by Terry Jan Reedy 
(Sanket Dasgupta) in branch 'master':
bpo-30085: Improve documentation for operator (#1171)
https://github.com/python/cpython/commit/5b9299d8c72aeadccadd77e4b8132094ba9a1f96


--

___
Python tracker 

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

[issue31566] assertion failure in _warnings.warn() in case of a bad __name__ global

[Roundup Robot]

Changes by Roundup Robot :


--
pull_requests: +3716

___
Python tracker 

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

[issue31566] assertion failure in _warnings.warn() in case of a bad __name__ global

[Serhiy Storchaka]

Serhiy Storchaka added the comment:


New changeset 5d3e80021ab33360191eb0fbff34e0246c913884 by Serhiy Storchaka 
(Oren Milman) in branch 'master':
bpo-31566: Fix an assertion failure in _warnings.warn() in case of a bad 
__name__ global. (#3717)
https://github.com/python/cpython/commit/5d3e80021ab33360191eb0fbff34e0246c913884


--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue31285] a SystemError and an assertion failure in warnings.warn_explicit()

[Serhiy Storchaka]

Serhiy Storchaka added the comment:


New changeset 91fb0afe181986b48abfc6092dcca912b39de51d by Serhiy Storchaka 
(Oren Milman) in branch 'master':
bpo-31285: Fix an assertion failure and a SystemError in 
warnings.warn_explicit. (#3219)
https://github.com/python/cpython/commit/91fb0afe181986b48abfc6092dcca912b39de51d


--

___
Python tracker 

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

[issue31572] Avoid suppressing all exceptions in PyObject_HasAttr()

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
pull_requests: +3715

___
Python tracker 

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

[issue31572] Avoid suppressing all exceptions in PyObject_HasAttr()

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
pull_requests: +3714

___
Python tracker 

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

[issue31572] Avoid suppressing all exceptions in PyObject_HasAttr()

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
pull_requests: +3713

___
Python tracker 

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

[issue31572] Avoid suppressing all exceptions in PyObject_HasAttr()

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
pull_requests: +3712

___
Python tracker 

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

[issue31572] Avoid suppressing all exceptions in PyObject_HasAttr()

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
pull_requests: +3711

___
Python tracker 

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

[issue31572] Avoid suppressing all exceptions in PyObject_HasAttr()

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
pull_requests: +3710

___
Python tracker 

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

[issue31572] Avoid suppressing all exceptions in PyObject_HasAttr()

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


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

___
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

[INADA Naoki]

INADA Naoki added the comment:

> Actually it is easy. You need just one global integer accumulator and a local 
> variable for keeping a temporary copy of it.

You're right!  I updated my pull request.
See current output: 
https://gist.github.com/methane/185d75a3c8da762d85317dd95918a623

--

___
Python tracker 

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

[issue30826] More details in reference 'Looping through a list in Python and modifying it'

[Raymond Hettinger]

Raymond Hettinger added the comment:

After looking at this again, I think the entire example should be removed.  We 
really don't want to encourage people to code like this (it would never make it 
through a code review).  The example itself is silly (not fully, just weird and 
lacking real-world motiviation).  The s.insert(0,x) code is an anti-pattern.  
And in general, mutating a data structure while iterating over it is a perilous 
practice leading to fragile code (many data structures ban the practice 
outright: databases, deques, dicts).

Mutating while iterating is only safe if a data structure makes explicit 
guarantees about how it iterates.  In Python, we have only a handful of such 
guarantees (you can safely mutate dict values while iterating over the keys and 
lists guarantee that the iterator looks-up consecutive indicies regardless of 
changes to the underlying list).

I propose to remove the last two paragraphs and the example, replacing them 
with clear practical advice and patterns that would pass a code review.

Something like this:

Code that modifies a collection while iterating over
that same collection can be tricky to get right.  Instead,
it is usually more straight-forward to loop over a copy
of the collection or to create a new collection.

# Strategy:  Iterate over a copy
for user, status in users.copy():
if status == 'inactive':
del users[user]

# Strategy:  Create a new collection
active_users = {}
for user, status in users.items():
if status == 'active':
active_users[user] = status

--

___
Python tracker 

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

[issue31572] Avoid suppressing all exceptions in PyObject_HasAttr()

[Serhiy Storchaka]

New submission from Serhiy Storchaka:

Initially hasattr() suppressed all raised exceptions. In issue2196 hasattr() 
was changed to suppress only Exception exceptions and propagate exceptions like 
SystemExit and KeyboardInterrupt. In issue9666 hasattr() was changed to 
suppress only AttributeError.

But C API functions, PyObject_HasAttr() and like, were not changed. 
PyObject_HasAttr() is documented as an equivalent of hasattr(), but there is 
undocumented difference. The C code that uses PyObject_HasAttr() starves from 
the same problem as the Python code that used old hasattr().

The only solution of this problem is getting rid of PyObject_HasAttr() if favor 
of PyObject_GetAttr(). In this issue I'm going to propose a set of PRs that 
replace PyObject_HasAttr() invocations in different components with more 
correct code.

--
components: Extension Modules, Interpreter Core
messages: 302873
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: Avoid suppressing all exceptions in PyObject_HasAttr()
type: behavior

___
Python tracker 

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

[issue30085] Discourage operator.__dunder__ functions

[Raymond Hettinger]

Changes by Raymond Hettinger :


--
assignee:  -> terry.reedy

___
Python tracker 

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

[issue30995] Support logging.getLogger(style='{')

[Steven Warwick]

Steven Warwick added the comment:

you probably have already considered this, but I just wanted to ask if it might 
be worth considering turning the problem "upside down" to make things easier.

  I'm interpreting the problem that there are variables we'd like to add to the 
output log that are provided inside the logger, which is why we need to use a 
specific type of format string to make sure you add them correctly.   If 
instead, these same variables are simply exposed as logger attributes, we could 
just create the complete formatted string when we call the logger.  

logger.info( " {:s} {:s} ", logger.name, logger.module ) 

does this make any sense?

--
nosy: +sdwarwick

___
Python tracker 

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

[issue27268] Incorrect error message on float('')

[Henk-Jaap Wagenaar]

Henk-Jaap Wagenaar added the comment:

@Wolfgang

I just created a PR, only to realise that Pedro already made one a while back: 
PR 2745

--
nosy: +Henk-Jaap Wagenaar

___
Python tracker 

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

[issue27268] Incorrect error message on float('')

[Henk-Jaap Wagenaar]

Changes by Henk-Jaap Wagenaar :


--
pull_requests: +3708

___
Python tracker 

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

[issue31145] PriorityQueue.put() fails with TypeError if priority_number in tuples of (priority_number, data) are the same.

[Raymond Hettinger]

Raymond Hettinger added the comment:

Nick, what do you think about this proposal?

The problem being solved is that decorated tuples no longer work well for 
controlling ordering (because so many types are now non-comparable).  This 
provides a wrapper to control which fields are used in comparison.

For implementation and API, there are several ways to do it, (accept separate 
arguments vs accept an existing sequence, standalone class vs a tuple subclass, 
pure python and/or c-implementation, etc).

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

___
Python tracker 

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

[issue31423] Error while building PDF documentation

[Ned Deily]

Ned Deily added the comment:

> Seems like people are seeing 404s when downloading docs today.

Do you have specific URLs or web pages?  Or a link to where this was discussed? 
 I just did a quick look at some of the download pages and everything worked 
for me.

--

___
Python tracker 

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

[issue27268] Incorrect error message on float('')

[Raymond Hettinger]

Changes by Raymond Hettinger :


--
assignee: rhettinger -> 
versions:  -Python 2.7, Python 3.5, Python 3.6

___
Python tracker 

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

[issue31550] Inconsistent error message for TypeError with subscripting

[Anthony Sottile]

Anthony Sottile added the comment:

Shouldn't you wait for Raymond's arguments before outright closing the PR?

--

___
Python tracker 

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

[issue31570] minor bug in documentataion relating to sending html email

[Mariatta Wijaya]

Mariatta Wijaya added the comment:


New changeset ce418bf8228c9a6a19702638e5f5c2fb66ad0588 by Mariatta (Miss 
Islington (bot)) in branch '3.6':
bpo-31570: Update Email library documentation example (GH-3720) (GH-3721)
https://github.com/python/cpython/commit/ce418bf8228c9a6a19702638e5f5c2fb66ad0588


--
nosy: +Mariatta

___
Python tracker 

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

[issue31570] minor bug in documentataion relating to sending html email

[Mariatta Wijaya]

Mariatta Wijaya added the comment:

This is fixed now. Thanks Larry and Henk-Jaap!

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

[issue31570] minor bug in documentataion relating to sending html email

[Roundup Robot]

Changes by Roundup Robot :


--
pull_requests: +3707

___
Python tracker 

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

[issue31570] minor bug in documentataion relating to sending html email

[Henk-Jaap Wagenaar]

Henk-Jaap Wagenaar added the comment:

I have made a PR, not sure whether it needs backporting?

--
nosy: +Henk-Jaap Wagenaar

___
Python tracker 

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

[issue31571] Redundand information on Doc/reference/lexical_analysis.rst

[Guilherme Praciano Karst Caminha]

Guilherme Praciano Karst Caminha added the comment:

Also, "Numeric literals" is a more general section, so rules that apply for the 
three types of numeric literals should probably go there to avoid repetition. 
Maybe the Integer, Floating point and Imaginary literal sections should be one 
section level deeper, so that they are under the Numeric Literal section.

--

___
Python tracker 

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

[issue31571] Redundand information on Doc/reference/lexical_analysis.rst

[Guilherme Praciano Karst Caminha]

Guilherme Praciano Karst Caminha added the comment:

I believe that the sentence regarding the - operator also applies to Integer 
literals and Imaginary literals. But it only appears on the Floating point 
literals and Numeric literals sections.

--

___
Python tracker 

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

[issue31571] Redundand information on Doc/reference/lexical_analysis.rst

[Mariatta Wijaya]

Mariatta Wijaya added the comment:

I think we can remove 
```
As of Python 3.3 it is possible again to prefix ..."
```
and keep the other one where it says:
```
.. versionadded:: 3.3
   Support for the unicode legacy literal 
```

About the sentence about numeric literals that appears twice: it appears on 
different sections of the language reference documentation. It's very likely 
for a person to only read one section and not the other. I think it's ok to 
have them in different places like that.

--
nosy: +Mariatta

___
Python tracker 

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

[issue31423] Error while building PDF documentation

[Mariatta Wijaya]

Mariatta Wijaya added the comment:

Seems like people are seeing 404s when downloading docs today. By any chance 
this issue is related?

--
nosy: +Mariatta

___
Python tracker 

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

[issue31571] Redundand information on Doc/reference/lexical_analysis.rst

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

The first pair was added in 50364b4a5c8f02ec05d33928e29a8780d9acf968 by Armin 
Ronacher.

The duplicate of the other phrase was introduced in 
60f2f0cf8e10c94693dfea8937b7feabeffe5744.

--
nosy: +aronacher, gvanrossum, serhiy.storchaka

___
Python tracker 

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

[issue31570] minor bug in documentataion relating to sending html email

[Henk-Jaap Wagenaar]

Changes by Henk-Jaap Wagenaar :


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

___
Python tracker 

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

[issue31571] Redundand information on Doc/reference/lexical_analysis.rst

[Guilherme Praciano Karst Caminha]

New submission from Guilherme Praciano Karst Caminha:

The file Doc/reference/lexical_analysis.rst has at least two redundant parts.

The first one is quoted below:
"As of Python 3.3 it is possible again to prefix string literals with a u 
prefix to simplify maintenance of dual 2.x and 3.x codebases."

This is repeated a couple paragraphs after:
"New in version 3.3: Support for the unicode legacy literal (u'value') was 
reintroduced to simplify the maintenance of dual Python 2.x and 3.x codebases. 
See PEP 414 for more information."


Also, this other one:
"Note that numeric literals do not include a sign; a phrase like -1 is actually 
an expression composed of the unary operator - and the literal 1."

Is literally repeated twice, only that on the first time it has quotes around 
the - operator:
"Note that numeric literals do not include a sign; a phrase like -1 is actually 
an expression composed of the unary operator ‘-‘ and the literal 1."

--
assignee: docs@python
components: Documentation
messages: 302859
nosy: Guilherme, docs@python
priority: normal
pull_requests: 3705
severity: normal
status: open
title: Redundand information on Doc/reference/lexical_analysis.rst
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

[issue31570] minor bug in documentataion relating to sending html email

[Larry Myerscough]

Changes by Larry Myerscough :


--
assignee:  -> docs@python
components: +Documentation, email
nosy: +barry, docs@python, r.david.murray

___
Python tracker 

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

[issue31570] minor bug in documentataion relating to sending html email

[Larry Myerscough]

New submission from Larry Myerscough:

I believe the documentation page 
https://docs.python.org/3/library/email.examples.html contains a minor error:

href="http://www.yummly.com/recipe/Roasted-Asparagus-Epicurious-203718 
...should be followed by a closing double quote. This is a small detail but was 
enough to stop the code from working, so slowed me down a while. (This is a new 
area for me so I wanted to adopt the 'safe' approach of using the example as 
much as possible 'as is' before changing anything!)

--
messages: 302858
nosy: Larry Myerscough
priority: normal
severity: normal
status: open
title: minor bug in documentataion relating to sending html email
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

[issue31569] inconsistent case of PCbuild/ directory

[Paul Moore]

Paul Moore added the comment:

I would strongly prefer the docs to be changed to match the implementation 
rather than the other way round. However, I don't see the use case for this - 
what case sensitive filesystem would anybody be building the Windows version of 
Python on?


I'm -1 on changing the actual build scripts, as that introduces risk for no 
actual benefit. I'm +0 on changing the docs, assuming it's possible to make 
things consistent with a doc-only change. But I can't imagine anyone reading 
those docs would expect a filesystem to be case sensitive, so I doubt it would 
matter in practice.

--

___
Python tracker 

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

[issue31508] Running test_ttk_guionly logs "test_widgets.py:1562: UserWarning: Deprecated API of Treeview.selection() should be removed" warnings

[STINNER Victor]

STINNER Victor added the comment:

Thank you for the fix Serhiy!

--

___
Python tracker 

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

[issue31508] Running test_ttk_guionly logs "test_widgets.py:1562: UserWarning: Deprecated API of Treeview.selection() should be removed" warnings

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Warnings are fixed in 3.7. They will reappear in 3.8.

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

[issue27319] Multiple item arguments for selection operations

[Serhiy Storchaka]

Serhiy Storchaka added the comment:


New changeset e31eca45e548bf6f439d540f3751516acbc31689 by Serhiy Storchaka 
(Miss Islington (bot)) in branch '3.6':
[3.6] bpo-27319, bpo-31508: Document deprecation in Treeview.selection(). 
(GH-3667) (#3719)
https://github.com/python/cpython/commit/e31eca45e548bf6f439d540f3751516acbc31689


--

___
Python tracker 

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

[issue31508] Running test_ttk_guionly logs "test_widgets.py:1562: UserWarning: Deprecated API of Treeview.selection() should be removed" warnings

[Serhiy Storchaka]

Serhiy Storchaka added the comment:


New changeset e31eca45e548bf6f439d540f3751516acbc31689 by Serhiy Storchaka 
(Miss Islington (bot)) in branch '3.6':
[3.6] bpo-27319, bpo-31508: Document deprecation in Treeview.selection(). 
(GH-3667) (#3719)
https://github.com/python/cpython/commit/e31eca45e548bf6f439d540f3751516acbc31689


--

___
Python tracker 

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

[issue31569] inconsistent case of PCbuild/ directory

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Wouldn't be easier to make changes in the opposite direction? Change PCbuild to 
PCBuild?

The file systems on Windows are case-insensitive, so this hardly an error.

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue31569] inconsistent case of PCbuild/ directory

[Stefan Grönke]

New submission from Stefan Grönke:

While reading the build documentation for Windows, I've noticed the `PCbuild/` 
directory to be mentioned with a different case than the directory in the 
repository (`PCBuild/` instead of `PCbuild/`).

Every occasion of `PCBuild` should be replaced with `PCbuild`, so that builds 
can work on case-sensitive filesystems as well.

--
assignee: docs@python
components: Build, Documentation, Windows
messages: 302851
nosy: docs@python, gronke, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
pull_requests: 3704
severity: normal
status: open
title: inconsistent case of PCbuild/ directory
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7

___
Python tracker 

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

[issue27319] Multiple item arguments for selection operations

[Roundup Robot]

Changes by Roundup Robot :


--
pull_requests: +3702

___
Python tracker 

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

[issue31508] Running test_ttk_guionly logs "test_widgets.py:1562: UserWarning: Deprecated API of Treeview.selection() should be removed" warnings

[Roundup Robot]

Changes by Roundup Robot :


--
pull_requests: +3703

___
Python tracker 

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

[issue31508] Running test_ttk_guionly logs "test_widgets.py:1562: UserWarning: Deprecated API of Treeview.selection() should be removed" warnings

[Serhiy Storchaka]

Serhiy Storchaka added the comment:


New changeset 2fad10235460ac394cc8b869c41f47aba3d63594 by Serhiy Storchaka in 
branch 'master':
bpo-27319, bpo-31508: Document deprecation in Treeview.selection(). (#3667)
https://github.com/python/cpython/commit/2fad10235460ac394cc8b869c41f47aba3d63594


--

___
Python tracker 

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

[issue27319] Multiple item arguments for selection operations

[Serhiy Storchaka]

Serhiy Storchaka added the comment:


New changeset 2fad10235460ac394cc8b869c41f47aba3d63594 by Serhiy Storchaka in 
branch 'master':
bpo-27319, bpo-31508: Document deprecation in Treeview.selection(). (#3667)
https://github.com/python/cpython/commit/2fad10235460ac394cc8b869c41f47aba3d63594


--

___
Python tracker 

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

[issue31550] Inconsistent error message for TypeError with subscripting

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

I think it should. But let to hear Raymond's arguments.

--

___
Python tracker 

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

[issue30346] Odd behavior when unpacking `itertools.groupby`

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Added the patch for PR 1568 against the current master just for history.

--
Added file: https://bugs.python.org/file47167/groupby-invalid.diff

___
Python tracker 

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

[issue30346] Odd behavior when unpacking `itertools.groupby`

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Thank you for your review and explanations Raymond. This makes sense to me.

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

[issue31351] ensurepip discards pip's return code which leads to broken venvs

[Nick Coghlan]

Nick Coghlan added the comment:

Aye, it is - while there's no venv integration in 2.7 (since there's no venv 
module), ensurepip itself is essentially identical across the two version, so 
2.7 will suffer from the same problem.

--
stage: patch review -> backport needed
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

[issue30346] Odd behavior when unpacking `itertools.groupby`

[Serhiy Storchaka]

Serhiy Storchaka added the comment:


New changeset c247caf33f6e6000d828db4762d1cb12edf3cd57 by Serhiy Storchaka in 
branch 'master':
bpo-30346: An iterator produced by the itertools.groupby() iterator (#1569)
https://github.com/python/cpython/commit/c247caf33f6e6000d828db4762d1cb12edf3cd57


--

___
Python tracker 

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

[issue30346] Odd behavior when unpacking `itertools.groupby`

[Raymond Hettinger]

Raymond Hettinger added the comment:

Go ahead with PR 1569 to exhaust the inner iterator when the outer iterator 
advances.

Rationale:  The OP expected the inner iterator to be exhausted.  That is also 
what the PyPy team originally implemented and it is what I would have expected.

Also, there are some loose analogies elsewhere in the language.  Raising 
StopIteration is what next(somefileobject) does when there is a seek-to-end 
between next() calls.  A list iterator raises StopIteration when there is a del 
somelist[:] between next() calls.  When zip(it1, it2) terminates on the 
shortest input, it leaves the other iterator alive, allowing it to run and 
terminally normally with StopIteration. And though I don't have a use case for 
it, I would expect that next(inner_iterator, default_value) would return a 
value from the input stream or the default value but would not fail with a 
RuntimeError (this would apply to islice() as well).

--
assignee: rhettinger -> serhiy.storchaka

___
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

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

> Stack management is difficult than inc/dec integer in multi threading case.

Actually it is easy. You need just one global integer accumulator and a local 
variable for keeping a temporary copy of it.

--

___
Python tracker 

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

[issue31311] a SystemError and a crash in PyCData_setstate() when __dict__ is bad

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

I thought about this issue so long because I can't find good cause for __dict__ 
to be not a dict. Defining the __dict__ method or property doesn't affect 
instance dictionary and attributes lookup. It just breaks the __setstate__ 
method. Without having good example of overriding __dict__ I have no good test 
cases and don't know what a way of handling this error is better.

There is yet one disadvantage of the current implementation. The instance's 
dict can be lazy. It can be created only on demand, when instance's attribute 
is set or the __dict__ attribute is read. PyObject_GetAttrString(myself, 
"__dict__") creates it if it was not created. It would be more efficient to use 
_PyObject_GetDictPtr(). But this is a separate issue, 3.7 only.

--

___
Python tracker 

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

[issue31311] a SystemError and a crash in PyCData_setstate() when __dict__ is bad

[Serhiy Storchaka]

Serhiy Storchaka added the comment:


New changeset 4facdf523aa6967487a9425f124da9661b59fd43 by Serhiy Storchaka 
(Oren Milman) in branch 'master':
bpo-31311: Impove error reporting in case the first argument to 
PyCData_setstate() isn't a dictionary. (#3255)
https://github.com/python/cpython/commit/4facdf523aa6967487a9425f124da9661b59fd43


--

___
Python tracker 

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