[issue37827] IDLE: Have the shell mimic terminal handling of \r and \b control characters in outputs

Tal Einat added the comment: I will highlight the fact that IDLE's shell currently allows no way of showing a progress indicator, beyond extremely simple bar that only fill up from left to right, without any indication of the rightmost limit, a percentage indicator, or a rotating progress

[issue37827] IDLE: Have the shell mimic terminal handling of \r and \b control characters in outputs

t;. If in the future there is interest in this again, it may be reopened. -- resolution: -> rejected stage: patch review -> resolved status: open -> closed title: IDLE Shell: add a terminal mode that responds to \a, \b, and \r -> IDLE: Have the shell mimic terminal handling

Re: importlib: import X as Y; from A import B

> > import pandas; pd = pandas > > >df = pd.from_csv (...) > >from selenium import webdriver > > import selenium.webdriver; webdriver = selenium.webdriver > Thank you, this works. -- https://mail.python.org/mailman/listinfo/python-list

Re: importlib: import X as Y; from A import B

Jason Friedman wrote at 2020-8-8 21:23 -0600: > ... >The cherry-on-top would be to import with the "aliasing" and "from" they >will most likely see on the web, so that my code matches what they see >there. In other words, instead of: > >import pandas >df = pandas.from_csv (...) >import selenium

Re: importlib: import X as Y; from A import B

On Sun, Aug 9, 2020 at 1:25 PM Jason Friedman wrote: > > I have some code I'm going to share with my team, many of whom are not yet > familiar with Python. They may not have 3rd-party libraries such as pandas > or selenium installed. Yes I can instruct them how to install, but the path > of least

Re: importlib: import X as Y; from A import B

On 09/08/2020 15:23, Jason Friedman wrote: I have some code I'm going to share with my team, many of whom are not yet familiar with Python. They may not have 3rd-party libraries such as pandas or selenium installed. Yes I can instruct them how to install, but the path of least resistance is to

importlib: import X as Y; from A import B

I have some code I'm going to share with my team, many of whom are not yet familiar with Python. They may not have 3rd-party libraries such as pandas or selenium installed. Yes I can instruct them how to install, but the path of least resistance is to have my code to check for missing dependencies

[issue41467] asyncio: recv_into() must not return b'' if the socket/pipe is closed

David Bolen added the comment: Just for the record, this fix also appears to have resolved the issue with the Win10 buildbot from bpo-41273, which was related to the same unraisable exceptions mentioned in bpo-38912. -- nosy: +db3l ___ Python

[issue41467] asyncio: recv_into() must not return b'' if the socket/pipe is closed

Change by STINNER Victor : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue41467] asyncio: recv_into() must not return b'' if the socket/pipe is closed

miss-islington added the comment: New changeset 1d16229f3f5b91f2389c7c5c6425c5524c413651 by Miss Islington (bot) in branch '3.9': bpo-41467: Fix asyncio recv_into() on Windows (GH-21720) https://github.com/python/cpython/commit/1d16229f3f5b91f2389c7c5c6425c5524c413651 --

[issue41467] asyncio: recv_into() must not return b'' if the socket/pipe is closed

miss-islington added the comment: New changeset b934d832d1e16bf235c536dcde3006faf29757fc by Miss Islington (bot) in branch '3.8': bpo-41467: Fix asyncio recv_into() on Windows (GH-21720) https://github.com/python/cpython/commit/b934d832d1e16bf235c536dcde3006faf29757fc --

[issue41467] asyncio: recv_into() must not return b'' if the socket/pipe is closed

Change by miss-islington : -- pull_requests: +20869 pull_request: https://github.com/python/cpython/pull/21726 ___ Python tracker ___

[issue41467] asyncio: recv_into() must not return b'' if the socket/pipe is closed

Change by miss-islington : -- nosy: +miss-islington nosy_count: 3.0 -> 4.0 pull_requests: +20867 pull_request: https://github.com/python/cpython/pull/21724 ___ Python tracker

[issue41467] asyncio: recv_into() must not return b'' if the socket/pipe is closed

STINNER Victor added the comment: New changeset 602a971a2af3a685d625c912c400cadd452718b1 by Victor Stinner in branch 'master': bpo-41467: Fix asyncio recv_into() on Windows (GH-21720) https://github.com/python/cpython/commit/602a971a2af3a685d625c912c400cadd452718b1 --

