[issue39871] math.copysign raises SystemError with non-float x and custom y

[Zackery Spytz]

Change by Zackery Spytz :


--
pull_requests: +21378
pull_request: https://github.com/python/cpython/pull/22333

___
Python tracker 

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

[issue41513] High accuracy math.hypot()

[Raymond Hettinger]

Raymond Hettinger  added the comment:


New changeset bc6b7fa6d7fb8957eb4ff809366af40dfb12b8cd by Raymond Hettinger in 
branch 'master':
bpo-41513: Add accuracy tests for math.hypot() (GH-22327)
https://github.com/python/cpython/commit/bc6b7fa6d7fb8957eb4ff809366af40dfb12b8cd


--

___
Python tracker 

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

[issue41769] Positional arguments with boolean actions behave differently

[paul j3]

paul j3  added the comment:

'store_true/false' are subclasses of 'store_const'.  All have a 'nargs=0' 
value.  It's that value which explains their behavior.  ('append_const' would 
also fall in this category)

In [2]: parser = argparse.ArgumentParser()
In [3]: parser.add_argument('foo', action='store_const', default='xxx', 
const='yyy')
Out[3]: _StoreConstAction(option_strings=[], dest='foo', nargs=0, const='yyy', 
default='xxx', type=None, choices=None, help=None, metavar=None)
In [4]: _.required
Out[4]: True
In [5]: parser.print_help()
usage: ipython3 [-h]

positional arguments:
  foo

optional arguments:
  -h, --help  show this help message and exit

In [6]: parser.parse_args([])
Out[6]: Namespace(foo='yyy')

In [7]: parser.parse_args(['zzz'])
usage: ipython3 [-h]
ipython3: error: unrecognized arguments: zzz

---

Like '*' and '?' this argument is 'satisfied' with nothing, an empty list of 
values.  For those nargs, 'get_values' takes a the special step of assigning 
the default.  For 'store_const' it's the 'const' that's placed in the 
namespace.  'store_true' does store True, and 'store_false' does store False.

Providing a string produces an error because there isn't any Action to consume 
it.  With nargs=0, this Action can't use it.   Usage is also correct since we 
can't provide any string to meet this Action's needs.

Technically then the Action behaves correctly - both in usage and what it does. 
 That said, it normally isn't useful, since it will always assign the 
'const/True/False' to the namespace.  Even without an in depth knowledge of how 
parsing is done, this should be logically evident (if not obvious).

I don't recall any previous issues like this, though I wouldn't be surprised if 
there were.  I don't recall anything on Stackoverflow either.

I think adding an error would be overkill.  It doesn't come up often, and some 
user might have their own obscure reason for using it.  

A note to the docs might be in order, but until a user has encountered this 
behavior as you have, such a note might be more confusing than useful.

As a general rule, parameter checking in add_argument() is rather loose (and 
multilayered).  While 'action' is used to select the Action subclass, most of 
the rest are passed on to that Action.  The Action __init__ check a few key 
parameters (for example 'store_const' will complain if we don't provide a 
'const'), but accept or ignore the rest.

--
nosy: +paul.j3

___
Python tracker 

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

[issue41561] test_ssl fails in Ubuntu 20.04: test_min_max_version_mismatch

[Bug Reporter]

Bug Reporter  added the comment:

I added client_context.set_ciphers("@SECLEVEL=1:HIGH"), then added 
server_context.set_ciphers("@SECLEVEL=1:HIGH"). The test failed in both cases.

I did not have problem with python 3.7.x. in Ubuntu 18.04. I have just tried 
compiling 3.7.5 in Ubuntu 20.04 and test_ssl failed.

I also remember downloading openssl source code, compiling it, and using 
--with-openssl=DIR option with python 3.8.x in Ubuntu 20.04. I tried different 
versions of openssl (I did not edit any config files, just compiled) and 
test_ssl failed with all of them. Does it mean that Ubuntu's config files were 
still used even in this case?

--

___
Python tracker 

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

[issue41819] Fix some compiler warnings

[Samuel Marks]

Change by Samuel Marks :


--
keywords: +patch
pull_requests: +21376
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/22332

___
Python tracker 

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

[issue41819] Fix some compiler warnings

[Samuel Marks]

