[issue39456] Make IDLE calltip tests work when there are no docstrings

[Terry J. Reedy]

New submission from Terry J. Reedy :

IDLE should run and calltips and tests should work even callables lack 
docstrings, either because none is defined or because there are suppressed 
(CPython compile switch for builtins, CPython runtime switch for user objects). 
 I believe calltips work with or without docstrings present, but:

One User class test is skipped with -OO.  It should be changed to still work.

Multiple builtin tests fail.  #37501 proposes to skip them when compiled 
without docstrings.  The right long-term solution for IDLE is to change the 
tests.  My idea is to expand tiptest with 'out' replaced by the signature part, 
the processed docstring part, and the docstring object.  I want to try 
something like 

def tiptest(obj, docobj, sig, doc):
out = sig += doc if docobj.__doc__ is not None else ''
self.assertEqual(get_spec(obj), out)

--
assignee: terry.reedy
components: IDLE
messages: 360722
nosy: terry.reedy
priority: normal
severity: normal
stage: test needed
status: open
title: Make IDLE calltip tests work when there are no docstrings
type: behavior
versions: 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

[issue39456] Make IDLE calltip tests work when there are no docstrings

[Terry J. Reedy]

Terry J. Reedy  added the comment:

In a comment on PR-14592, I noted that other tests fail with -OO; these should 
be fixed (or skipped?) also.  test_calltips was the only failure with the 
compile switch.

--

___
Python tracker 

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

[issue39456] Make IDLE calltip tests work when there are no docstrings

[Terry J. Reedy]

Terry J. Reedy  added the comment:

If test_calltips is fixed before PR-14592 is merged, it should be removed from 
the latter.

--

___
Python tracker 

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

[issue32309] Implement asyncio.run_in_executor shortcut

[Kyle Stanley]

Kyle Stanley  added the comment:

> So, I just had an interesting idea... what if ThreadPool.run() returned a 
> Task instead of a coroutine object?

After having some time to think this over, I prefer the current behavior. I 
don't think there would be significant enough improvement from returning a Task 
instead, and it would likely result in an overall performance loss.

Also, as a general update on the project, I'm close to being ready to open a PR 
to implement asyncio.ThreadPool. I finished the basic implementation and added 
a decent number of new tests to ensure its functionality. Here's my current 
progress: 
https://github.com/python/cpython/compare/master...aeros:asyncio-threadpool

I just need to work on adding the new documentation, and more specifically 
finding a good place for it in the current asyncio docs. Do you have any ideas 
for that, Yury? I figured that you might already have a preference in mind.

--

___
Python tracker 

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

[issue39418] str.strip() should have a means of adding to the default behaviour

[Raymond Hettinger]

Raymond Hettinger  added the comment:

For this problem, I would reach for regular expressions.  They are specifically 
designed for flexibility and customization.

--
nosy: +rhettinger

___
Python tracker 

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

[issue39082] AsyncMock is unable to correctly patch static or class methods

[Chris Withers]

Chris Withers  added the comment:


New changeset 19be85c76503535c101b38194d282187de0ff631 by Chris Withers 
(Matthew Kokotovich) in branch '3.8':
[3.8] bpo-39082: Allow AsyncMock to correctly patch static/class methods 
(GH-18190)
https://github.com/python/cpython/commit/19be85c76503535c101b38194d282187de0ff631


--

___
Python tracker 

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

[issue39309] Please delete my account

[Ernest W. Durbin III]

Ernest W. Durbin III  added the comment:

The account has been marked as "retired".

>From roundup docs:

  Items in the database are never deleted, they’re just “retired”. You can 
still refer to them by ID - hence removing an item won’t break references to 
the item. It’s just that the item won’t appear in any listings.

I'm not sure what further action can be taken.

--
nosy:  -sfjwlejfawnf

___
Python tracker 

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

[issue10740] sqlite3 module breaks transactions and potentially corrupts data

[Géry]

Géry  added the comment:

@Aymeric Augustin

> While you're there, it would be cool to provide "connection.autocommit = 
> True" as an API to enable autocommit, because "connection.isolation_level = 
> None" isn't a good API at all -- it's very obscure and has nothing to do with 
> isolation level whatsoever.

+1. We could use this new autocommit property to enable the new full 
transactional mode (that is to say with transactional DDL):

```
connection.autocommit = True  # enable the autocommit mode
connection.autocommit = False  # disable the autocommit mode (enable the full 
transactional mode)
connection.autocommit = None  # fallback to connection.isolation_level
```