[issue41467] asyncio: recv_into() must not return b'' if the socket/pipe is closed

STINNER Victor added the comment: > This bug may be the root cause of bpo-38912 bug. Yeah, very likely. This bug makes asyncio inconsistent. A transport is "not closed" and "closed" at the same time... C:\vstinner\python\master\lib\asyncio\proactor_events.py:121: ResourceWarning: unclosed

[issue41467] asyncio: recv_into() must not return b'' if the socket/pipe is closed

STINNER Victor added the comment: The function was added in 2017 in bpo-31819, PR 4051: commit 525f40d231aba2c004619fc7a5207171ed65b0cb Author: Antoine Pitrou Date: Thu Oct 19 21:46:40 2017 +0200 bpo-31819: Add AbstractEventLoop.sock_recv_into() (#4051) --

[issue41467] asyncio: recv_into() must not return b'' if the socket/pipe is closed

Change by STINNER Victor : -- keywords: +patch pull_requests: +20863 stage: -> patch review pull_request: https://github.com/python/cpython/pull/21720 ___ Python tracker ___

[issue41467] asyncio: recv_into() must not return b'' if the socket/pipe is closed

New submission from STINNER Victor : The proactor event loop of asyncio returns b'' on recv_into() if the socket/pipe is closed: def recv_into(self, conn, buf, flags=0): ... try: ... except BrokenPipeError: return self._result(b

[issue41124] String with encode causing addition of 'b' in the beginning

Srinivas Sampath added the comment: if you look at my code, couple of lines below the print, i am actually doing the send over the socket. It took me awhile to figure out why the socket is failing. I understand that the byte array is represented with a 'b' infront as part of encode function

[issue41124] String with encode causing addition of 'b' in the beginning

SilentGhost added the comment: Your request is likely failing for entirely different reasons. What you've done is encoded a str object into bytes object, which is represented with as literal using b prefix. It isn't being sent over the socket. -- nosy: +SilentGhost resolution

[issue41124] String with encode causing addition of 'b' in the beginning

New submission from Srinivas Sampath : I am trying to run the attached code. when hard-coding the string in the URL and doing .encode, then the code works. However since i am requesting user input, i cannot hard-code and the code seem to add the 'b' character in the beginning causing

[issue41060] `with a as b` segfault in new peg parser

miss-islington added the comment: New changeset 71bb921829c33c30b2e111e18948df8c2b6731e4 by Lysandros Nikolaou in branch '3.9': [3.9] bpo-41060: Avoid SEGFAULT when calling GET_INVALID_TARGET in the grammar (GH-21020) (GH-21024)

[issue41060] `with a as b` segfault in new peg parser

Change by Lysandros Nikolaou : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue41060] `with a as b` segfault in new peg parser

Change by Lysandros Nikolaou : -- pull_requests: +20196 pull_request: https://github.com/python/cpython/pull/21024 ___ Python tracker ___

[issue41060] `with a as b` segfault in new peg parser

Pablo Galindo Salgado added the comment: New changeset 6c4e0bd974f2895d42b63d9d004587e74b286c88 by Lysandros Nikolaou in branch 'master': bpo-41060: Avoid SEGFAULT when calling GET_INVALID_TARGET in the grammar (GH-21020)

[issue41060] `with a as b` segfault in new peg parser

Lysandros Nikolaou added the comment: Thanks for the report, Steve. I've now opened a PR that should fix this. -- ___ Python tracker ___

[issue41060] `with a as b` segfault in new peg parser

Change by Lysandros Nikolaou : -- assignee: -> lys.nikolaou ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue41060] `with a as b` segfault in new peg parser

Change by Lysandros Nikolaou : -- keywords: +patch pull_requests: +20192 stage: -> patch review pull_request: https://github.com/python/cpython/pull/21020 ___ Python tracker

[issue41060] `with a as b` segfault in new peg parser

Lysandros Nikolaou added the comment: On it. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue41060] `with a as b` segfault in new peg parser

Change by Guido van Rossum : -- nosy: +gvanrossum, pablogsal ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue41060] `with a as b` segfault in new peg parser