Samuel Marks  added the comment:

Okay I'll redo it on master, here is my config, on macOS 10.15.6:
```
$ export PKG_CONFIG_PATH="/usr/local/opt/openssl@1.1/lib/pkgconfig"
$ export CPPFLAGS="-I/usr/local/opt/openssl@1.1/include"
$ export LDFLAGS="-L/usr/local/opt/openssl@1.1/lib"
$ export CPPFLAGS="-I/usr/local/opt/zlib/include $CPPFLAGS"
$ export LDFLAGS="-L/usr/local/opt/zlib/lib $LDFLAGS"
$ gcc --version && clang --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr 
--with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
Apple clang version 12.0.0 (clang-1200.0.32.2)
Target: x86_64-apple-darwin19.6.0
Thread model: posix
InstalledDir: 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
Apple clang version 12.0.0 (clang-1200.0.32.2)
Target: x86_64-apple-darwin19.6.0
Thread model: posix
InstalledDir: 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
$ ./configure --enable-optimizations --prefix /opt/python3-master
$ ./configure --enable-optimizations --prefix /opt/python3-master
checking for git... found
checking build system type... x86_64-apple-darwin19.6.0
checking host system type... x86_64-apple-darwin19.6.0
checking for python3.10... no
checking for python3... python3
checking for --enable-universalsdk... no
checking for --with-universal-archs... no
checking MACHDEP... "darwin"
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr 
--with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
[… omitted for brevity]
$ make
```

With these warnings being addressed by this bug report and PR:
```
gcc -c -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -g -fwrapv 
-O3 -Wall-std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter 
-Wno-missing-field-initializers -Wstrict-prototypes 
-Werror=implicit-function-declaration -fvisibility=hidden 
-fprofile-instr-generate -I./Include/internal  -I. -I./Include 
-I/usr/local/opt/zlib/include -I/usr/local/opt/openssl@1.1/include 
-I/usr/local/opt/zlib/include -I/usr/local/opt/openssl@1.1/include  
-DPy_BUILD_CORE \
-DPLATLIBDIR='"lib"' \
-o Python/initconfig.o ./Python/initconfig.c
./Python/initconfig.c:2677:38: warning: format specifies type 'wint_t' (aka 
'int') but the argument has type 'unsigned int' [-Wformat]
PySys_WriteStderr("%lc", ch);
   ~~~   ^~
   %c
1 warning generated.
```

Looks like someone else has already picked up the other bug. So opened a new PR 
for this.

--

___
Python tracker 

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

[issue41823] Add more fields to sys.float_info

[Raymond Hettinger]

New submission from Raymond Hettinger :

Consider adding new non-sequence fields to sys.float_info: doubling_rounding 
and ieee_754.

The code in test_math defines a useful constant:

   # detect evidence of double-rounding: fsum is not always correctly
   # rounded on machines that suffer from double rounding.
   x, y = 1e16, 2. # use temporary values to defeat peephole optimizer
   HAVE_DOUBLE_ROUNDING = (x + y == 1e16 + 4)

There is another useful value in a float.__getformat__ which is hard to find 
and only documented for internal use:

   >>> float.__getformat__('double')
   'IEEE, little-endian

Making this information available would make it easier for users to do what we 
do in test_math:

@requires_IEEE_754
@unittest.skipIf(HAVE_DOUBLE_ROUNDING,
   "fsum is not exact on machines with double rounding")
def testFsum(self):
...

--
components: Extension Modules
messages: 377237
nosy: mark.dickinson, rhettinger, tim.peters
priority: normal
severity: normal
status: open
title: Add more fields to sys.float_info
versions: Python 3.10

___
Python tracker 

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

[issue41684] argparse: unexpected subparser behaviour on parse_args with namespace option

[paul j3]

Change by paul j3 :


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

[issue41822] Document the mean of values for sys.float_info.rounds

[Raymond Hettinger]

Change by Raymond Hettinger :


--
nosy: +mark.dickinson, serhiy.storchaka, tim.peters

___
Python tracker 

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

[issue41822] Document the mean of values for sys.float_info.rounds

[Raymond Hettinger]

New submission from Raymond Hettinger :

