[issue44869] MacOS Monterrey malloc issue

[Eduardo Morales]

Eduardo Morales  added the comment:

These are the libraries that I'm using:
```
ibm-db~=3.0.4
Flask~=2.0.1
pandas~=1.2.5
requests~=2.25.1
flask_basicauth~=0.2.0
schedule~=1.1.0
```

--

___
Python tracker 

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

[issue44869] MacOS Monterrey malloc issue

[Eduardo Morales]

Eduardo Morales  added the comment:

I am not sure how to reproduce it, I think it's being caused by an imported 
library.

--

___
Python tracker 

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

[issue43585] perf_counter() returns computers uptime

[Dennis Sweeney]

Change by Dennis Sweeney :


--
resolution:  -> not a bug
stage:  -> resolved
status: pending -> closed

___
Python tracker 

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

[issue44869] MacOS Monterrey malloc issue

[Eduardo Morales]

New submission from Eduardo Morales :

Running on MacOS Monterrey throws following error:

```malloc: *** error for object 0x7ffb5ea1a120: pointer being freed was not 
allocatedPython(4899,0x1061a8600)```

This started happening right after upgrading to the new MacOS Beta.

--
messages: 399247
nosy: edumorlom
priority: normal
severity: normal
status: open
title: MacOS Monterrey malloc issue
versions: Python 3.10, Python 3.6, Python 3.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

[issue44765] Misspelled Word In Docs

[Eesa Ibrahim Khokhar]

Eesa Ibrahim Khokhar  added the comment:

Thanks for the tip! I just saw that the docs at the above URL are now updated. 
Thanks again!

--

___
Python tracker 

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

[issue44865] [argparse] Missing translations

[hai shi]

Change by hai shi :


--
nosy: +paul.j3, rhettinger

___
Python tracker 

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

[issue44864] [argparse] Do not translate user-provided strings in `ArgumentParser.add_subparsers()`

[hai shi]

Change by hai shi :


--
nosy: +paul.j3, rhettinger

___
Python tracker 

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

[issue44544] Add full list of possible args to textwrap: wrap, fill, shorten

[Andrei Kulakov]

Change by Andrei Kulakov :


--
pull_requests: +26159
pull_request: https://github.com/python/cpython/pull/27671

___
Python tracker 

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

[issue44522] [doc] open() function errors='surrogateescape' has inaccurate information

[Bupjae Lee]

Bupjae Lee  added the comment:

I just noticed that very next sentence, "These private code points will then be 
turned back...", also needs to be fixed.

Suggested fix:

"These surrogate code units will then be turned back..."

--

___
Python tracker 

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

[issue22240] argparse support for "python -m module" in help

[Nils Kattenbeck]

Nils Kattenbeck  added the comment:

I implemented the logic and adjusted the existing tests to have a fixed program 
name. I also fixed the build error by changing how zip files are detected. 
Based on you comment Nick you however even had a different idea. Currently I 
check if __spec__.__loader__ is a zip loader but if I understood correct you 
suggest the check if __spec__.__location__ is a proper subdir of sys.argv[0]?

https://github.com/septatrix/cpython/compare/main...septatrix:enhance/argparse-prog-name.

When I have some more time I will check whether mocking works and otherwise 
checkout test.support.script_helper or making the function accept spec/argv0

--

___
Python tracker 

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

[issue25782] CPython hangs on error __context__ set to the error itself

[Irit Katriel]

Irit Katriel  added the comment:

Note that my PR can (and should) be backported, while a change in the semantics 
of __context__ assignment, I'm not sure.

--

___
Python tracker 

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

[issue41645] Typo First Page of Documentation

[Carol Willing]

Carol Willing  added the comment:

I've run the two sentences through Grammarly's checker. No errors were flagged 
for the sentence in question. Let's leave "as is". Thanks to all who discussed 
this issue.

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

[issue44859] Improve some sqlite3 errors

[Erlend E. Aasland]

Erlend E. Aasland  added the comment:

* sqlite3.ProgrammingError is raised for SQLITE_MISUSE. IMO, 
sqlite3.InterfaceError, is more appropriate.
* In case of too large integer values, OverflowError is raised on bind, but 
sqlite3.DataError is raised on UDF return. Using sqlite3.DataError in both 
cases would be more aligned with PEP 249.
* Too long strings/blobs raise OverflowError. Consider raising 
sqlite3.DataError instead.
* For non-contiguous (blob) buffers, we overwrite the BufferError with 
ValueError. Instead of overwriting BufferError, we should consider chaining 
with sqlite3.DataError.
* Consider raising sqlite3.Warning when nan is implicitly converted to NULL by 
SQLite
* In pysqlite_statement_create(), consider raising sqlite3.ProgrammingError 
iso. sqlite3.Warning when more than one statement is executed
* In pysqlite_statement_create(), consider raising sqlite3.DataError iso. 
ValueError for queries with null characters

--

___
Python tracker 

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

[issue41645] Typo First Page of Documentation

[Raymond Hettinger]

Raymond Hettinger  added the comment:

To my ears, the sentence reads nicely.  I vote for leaving it as is.

--
nosy: +rhettinger

___
Python tracker 

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

[issue44868] misleading error about fd / follow_symlinks from os.stat()

[Andrei Kulakov]

Andrei Kulakov  added the comment:

> In addition, fwalk() can probably check that `top` arg is a string and raise 
> an error stating that it should be a string if it's not.

I should clarify that fwalk() cannot accept an fd as the `top` arg, see 
https://bugs.python.org/issue42053

--

___
Python tracker 

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

[issue44867] types.MappingProxyType and collections.defaultdict

[Raymond Hettinger]

Raymond Hettinger  added the comment:

> `types.MappingProxyType` is documented as 
> 'Read-only proxy of a mapping'.  But if used with a 
> `collections.defaultdict` mapping, it can modify 
> the underlying mapping.

Technically, the underlying mapping is modifying itself.  That is allowed.

Also, there isn't really anything that the mapping proxy can do about it.  All 
MappingProxy can do it forward calls to methods that are usually non-mutating.

--
assignee:  -> rhettinger
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

[issue44868] misleading error about fd / follow_symlinks from os.stat()

[Andrei Kulakov]

New submission from Andrei Kulakov :

(note the actual relevant code is in posixmodule.c) 

os.stat() error can be confusing and misleading when given an fd and with 
follow_symlinks=False:

ValueError: stat: cannot use fd and follow_symlinks together

It's less bad when os.stat() is used directly because the user would look at 
the signature and would have provided the follow_symlinks=False directly, but 
it's confusing when used indirectly by other function.

I've ran into this when reviewing https://github.com/python/cpython/pull/27524

list(os.fwalk(1))
/usr/local/Cellar/python@3.9/3.9.1/Frameworks/Python.framework/Versions/3.9/lib/python3.9/os.py
 in fwalk(top, topdown, onerror, follow_symlinks, dir_fd)
467 # lstat()/open()/fstat() trick.
468 if not follow_symlinks:
--> 469 orig_st = stat(top, follow_symlinks=False, dir_fd=dir_fd)
470 topfd = open(top, O_RDONLY, dir_fd=dir_fd)
471 try:

ValueError: stat: cannot use fd and follow_symlinks together


A few things are confusing here: I did not use follow_symlinks argument; I can 
see from traceback that the arg is used but set to False, which is the usual 
meaning of "do not use follow_symlinks".

In addition, fwalk() can probably check that `top` arg is a string and raise an 
error stating that it should be a string if it's not.