Change by Pablo Galindo Salgado : -- nosy: +lys.nikolaou ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue41060] `with a as b` segfault in new peg parser

Steve Stagg added the comment: Appears to have been introduced by: bpo-40334: Produce better error messages on invalid targets (GH-20106) 01ece63d42b830df106948db0aefa6c1ba24416a -- ___ Python tracker

[issue41060] `with a as b` segfault in new peg parser

New submission from Steve Stagg : Hi Fuzzing found the following: $ ./python/bin/python3 Python 3.10.0a0 (heads/master:eb0d5c38de, Jun 20 2020, 21:35:36) [Clang 10.0.0 ] on linux Type "help", "copyright", "credits" or "license" for more information. >

[issue40762] Writing bytes using CSV module results in b prefixed strings

Eric V. Smith added the comment: I've created issue40825 for adding a "strict" parameter. -- ___ Python tracker ___ ___

[issue40762] Writing bytes using CSV module results in b prefixed strings

with possible variations. >>> b'\xc2a9'.hex() # One might want to add prefix '0x' or r'\x'. 'c26139' # Or add a separator. >>> str(list(b'\xc2a9')) # One might want to change or strip brackets, '[194, 97, 57]' # change separator, or strip spaces. >>>

[issue40762] Writing bytes using CSV module results in b prefixed strings

Skip Montanaro added the comment: I would also that tweaking Python to make this work with no change in Pandas would be a case of the tail wagging the dog. A big tail, but a tail nonetheless. -- ___ Python tracker

[issue40762] Writing bytes using CSV module results in b prefixed strings

Serhiy Storchaka added the comment: Since Pandas opens an output file it has control on what encoding is used. It is a Pandas' responsibility to decode bytes, or raise an exception, or just ignore the problem if it is pretty uncommon case. Pandas already have a complex code for formatting

[issue40762] Writing bytes using CSV module results in b prefixed strings

Skip Montanaro added the comment: This likely worked in the past because bytes == str in Python 2.x. This is just a corner case people porting from 2 to 3 need to address in their code. Papering over it so people using Pandas don't have to do the right thing is no reason to make changes.

[issue40762] Writing bytes using CSV module results in b prefixed strings

Eric V. Smith added the comment: > Short of outright banning the use of bytes (raise a TypeError), I think > the current behaviour is least-worst. I agree. I'd like to see the TypeError raised for everything that's not a string or number (since the docs say that's what's accepted), but at

[issue40762] Writing bytes using CSV module results in b prefixed strings

they try writing those bytes to the CSV file, at best they get an explicit but confusing exception that the decoding failed, at worst they get data loss (mojibake). # Latin-1 to UTF-8 fails py> b = 'ßæ'.encode('latin-1') py> b.decode('utf-8') # raises UnicodeDecodeError:

[issue40762] Writing bytes using CSV module results in b prefixed strings

Steven D'Aprano added the comment: The csv file object knows the encoding it was opened with, I think? If so, we could add an enhancement that bytes objects are first decoded to str using the same encoding the file was opened with. That seems like a reasonable new feature to me. Everything

[issue40762] Writing bytes using CSV module results in b prefixed strings

Serhiy Storchaka added the comment: It would be confusing. There would be the encoding argument for open() to encode strings to bytes and the encoding argument for csv.writer() to decode bytes to strings. The latter will be ignored in all normal cases (for strings and numbers). --

[issue40762] Writing bytes using CSV module results in b prefixed strings

Rémi Lapeyre added the comment: I don't think this would be accepted but I think you could try to propose that on the python-ideas mailing list to get some feedback on your proposal. -- nosy: +skip.montanaro ___ Python tracker

[issue40762] Writing bytes using CSV module results in b prefixed strings