The current docs unnecessarily refer readers to the C99 standard. "integer 
constant representing the rounding mode used for arithmetic operations. This 
reflects the value of the system FLT_ROUNDS macro at interpreter startup time. 
See section 5.2.4.2.2 of the C99 standard for an explanation of the possible 
values and their meanings."

The docs should quote the standard, "The rounding mode for floating-point 
addition is characterized by the implementation defined value of FLT_ROUNDS: -1 
indeterminable, 0 toward zero, 1 to nearest, 2 toward positive infinity, 3 
toward negative infinity.  All other values for FLT_ROUNDS characterize 
implementation-defined rounding."
behavior.

--
assignee: docs@python
components: Documentation
keywords: newcomer friendly
messages: 377236
nosy: docs@python, rhettinger
priority: normal
severity: normal
status: open
title: Document the mean of values for sys.float_info.rounds

___
Python tracker 

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

[issue41820] ipaddress Library gives me incorrect results

[Anudeep Balla]

Anudeep Balla  added the comment:

Greetings,

Any Ip address containing 2 zeros or more are considered to be an invalid
IP address.

 '172.16.254.00' *is not* equivalent to '172.16.254.0'

I guess this small logic is causing the error

I hope it makes it clear from the below images.

Regards,
Raj.

[image: Screen Shot 2020-09-20 at 11.42.39 AM.png]
[image: Screen Shot 2020-09-20 at 11.42.31 AM.png]
[image: Screen Shot 2020-09-20 at 11.42.18 AM.png]
[image: Screen Shot 2020-09-20 at 11.42.09 AM.png]

On Sun, 20 Sep 2020 at 08:00, Eric V. Smith  wrote:

>
> Eric V. Smith  added the comment:
>
> Simplified:
> >>> import ipaddress
> >>> print(ipaddress.ip_address('172.16.254.00').version)
> 4
>
> So your concern is that you think '172.16.254.00' (or equivalently,
> '172.16.254.0') shouldn't be treated as a valid IPv4 address. Is that
> correct?
>
> Can you tell us why you think it's not a valid IPv4 address? I think
> everything is working correctly here.
>
> --
> nosy: +eric.smith
>
> ___
> Python tracker 
> 
> ___
>

--
Added file: https://bugs.python.org/file49465/Screen Shot 2020-09-20 at 
11.42.31 AM.png
Added file: https://bugs.python.org/file49466/Screen Shot 2020-09-20 at 
11.42.39 AM.png
Added file: https://bugs.python.org/file49467/Screen Shot 2020-09-20 at 
11.42.18 AM.png
Added file: https://bugs.python.org/file49468/Screen Shot 2020-09-20 at 
11.42.09 AM.png

___
Python tracker 

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

[issue33085] *** Error in `python': double free or corruption (out): 0x00007ff5254d50d0 ***

[Irit Katriel]

Change by Irit Katriel :


--
components:  -2to3 (2.x to 3.x conversion tool)

___
Python tracker 

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

[issue34199] Add support for delete logger in log module.

[Irit Katriel]

Change by Irit Katriel :


--
components: +Library (Lib) -2to3 (2.x to 3.x conversion tool)

___
Python tracker 

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

[issue41631] _ast module: get_global_ast_state() doesn't work with Mercurial lazy import

[Pablo Galindo Salgado]

Change by Pablo Galindo Salgado :


--
pull_requests: +21375
pull_request: https://github.com/python/cpython/pull/22331

___
Python tracker 

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

[issue41821] Printing specific Unicode characters causes unwanted beeping in Windows 7 console

[Eryk Sun]

Eryk Sun  added the comment:

> It is set to use an OEM raster font.

Okay, then the issue can either be closed as third-party or changed to a 
documentation enhancement. It could be documented that Unicode support requires 
selecting a TrueType font in the console properties. "Raster Fonts" uses OEM 
with a lossy best-fit conversion (e.g. "α" -> "a").  

> So I assume that with the UTF-8 flag set the font still has to be 
> set to a TTF-Font so it does not beep?

Yes, the conversion to OEM for "Raster Fonts" occurs in the console itself. 

> I CP850 required to encode those characters via CP850 to the 
> bell character?

Other OEM codepages have a different best-fit mapping. For example, codepage 
437 maps U+2022 to ASCII bell, but not U+2024 or U+2219.

> I was a bit lost on what happens under the hood encoding-wise as 
> sys.stdout.encoding just returns 'utf-8'.

For a console file, the io module uses io._WindowsConsoleIO for the raw layer 
instead of io.FileIO. _WindowsConsoleIO internally uses the console's 
wide-character (UTF-16) API and converts to and from UTF-8. 

Overriding the standard I/O encoding to UTF-8 isn't needed for 
_WindowsConsoleIO. It's needed for regular files and pipes when standard I/O is 
redirected, since those still default to the process active codepage (usually 
system ANSI).

--

___
Python tracker 

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

[issue24403] Missing fixer for changed round() behavior

[Irit Katriel]

Irit Katriel  added the comment:

Looks like this issue can be closed as rejected.

--
nosy: +iritkatriel

___
Python tracker 

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

[issue40407] Zipfile couldn`t recognized character set rightly.