To transition from the old partial transactional mode (without transactional 
DDL) by default to the new full transactional mode (with transactional DDL) by 
default, we could use the following migration strategy:

1. During the deprecation period:

- Add the new autocommit property with the value None by default, so that the 
old partial transactional mode is still the default.
- Add a deprecation warning for the value None of the autocommit property, in 
favor of the other values True and False. It will prompt users who enabled the 
autocommit mode with connection.isolation_level = None to use 
connection.autocommit = True instead, and users who disabled the autocommit 
mode (that is to say users who enabled the old partial transactional mode) with 
connection.isolation_level = DEFERRED/IMMEDIATE/EXCLUSIVE to use 
connection.autocommit = False instead AND add to their code the potentially 
missing connection.commit() calls required by the new full transactional mode 
for committing DDL statements.

2. After the deprecation period:

- Set the value of the autocommit property to False by default, so that the new 
full transactional mode becomes the new default.
- Remove the value None of the autocommit property and its deprecation warning.
- Remove the value None of the isolation_level property, so that the old 
partial transactional mode disappears.

--

___
Python tracker 

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

[issue39451] enum.Enum reference count leaks

[Dan Gass]

Dan Gass  added the comment:

Sorry for not thinking of trying this sooner. Running garbage collection, 
import gc; gc.collect(), releases the resources and restores the expected 
reference counts.

>From my perspective, this is satisfactory and could justify closing this bug 
>report. 

The exception logic in Enum.__new__ could potentially be cleaned up for this 
use case, just not sure if that would introduce risk for other use cases. 

I am guessing (from the perspective of the larger Python exception handling 
design and implementation) what this bug report demonstrates had been 
previously thought through.

--

___
Python tracker 

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

[issue39309] Please delete my account

[Berker Peksag]

Change by Berker Peksag :


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

[issue38971] codecs.open leaks file descriptor when invalid encoding is passed

[Chris Aporta]

Chris Aporta  added the comment:

Just quickly pinging the thread as a friendly reminder that PR 17666 is open 
and potentially close to mergeable, as it's been through two review cycles 
already (thanks Serhiy). If someone has the bandwidth to take another look, it 
would be greatly appreciated. Thanks!

--
nosy: +caporta

___
Python tracker 

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

[issue39457] Add an autocommit property to sqlite3.Connection with truly PEP 249 compliant manual commit mode and migrate

[Géry]

New submission from Géry :