= csv.writer(csvfile, delimiter=' ', + spamwriter = csv.writer(csvfile, encoding='latin1', delimiter=' ', quotechar='|', quoting=csv.QUOTE_MINIMAL) + spamwriter.writerow([b'\xc2', 'A', 'B']) spamwriter.writerow(['Spam'] * 5 + ['Baked Beans

[issue40762] Writing bytes using CSV module results in b prefixed strings

Rémi Lapeyre added the comment: > in real-life that b-prefixed string is just not readable by another program > in an easy way If another program opens this CSV file, it will read the string "b'A'" which is what this field actually contains. Everything that is not a number o

[issue40762] Writing bytes using CSV module results in b prefixed strings

Sidhant Bansal added the comment: Hi Remi, Currently a code like this: ``` with open("abc.csv", "w", encoding='utf-8') as f: data = [b'\x41'] w = csv.writer(f) w.writerow(data) with open("abc.csv", "r") as f: rows = csv.reader(f)

[issue40762] Writing bytes using CSV module results in b prefixed strings

Rémi Lapeyre added the comment: > As an example, if I write character "A" as a byte, i.e b'A' in a csv file But you can't write b'A' in a csv file, what you can't do is write `b'a'.decode()` or `b'a'.decode('latin1')` or `b'a'.decode('whatever')` but the string representation of a byte

[issue40762] Writing bytes using CSV module results in b prefixed strings

passes it through str() as you stated, however this results it into being being prefixed with a b. Ex. "b'A'" is written instead of "A". This kind of output is in most real-life cases not useful for any other program (be it python or non-python) that ends up reading this csv

[issue40762] Writing bytes using CSV module results in b prefixed strings

em through str() first) for DictWriter objects. """ Byte object is neither string nor number. Passing it through str() gives your what you get. Run Python with option -b or -bb to catch such kind of errors. -- nosy: +serhiy.storchaka

[issue40762] Writing bytes using CSV module results in b prefixed strings

Change by Sidhant Bansal : -- keywords: +patch pull_requests: +19634 stage: -> patch review pull_request: https://github.com/python/cpython/pull/20371 ___ Python tracker ___

[issue40762] Writing bytes using CSV module results in b prefixed strings

Sidhant Bansal added the comment: The following code ``` import csv with open("abc.csv", "w") as f: data = [b'\xc2a9', b'\xc2a9'] w = csv.writer(f) w.writerow(data) ``` writes "b'\xc2a9',b'\xc2a9'" in "abc.csv", i.e the b-prefixed byte string

[issue40762] Writing bytes using CSV module results in b prefixed strings

New submission from Sidhant Bansal : The following code ``` import csv with open("abc.csv", "w") as f: data = [b'\xc2a9', b'\xc2a9'] w = csv.writer(f) w.writerow(data) ``` writes "b'\xc2a9',b'\xc2a9'" in "abc.csv", i.e the b-prefixed byte string

[issue40738] backspace character \b not processed by IDLE

Stan Hendryx added the comment: Hello Terry, Thank you for your reply. I understand there are different interpretations of \b. IMHO, since IDLE is part of a python distribution, IDLE needs to be consistent with the native python interpreter on each platform. On Mac, IDLE gives >>&

[issue40738] backspace character \b not processed by IDLE

Terry J. Reedy added the comment: I am considering terminal simulation as an option, but there is not exactly a standard to emulate. \b originally meant the same as the typewrite backspace and modern US computer keyboard left arrow key <- (move cursor left without erasing), which wo

[issue40738] backspace character \b not processed by IDLE

New submission from Stan Hendryx : The backspace character \b is not processed correctly in IDLE 3.8.2: >>> print("deleted\b file") deleted file Running the interpreter from Terminal, it works: >>> print("deleted\b file") delete file Same result o

[issue40446] pow(a, b, p) where b=int((p-1)/2) spits out gibbrish for big p

Change by Tim Peters : -- resolution: fixed -> not a bug ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40446] pow(a, b, p) where b=int((p-1)/2) spits out gibbrish for big p

Ammar Askar added the comment: And just to add on, the reason this gives you the correct result in Python 2 is that `/` performs integer division whereas in Python 3 the `/` operator provides a float as a result. See https://docs.python.org/3/howto/pyporting.html#division for more details.

[issue40446] pow(a, b, p) where b=int((p-1)/2) spits out gibbrish for big p

r-division operator `(p-1)//2` as you mention. If `p` is an int, the result will be exact. -- nosy: +steven.daprano title: pow(a,b,p) where b=int((p-1)/2) spits out gibbrish for big p -> pow(a, b, p) where b=int((p-1)/2) spits out gibbrish for big p ___ P

[issue40446] pow(a, b, p) where b=int((p-1)/2) spits out gibbrish for big p

Basic ICT Repairs added the comment: Hi, I was calculating Legendre coefficients, and quadratic residues and encountered what I believe to be a bug while using this code: for a in range (5): exp=int((p-1)/2) x=pow(a,exp,p) print(x) If p is an odd prime, then x can

[issue40446] pow(a, b, p) where b=int((p-1)/2) spits out gibbrish for big p

it on : p = 101524035174539890485408575671085261788758965189060164484385690801466167356667036677932998889725476582421738788500738738503134356158197247473850273565349249573867251280253564698939768700489401960767007716413932851838937641880157263936985954881657889497583485535527613578457628399173971810541670838543309159139 -- messages: 367735 nosy: Basic ICT Repairs priority: normal severity: normal status: open title: pow(a,b,p) where b=int((p-1)/2) spits out gibbrish for big p ___ Python track

[issue40322] struct.pack adding unexpected byte in 'B' format

Robert Bressan added the comment: After placing a standard size instead of a native one, solved. -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker

[issue40322] struct.pack adding unexpected byte in 'B' format

New submission from Robert Bressan : struct.pack() is adding an unexpected null byte. When I've run this code: ___ import struct d = {'c':b'a', 'b':1, 'B':1, '?':False, 'h':2, 'H':2, 'i':-3, 'I':3, 'l':4, 'L':4, 'q':5, 'Q':5, 'f':100.0, 'd':2.0} for x

[issue39840] FileNotFoundError et al show b-prefix on filepaths if passed as bytes

Eric V. Smith added the comment: That behavior is consistent with other exceptions. It's a helpful piece of information if you were to see it in a traceback, without any other context. So this is by design. -- nosy: +eric.smith resolution: -> not a bug stage: -> resolved status:

[issue39840] FileNotFoundError et al show b-prefix on filepaths if passed as bytes

presentation format of this feels right to Python that's no big deal. -- messages: 363297 nosy: durin42 priority: normal severity: normal status: open title: FileNotFoundError et al show b-prefix on filepaths if passed as bytes versions: Python 3.7 ___ Pyt

[issue39396] AIX: math.nextafter(a, b) breaks AIX bot

Michael Felt added the comment: As I said, was investigating. a) is a bug in most AIX system libraries. b) there is a fix, but not one I can install - as my bots and build systems run on AIX 6.1 and AIX 7.1 c) the fix is APAR IV95512 which includes fixes in the following filesets: IV95512