[Irit Katriel]

Change by Irit Katriel :


--
components: +Library (Lib) -2to3 (2.x to 3.x conversion tool)

___
Python tracker 

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

[issue35247] test.test_socket.RDSTest.testPeek hangs indefinitely

[Jáchym Barvínek]

Jáchym Barvínek  added the comment:

I am experiencing the same issue when trying to build the ArchLinux python 
package. Not sure how to reproduce, but I can provide specific details of my 
system if requested.

--
nosy: +Jáchym Barvínek

___
Python tracker 

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

[issue41561] test_ssl fails in Ubuntu 20.04: test_min_max_version_mismatch

[Tal Einat]

Tal Einat  added the comment:

Same.

--

___
Python tracker 

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

[issue41821] Printing specific Unicode characters causes unwanted beeping in Windows 7 console

[john_miller]

john_miller  added the comment:

It is set to use an OEM raster font.

(Should the information about the font and possible unwanted beeping be 
mentioned on https://docs.python.org/3/using/windows.html ? Perhaps even a 
short link regarding "Windows issues" under the print()-entry?)

Thanks for your help.

I was a bit lost on what happens under the hood encoding-wise as 
sys.stdout.encoding just returns 'utf-8'.

I CP850 required to encode those characters via CP850 to the bell character?

I'm not clear on how setting Python to use UTF-8 interacts with the regular 
console.

Basically there are two different basic fixes for printing various text without 
beeping to the console as-is (with the font set to the default setting raster 
font):
1. Set the font to a TTF-Font in the console settings
2. Filter or replace the offending Unicode characters (\u2022, \u2024, \u2219) 
in the Unicode string before printing it to "sys.stdout".

In the case where the UTF-8 flag is set (Environment variable set PYTHONUTF8=1 
or "python.exe -X utf8 script.py" called within the console), it seems that it 
still beeps. In interactive mode and when entering the command in the console.

Both these cases still beep.
python.exe -X utf8 -c "print('\u2022')"
set /A PYTHONUTF8=1 & python.exe -c "print('\u2022')" & set PYTHONUTF8=

Using python.exe from the explorer without opening it from a console Window 
(that was opened via cmd.exe) also beeps.

So I assume that with the UTF-8 flag set the font still has to be set to a 
TTF-Font so it does not beep?


As for redirecting STDOUT in the console, the UTF-8 option seems to be 
sufficient, simply printing the character utf-8 encoded into the file:
python.exe -X utf8 -c "print('\u2023')" >> testfile.txt

A quick test for writing bytes to a file this way (see also Issue4571):
python.exe -X utf8 -c "import sys; sys.stdout.buffer.raw.write(b'\x20\x20a')" 
>> testfile.txt )

--

___
Python tracker 

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

[issue41820] ipaddress Library gives me incorrect results

[Eric V. Smith]

Eric V. Smith  added the comment:

Given that RFC 790 uses 000 as an octet (thanks Serhiy), I think the bug here, 
if there is one, is in the other validator that you're using. Without a 
standard saying not to accept 00 or 000, I think we won't make any change here.

--

___
Python tracker 

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

[issue41820] ipaddress Library gives me incorrect results

[Anudeep Balla]

Anudeep Balla  added the comment:

That was the whole point I was trying to make that there were no references
that state .00 is equivalent to .0 and  if you would try any IP validator
or would check by any means you would find that the IP address is invalid.