In non-autocommit mode (manual commit mode), the sqlite3 database driver 
implicitly issues a BEGIN statement before each DML statement (INSERT, UPDATE, 
DELETE, REPLACE) not already in a database transaction, BUT NOT before DDL 
statements (CREATE, DROP) nor before DQL statements (SELECT) (cf. 
https://github.com/python/cpython/blob/master/Modules/_sqlite/cursor.c#L480):

```
/* We start a transaction implicitly before a DML statement.
   SELECT is the only exception. See #9924. */
if (self->connection->begin_statement && self->statement->is_dml) {
if (sqlite3_get_autocommit(self->connection->db)) {
result = _pysqlite_connection_begin(self->connection);
if (!result) {
goto error;
}
Py_DECREF(result);
}
}
```

Like Mike Bayer explained in issue #9924, this is not what other database 
drivers do, and this is not PEP 249 compliant (Python Database API 
Specification v2.0), as its author Marc-André Lemburg explained (cf. 
https://mail.python.org/pipermail/db-sig/2010-September/005645.html):

> Randall Nortman wrote:
> # PEP 249 says that transactions end on commit() or rollback(), but it
> # doesn't explicitly state when transactions should begin, and there is
> # no begin() method. 
>
> Transactions start implicitly after you connect and after you call
.commit() or .rollback(). They are not started for each statement.
>
> # I think the implication is that transactions begin
> # on the first execute(), but that's not explicitly stated.  At least
> # one driver, pysqlite2/sqlite3, does not start a transaction for a
> # SELECT statement.  It waits for a DML statement (INSERT, UPDATE,
> # DELETE) before opening a transaction.  Other drivers open transactions
> # on any statement, including SELECT.
> #
> # My question for the DB-SIG is: Can I call it a bug in pysqlite2 that
> # it does not open transactions on SELECT?  Should the spec be amended
> # to make this explicit?  Or are both behaviors acceptable, in which
> # case perhaps a begin() method needs to be added for when the user
> # wants control over opening transactions?
>
> I should probably add a note to PEP 249 about this.

Aymeric Augustin said in issue #10740:

> While you're there, it would be cool to provide "connection.autocommit = 
> True" as an API to enable autocommit, because "connection.isolation_level = 
> None" isn't a good API at all -- it's very obscure and has nothing to do with 
> isolation level whatsoever.

So I suggest that we introduce a new autocommit property and use it to enable a 
truly PEP 249 compliant manual commit mode (that is to say with transactions 
starting implicitly after connect(), commit() and rollback() calls, allowing 
transactional DDL and DQL):

```
autocommit = True  # enable the autocommit mode
autocommit = False  # disable the autocommit mode (enable the new PEP 249 
manual commit mode)
autocommit = None  # fallback to the commit mode set by isolation_level
```

I also suggest that we use this new PEP 249 manual commit mode (with 
transactional DDL and DQL) by default and drop the old manual commit mode 
(without transactional DDL and DQL). We could use the following migration 
strategy:

1. During the deprecation period:

- Add the new autocommit property with the value None by default, so that the 
old manual commit mode is still the default.
- Add a deprecation warning for the value None of the autocommit property, in 
favor of the other values True and False. It will prompt users who enabled the 
autocommit mode with isolation_level = None to use autocommit = True instead, 
and users who disabled the autocommit mode (that is to say users who enabled 
the old manual commit mode) with isolation_level = DEFERRED/IMMEDIATE/EXCLUSIVE 
to use autocommit = False instead AND add to their code the potentially missing 
commit() calls required by the new PEP 249 manual commit mode.

2. After the deprecation period:

- Set the value of the autocommit property to False by default, so that the new 
PEP 249 manual commit mode becomes the new default.
- Remove the value None of the autocommit property and its deprecation warning.
- Remove the value None of the isolation_level property, so that the old manual 
commit mode disappears.

--
components: Library (Lib)
messages: 360732
nosy: ghaering, lemburg, maggyero, r.david.murray, zzzeek
priority: normal
severity: normal
status: open
title: Add an autocommit property to sqlite3.Connection with truly PEP 249 
compliant manual commit mode and migrate
type: enhancement
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

[issue39457] Add an autocommit property to sqlite3.Connection with a PEP 249 compliant manual commit mode and migrate

[Géry]

Change by Géry :


--
title: Add an autocommit property to sqlite3.Connection with truly PEP 249 
compliant manual commit mode and migrate -> Add an autocommit property to 
sqlite3.Connection with a PEP 249 compliant manual commit mode and migrate

___
Python tracker 

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

[issue10740] sqlite3 module breaks transactions and potentially corrupts data

[Géry]

Géry  added the comment:

@R. David Murray

> Please open a new issue for this request.

Done here: https://bugs.python.org/issue39457

--

___
Python tracker 

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

[issue39457] Add an autocommit property to sqlite3.Connection with a PEP 249 compliant manual commit mode and migrate

[Géry]

Géry  added the comment:

> - Remove the value None of the isolation_level property, so that the old 
> manual commit mode disappears.

Correction:

- Remove the value None of the isolation_level property.

--

___
Python tracker 

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

[issue39457] Add an autocommit property to sqlite3.Connection with a PEP 249 compliant manual commit mode and migrate

[SilentGhost]

Change by SilentGhost :


--
versions: +Python 3.9 -Python 3.8

___
Python tracker 

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

[issue39457] Add an autocommit property to sqlite3.Connection with a PEP 249 compliant manual commit mode and migrate

[Géry]

Géry  added the comment:

> - Remove the value None of the autocommit property and its deprecation 
> warning.

Correction:

- Remove the value None of the autocommit property and its deprecation warning, 
so that the old manual commit mode disappears.

--

___
Python tracker 

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

[issue39458] Multiprocessing.Pool maxtasksperchild=1 doesn't work

[Gabriel Tardif]

New submission from Gabriel Tardif :

Hello

This bug is about the maxtasksperchild parameter in the Pool object constructor 
of the multiprocessing module.

When you set processes = 1 in the Pool constructor
maxtasksperchild value is double by two for unknow raison whatever the 
maxtaskperchild value.

As mentionned in the documentation, once the process has reach the 
maxtasksperchil value it should rebuild itself in the memory from the parent 
process.

In the short python exemple provided below, you can see the value of 
showedFiles of each process incresing over 1 which is not normal if Pool 
constructor is set to processes = 1, maxtasksperchil = 1.

The only running process should destroy / reset itself and so set its value 
'showedFiles' to 0 first and 1 for each os.listdir() entry.

--
assignee: docs@python
components: Documentation
files: reader.py
messages: 360736
nosy: Gabriel Tardif, docs@python
priority: normal
severity: normal
status: open
title: Multiprocessing.Pool maxtasksperchild=1 doesn't work
type: behavior
versions: Python 3.6
Added file: https://bugs.python.org/file48864/reader.py

___
Python tracker 

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

[issue38599] Deprecate creation of asyncio object when the loop is not running

[Emmanuel Arias]

Change by Emmanuel Arias :


--
pull_requests: +17576
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18195

___
Python tracker 

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

[issue37625] Class variable is still accessible after class instance has been overwritten out

[chris]

chris  added the comment:

Great content and outstanding, How can I start getting your https://logingit.com/www-txsurchargeonline-com-login-tx-surcharge-pay/";>newsletters
 in my email to enable keep track of your future content? Thank for this great 
piece.

--
nosy: +Nadas

___
Python tracker 

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

[issue37625] Class variable is still accessible after class instance has been overwritten out

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
Removed message: https://bugs.python.org/msg360737

___
Python tracker 

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

[issue39380] ftplib uses latin-1 as default encoding

[Inada Naoki]

Inada Naoki  added the comment:

I'm not FTP user so I don't have strong opinion.
If it is too late to change already, change it in 3.9 might be OK.

> However, shouldn't it be a FutureWarning, so it will be reported by default 
> at initialisation?

If it is warning for end users, it should be FutureWarning.
If the warning is for developers, it should be DeprecationWarning.
Warning for API changes is DeprecationWarning in general.

--

___
Python tracker 

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

[issue25597] unittest.mock does not wrap dunder methods (__getitem__ etc)

[Chris Withers]

Chris Withers  added the comment:


New changeset 72b1004657e60c900e4cd031b2635b587f4b280e by Chris Withers 
(Karthikeyan Singaravelan) in branch 'master':
bpo-25597: Ensure wraps' return value is used for magic methods in MagicMock 
(#16029)
https://github.com/python/cpython/commit/72b1004657e60c900e4cd031b2635b587f4b280e


--

___
Python tracker 

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

[issue39380] ftplib uses latin-1 as default encoding

[STINNER Victor]

STINNER Victor  added the comment:

I'm in favor of changing the default encoding to UTF-8, but it requires good 
documentation, especially to provide a solution working on Python 3.8 and 3.9 
to change the encoding (see below).

--

The encoding is used to encode commands with the FTP server and decode the 
server replies. I expect that most replies are basically letters, digits and 
spaces. I guess that the most problematic commands are:

* send user and password
* decode filenames of LIST command reply
* encode filename in STOR command

I expect that the original FTP protocol doesn't specify any encoding and so 
that FTP server implementations took some freedom. I would not be surprised to 
use ANSI code pages used on servers running on Windows.

Currently, encoding is a class attribute: it's not convenient to override it 
depending on the host. I would prefer to have a new parameter for the 
constructor.

Giampaolo:
> some servers may enable UTF-8 only if client explicitly sends "OPTS UTF-8 ON" 
> first, but that is based on an draft RFC. Server implementors usually treat 
> this command as a no-op and simply assume UTF-8 as the default.
> With that said, I am -1 about implementing logic based on FEAT/OPTS: that 
> should be done before login, and at that point some servers may erroneously 
> reject any command other than USER, PASS and ACCT. 

Oh. In this case, always send "OPTS UTF-8 ON" just after the socket is 
connected sounds like a bad idea.


Sebastian:
> Since RFC 2640, the industry standard within FTP Clients is UTF-8 (see e.g. 
> FileZilla here: https://wiki.filezilla-project.org/Character_Encoding, or 
> WinSCP here: https://winscp.net/eng/docs/faq_utf8).

"Internationalization of the File Transfer Protocol" was published in 1999. It 
recommends the UTF-8. Following a RFC recommendation is good argument to change 
the default encoding to UTF-8.
https://tools.ietf.org/html/rfc2640


Giampaolo:
> Personally I think it makes more sense to just use UTF-8 without going 
> through a deprecation period

I concur. Deprecation is usually used for features which are going to be 
removed (module, function or function parameter). Here it's just about a 
default parameter value. I expect to have encoding="utf-8" default in the 
constructor.

The annoying part is that Python 3.8 only has a class attribute. The simplest 
option seems to be creating a FTP object, modify its encoding attribute and 
*then* logs in. Another options is to subclass the FTP class. IMO the worst is 
to modify ftplib.FTP.encoding attribute (monkey patch the module).

I expect that most users use username, password and filenames encodable to 
ASCII and so will not notify the change to UTF-8. We can document a solution 
working on all Python versions to use different encoding name.

--
nosy: +vstinner

___
Python tracker 

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