If that's done, this issue will no longer happen for current code anywhere in 
os module, but stat(follow_symlinks=False) is also used in shutil and pathlib 
(I didn't check if fd may be passed in those cases), but also in 3rd party 
libraries.

So I think it would be clearer to rephrase the error to say

stat: cannot use fd and follow_symlinks set to False or NULL together

(adding NULL as it may be used from C code).

--
components: C API, Library (Lib)
messages: 399237
nosy: andrei.avk
priority: normal
severity: normal
status: open
title: misleading error about fd / follow_symlinks from os.stat()
type: behavior
versions: Python 3.11

___
Python tracker 

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

[issue44866] Inconsistent Behavior of int()

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

I understand your confusion John.

The fact is that int() serves two functions. If argument is a number, it 
truncates it to an integer. If argument is a string, it parses the string 
representation of integer (not necessary decimal).

For details see https://docs.python.org/3/library/functions.html#int .

--

___
Python tracker 

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

[issue28022] SSL releated deprecation for 3.6

[Christian Heimes]

Christian Heimes  added the comment:

The part with "make ftplib, imaplib, nntplib, pop3lib, smtplib etc. validate 
certs by default" was not implemented. These modules still default to 
unverified connections.

--

___
Python tracker 

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

[issue44867] types.MappingProxyType and collections.defaultdict

[Guo Ci Teo]

New submission from Guo Ci Teo :

`types.MappingProxyType` is documented as 'Read-only proxy of a mapping'.
But if used with a `collections.defaultdict` mapping, it can modify the 
underlying mapping.
```
import collections, types
dd = collections.defaultdict(set)
mpt = types.MappingProxyType(dd)
mpt['__getitem__'] # key inserted
mpt.get('get') # key not inserted
print(dd.items()) # dict_items([('__getitem__', set())])
```

--
components: Library (Lib)
messages: 399234
nosy: guoci
priority: normal
severity: normal
status: open
title: types.MappingProxyType and collections.defaultdict
type: behavior
versions: Python 3.10, Python 3.11, Python 3.6, Python 3.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

[issue44866] Inconsistent Behavior of int()

[Terry J. Reedy]

Terry J. Reedy  added the comment:

John, for next time, please read 
https://stackoverflow.com/help/minimal-reproducible-example

--

___
Python tracker 

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

[issue44866] Inconsistent Behavior of int()

[Steven D'Aprano]

Change by Steven D'Aprano :


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

[issue44866] Inconsistent Behavior of int()

[Steven D'Aprano]

Steven D'Aprano  added the comment:

John, there's no need to establish every feature in Python that you are **not** 
questioning. Please focus on the behaviour that you think is a bug. Pretty much 
nothing in your example before the line "So everything here is working as 
expected" is necessary. We're experienced Python users, some of us have been 
using Python for 20 years or more. We know how int() operates, you don't have 
to teach us.

What you have done is confuse the string '2.8' and the float 2.8, which is easy 
enough to do as a beginner. The critical error is this line:

int_y = int(2.8) #conver y to an integer 2 and assign to int_y

But that's not converting the variable `y` to an integer, it is converting the 
float 2.8 to an integer. 2.8 is already a number, and calling int(2.8) drops 
the fractional part leaving 2 as expected.

Had you tried `int_y = int(y)` instead (y being a string) you would have got 
the exact error you were expecting.

It takes a little while to completely understand the differences between 
strings, ints, floats, literal numbers like 2.8 versus strings like "2.8", but 
that will come with some practice.

In future, rather than posting on the bug tracker, please consider asking 
questions on one of the many forums where volunteers will answer your questions 
and leave the bug tracker for actual bugs.

(Hint: there are many tens of thousands of Python programmers with collectively 
thousands of years of experience with the language. As a beginner with only a 
few days experience, you are highly unlikely to spot a bug that everyone else 
has missed.)

You can try the Python Discussion area:

https://discuss.python.org/


or the Python-List or Tutor mailing lists:

https://mail.python.org/mailman/listinfo/python-list

https://mail.python.org/mailman/listinfo/tutor


Good luck!

--
nosy: +steven.daprano

___
Python tracker 

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

[issue28022] SSL releated deprecation for 3.6

[Nick Guenther]

Nick Guenther  added the comment:

Hello everyone, and thank you as usual for all your hard work keeping the 
python ecosystem going.

I saw that the start of this thread said it was going to

> - make ftplib, imaplib, nntplib, pop3lib, smtplib etc. validate certs by 
> default.

but this hasn't been done, at least not for imaplib. imaplib is still calling 
the undocumented "ssl._create_stdlib_context":

https://github.com/python/cpython/blob/2b496e79293a8b80e8ba0e514e186b3b1467b64b/Lib/imaplib.py#L1320

which is actually "ssl._create_unverified_context":

https://github.com/python/cpython/blob/2b496e79293a8b80e8ba0e514e186b3b1467b64b/Lib/ssl.py#L842

which is indeed unverified: despite defaulting to PROTOCOL_TLS_CLIENT, which 
"enables CERT_REQUIRED and check_hostname by default.", it overrides that by 
setting check_hostname=False:

https://github.com/python/cpython/blob/2b496e79293a8b80e8ba0e514e186b3b1467b64b/Lib/ssl.py#L811



To demonstrate, check out this tester script:

$ cat a.py 
import os, imaplib

with imaplib.IMAP4_SSL(os.environ.get('HOSTNAME')) as S: 
print(S.login(os.environ.get('USERNAME'), os.environ.get('PASSWORD')))
$ HOSTNAME=46.23.90.174 USERNAME=test1 PASSWORD=test1test1 python3 a.py 
('OK', [b'Logged in'])

I don't have a cert for 46.23.90.174 (no one will give out certs for IPs!), so 
this is wrong!

In order to actually enable verification you need to know the incantation. It's 
not that long but it is subtle and frighteningly easy to get wrong. Here it is:

$ cat a.py 
import os, ssl, imaplib

ctx = ssl.SSLContext(ssl.PROTOCOL_TLS_CLIENT)
ctx.load_default_certs()

with imaplib.IMAP4_SSL(os.environ.get('HOSTNAME'), ssl_context=ctx) as S: 
print(S.login(os.environ.get('USERNAME'), os.environ.get('PASSWORD')))
$ HOSTNAME=46.23.90.174 USERNAME=test1 PASSWORD=test1test1 python3 a.py 
Traceback (most recent call last):
  File "a.py", line 6, in 
with imaplib.IMAP4_SSL(os.environ.get('HOSTNAME'), ssl_context=ctx) as S: 
  File "/usr/lib/python3.6/imaplib.py", line 1288, in __init__
IMAP4.__init__(self, host, port)
  File "/usr/lib/python3.6/imaplib.py", line 198, in __init__
self.open(host, port)
  File "/usr/lib/python3.6/imaplib.py", line 1301, in open
IMAP4.open(self, host, port)
  File "/usr/lib/python3.6/imaplib.py", line 299, in open
self.sock = self._create_socket()
  File "/usr/lib/python3.6/imaplib.py", line 1293, in _create_socket
server_hostname=self.host)
  File "/usr/lib/python3.6/ssl.py", line 407, in wrap_socket
_context=self, _session=session)
  File "/usr/lib/python3.6/ssl.py", line 817, in __init__
self.do_handshake()
  File "/usr/lib/python3.6/ssl.py", line 1077, in do_handshake
self._sslobj.do_handshake()
  File "/usr/lib/python3.6/ssl.py", line 694, in do_handshake
match_hostname(self.getpeercert(), self.server_hostname)
  File "/usr/lib/python3.6/ssl.py", line 327, in match_hostname
% (hostname, ', '.join(map(repr, dnsnames
ssl.CertificateError: hostname '46.23.90.174' doesn't match either of 
'comms.kousu.ca', 'comms3.kousu.ca'


I can see from this thread there were some concerns about breaking people's 
self-signed certs back in 2016. But it's five years later now and letsencrypt 
is super common now, and most servers and clients are enforcing TLS, especially 
when credentials are involved.

Could this be revisited?

Thanks for any attention you have gifted to this :)

--
nosy: +kousu

___
Python tracker 

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

[issue25782] CPython hangs on error __context__ set to the error itself

[Chris Jerdonek]

Chris Jerdonek  added the comment:

> Preventing creation of the loop will fix all other code that iterate the 
> __context__ chain.

We can still do / discuss that following Irit's proposed change, which is an 
improvement, IMO.

--

___
Python tracker 

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

[issue44866] Inconsistent Behavior of int()

[Dennis Sweeney]

Dennis Sweeney  added the comment:

You typed `int_y = int(2.8)`, so you passed the floating point number 2.8, 
which the int() function rounds down to 2.

On the other hand when y had the string value '2.8'. The int(y) call tried to 
parse an integer out of the string, but failed since there were numbers after 
the decimal point.

Passing a float rounds down:

>>> int(2.8)
2

Passing a string with numbers after the decimal raises ValueError:

>>> int('2.8')
ValueError: invalid literal for int() with base 10: '2.8'

Passing a string of digits without a decimal correctly parses an integer:

>>> int('42')
42

Note that the input() function always returns a string, so input() can return 
'2.8', but not 2.8.

--
nosy: +Dennis Sweeney

___
Python tracker 

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

[issue25782] CPython hangs on error __context__ set to the error itself

[Irit Katriel]

Irit Katriel  added the comment:

> My argument is the loop creation should be prevented at first place.

I agree, but avoiding the hang is higher priority.

> Preventing creation of the loop will fix all other code that iterate the 
> __context__ chain.

There could still be a cycles involving both __context__ and __cause__ links. 
This is why the traceback code uses a visited set to detect cycles.

--

___
Python tracker 

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

[issue25782] CPython hangs on error __context__ set to the error itself

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

My argument is the loop creation should be prevented at first place. 
PyErr_SetObject() is not the only C code that can hang or overflow the stack 
when iterate a loop. Preventing creation of the loop will fix all other code 
that iterate the __context__ chain.

--

___
Python tracker 

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

[issue42053] fwalk: incorrect boolean test for non-fd arguments

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.11 -Python 3.9

___
Python tracker 

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

[issue42053] fwalk: incorrect boolean test for non-fd arguments

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset 2b496e79293a8b80e8ba0e514e186b3b1467b64b by Serhiy Storchaka in 
branch 'main':
bpo-42053: Remove misleading check in os.fwalk() (GH-27669)
https://github.com/python/cpython/commit/2b496e79293a8b80e8ba0e514e186b3b1467b64b


--

___
Python tracker 

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

[issue44866] Inconsistent Behavior of int()

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Following your long example, it seems to me that all works as you expected. 
Raise an exception if you expect exception, and does raise it if you expect no 
exception.

I may miss something, what exactly does not work as you expected?

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue44866] Inconsistent Behavior of int()

[John Joseph Morelli]

New submission from John Joseph Morelli :

I first noticed this and reported it on the W3 Schools Tutorial, the section 
entitled "Add Two Numbers with User Input"

There were many behaviors that I did not understand, but for this bug report, I 
will state that the input statements present seem to return a string and under 
most situations will return an error if the user inputs a real number like 2.8. 
 However, under a very specific situation, it will truncate 2.8 to 2 without 
error.  

After further investigation, I believe the following session in the IDLE's 
output window  and editor illustrates this inconsistent behavior.  Note that I 
have added comments after copying the session here...

>>> print(x)  #want to ensure new session has x as undefined
Traceback (most recent call last):
  File "", line 1, in 
print(x)
NameError: name 'x' is not defined  # confirmed x is undefined
>>> x="2" # define x as the string "2"
>>> print(x)
2
>>> print(type(x)) # confirm that x is a string value of "2" 

>>> y=int(x) # convert string value of "2" to integer of 2  -
# according to documentation this should work - see "If x is not a 
# number or if base is given, then x must be a string, bytes, or
# bytearray instance representing an integer literal in radix base."
# at link --> https://docs.python.org/3.9/library/functions.html#int
>>> print(type(y)) # ensure y is type int

>>> print(y)
2
>>> z=x+".8" # create z to be the concatenation of two strings "2" and ".8" = 
>>> "2.8", a string representation of the real number 2.8
>>> print(z)
2.8
>>> print(type(z)) # ensure z is a string

>>> aa=int(z) # convert z to an integer (as descried in the link
# above, this should NOT work
Traceback (most recent call last):
  File "", line 1, in 
aa=int(z)
ValueError: invalid literal for int() with base 10: '2.8'
>>> w="2.8" # Define w directly as the string value of 2.8 = "2.8"
>>> bb=int(w) # This should also produce an error
Traceback (most recent call last):
  File "", line 1, in 
bb=int(w)
ValueError: invalid literal for int() with base 10: '2.8'
>>> a='2.8'
>>> b=int(a)
Traceback (most recent call last):
  File "", line 1, in 
b=int(a)
ValueError: invalid literal for int() with base 10: '2.8'
>>> print(type(a)) # Ensure a is a string

>>> w="2"
>>> bb=int(w)
>>> print(bb)
2

>>> print(type(bb))

>>> test=int(input("What is test value? ")) #lets try inputting a
# real number but as an argument to int and assigning it to test
What is test value? 2.8 # this should not work either
Traceback (most recent call last):
  File "", line 1, in 
test=int(input("What is test value? "))
ValueError: invalid literal for int() with base 10: '2.8'
>>> # So everything here is working as expected, but...

Here is code from the IDLE editor... a file called testinput1.py

x = int(1)
y = input("Type a number: ")
print(type(y))
int_y = int(2.8) #conver y to an integer 2 and assign to int_y
z = int("3")
print(x)
print(y)
print(int_y)
print(z)

# I can find no documentation to suggest this should work, but it does.  Here 
is the output in IDLE's shell

Type a number: 2.8

1
2.8
2
3

Now, if I immediately go into the shell while the variables remain untouched 
and defined...

>>> a=int(y) # Correctly, this produces the expected error
Traceback (most recent call last):
  File "", line 1, in 
a=int(y)
ValueError: invalid literal for int() with base 10: '2.8'

After extensive testing, I conclude that after input, you may immediately apply 
the int() function to the resulting string, but you quickly lose that ability, 
resulting in the expected error.  I can find no documentation to explain this 
behavior.  

If I am not overlooking something, I think this should either be in the 
documentation of the function int(), if it is intended to behaviour this way, 
or as a bug, should be corrected.

NOTE, I just started learning Pytyon this weekend, so I may be just ignorant of 
the behavior, but I have searched a good bit and found nothing suggesting this 
is how int() should behalf.  I have also not studied the other constructor 
functions.

--
assignee: docs@python
components: Build, Documentation, IDLE, Library (Lib), Windows
files: function_int_08Aug21.txt
messages: 399224
nosy: TheDoctor165, docs@python, paul.moore, steve.dower, terry.reedy, 
tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Inconsistent Behavior of int()
type: behavior
versions: Python 3.9
Added file: https://bugs.python.org/file50205/function_int_08Aug21.txt

___
Python tracker 

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

[issue42053] fwalk: incorrect boolean test for non-fd arguments

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
pull_requests: +26158
pull_request: https://github.com/python/cpython/pull/27669

___
Python tracker 

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

[issue42053] fwalk: incorrect boolean test for non-fd arguments

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

I confirm that fwalk() does not support integer first argument. This check is 
misleading.

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue44830] Broken Mozilla devguide link in "Dealing with Bugs" doc section

[Jack DeVries]

Jack DeVries  added the comment:

I'm pretty much a novice, Senthil, so I don't know how much a review from me is 
worth but removing the broken link seems best!

--

___
Python tracker 

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

[issue40696] Exception handling with "await" can hang in Python3.9.0b1

[Chris Jerdonek]

Chris Jerdonek  added the comment:

Okay, I'll close the issue and update it to reflect that it was restricted to 
the narrower, originally reported issue.

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
title: exception chain cycles cause hangs  (was "Exception handling with 
"await" can hang in Python3.9.0b1") -> Exception handling with "await" can hang 
in Python3.9.0b1

___
Python tracker 

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

[issue25782] CPython hangs on error __context__ set to the error itself

[Chris Jerdonek]

Chris Jerdonek  added the comment:

> No, I meant C -> A -> B -> C -> A 

Oh, good. I support your reasoning and approach, by the way.

--

___
Python tracker 

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

[issue25782] CPython hangs on error __context__ set to the error itself

[Irit Katriel]

Irit Katriel  added the comment:

> > the result is  C -> A -> B -> C

> Did you mean C -> A -> B?

No, I meant C -> A -> B -> C -> A 
the cycle remains unchanged.

> By the way, if you applied to this example your reasoning that  
> PyErr_SetObject shouldn't try to fix user bugs, should this example  instead 
> be C -> A -> B -> C -> ... (leaving the cycle as is but just not hanging)? 

Yes, exactly, see above.

> Is it not being changed then because the reasoning doesn't apply, or because 
> we're restricted in what we can do by backwards compatibility?

The reason for leaving the cycle unchanged is not backwards compatibility, it's 
that this function cannot break the cycle in a meaningful way (this is why it's 
hard to agree on how it should do that).

It can't be that A happened in the context of B at the same time that B 
happened in the context of A. So a cycle means there was a bug somewhere, and 
the exception's history is corrupt, so changing it will only make it more 
corrupt and harder to debug.

Note that PyErr_SetObject avoids creating cycles, so the cycle was not created 
by someone catching an exception e and doing "raise e". It was caused by some 
other code tampering with the __context__ in an incorrect way.

--

___
Python tracker 

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

[issue25782] CPython hangs on error __context__ set to the error itself

[Chris Jerdonek]

Chris Jerdonek  added the comment:

> the result is  C -> A -> B -> C

Did you mean C -> A -> B?

By the way, if you applied to this example your reasoning that PyErr_SetObject 
shouldn't try to fix user bugs, should this example instead be C -> A -> B -> C 
-> ... (leaving the cycle as is but just not hanging)? Is it not being changed 
then because the reasoning doesn't apply, or because we're restricted in what 
we can do by backwards compatibility?

--

___
Python tracker 

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

[issue44830] Broken Mozilla devguide link in "Dealing with Bugs" doc section

[Senthil Kumaran]

Senthil Kumaran  added the comment:

@Jack, if you review this backport - 
https://github.com/python/cpython/pull/27666 , I can merge this PR.

--

___
Python tracker 

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

[issue44865] [argparse] Missing translations

[Jérémie Detrey]

Change by Jérémie Detrey :


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

___
Python tracker 

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

[issue33775] argparse: the word 'default' (in help) is not marked as translatable

[Jérémie Detrey]

Change by Jérémie Detrey :


--
versions: +Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.9

___
Python tracker 

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

[issue44865] [argparse] Missing translations

[Jérémie Detrey]

New submission from Jérémie Detrey :

Dear all,

There are a few strings in the `argparse` module which are not translatable 
through the `gettext` API.

Some have already been reported:
- the "--version" help text at 3.9/Lib/argparse.py:1105 (reported in issue 
16786, fixed by PR 12711);
- the "default" help text at 3.9/Lib/argparse.py:697 (reported in 33775, fixed 
by PR 12711).

However, some others remain:
- the "default" help text for `BooleanOptionalAction` at 
3.9/Lib/argparse.py:878 (which, incidentally, will be duplicated when used with 
`ArgumentDefaultsHelpFormatter`);
- the "argument %(argument_name)s: %(message)s" error message at 
3.9/Lib/argparse.py:751;
- the formatted section heading at 3.9/Lib/argparse.py:225: if the heading 
itself is translatable, the string "%(heading)s:" is not. More precisely, the 
colon right after the heading might also require localization, as some 
languages (e.g., French) typeset colons with a preceding non-breaking space 
(i.e., "%(heading)s :"). (Okay, I'll admit that this is nitpicking!)

I'll submit a pull request with proposed fixes for these strings.

Kind regards,
Jérémie.

--
components: Library (Lib)
messages: 399216
nosy: jdetrey
priority: normal
severity: normal
status: open
title: [argparse] Missing translations
type: behavior
versions: Python 3.10, Python 3.11, Python 3.6, Python 3.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

[issue44830] Broken Mozilla devguide link in "Dealing with Bugs" doc section

[Jack DeVries]

Jack DeVries  added the comment:

@mark.dickinson, Steven D'Aprano suggested just linking to the wayback machine 
on discuss.python.org. What do you think of that?

https://discuss.python.org/t/alternate-article-for-how-to-wite-good-bug-report/10040/2?u=jdevries3133

--

___
Python tracker 

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

[issue16786] argparse doesn't offer localization interface for "version" action

[Jérémie Detrey]

Change by Jérémie Detrey :


--
versions: +Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 
3.9 -Python 2.7, Python 3.4, Python 3.5

___
Python tracker 

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

[issue16786] argparse doesn't offer localization interface for "version" action

[Jérémie Detrey]

Jérémie Detrey  added the comment:

Dear all,

As commented on PR 12711 
(https://github.com/python/cpython/pull/12711#pullrequestreview-724899323), 
there is a slight issue with the proposed patch, as it translates the 
`--version` help string as soon as the `argparse` module is imported (at which 
point the programmer might not have correctly initialized the `gettext` global 
domain yet). The suggested modification of PR 12711 should fix this, so that 
the translation only happens when an instance of `_VersionAction` is actually 
created:
```
diff a/Lib/argparse.py b/Lib/argparse.py
--- a/Lib/argparse.py
+++ b/Lib/argparse.py
@@ -1042,7 +1042,9 @@ def __init__(self,
  version=None,
  dest=SUPPRESS,
  default=SUPPRESS,
- help="show program's version number and exit"):
+ help=None):
+if help is None:
+help = _("show program's version number and exit")
 super(_VersionAction, self).__init__(
 option_strings=option_strings,
 dest=dest,
```

However, I'm not sure I understand correctly Pavel's comment as to why merging 
this patch would make some old programs lose their translation for this string: 
since `argparse` does not itself provide any translation, it is up to the 
programmers to provide `gettext` translations for `argparse` strings as well. 
Adding the call to `_()` here seems harmless to me:
- if a program already has a `gettext` translation string for "show program's 
version number and exit", it will be used, as expected;
- otherwise, if it hasn't (and relies on other mechanisms to translate this 
string), the string will remain untranslated, and the "custom" translation 
mechanisms will be able to process it as before.

In any case, my guess is that localized programs already explicitly pass a 
localized help string to the `_VersionAction` constructor in order to 
circumvent the nonlocalized default help string:
```
parser.add_argument('-V', action='version', version='%(prog)s 3.9',
help=_("show program's version number and exit"))
```
These programs should also remain completely unaffected by this change.

Thanks!

Kind regards,
Jérémie.

--
nosy: +jdetrey

___
Python tracker 

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

[issue41556] hostname verification fails if hostname starts with literal IPv4

[Amir Mohamadi]

Amir Mohamadi  added the comment:

Seems to be solved by https://github.com/openssl/openssl/pull/16201.
I guess we can close this issue.

--
nosy: +Amir

___
Python tracker 

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

[issue43994] change representation of match as / capture as `Name(..., ctx=Store())`

[Marc Mueller]

Change by Marc Mueller :


--
nosy: +cdce8p

___
Python tracker 

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

[issue43532] Add keyword-only fields to dataclasses

[Marc Mueller]

Change by Marc Mueller :


--
nosy: +cdce8p

___
Python tracker 

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

[issue44864] [argparse] Do not translate user-provided strings in `ArgumentParser.add_subparsers()`

[Roundup Robot]

Change by Roundup Robot :


--
keywords: +patch
nosy: +python-dev
nosy_count: 1.0 -> 2.0
pull_requests: +26156
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/27667

___
Python tracker 

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

[issue44864] [argparse] Do not translate user-provided strings in `ArgumentParser.add_subparsers()`

[Jérémie Detrey]

New submission from Jérémie Detrey :

Dear all,

In the `argparse` module, the `ArgumentParser.add_subparsers()` method may call 
the `_()` translation function on user-provided strings. See e.g. 
3.9/Lib/argparse.py:1776 and 3.9/Lib/argparse.py:L1777:

def add_subparsers(self, **kwargs):
# [...]
if 'title' in kwargs or 'description' in kwargs:
title = _(kwargs.pop('title', 'subcommands'))
description = _(kwargs.pop('description', None))

When elements `'title'` and/or `'description'` are set in `kwargs`, they will 
be popped from the dictionary and then fed to `_()`. However, these are 
user-provided strings, and it seems to me that translating them should be the 
user's responsibility. This seems to be the expected behavior for all other 
user-provided strings in the `argparse` module: see e.g. the `ArgumentParser`'s 
`description` parameter (in 3.9/Lib/argparse.py:1704 then 
3.9/Lib/argparse.py:1312), which never gets translated by the `argparse` module.

However, the default title string `'subcommands'` should still be localized. 
Therefore, I'd suggest restricting the call to `_()` to this string only, as in 
the following:

title = kwargs.pop('title', _('subcommands'))
description = kwargs.pop('description', None)

I'll submit a pull request with this change.

Kind regards,
Jérémie.

--
components: Library (Lib)
messages: 399212
nosy: jdetrey
priority: normal
severity: normal
status: open
title: [argparse] Do not translate user-provided strings in 
`ArgumentParser.add_subparsers()`
type: behavior
versions: Python 3.10, Python 3.11, Python 3.6, Python 3.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