I truly understand the point that you are trying to make but if my program
says a invalid IP address as valid I don't see how that helps.

I have checked almost every online IP validators to give me the same
INVALID as result for 172.16.254.00 while they say 172.16.254.0 is VALID.

On Sun, 20 Sep 2020 at 12:04, Eric V. Smith  wrote:

>
> Eric V. Smith  added the comment:
>
> Please do not include screen shots in bug reports. They've unfriendly to
> people who use screen readers or other accessibility software. Instead,
> please copy and paste (or retype, if needed) the text into the comment
> section.
>
> > '172.16.254.00' *is not* equivalent to '172.16.254.0'
>
> Do you have an RFC or other document that makes that clear? I've never
> seen an IP address library that makes a distinction between '00' and '0'.
> But I'm happy to learn something new, if you can point to a standard.
>
> If this were going to be an error, it would be in the call to
> ipaddress.ip_address() or its equivalent. It would raise ValueError, like
> it does for other strings that don't represent valid addresses. But for
> backward compatibility reasons, unless there's a standard that explicitly
> disallows .00, I doubt we'd change the code to raise an exception. And even
> if there were a standard that says .00 is not a valid address, I'd be
> reluctant to make a change here. We could potentially break people's code,
> and we'd need a very good reason to do that.
>
> Also, is this causing you a practical problem? Is there somewhere you're
> getting a .00 address and you'd like to treat it as being invalid?
>
> --
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue41561] test_ssl fails in Ubuntu 20.04: test_min_max_version_mismatch

[Christian Heimes]

Christian Heimes  added the comment:

What happens if you modify both contexts?

--

___
Python tracker 

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

[issue1207613] Idle Editor: Bottom Scroll Bar

[Tal Einat]

Tal Einat  added the comment:

We've run into a significant technical hurdle in trying to implement a 
horizontal scrollbar: The Tk text widget sets the horizontal scroll position 
only according to the currently visible lines! If the text was scrolled to the 
right, scrolling down to where there are only shorter lines will scroll the 
text back to the left!!

Implementing this will require either getting a fix for this into Tk itself, or 
finding a good workaround.

The workaround I was considering--wrapping the text widget with a frame and 
implementing custom scrolling logic--is very unlikely to provide reasonable 
performance with large files. This is because it will have to have all of the 
text widget rendered at all times, which the Tk Text widget takes special care 
to avoid in order to achieve good performance.

--
nosy: +taleinat

___
Python tracker 

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

[issue41819] Fix some compiler warnings

[Irit Katriel]

Irit Katriel  added the comment:

Can you give more details about what you're fixing: what were the compiler 
warnings, which compiler (and which version of the compiler), which system?

Also, why did you create the PR against the 3.9 branch rather than master?

--
nosy: +iritkatriel

___
Python tracker 

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

[issue41561] test_ssl fails in Ubuntu 20.04: test_min_max_version_mismatch

[Tal Einat]

Tal Einat  added the comment:

No, adding that after the first line of test_min_max_version_mismatch() still 
results in the same error:

ssl.SSLError: [SSL: UNSUPPORTED_PROTOCOL] unsupported protocol (_ssl.c:1122)

--

___
Python tracker 

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

[issue41561] test_ssl fails in Ubuntu 20.04: test_min_max_version_mismatch

[Christian Heimes]

Christian Heimes  added the comment:

Does "test_min_max_version_mismatch" pass on your system when you add

client_context.set_ciphers("@SECLEVEL=1:HIGH")

?

--

___
Python tracker 

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

[issue41820] ipaddress Library gives me incorrect results

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Why do you think it is invalid? What formal document specify this?

In contrary, there are examples of using 0-padded notation for IPv4 addresses 
(000.rrr.rrr.rrr, 128.000.rrr.rrr, 192.000.001.rrr and 224.000.000.000) in RFC 
790.

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue41820] ipaddress Library gives me incorrect results

[Eric V. Smith]

Eric V. Smith  added the comment:

Please do not include screen shots in bug reports. They've unfriendly to people 
who use screen readers or other accessibility software. Instead, please copy 
and paste (or retype, if needed) the text into the comment section.

> '172.16.254.00' *is not* equivalent to '172.16.254.0'

