[issue38354] Fix for bug 30378 regressed SysLogHandler by making it resolve addresses at initialization instead of in `.emit()`

Change by Karthikeyan Singaravelan : -- nosy: +vinay.sajip ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: ht

[issue38357] print adding extra bytes in hex above x7F

Artificial added the comment: python3 -c "print('\x7F')" > test.txt && xxd test.txt : 7f0a .. python3 -c "print('\x80')" > test.txt && xxd test.txt : c280 0a ... -- __

[issue38352] In typing docs, note explicit import needed for IO and Pattern/Match

Change by Karthikeyan Singaravelan : -- nosy: +gvanrossum, levkivskyi ___ Python tracker ___ ___ Python-bugs-list mailing list Unsub

[issue38357] print adding extra bytes in hex above x7F

Ammar Askar added the comment: If you're trying to get raw bytes, you need to use print(b'\x80') what's happening right now is that the '\x80' is treated as a unicode code point (see https://docs.python.org/3/howto/unicode.html#the-string-type), and when Python goes to print it, it gets

[issue38351] Modernize email example from %-formatting to f-string

Eric V. Smith added the comment: >> I definitely think we should not modify any code in the stdlib just to >> switch to f-strings. > Does this also apply to updating code to use f-strings in an area that's > already being modified for a functional purpose? No. As I said, not just to switch

[issue38350] ./configure --with-pydebug should use -O0 rather than -Og

Benjamin Peterson added the comment: If -Og is breaking debugging, isn't that a compiler bug? The GCC manpage claims " -Og enables optimizations that do not interfere with debugging." -- nosy: +benjamin.peterson ___ Python tracker

[issue38357] print adding extra bytes in hex above x7F

Arfrever Frehtes Taifersar Arahesis added the comment: However print() called with non-str argument would firstly call str() on it, which is most likely not what reporter wanted: >>> print(b'\x80') b'\x80' >>> str(b"\x80") "b'\\x80'" >>> print(str(b"\x80")) b'\x80' $ python -c "print(b'\x80')

[issue38351] Modernize email example from %-formatting to f-string

Fred L. Drake, Jr. added the comment: Definitely agree with Eric on this; code modernization is definitely on the risky side, so judicious updates are important. (Of course, not updating is also a risk, eventually. But not much of one in this case.) This issue is really about whether the doc

[issue38357] print adding extra bytes in hex above x7F

Artificial added the comment: Thanks, Arfrever Seems unnecessarily complicated for what worked in Python2. -- ___ Python tracker ___ _

[issue38350] ./configure --with-pydebug should use -O0 rather than -Og

Charalampos Stratakis added the comment: It seems that it's still being worked on from gcc's side: https://gcc.gnu.org/bugzilla//show_bug.cgi?id=78685 -- ___ Python tracker _

[issue38333] add type signatures to library function docs

Vedran Čačić added the comment: In that case, I'm pretty sure you'd never be able to document almost _any_ function signature. Python is simply not a statically typed language, and we love it because of that. Ok, go to the list of builtins, and start alphabetically. First is abs. What type d

[issue38356] test_asyncio: SubprocessThreadedWatcherTests leaks threads

Kyle Stanley added the comment: First I'll work on adding a new method. Here's a few potential names, ordered roughly by my preferences: 1) join_threads() 2) shutdown_threads() 3) shutdown_threadpool() The first and second options are roughly equal, but I think join_threads() is a bit mor

[issue38356] test_asyncio: SubprocessThreadedWatcherTests leaks threads

Kyle Stanley added the comment: > Another consideration is if we want this method to join the threads to be > called in `ThreadedChildWatcher.close()`. An additional benefit of having the method called from `close()` is that it means we don't have to modify the tests directly. Also, Threaded

[issue38351] Modernize email example from %-formatting to f-string

Raymond Hettinger added the comment: > (Not that I can think of others off the top of my head.) For the most part, templating examples can be switched to the .format() style but shouldn't be switched to f-strings. The former technique is still necessary if someone wants to move templates t

[issue38333] add type signatures to library function docs

paul rubin added the comment: abs takes any value that understands the __abs__ method and returns something of the same type. In fact there is already a type protocol for it: https://mypy.readthedocs.io/en/stable/protocols.html#supportsabs-t So abs's signature would be (x : Abs[T]) -> T whe

[issue38356] test_asyncio: SubprocessThreadedWatcherTests leaks threads

Change by Kyle Stanley : -- keywords: +patch pull_requests: +16140 stage: -> patch review pull_request: https://github.com/python/cpython/pull/16552 ___ Python tracker ___ ___

[issue13153] IDLE 3.x on Windows exits when pasting non-BMP unicode

Terry J. Reedy added the comment: The revised PR appears to fix this and other issues, although the presence of astral chars in code being edited messes up tk's cursor positioning. Assuming that this cannot be changed, we could add the the ability to replace astral chars with \U escapes. -

[issue38351] Modernize email example from %-formatting to f-string

Kyle Stanley added the comment: > For the most part, templating examples can be switched to the .format() style > but shouldn't be switched to f-strings. Is there no specific use case for the older "%s" % sub template that .format() doesn't have? > The former technique is still necessary if

[issue38351] Modernize email example from %-formatting to f-string

Fred L. Drake, Jr. added the comment: I'd like to see consistent usage by default, with specific examples using the older forms as appropriate. The use cases Raymond identified are worth discussing (and the tutorial may be a good place for this), and well as mentioned in the reference docs

[issue38333] add type signatures to library function docs

Vedran Čačić added the comment: Well, yes, if you're going to invent a special typeclass for every protocol, then you can document any signature. But what purpose does it serve? Abs to me seems like a hack, not something we really wanted to capture with the type system. Do you find (x : Abs[

[issue34455] Tkinter crashing when pressing Command + ^ (OSX)

Aivar Annamaa added the comment: I created the ticket: https://core.tcl-lang.org/tk/tktview/5849df7852c48cb763b11a11d848a68482b0f828 -- nosy: +Aivar.Annamaa ___ Python tracker __

[issue38333] add type signatures to library function docs

paul rubin added the comment: At first glance, having a typeclass for each protocol (at least the widely used ones) seems fine. It's inherent in Haskell and a lot of libraries are organized around a common set of typeclasses--look up "Typeclassopedia" for descriptions of them. Certainly th

[issue38333] add type signatures to library function docs

Vedran Čačić added the comment: Your arguments in my view boil down to "Haskell is a nice language" and "Static typing is useful". It still doesn't change my argument that Python is genetically neither of these. And we will cripple it greatly if we try to push it in that direction. [Your pro

[issue38333] add type signatures to library function docs

paul rubin added the comment: I don't think we're going to accomplish anything continuing the eternal static-vs-dynamic debate, which in Python's case has already been resolved by adding optional static typing. It's a done deal, and the issue here is just how to document it. Erlang (via th

<    1   2