[issue39396] AIX: math.nextafter(a, b) breaks AIX bot

STINNER Victor added the comment: > AIX: math.nextafter(a, b) breaks AIX bot Please elaborate. What is the error? -- nosy: +vstinner ___ Python tracker <https://bugs.python.org/issu

[issue39396] AIX: math.nextafter(a, b) breaks AIX bot

: Michael.Felt priority: normal severity: normal status: open title: AIX: math.nextafter(a, b) breaks AIX bot versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue39

[issue39288] Add math.nextafter(a, b)

STINNER Victor added the comment: I created bpo-39310 to propose to add math.ulp(x). -- ___ Python tracker ___ ___

[issue39288] Add math.nextafter(a, b)

STINNER Victor added the comment: New changeset 54cfbb2feee1f7328c3d6799ec3734b00824b555 by Victor Stinner in branch 'master': bpo-39288: Add examples to math.nextafter() documentation (GH-17962) https://github.com/python/cpython/commit/54cfbb2feee1f7328c3d6799ec3734b00824b555 --

[issue39288] Add math.nextafter(a, b)

Mark Dickinson added the comment: > I suggest "next_after" instead of "nextafter". "nextafter" gives us consistency with C, with NumPy and with other compound names in the math module ("isnan", "isclose", "copysign"). My own brain doesn't perceive either of "nextafter" or "next_after" as

[issue39288] Add math.nextafter(a, b)

Change by STINNER Victor : -- pull_requests: +17371 pull_request: https://github.com/python/cpython/pull/17962 ___ Python tracker ___

[issue39288] Add math.nextafter(a, b)

Raymond Hettinger added the comment: I suggest "next_after" instead of "nextafter". -- ___ Python tracker ___ ___ Python-bugs-list