Do you have an RFC or other document that makes that clear? I've never seen an 
IP address library that makes a distinction between '00' and '0'. But I'm happy 
to learn something new, if you can point to a standard.

If this were going to be an error, it would be in the call to 
ipaddress.ip_address() or its equivalent. It would raise ValueError, like it 
does for other strings that don't represent valid addresses. But for backward 
compatibility reasons, unless there's a standard that explicitly disallows .00, 
I doubt we'd change the code to raise an exception. And even if there were a 
standard that says .00 is not a valid address, I'd be reluctant to make a 
change here. We could potentially break people's code, and we'd need a very 
good reason to do that.

Also, is this causing you a practical problem? Is there somewhere you're 
getting a .00 address and you'd like to treat it as being invalid?

--

___
Python tracker 

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

[issue41561] test_ssl fails in Ubuntu 20.04: test_min_max_version_mismatch

[Christian Heimes]

Christian Heimes  added the comment:

Four times 'True' means that OpenSSL is compiled with TLS 1.0, 1,1, 1.2, and 
1.3 support. SSLContext().minium_version == MINIMUM_SUPPORTED and 
maximum_version == MAXIMUM_SUPPORTED mean that no crypto policy setting or 
OpenSSL security level setting has modified the minimum and maximum version. 
TLS 1.0 and 1.1 connection should work.

But it's not working for you and some connection are even failing "internal 
error". This smells like a Debian/Ubuntu have patched OpenSSL with a buggy 
patch that breaks OpenSSL's internal API.

--

___
Python tracker 

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

[issue41756] Do not always use exceptions to return result from coroutine

[Yury Selivanov]

Yury Selivanov  added the comment:

Vladimir, could you please submit a PR to update 3.10/whatsnew? Need to mention 
both the new C API and the new perf boost in relevant sections.

--

___
Python tracker 

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

[issue41821] Printing specific Unicode characters causes unwanted beeping in Windows 7 console

[Eryk Sun]

Eryk Sun  added the comment:

If you've selected an OEM raster font in the console properties instead of a 
TrueType font (Consolas, Lucida Console, etc), then the console implements some 
magic to support the OEM character mapping in the raster font. The following 
shows that encoding to codepage 850 (the system OEM codepage in the UK and 
Canada) maps the characters that you've flagged, and only those characters, to 
an ASCII bell (0x07):

>>> [hex(x) for x in range(0x)
...   if codecs.code_page_encode(850, chr(x), 'replace')[0] == b'\x07']
['0x7', '0x2022', '0x2024', '0x2219']

Please confirm whether you're using an OEM raster font. If you are, then this 
issue can be closed.

---

> UnicodeEncodeError: 'charmap' codec can't encode character 
> '\u2023' in position 0: character maps to 

Windows Python defaults to using the process active codepage (WinAPI GetACP) 
for non-console I/O. In Windows 7, the process active codepage is limited to 
the system ANSI encoding, which is limited to a legacy codepage such as 1252. 
You can force standard I/O to use UTF-8 via PYTHONIOENCODING, or force all I/O 
to default to UTF-8 by enabling UTF-8 mode via PYTHONUTF8.

---

For future reference, a console session is hosted by conhost.exe. The cmd.exe 
shell is a console client application, which uses standard I/O just like 
python.exe. If you run python.exe from Explorer, you won't see cmd.exe as a 
parent or in any way involved with the console session.

The confusion stems from how the system pretends that the process that 
allocates a console session owns the console window. This is a convenience to 
allow easily identifying and closing a console session in Task Manager, or via 
taskkill.exe. But it also leads people to confuse the console with the shell 
that they run -- such as CMD or PowerShell.

--
nosy: +eryksun

___
Python tracker 

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

[issue19915] int.bit_at(n) - Accessing a single bit in O(1)

[STINNER Victor]

Change by STINNER Victor :


--
nosy:  -vstinner

___
Python tracker 

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

[issue41821] Printing specific Unicode characters causes unwanted beeping in Windows 7 console

[STINNER Victor]

Change by STINNER Victor :


--
nosy:  -vstinner

___
Python tracker 

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

[issue41820] ipaddress Library gives me incorrect results

[Eric V. Smith]

Eric V. Smith  added the comment:

Simplified:
>>> import ipaddress
>>> print(ipaddress.ip_address('172.16.254.00').version)
4

So your concern is that you think '172.16.254.00' (or equivalently, 
'172.16.254.0') shouldn't be treated as a valid IPv4 address. Is that correct?

Can you tell us why you think it's not a valid IPv4 address? I think everything 
is working correctly here.

--
nosy: +eric.smith

___
Python tracker 

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

[issue29526] Documenting format() function

[Eric V. Smith]

Change by Eric V. Smith :


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

[issue29526] Documenting format() function

[Irit Katriel]

Irit Katriel  added the comment:

It looks like this is complete and can be closed.

--
nosy: +iritkatriel

___
Python tracker 

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

[issue41756] Do not always use exceptions to return result from coroutine

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

PR 22330 refactors gen_send_ex(), making it similar to the new PyGen_Send().

--
status: closed -> open

___
Python tracker 

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

[issue41756] Do not always use exceptions to return result from coroutine

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
pull_requests: +21374
pull_request: https://github.com/python/cpython/pull/22330

___
Python tracker 

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

[issue41821] Printing specific Unicode characters causes unwanted beeping in Windows 7 console

[john_miller]

New submission from john_miller :

I noticed some beeping when printing data to the console (cmd), so I narrowed 
down the problem to three specific Unicode-characters somehow producing beeps 
when printed to the Windows console (CMD). This also works in interactive mode. 
(I checked every single Unicode-character up to sys.maxunicode (except 
character-values between 0xD800 and 0xE000) by bisecting ever-more fine-grained 
until I narrowed it down to only those three characters producing unwanted 
beeps.)

Isolated example of bug: for i in ['\u2022', '\u2024', '\u2219']: print(i)

\u0007 beeps too, but this works as intended.

Python version: 3.8.5 (tags/v3.8.5:580fbb0, Jul 20 2020, 15:43:08) [MSC v.1926 
32 bit (Intel)]
Windows version: Microsoft Windows 7 Professional (6.1.7601 Service Pack 1 
Build 7601)
CMD active code page: 850 (According to chcp-command.) 
sys.stdout.encoding: utf-8