[issue39288] Add math.nextafter(a, b)

STINNER Victor added the comment: I chose to make y mandatory in nextafter(x, y). Implement your own flavor if nextUp(x) if you want to omit y. I prefer to make y explicit, becauseit has been said in this discussion that "nextafter" name is ambiguous. Thanks all for the constructive

[issue39288] Add math.nextafter(a, b)

STINNER Victor added the comment: New changeset 100fafcf20e8fc67cd8ef512074f9c0a253cb427 by Victor Stinner in branch 'master': bpo-39288: Add math.nextafter(x, y) (GH-17937) https://github.com/python/cpython/commit/100fafcf20e8fc67cd8ef512074f9c0a253cb427 --

[issue27195] Crash when RawIOBase.write(b) evaluates b.format

Change by Cheryl Sabella : -- resolution: -> wont fix stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue39288] Add math.nextafter(a, b)

Mark Dickinson added the comment: > Do you mean nextafter(x, y=inf, /): toward positive infinity by default? Yes; I believe that was what Steven was suggesting in the last part of msg359779. I don't have strong feelings either way. -- ___ Python

[issue39288] Add math.nextafter(a, b)

Mark Dickinson added the comment: [Steven] > I know Wikipedia isn't a primary source, but it says IEEE 754 recommends > nextafter(x, y). Um. Then it sounds as though Wikipedia is out of date. Which page was this on? IEEE 754-1985 did recommend nextafter, but only in Annex A, which is not

[issue39288] Add math.nextafter(a, b)

STINNER Victor added the comment: Mark: > Making the second argument optional sounds reasonable to me, but doesn't > necessarily have to happen in the existing PR; we can always add that option > later. Do you mean nextafter(x, y=inf, /): toward positive infinity by default? I prefer to

[issue39288] Add math.nextafter(a, b)

Mark Dickinson added the comment: "nextafter" is fine with me. I just wanted to make sure that we'd considered the options, and weren't choosing nextafter simply because it's the easiest thing to implement. [Victor] > It mentions for example "If x== y, y (of the type x) shall be returned"

[issue39288] Add math.nextafter(a, b)

STINNER Victor added the comment: Oh, I forgot to also give the nextafer() link to the POSIX standard: https://pubs.opengroup.org/onlinepubs/009695399/functions/nextafter.html It mentions for example "If x== y, y (of the type x) shall be returned" and "If x or y is NaN, a NaN shall be

[issue39288] Add math.nextafter(a, b)

STINNER Victor added the comment: PR 17937 is ready to be reviewed. The tests passed on the regular CIs and buildbots: good. > That last assumes you want -0 and +0 to act differently It is the case: I wrote an unit test checking exactly that, and it works as expected on all platforms

[issue39288] Add math.nextafter(a, b)

Tim Peters added the comment: [Steven] > I think the second argument should also be optional, so > that nextafter(x) returns the next representable float. That's why the name sucks - there are, in general, two adjacent floats, so "next" is ambiguous. I expect you intend that y default to

[issue39288] Add math.nextafter(a, b)

Steven D'Aprano added the comment: I agree, "nextafter" is so widely used it's probably pointless to fight against the name :-) Mark: "IEEE 754, on the other hand, requires instead nextUp and nextDown". I know Wikipedia isn't a primary source, but it says IEEE 754 recommends nextafter(x,

[issue39288] Add math.nextafter(a, b)

Tim Peters added the comment: No doubt that something along these lines would be useful. `nextafter()` is too widely implemented to fight against, despite the sucky name ;-) I believe the rest should be straightforward (for those who want them) to do with one-liners, so there's not much of

[issue39288] Add math.nextafter(a, b)

STINNER Victor added the comment: > NumPy has nextafter. That's why I proposed math.nextafter() name. Moreover, in the math module, most functions reuse the same names than C function names: expm1(), atan2(), erf(), etc. > IEEE 754, on the other hand, requires instead nextUp and nextDown,

[issue39288] Add math.nextafter(a, b)

Mark Dickinson added the comment: I'm not opposed to some form of this by any means, but I fear there's some bikeshedding to go through, both on the name and the functionality (one function with two arguments, or two functions each taking a single argument?). C 99 prescribes "nextafter" and

[issue39288] Add math.nextafter(a, b)

Change by STINNER Victor : -- keywords: +patch pull_requests: +17345 stage: -> patch review pull_request: https://github.com/python/cpython/pull/17937 ___ Python tracker ___

[issue39288] Add math.nextafter(a, b)

Change by STINNER Victor : -- keywords: +3.3regression nosy: +lemburg, mark.dickinson, rhettinger, stutzbach ___ Python tracker ___

[issue39288] Add math.nextafter(a, b)

ps://docs.scipy.org/doc/numpy/reference/generated/numpy.nextafter.html Attached PR adds math.nextafter(). -- components: Library (Lib) messages: 359731 nosy: vstinner priority: normal severity: normal status: open title: Add math.nextafter(a, b) versions: Python 3.9 _

[issue31711] ssl.SSLSocket.send(b"") fails

Jörn Heissler added the comment: Manpage (openssl 1.1.1d) now states: You should not call SSL_write() with num=0, it will return an error. SSL_write_ex() can be called with num=0, but will not send application data to the peer. SSL_write_ex was added in 1.1.1 So it looks like openssl

[issue31711] ssl.SSLSocket.send(b"") fails

Change by César : -- pull_requests: +17144 pull_request: https://github.com/python/cpython/pull/17671 ___ Python tracker ___ ___

[issue37827] IDLE Shell: add a terminal mode that responds to \a, \b, and \r

Tal Einat added the comment: Note that most of the issues with special characters described in Terry latest comment have been addressed by the fix for issue13153. Can we continue discussing just properly rendering \r and \b, e.g. as done in PR GH-15211? Let's just decide whether we want

Re: a &= b

On Fri, 4 Oct 2019 at 19:02, Hongyi Zhao wrote: > > Could you please give me some more hints on: > > a &= b $ python3 Python 3.5.3 (default, Sep 27 2018, 17:25:39) [GCC 6.3.0 20170516] on linux Type "help", "copyright", "credits" or "license&qu

Re: a &= b

On Fri, Oct 4, 2019 at 5:01 AM Hongyi Zhao wrote: > > Hi, > > Could you please give me some more hints on: > > a &= b > > It's very difficult for me to understand. > -- > https://mail.python.org/mailman/listinfo/python-list & is bitwise And. a &

a &= b

Hi, Could you please give me some more hints on: a &= b It's very difficult for me to understand. -- https://mail.python.org/mailman/listinfo/python-list

[issue38220] Wrong values for %b and %B in ca_ES and ca_AD locales

13)] >>> locale.setlocale(locale.LC_ALL, 'ca_ES.utf8') 'ca_ES.utf8' >>> print(*(time.strftime('%b|%B', m) for m in months), sep='\n') gen.|gener febr.|febrer març|març abr.|abril maig|maig juny|juny jul.|juliol ag.|agost set.|sete

[issue38220] Wrong values for %b and %B in ca_ES and ca_AD locales

and time date_time = now.strftime("|%b|%B|") print("date and time:",date_time) --- -- ___ Python tracker <https://bugs.python.org/issue38220> ___ __

[issue38220] Wrong values for %b and %B in ca_ES and ca_AD locales

New submission from Joan : There's an incorrect behaviour in the output for the strftime values when in catalan. On the documentation at https://docs.python.org/3.7/library/datetime.html#strftime-strptime-behavior: - %b Month as locale’s abbreviated name. Jan, Feb, …, Dec (en_US) - %B Month

Re: a,b = 2,3 and [a,b] = [2,3]

effect of moving the optimization for `x in [a, b]` from the peepholer to the AST optimizer. Ah ha. Thank you. Is it worth trying to reinstate that? On the one hand, there's no reason to build the list, and this technically is a (performance) regression. On the other hand, it's not code people

Re: a,b = 2,3 and [a,b] = [2,3]

is was a side effect of moving the optimization for `x in [a, b]` from > the peepholer to the AST optimizer. > Ah ha. Thank you. Is it worth trying to reinstate that? On the one hand, there's no reason to build the list, and this technically is a (performance) regression. On the other hand, it's not c

<    1   2   3   4   5   6   7   8   9   10   >