Might be loosly related to PEP-528 (https://www.python.org/dev/peps/pep-0528/)

Addendum:
Piping the output like: 'python.exe script.py >> testfile.txt' produced an 
error.
This might happen with more Unicode characters but I haven't checked.

Addendum-Example:
Traceback (most recent call last):
  File "pytest2.py", line 38, in 
print(hex(i), ":", chr(i), end='\n')
  File "C:\Python38-32\lib\encodings\cp1252.py", line 19, in encode
return codecs.charmap_encode(input,self.errors,encoding_table)[0]
UnicodeEncodeError: 'charmap' codec can't encode character '\u2023' in position 
0: character maps to 

--
components: Unicode, Windows
messages: 377214
nosy: ezio.melotti, john_miller, paul.moore, steve.dower, tim.golden, vstinner, 
zach.ware
priority: normal
severity: normal
status: open
title: Printing specific Unicode characters causes unwanted beeping in Windows 
7 console
type: behavior
versions: Python 3.8

___
Python tracker 

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

[issue21261] Teach IDLE to Autocomplete dictionary keys

[Terry J. Reedy]

Terry J. Reedy  added the comment:

> the PR allows using either type of quote when typing completions.

Only if one types a quote before the box pops up.  In this case, there is no 
auto popup and one must request completions.  The box then uses the quote 
typed.  Thereafter, there is no choice. Backspacing to delete the quote and 
typing the another one disables matching.

If one type >>> d[ and pauses long enough for the auto-popup, (I have 'wait' 
set to 200 milleseconds), one must similarly match the existing quote, because 
jumping ahead requires a string match.  Because of the bytes inclusion, the 
match much include the opening quote, because otherwise an initial 'b' would be 
ambiguous.  Without bytes, we could either removed the quotes from the box or 
automatically add an open quote.

--

___
Python tracker 

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

[issue21261] Teach IDLE to Autocomplete dictionary keys

[Tal Einat]

Tal Einat  added the comment:

People still get confused between bytes and strings, even with Python 3, 
especially novice programmers who are a major target audience of IDLE.

I simply thought it would be  confusing if string dict keys did appear in the 
completion list, but bytes keys did not.

You're certainly right that removing support for completing bytes keys would 
simplify the code.

--

___
Python tracker 

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

[issue21261] Teach IDLE to Autocomplete dictionary keys

[Tal Einat]

Tal Einat  added the comment:

Also, please note that the PR allows using either type of quote when typing 
completions.

--

___
Python tracker 

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

[issue39960] Using typename.__setattr__ in extension type with Py_TPFLAGS_HEAPTYPE is broken (hackcheck too eager?)

[Stefan Behnel]

Stefan Behnel  added the comment:

Closing again since GH-21528 has been merged in issue 41295.

--
status: open -> closed

___
Python tracker 

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

[issue21261] Teach IDLE to Autocomplete dictionary keys

[Terry J. Reedy]

Terry J. Reedy  added the comment:

The current patch completes both strings keys and bytes keys mixed together.  I 
want to challenge this.

0. What is the use case?  The current patch nearly doubles the autocomple code, 
which handle user actions up to creation of a completion list.  I would prefer 
smaller.

1. We agreed on completing 'string keys'. Bytes are not strings.  Bytes might 
represent an encoded string, but might instead be anything else.  Some bytes 
are represented by ascii chars, but the majority need hex escapes.

2. Including bytes forces quoting keys in the list box in order to add the 'b' 
prefix for bytes.  I said above that we should quote anyway, but that was 
before working with the implementation and discovering the resulting usage 
issues.

3. Including bytes makes it harder to select a key by typing a partial key.  
Suppose d had hundreds of key, a to z.  One want to select 'zeta13  c3'.
>>> d[  opens a list box with starting with the 'a' words.
One enters 'z'.  Nothing happens because no entry starts with 'a'.
Backspace, enter "'z".  Nothings happens because the default quote used in the 
listbox is '"'.  If 'b' did not possibly represent a bytes prefix, we could 
either remove surrounding quotes or ignore them when matching.

--
versions: +Python 3.10 -Python 3.7

___
Python tracker 

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

[issue41820] ipaddress Library gives me incorrect results

[Anudeep Balla]

New submission from Anudeep Balla :

https://docs.python.org/3.8/library/ipaddress.html

import ipaddress


ADDRESSES = [
'172.16.254.00'
]

for ip in ADDRESSES:
addr = ipaddress.ip_address(ip)
if addr.version==4:
{
print("true")
}
else:
{
print("false")
}
Screen Shot 2020-09-20 at 1 33 30 AM

I tried to validate an invalid IPv4 address using IPaddress library from py 
3.8.6 but somehow it considers any address ending with "00" to be valid.

I hope this is helpful to the community please let me know if the issue is with 
validation from your end or a bug in the library.

@AnudeepBalla

--
components: Library (Lib)
messages: 377208
nosy: anudeepballa07
priority: normal
severity: normal
status: open
title: ipaddress Library gives me incorrect results
type: behavior
versions: Python 3.8

___
Python tracker 

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

[issue12178] csv writer doesn't escape escapechar

[Tal Einat]

Tal Einat  added the comment:

After a great deal of delay, a fix for this has finally been merged, and will 
be available in Python 3.10.

Thanks to everyone involved!

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.10 -Python 2.7, Python 3.8, Python 3.9

___
Python tracker 

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

[issue12178] csv writer doesn't escape escapechar

[Tal Einat]

Tal Einat  added the comment:


New changeset 5c0eed7375fdd791cc5e19ceabfab4170ad44062 by Berker Peksag in 
branch 'master':
bpo-12178: Fix escaping of escapechar in csv.writer() (GH-13710)
https://github.com/python/cpython/commit/5c0eed7375fdd791cc5e19ceabfab4170ad44062


--

___
Python tracker 

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

[issue41819] Fix some compiler warnings

[Samuel Marks]

New submission from Samuel Marks :

https://github.com/SamuelMarks/cpython/tree/3.9-compiler-fixes

--
components: Build
messages: 377205
nosy: samuelmarks
priority: normal
pull_requests: 21373
severity: normal
status: open
title: Fix some compiler warnings
type: compile error
versions: Python 3.9

___
Python tracker 

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