[issue44820] subprocess hungs when processing value from mariadb

[jb]

New submission from jb :

I am doing an insert in mariadb databases. For example, INSERT INTO t (a, b, c) 
VALUES (1, 3, None) RETURNING a, b. Upon execution, I get the value as (, 
). When accessing the zero element, my subroutine hangs.

--
components: Interpreter Core
messages: 398862
nosy: zh.bolatbek
priority: normal
severity: normal
status: open
title: subprocess hungs when processing  value from mariadb
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

[issue43468] functools.cached_property incorrectly locks the entire descriptor on class instead of per-instance locking

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Here's the latest effort:

---

def __get__(self, instance, owner=None):
if instance is None:
return self
if self.attrname is None:
raise TypeError(
"Cannot use cached_property instance without calling 
__set_name__ on it.")
try:
cache = instance.__dict__
except AttributeError:  # not all objects have __dict__ (e.g. class 
defines slots)
msg = (
f"No '__dict__' attribute on {type(instance).__name__!r} "
f"instance to cache {self.attrname!r} property."
)
raise TypeError(msg) from None

# Quickly and atomically determine which thread is reponsible
# for doing the update, so other threads can wait for that
# update to complete.  If the update is already done, don't
# wait.  If the updating thread is reentrant, don't wait.
key = id(self)
this_thread = get_ident()
with self.updater_lock:
val = cache.get(self.attrname, _NOT_FOUND)
if val is not _NOT_FOUND:
return val
wait = self.updater.setdefault(key, this_thread) != this_thread

# ONLY if this instance currently being updated, block and wait
# for the computed result. Other instances won't have to wait.
# If an exception occurred, stop waiting.
if wait:
with self.cv:
while cache.get(self.attrname, _NOT_FOUND) is _NOT_FOUND:
self.cv.wait()
val = cache[self.attrname]
if val is not _EXCEPTION_RAISED:
return val

# Call the underlying function to compute the value.
try:
val = self.func(instance)
except Exception:
val = _EXCEPTION_RAISED

# Attempt to store the value
try:
cache[self.attrname] = val
except TypeError:
# Note: we have no way to communicate this exception to
# threads waiting on the condition variable.  However, the
# inability to store an attribute is a programming problem
# rather than a runtime problem -- this exception would
# likely occur early in testing rather than being runtime
# event triggered by specific data.
msg = (
f"The '__dict__' attribute on {type(instance).__name__!r} 
instance "
f"does not support item assignment for caching 
{self.attrname!r} property."
)
raise TypeError(msg) from None

# Now that the value is stored, threads waiting on the condition
# variable can be awakened and the updater dictionary can be
# cleaned up.
with self.updater_lock:
self.updater.pop(key, None)
cache[self.attrname] = _EXCEPTION_RAISED
self.cv.notify_all()

if val is _EXCEPTION_RAISED:
raise
return val

--

___
Python tracker 

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

[issue44819] assertSequenceEqual does not use _getAssertEqualityFunc

[Jack DeVries]

Jack DeVries  added the comment:

Brian, can you be more specific about what problem is caused by the fact that 
assertSequenceEqual does not use _getAssertEqualityFunc? Also, I'm not sure 
what your example is trying to demonstrate. Can you provide a minimal example 
that shows the problem, but also defines what ``MyObject``, etc. are?

Let me know if I'm missing something.

--
nosy: +jack__d

___
Python tracker 

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

[issue44019] operator.call/operator.__call__

[Antony Lee]

Antony Lee  added the comment:

Actually, upon further thought, the semantics I suggested above should go into 
`operator.caller` (cf. `operator.methodcaller`), and 
`operator.call`/`operator.__call__` should instead be defined as 
`operator.call(f, *args, **kwargs) == f(*args, **kwargs)`, so that the general 
rule `operator.opname(a, b) == a.__opname__(b)` (modulo dunder lookup rules) 
remains applicable.

--

___
Python tracker 

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

[issue32397] textwrap output may change if you wrap a paragraph twice

[Andrei Kulakov]

Andrei Kulakov  added the comment:

I've added an initial draft PR: 
https://github.com/python/cpython/pull/27587/files

I will add docs and news if this looks good in general.

--

___
Python tracker 

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

[issue32397] textwrap output may change if you wrap a paragraph twice

[Andrei Kulakov]

Change by Andrei Kulakov :


--
pull_requests: +26089
pull_request: https://github.com/python/cpython/pull/27587

___
Python tracker 

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

Re: Defining a Python enum in a C extension - am I doing this right?

[Sean DiZazzo]

On Tuesday, August 3, 2021 at 3:04:19 AM UTC-7, Bartosz Golaszewski wrote:
> On Sat, Jul 31, 2021 at 3:01 PM Bartosz Golaszewski  wrote: 
> > 
> > On Fri, Jul 30, 2021 at 2:41 PM Serhiy Storchaka  wrote: 
> > > 
> > > 23.07.21 11:20, Bartosz Golaszewski пише: 
> > > > I'm working on a Python C extension and I would like to expose a 
> > > > custom enum (as in: a class inheriting from enum.Enum) that would be 
> > > > entirely defined in C. 
> > > 
> > > I think that it would be much easier to define it in Python, and then 
> > > either import a Python module in your C code, or exec a Python code as a 
> > > string. 
> > > 
> > 
> > You mean: evaluate a string like this: 
> > 
> > ''' 
> > import enum 
> > 
> > class FooBar(enum.Enum): 
> > FOO = 1 
> > BAR = 2 
> > BAZ = 3 
> > ''' 
> > 
> > And then pull in the FooBar type from the resulting dictionary into my 
> > C code? Sounds good actually. I think I'll be able to add the FooBar 
> > type to another type's tp_dict too - because some enums I want to 
> > create will be nested in other classes. 
> > 
> > Bart
> Just a follow-up: this is how I did it eventually: 
> 
> ``` 
> #include  
> 
> typedef struct { 
> PyObject_HEAD; 
> } dummy_object; 
> 
> PyDoc_STRVAR(dummy_type_doc, "Dummy type in which the enum will be nested."); 
> 
> static PyTypeObject dummy_type = { 
> PyVarObject_HEAD_INIT(NULL, 0) 
> .tp_name = "pycenum.DummyType", 
> .tp_basicsize = sizeof(dummy_object), 
> .tp_flags = Py_TPFLAGS_DEFAULT, 
> .tp_doc = dummy_type_doc, 
> .tp_new = PyType_GenericNew, 
> .tp_dealloc = (destructor)PyObject_Del, 
> };
> PyDoc_STRVAR(module_doc, 
> "C extension module defining a class inheriting from enum.Enum."); 
> 
> static PyModuleDef module_def = { 
> PyModuleDef_HEAD_INIT, 
> .m_name = "pycenum", 
> .m_doc = module_doc, 
> .m_size = -1, 
> };
> static int add_foobar_enum(PyObject *module) 
> { 
> static const char *foobar_src = 
> "class FooBar(enum.Enum):\n" 
> " FOO = 1\n" 
> " BAR = 2\n" 
> " BAZ = 3\n"; 
> 
> PyObject *main_mod, *main_dict, *enum_mod, *result, *foobar_type; 
> int ret; 
> 
> main_mod = PyImport_AddModule("__main__"); 
> if (!main_mod) 
> return -1; 
> 
> main_dict = PyModule_GetDict(main_mod); 
> if (!main_dict) { 
> Py_DECREF(main_mod); 
> return -1;
> } 
> 
> enum_mod = PyImport_ImportModule("enum");
> if (!enum_mod) { 
> Py_DECREF(main_mod); 
> return -1; 
> } 
> 
> ret = PyDict_SetItemString(main_dict, "enum", enum_mod); 
> Py_DECREF(enum_mod); 
> if (ret) { 
> Py_DECREF(main_mod); 
> return -1; 
> } 
> 
> result = PyRun_String(foobar_src, Py_single_input, 
> main_dict, main_dict); 
> if (!result) { 
> Py_DECREF(main_mod); 
> return -1; 
> } 
> 
> foobar_type = PyDict_GetItemString(main_dict, "FooBar"); 
> if (!foobar_type) { 
> Py_DECREF(main_mod); 
> return -1; 
> } 
> 
> ret = PyDict_SetItemString(dummy_type.tp_dict, "FooBar", foobar_type); 
> Py_DECREF(foobar_type); 
> Py_DECREF(main_mod); 
> if (ret) 
> return -1; 
> 
> PyType_Modified(_type); 
> 
> return ret; 
> } 
> 
> PyMODINIT_FUNC PyInit_pycenum(void) 
> { 
> PyObject *module;
> int ret; 
> 
> module = PyModule_Create(_def); 
> if (!module) 
> return NULL; 
> 
> ret = PyModule_AddStringConstant(module, "__version__", "0.0.1");
> if (ret) { 
> Py_DECREF(module); 
> return NULL; 
> } 
> 
> ret = PyType_Ready(_type); 
> if (ret) { 
> Py_DECREF(module); 
> return NULL; 
> } 
> 
> ret = add_foobar_enum(module); 
> if (ret) { 
> Py_DECREF(module); 
> return NULL; 
> } 
> 
> Py_INCREF(_type); 
> ret = PyModule_AddObject(module, "DummyType", (PyObject *)_type); 
> if (ret) { 
> Py_DECREF(_type);
> Py_DECREF(module); 
> return NULL; 
> } 
> 
> return module; 
> }
> ``` 
> 
> Bart
No
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: SQLALchemy: update with in clause from kwargs

[dn via Python-list]

On 04/08/2021 13.08, Larry Martell wrote:
> I am trying to write a function that takes kwargs as a param and
> generates an update statement where the rows to be updated are
> specified in an in clause.
> 
> Something like this:
> 
> def update_by_in(self, **kwargs):
> filter_group = []
> for col in kwargs['query_params']:
> # obviously this line does not work as col is a string,
> but this is the intent
> filter_group.append(col.in_(tuple(kwargs['query_params'][col])))
> 
> 
> self._session.query(self.model_class).filter(*filter_group).update(kwargs['values'])
> 
> self.update_by_in(
> **{'query_params': {'companyCode': ['A', 'B', 'C']},
> 'values': {'portfolioName': 'test'}}
>  )
> 
> Is there a way to do this? I think I need to use setattr in building
> up the filter_group list, but I'm not quite sure how to do it.


When feeling bamboozled by a problem, particularly when using
sophisticated tools such as SQLAlchemy, the trick is often to simplify
the problem.

Step 1 (using the sample data provided)
Write the query on paper - and as constant-values.

Step 2
Compare the two input dicts with that requirement.

Step 3
Work-out the transformation(s) required...


One complexity is that the parameter to update_by_in() is formed by
joining two dicts. However, the function later tries to treat them in
distinct fashions. Why the join/why not two parameters?

companyCode = ['A', 'B', 'C']
values = {'portfolioName': 'test'}

leading to:

self.update_by_in( companyCode, values )

and:

def update_by_in(self, company_code, portfolio_type ):



As to the core of the question-asked, I'm a little confused (which may
be my fuzzy head). Do you want the update(s) - portrayed as a list -
like this:

[('A', 'test'), ('B', 'test'), ('C', 'test')]

like this:

[('A', 'portfolioName'), ('B', None), ('C', None)]

or only:

[('A', 'portfolioName')]


You will find a friend in the itertools (PSL) library:

import itertools as it

list( it.product( companyCode, values.values() ) )
[('A', 'test'), ('B', 'test'), ('C', 'test')]

list( it.zip_longest( companyCode, values.values() ) )
[('A', 'test'), ('B', None), ('C', None)]

list( zip( companyCode, values ) )
[('A', 'portfolioName')]


Now, have we simplified things to the point of being able to more-easily
code the update and filter?

PS I fear even that step is/those steps are more complicated than needed
- but you know your data and schema better than I!


Critique:
1 never, never, never(!) use a name which will "shadow" a Python keyword
or frequently-used function-name (in this case "values" ) - if you don't
confuse Python you will confuse simple-boys like me! Plus, when you come
back in six-month's time, does "values" tell you what kind of value it
is/holds?
2 Python != C | Java
Thus: company_code, portfolio_name


Web.Refs:
https://www.dictionary.com/browse/bamboozled
https://docs.python.org/3/library/itertools.html
-- 
Regards,
=dn
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: SQLALchemy: update with in clause from kwargs

[MRAB]

On 2021-08-04 02:08, Larry Martell wrote:

I am trying to write a function that takes kwargs as a param and
generates an update statement where the rows to be updated are
specified in an in clause.

Something like this:

 def update_by_in(self, **kwargs):
 filter_group = []
 for col in kwargs['query_params']:
 # obviously this line does not work as col is a string,
but this is the intent
 filter_group.append(col.in_(tuple(kwargs['query_params'][col])))

 
self._session.query(self.model_class).filter(*filter_group).update(kwargs['values'])

self.update_by_in(
 **{'query_params': {'companyCode': ['A', 'B', 'C']},
 'values': {'portfolioName': 'test'}}
  )

Is there a way to do this? I think I need to use setattr in building
up the filter_group list, but I'm not quite sure how to do it.


If it's any help, on this page:

https://docs.sqlalchemy.org/en/14/core/metadata.html

it has this:

# access the column "employee_id":
employees.columns.employee_id

# or just
employees.c.employee_id

# via string
employees.c['employee_id']
--
https://mail.python.org/mailman/listinfo/python-list

[issue44772] Regression in memory use of instances due to dictionary ordering

[Raymond Hettinger]

Raymond Hettinger  added the comment:

ISTM this was mostly a net win.  We get compactness and sharing most of the 
time, and lose sharing only in cases like this where different instances of the 
same class happen to have different attributes.  Personally, I would not have 
expected sharing to occur in those cases.

--
nosy: +rhettinger

___
Python tracker 

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

SQLALchemy: update with in clause from kwargs

[Larry Martell]

I am trying to write a function that takes kwargs as a param and
generates an update statement where the rows to be updated are
specified in an in clause.

Something like this:

def update_by_in(self, **kwargs):
filter_group = []
for col in kwargs['query_params']:
# obviously this line does not work as col is a string,
but this is the intent
filter_group.append(col.in_(tuple(kwargs['query_params'][col])))


self._session.query(self.model_class).filter(*filter_group).update(kwargs['values'])

self.update_by_in(
**{'query_params': {'companyCode': ['A', 'B', 'C']},
'values': {'portfolioName': 'test'}}
 )

Is there a way to do this? I think I need to use setattr in building
up the filter_group list, but I'm not quite sure how to do it.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue43532] Add keyword-only fields to dataclasses

[jack1142]

jack1142  added the comment:

Does this change deserve an entry in the What's New in Python document in 
addition to the changelog entry?

--

___
Python tracker 

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

Re: argparse: delimiter for argparse list arguments

[Roel Schroeven]

Jon Ribbens via Python-list schreef op 3/08/2021 om 22:55:

>> Loads of git commands do this. e.g. commit, diff, log, status, etc.
>> It's not completely unlike what you're describing above, which is
>> already supported automatically by argparse.
>
> Commands like git commit do not use '--' to separate two lists, but as 
> Dan and Sven said to separate options from arguments,


That is not quite correct. Check out 'git diff' for example - it takes
as position arguments zero, one, or two commit hashes followed by zero
or more pathnames.  You can use '--' to separate these two lists,
because of course sometimes a pathname can be indistinguishable from
a commit hash.
Ah yes, I stand corrected, git diff indeed uses -- to separate two lists 
(commits and paths).


--
"Too often we hold fast to the cliches of our forebears. We subject all
facts to a prefabricated set of interpretations. Too often we enjoy the
comfort of opinion without the discomfort of thought."
-- John F Kennedy

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

[issue42524] [doc] pdb access to return value

[Irit Katriel]

Change by Irit Katriel :


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

___
Python tracker 

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

[issue42524] [doc] pdb access to return value

[Irit Katriel]

Irit Katriel  added the comment:

I just noticed your PR. Would you like to continue working on this?

I think we should update the documentation of retval (in the doc and in the 
function's doctring) to say:

"""
retval
Print the return value for the last return of a function.  Alternatively, the 
return value can be accessed with ``locals()['__return__']``.
"""

Then add unit tests and examples as you did.

--

___
Python tracker 

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

[issue42524] [doc] pdb access to return value

[Irit Katriel]

Irit Katriel  added the comment:

I just noticed your PR. Would you like to continue working on this?

I think we should update the documentation of retval (in the doc and in the 
functions' doctring) to say:

"""
retval
Print the return value for the last return of a function.  Alternatively, the 
return can be accessed with ``locals()['__return__']``.
"""

Then add unit tests and examples as you did.

--
title: pdb access to return value -> [doc] pdb access to return value
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

[issue42524] pdb access to return value

[Irit Katriel]

Irit Katriel  added the comment:

It actually is in the locals, and it's called __return__. So you can access it 
with 

locals()['__return__']

I'll try to see where that can be documented.

--
nosy: +iritkatriel

___
Python tracker 

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

[issue20703] RuntimeError caused by lazy imports in pdb

[Irit Katriel]

Irit Katriel  added the comment:

Closing as this is not a problem with pdb, it's a general problem with 
iterating sys.modules while doing things that can cause imports.

--
resolution:  -> wont fix
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

Re: argparse: delimiter for argparse list arguments

[Jon Ribbens via Python-list]

On 2021-08-03, Roel Schroeven  wrote:
> Jon Ribbens via Python-list schreef op 3/08/2021 om 17:48:
>> On 2021-08-03, Michael Torrie  wrote:
>> > On 8/2/21 1:43 PM, Sven R. Kunze wrote:
>> >> maybe, I am missing something here but is it possible to specify a 
>> >> delimiter for list arguments in argparse:
>> >> 
>> >> https://docs.python.org/3/library/argparse.html
>> >> 
>> >> Usually, '--' is used to separate two lists (cf. git).
>> >
>> > I've not seen this syntax in git. Are you referring the the double and
>> > triple dot notation git uses?  Can you give me an example of how git
>> > uses -- as a list separator?
>>
>> Loads of git commands do this. e.g. commit, diff, log, status, etc.
>> It's not completely unlike what you're describing above, which is
>> already supported automatically by argparse.
>
> Commands like git commit do not use '--' to separate two lists, but as 
> Dan and Sven said to separate options from arguments,

That is not quite correct. Check out 'git diff' for example - it takes
as position arguments zero, one, or two commit hashes followed by zero
or more pathnames.  You can use '--' to separate these two lists,
because of course sometimes a pathname can be indistinguishable from
a commit hash.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: argparse: delimiter for argparse list arguments

[Chris Angelico]

On Wed, Aug 4, 2021 at 7:07 AM Sven R. Kunze  wrote:
>
> It could be but I've seen them used somewhere else.
>
> I wouldn't bikeshed on this yet, as I haven't found a way to do this so
> far. Let's imagine the following parser:
>
> parser.add_argument('things',action='append')
> parser.add_argument('stuff',action='append')
>
> At least from my point of view, I don't any way to separate both lists
> on this command call:
>
>
> cool-script.py thing1 thing2 stuff1 stuff2
>
>
> Do I miss something here?
>

I'd probably design it like this:

cool-script.py --things thing1 thing2 --stuff stuff1 stuff2

which argparse already handles.

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

[issue41737] Improper NotADirectoryError when opening a file in a fake directory

[Łukasz Langa]

Change by Łukasz Langa :


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

Re: argparse: delimiter for argparse list arguments

[Sven R. Kunze]

It could be but I've seen them used somewhere else.

I wouldn't bikeshed on this yet, as I haven't found a way to do this so 
far. Let's imagine the following parser:


parser.add_argument('things',action='append')
parser.add_argument('stuff',action='append')

At least from my point of view, I don't any way to separate both lists 
on this command call:



cool-script.py thing1 thing2 stuff1 stuff2


Do I miss something here?


Best
Sven

On 03.08.21 01:49, Dan Stromberg wrote:


Isn't -- usually used to signal the end of options?

On Mon, Aug 2, 2021 at 12:52 PM Sven R. Kunze > wrote:


Hi everyone,

maybe, I am missing something here but is it possible to specify a
delimiter for list arguments in argparse:

https://docs.python.org/3/library/argparse.html


Usually, '--' is used to separate two lists (cf. git).

Cheers,
Sven

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




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

[issue44819] assertSequenceEqual does not use _getAssertEqualityFunc

[Brian]

New submission from Brian :

Like the title says, TestCase.assertSequenceEqual does not behave like 
TestCase.assertEqual where it uses TestCase._getAssertEqualityFunc. Instead, 
TestCase.assertSequenceEqual uses `item1 != item2`. That way I can do something 
like this:

```
def test_stuff(self):
   self.addTypeEqualityFunc(
  MyObject,
  comparison_method_which_compares_how_i_want,
   )
   self.assertListEqual(
  get_list_of_objects(),
  [MyObject(...), MyObject(...)],
   )
```

--
components: Tests
messages: 398851
nosy: Rarity
priority: normal
severity: normal
status: open
title: assertSequenceEqual does not use _getAssertEqualityFunc
type: behavior
versions: Python 3.6, Python 3.9

___
Python tracker 

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

[issue44037] Broad performance regression from 3.10a7 to 3.10b2 with python.org macOS binaries

[Ned Deily]

Ned Deily  added the comment:

Summary: With the 3.10.0rc1 release, this performance regression in the 
var_access_benchmark starting with the 3.10.0b1 binaries in the python.org 
macOS universal2 installer is now resolved. With the rc1 release, the 
performance of this micro benchmark has actually improved over alpha7 in many 
cases, most notably on Intel Macs.  We have also taken some steps to reduce the 
chances of significant performance regressions in future releases of the macOS 
binaries going undetected prior to release.

Details: All var_access_benchmark results (Appendix A and B) are from running 
macOS Big Sur 11.5.1 (the current release at the moment). The rc1 binaries were 
also built on 11.5.1 using the current Apple (Xcode) Command Line Tools 12.5.1. 
In general, we build the python.org macOS installers on the most current macOS 
and Command Line Tools that have been released by Apple prior to that Python 
release. The a7 and b2 released universal2 binaries were thus made on then 
current versions of macOS Big Sur and the Command Line Tools, each different 
from rc1.

To put these results in context, let me once again note that the primary goal 
of the python.org macOS installers for many years has been to provide a 
convenient way to run Python on macOS on as many different Mac systems as 
possible with one download. For 3.10, the universal2 installer variant we 
provide is designed to run natively on all Macs that can run any version of 
macOS from 10.9 through the current macOS 11 Big Sur (and soon to include macOS 
12 Monterey), both Intel and Apple Silicon (M1) Macs.  To be able to run on 
such a wide variety of systems obviously requires some compromises. Thus 
providing optimum performance in every situation has *never* been a goal for 
these installers.  That doesn't mean we should totally ignore performance 
issues and I am grateful to Raymond for bringing this issue forward.  But, and 
not to belabor the point: for those situations where optimum performance is 
important, there is no substitute to using a Python built and optimized 
explicitly for th
 at environment; in other words, don't look to the python.org binaries for 
those cases.

As an example, with 3.10.0b1, we introduced the first python.org macOS builds 
that use newer compile- and link-time optimizations (--enable-optimizations and 
--with-lto). There were some kinks with that that have been subsequently ironed 
out. But the performance improvements aren't uniform across all systems. It 
appears that Intel Macs see much more of an improvement than Apple Silicon Macs 
do. There are probably a couple of reasons for that: for one, the longer 
experience with the tool chain for Intel archs, but, perhaps more importantly, 
we currently build universal2 binaries on Intel-based Macs which means 
performance-based optimizations by the tool chain are based on the performance 
on an Intel arch which may not be the same as performance on an Apple Silicon 
(arm64) CPU. That's a topic for future investigation but it is an example of 
the potential pitfalls when looking at performance.

Another example is that while there are some significant differences in the 
var_access_benchmark results, which targets specific micro-operations in the 
Python virtual machine, there is a different story looking at the larger-scale 
"realworld" benchmarks in the pyperformance package.  When I first started 
looking at this issue, I ran pyperformance and var_access_benchmark and found 
that, in general, there were *significant* performance improvements in most 
pyperformance benchmarks between 3.10.0a7 and 3.10.0b2 even though the 
var_access_benchmark showed performance regressions.  For 3.10.0rc1, the 
pyperformance results have mostly improved even more.  I have with some 
trepidation included some pyperformance results in Appendix C (3.10.0a7 vs 
3.10.0b2) and Appendix D (3.10.0a7 vs 3.10.0rc1).  Note that these results were 
run on a different, faster Intel Mac than the var_access_benchmark results and 
were run under different updates of macOS 11 so they should be viewed 
cautiously; as al
 ways with performance issues, your mileage may vary.

So by now, one might be curious as to how the performance regression was fixed 
in rc1. The answer at the moment is: I'm not totally sure! There are a *lot* of 
moving parts in making a Python release and the binaries that we provide for 
macOS. While I do try to control the build environments as much as possible 
(for example, by using dedicated virtual machines for builds) and be 
conservative about making changes to the build process and environments, 
especially later in a development/release cycle, as noted above I normally try 
to keep up with the most recent Apple updates to a given macOS version and 
build tools to ensure everyone is getting the benefit of the latest security 
and performance fixes. There have been Apple updates along the way between a7, 
b2, and rc1. So I can't rule those out 

Re: argparse: delimiter for argparse list arguments

[Roel Schroeven]

Jon Ribbens via Python-list schreef op 3/08/2021 om 17:48:

On 2021-08-03, Michael Torrie  wrote:
> On 8/2/21 1:43 PM, Sven R. Kunze wrote:
>> maybe, I am missing something here but is it possible to specify a 
>> delimiter for list arguments in argparse:
>> 
>> https://docs.python.org/3/library/argparse.html
>> 
>> Usually, '--' is used to separate two lists (cf. git).

>
> I've not seen this syntax in git. Are you referring the the double and
> triple dot notation git uses?  Can you give me an example of how git
> uses -- as a list separator?

Loads of git commands do this. e.g. commit, diff, log, status, etc.
It's not completely unlike what you're describing above, which is
already supported automatically by argparse.
Commands like git commit do not use '--' to separate two lists, but as 
Dan and Sven said to separate options from arguments, even if the 
arguments start with '-' (like many other programs -- I think this is 
standard in GNU). If you're 100% certain that none of the filenames 
start with '-', you can leave out '--' without any change in behavior. 
Especially when scripting and/or using wildcards it's best always to use 
that '--' to avoid nasty surprises.


$ git commit -m "hello" -- hello.py

is exactly the same as

$ git commit -m "hello" hello.py

It's just that the former is safer to use, because it properly works 
even in cases like


$ git commit -m "hello" -- -hello.py

whereas

$ git commit -m "hello" -hello.py

will likely not do what you expect.

As https://git-scm.com/docs/git-commit says:

> --
>   Do not interpret any more arguments as options.

--
"The saddest aspect of life right now is that science gathers knowledge
faster than society gathers wisdom."
-- Isaac Asimov

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

[issue43874] argparse crashes on subparsers with no dest/metava

[Terence Honles]

Terence Honles  added the comment:

Closing as a duplicate of https://bugs.python.org/issue29298 (which was 
recently merged and caused conflicts with my patch)

--
resolution:  -> duplicate
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

[issue44801] Type expression is coerced to a list of parameter arguments in substitution of ParamSpec

[Serhiy Storchaka]

Change by Serhiy Storchaka :


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

___
Python tracker 

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

[issue44756] In ./Doc, "make html" and "make build" should depend on "make venv"

[Jack DeVries]

Jack DeVries  added the comment:

Actually, I tested out that idea 
(https://github.com/python/cpython/compare/main...jdevries3133:bpo-44756-doc-make),
 and I don't think its as nice of a solution. I think it is valuable for new 
contributors to be able to type "make html" and have it work. Look at how much 
the change simplifies the README for new contributors to setup their 
documentation build toolchain. Then, look at how many ``docs@python`` open 
issues there are. We need documentation contributors, and there is value in 
simplifying the process for them.

Additionally, this is the extent of the "downloading code from the internet and 
running it" that occurs::

pip install -U pip setuptools
pip install sphynx blurb python-docs-theme

If running that is ever unsafe, we have big problems!

--

___
Python tracker 

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

[issue32397] textwrap output may change if you wrap a paragraph twice

[Andrei Kulakov]

Andrei Kulakov  added the comment:

Note that I'm not handling a single '\r' because that was before Mac OS X; but 
it is handled by the following line (i.e. by the old logic):

text = text.translate(self.unicode_whitespace_trans)

--

___
Python tracker 

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

[issue32397] textwrap output may change if you wrap a paragraph twice

[Andrei Kulakov]

Andrei Kulakov  added the comment:

Irit: I assume you mean r' \r?\n', that's a great idea, it's much faster than 
adding a separate replacement step.

Latest version I came up with is this:

if re.search(r' \r?\n', text):
text = re.sub(r' \r?\n', ' ', text)
if re.search(r'\r?\n ', text):
text = re.sub(r'\r?\n ', ' ', text)

This optimizes the case when there's no newlines, which is likely the most 
common case for small fragments of text, but it may be the less common case for 
larger fragments where performance is more important; so I'm not sure if it's 
worth it.

Timings:
# sub() has to run
2904 (~/opensource/cpython) % ./python.exe -mtimeit 'import textwrap' 
'textwrap.wrap("abc foo\n bar baz", 5)'   VICMD
5000 loops, best of 5: 67.6 usec per loop

# search() runs; but sub() does NOT because there's no adjacent space
2906 (~/opensource/cpython) % ./python.exe -mtimeit 'import textwrap' 
'textwrap.wrap("abc foo\nbar baz", 5)'VICMD
5000 loops, best of 5: 60.3 usec per loop

--

___
Python tracker 

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

[issue41886] PyType_Type is documented incorrectly

[Ammar Askar]

Ammar Askar  added the comment:

Thank you for spotting this and the patch da-woods!

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
type:  -> behavior
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

[issue41886] PyType_Type is documented incorrectly

[miss-islington]

miss-islington  added the comment:


New changeset 952aa31c89f70d3c53596449bd2ed9a4817a2364 by Miss Islington (bot) 
in branch '3.10':
bpo-41886: Fix documented type of PyType_Type (GH-22454)
https://github.com/python/cpython/commit/952aa31c89f70d3c53596449bd2ed9a4817a2364


--

___
Python tracker 

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

[issue41886] PyType_Type is documented incorrectly

[miss-islington]

miss-islington  added the comment:


New changeset f26fec4f74ae7da972595703bc39d3d30b8cfdf9 by Miss Islington (bot) 
in branch '3.9':
bpo-41886: Fix documented type of PyType_Type (GH-22454)
https://github.com/python/cpython/commit/f26fec4f74ae7da972595703bc39d3d30b8cfdf9


--

___
Python tracker 

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

[issue44801] Type expression is coerced to a list of parameter arguments in substitution of ParamSpec

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Thank you Ken Jin. So the problem is the __args__ (x, str) is interpreted 
differently depending on x, and after substituting x the interpretation can be 
changed. If x was ParamSpec, it was interpreted in one way, but if it becomes 
int, it is now interpreted in other way.

The solution is to forbid substitution of P with wrong values (not parameters 
expression). Some normalization is also needed, before and after substitution.

Other related example is:

>>> from typing import *
>>> P = ParamSpec("P")
>>> class Z(Generic[P]): pass
... 
>>> A = Z[[int]]
>>> B = Z[int]
>>> A
__main__.Z[(,)]
>>> B
__main__.Z[int]
>>> A.__args__
((,),)
>>> B.__args__
(,)

It is expected that A and B should the same.

--

___
Python tracker 

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

Re: argparse: delimiter for argparse list arguments

[Jon Ribbens via Python-list]

On 2021-08-03, Michael Torrie  wrote:
> On 8/2/21 1:43 PM, Sven R. Kunze wrote:
>> maybe, I am missing something here but is it possible to specify a 
>> delimiter for list arguments in argparse:
>> 
>> https://docs.python.org/3/library/argparse.html
>> 
>> Usually, '--' is used to separate two lists (cf. git).
>
> I've not seen this syntax in git. Are you referring the the double and
> triple dot notation git uses?  Can you give me an example of how git
> uses -- as a list separator?

Loads of git commands do this. e.g. commit, diff, log, status, etc.
It's not completely unlike what you're describing above, which is
already supported automatically by argparse.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue41886] PyType_Type is documented incorrectly

[miss-islington]

Change by miss-islington :


--
pull_requests: +26087
pull_request: https://github.com/python/cpython/pull/27584

___
Python tracker 

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

[issue41886] PyType_Type is documented incorrectly

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 4.0 -> 5.0
pull_requests: +26086
pull_request: https://github.com/python/cpython/pull/27583

___
Python tracker 

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

[issue41886] PyType_Type is documented incorrectly

[Ammar Askar]

Ammar Askar  added the comment:


New changeset ac811f9b5a68ce8756911ef2c8be83b46696018f by da-woods in branch 
'main':
bpo-41886: Fix documented type of PyType_Type (GH-22454)
https://github.com/python/cpython/commit/ac811f9b5a68ce8756911ef2c8be83b46696018f


--
nosy: +ammar2

___
Python tracker 

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

[issue41886] PyType_Type is documented incorrectly

[Ammar Askar]

Change by Ammar Askar :


--
versions: +Python 3.11 -Python 3.5, 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

[issue44756] In ./Doc, "make html" and "make build" should depend on "make venv"

[Jack DeVries]

Jack DeVries  added the comment:

@petr.viktorin a whatsnew entry was added, what more notice could have been 
provided?

I have an idea for an alternative that might be better. What if ``make clean`` 
deletes and restores the venv only if it already existed in the first place?

--

___
Python tracker 

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

[issue32397] textwrap output may change if you wrap a paragraph twice

[Irit Katriel]

Irit Katriel  added the comment:

You should be able to do them in one re, something like 

text = re.sub(r' ?\n', ' ', text)

--
nosy: +iritkatriel

___
Python tracker 

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

[RELEASE] Python 3.10.0rc1 is available

[Pablo Galindo Salgado]

Python 3.10.0 is almost ready. This release, 3.10.0rc1, is the penultimate
release preview. You can get it here:

https://www.python.org/downloads/release/python-3100rc1/


*This is the first release candidate of Python 3.10*
This release, **3.10.0rc1**, is the penultimate release preview.  Entering
the release candidate phase, only reviewed code changes which are
clear bug fixes are allowed between this release candidate and the final
release. The second candidate and the last planned release preview is
currently planned for 2021-09-06 while the official release is planned for
2021-10-04.

There will be no ABI changes from this point forward in the 3.10 series and
the goal is that there will be as few code changes as possible.

*Call to action*
Core developers: all eyes on the docs now

   - Are all your changes properly documented?
   - Did you notice other changes you know of to have insufficient
   documentation?

Community members

We strongly encourage maintainers of third-party Python projects to prepare
their projects for 3.10 compatibilities during this phase. As always,
report any issues to the Python bug tracker .
Please keep in mind that this is a preview release and its use is **not**
recommended for production environments.

*And now for something completely different*

In theoretical physics, quantum chromodynamics (QCD) is the theory of the
strong interaction between quarks and gluons, the fundamental particles
that make up composite hadrons such as the proton, neutron, and pion. The
QCD analog of electric charge is a property called color. Gluons are the
force carrier of the theory, just as photons are for the electromagnetic
force in quantum electrodynamics. There are three kinds of charge in QCD
(as opposed to one in quantum electrodynamics or QED) that are usually
referred to as "color charge" by loose analogy to the three kinds of color
(red, green and blue) perceived by humans. Other than this nomenclature,
the quantum parameter "color" is completely unrelated to the everyday,
familiar phenomenon of color.


*We hope you enjoy those new releases!*
Thanks to all of the many volunteers who help make Python Development and
these releases possible! Please consider supporting our efforts by
volunteering yourself or through organization contributions to the Python
Software Foundation.

Regards from cloudy London,

Your friendly release team,
Pablo Galindo @pablogsal
Ned Deily @nad
Steve Dower @steve.dower
___
Python-announce-list mailing list -- python-announce-list@python.org
To unsubscribe send an email to python-announce-list-le...@python.org
https://mail.python.org/mailman3/lists/python-announce-list.python.org/
Member address: arch...@mail-archive.com

[issue44816] PEP 626 does not explain the handling of constants, at all.

[Brandt Bucher]

Brandt Bucher  added the comment:

Thanks for clarifying.

I'm worried, though, that the PEP's emphasis on "*all* lines of code executed 
and *only* for lines of code that are executed" could be problematic for other 
optimizations we perform. Consider:

if (  # <--
True  # <--
):
pass  # <--

I understand why lines 1 and 4 are covered, since PEP 626 defines "if" and 
"pass" keywords as executable code. But line 2 isn't executed at runtime (it's 
peepholed into a NOP)... is it a bug that it creates a line event?

--

___
Python tracker 

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

[RELEASE] Python 3.10.0rc1 is available

[Pablo Galindo Salgado]

Python 3.10.0 is almost ready. This release, 3.10.0rc1, is the penultimate
release preview. You can get it here:

https://www.python.org/downloads/release/python-3100rc1/


*This is the first release candidate of Python 3.10*
This release, **3.10.0rc1**, is the penultimate release preview.  Entering
the release candidate phase, only reviewed code changes which are
clear bug fixes are allowed between this release candidate and the final
release. The second candidate and the last planned release preview is
currently planned for 2021-09-06 while the official release is planned for
2021-10-04.

There will be no ABI changes from this point forward in the 3.10 series and
the goal is that there will be as few code changes as possible.

*Call to action*
Core developers: all eyes on the docs now

   - Are all your changes properly documented?
   - Did you notice other changes you know of to have insufficient
   documentation?

Community members

We strongly encourage maintainers of third-party Python projects to prepare
their projects for 3.10 compatibilities during this phase. As always,
report any issues to the Python bug tracker .
Please keep in mind that this is a preview release and its use is **not**
recommended for production environments.

*And now for something completely different*

In theoretical physics, quantum chromodynamics (QCD) is the theory of the
strong interaction between quarks and gluons, the fundamental particles
that make up composite hadrons such as the proton, neutron, and pion. The
QCD analog of electric charge is a property called color. Gluons are the
force carrier of the theory, just as photons are for the electromagnetic
force in quantum electrodynamics. There are three kinds of charge in QCD
(as opposed to one in quantum electrodynamics or QED) that are usually
referred to as "color charge" by loose analogy to the three kinds of color
(red, green and blue) perceived by humans. Other than this nomenclature,
the quantum parameter "color" is completely unrelated to the everyday,
familiar phenomenon of color.


*We hope you enjoy those new releases!*
Thanks to all of the many volunteers who help make Python Development and
these releases possible! Please consider supporting our efforts by
volunteering yourself or through organization contributions to the Python
Software Foundation.

Regards from cloudy London,

Your friendly release team,
Pablo Galindo @pablogsal
Ned Deily @nad
Steve Dower @steve.dower
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue43468] functools.cached_property incorrectly locks the entire descriptor on class instead of per-instance locking

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

> It should use "(id(instance), instance)" rather than just "instance" as the 
> key.

It should use a dict with id(instance) as a key and instance as value. An 
instance can be non-hashable.

--

___
Python tracker 

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

[issue32397] textwrap output may change if you wrap a paragraph twice

[Andrei Kulakov]

Andrei Kulakov  added the comment:

I think fix to make `drop_whitespace=False` stable, can be as simple as adding 
two lines in `_munge_whitespace()`:

+text = re.sub(r' \n', ' ', text)
+text = re.sub(r'\n ', ' ', text)
 text = text.translate(self.unicode_whitespace_trans)

The perf impact is not small though, 12% :

2892 (~/opensource/cpython) % ./python.exe -mtimeit 'import textwrap' 
'textwrap.wrap("abc foo\nbar baz", 5)'  --INS--
5000 loops, best of 5: 60.2 usec per loop

2893 (~/opensource/cpython) % r 
  --INS--
./python.exe -mtimeit 'import textwrap' 'textwrap.wrap("abc foo\nbar baz", 5)'
5000 loops, best of 5: 52.9 usec per loop


I don't know if it's worth doing, but if yes, the options are:

 - just add this change for drop_whitespace=False, which is not the default, so 
perf regression will not affect default usage of wrap.

 - add a new arg that will only have effect when drop_whitespace=False, and 
will run these 2 lines. Name could be something like `collapse_space_newline`. 
It's hard to think of a good name.

If '\r\n' is handled, it needs one additional `sub()` line, and the perf. 
difference is 22%.

--

___
Python tracker 

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

[issue44817] os.path.realpath fails with WinError 161

[Eryk Sun]

Eryk Sun  added the comment:

It should also ignore ERROR_BAD_NETPATH (53).

--
nosy: +eryksun

___
Python tracker 

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

[issue44301] Is there a way to provide destructor for module written using C API?

[Petr Viktorin]

Change by Petr Viktorin :


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

___
Python tracker 

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

[issue44818] '\t' (tab) support

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
status: open -> pending

___
Python tracker 

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

[issue44816] PEP 626 does not explain the handling of constants, at all.

[Mark Shannon]

Mark Shannon  added the comment:

This isn't a bug. Although PEP 626 is not at all clear about this.

The key word in the PEP is "executed".
Because compound and multi-line constants are constants, the parts of them are 
not "executed", but computed at compile time.

Having re-read the PEP, this is as clear as mud :(

I'll add a section to the PEP clarifying this.

--
assignee:  -> Mark.Shannon
title: Folded constants do not trace correctly. -> PEP 626 does not explain the 
handling of constants, at all.

___
Python tracker 

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

[issue20703] RuntimeError caused by lazy imports in pdb

[Irit Katriel]

Irit Katriel  added the comment:

Can we make sys.modules automatically return an iterator that has a copy of its 
contents?  Otherwise it's an odd API - it's iterable but we tell people not to 
iterate it.

--

___
Python tracker 

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

[issue20703] RuntimeError caused by lazy imports in pdb

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

My concern about importing readline at the top of the module is that importing 
readline has a side effect. The only module which imports it unconditionally at 
the top is rlcompleter. In all other places it is imported lazily.

And importing readline ahead may not fix the original issue, because there are 
other modules lazily imported in pdb: runpy, shlex, pydoc.

Perhaps we should just say that sys.modules should not be iterated directly, 
you should first make a copy. There are other issues about RuntimeError raised 
during iterating sys.modules.

--

___
Python tracker 

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

[issue34782] Pdb raises exception when code is executed in a mapping that does not define `__contains__`

[Irit Katriel]

Irit Katriel  added the comment:

I think we should close this. It's not a problem you will come across if you're 
not looking for trouble, so there's no point trying to make the error message a 
little nicer.

--
resolution:  -> not a bug
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

[issue44817] os.path.realpath fails with WinError 161

[Eryk Sun]

Change by Eryk Sun :


--
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware
type:  -> behavior
versions: +Python 3.10, Python 3.11, 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

Re: argparse: delimiter for argparse list arguments

[Michael Torrie]

On 8/2/21 1:43 PM, Sven R. Kunze wrote:
> Hi everyone,
> 
> maybe, I am missing something here but is it possible to specify a 
> delimiter for list arguments in argparse:
> 
> https://docs.python.org/3/library/argparse.html
> 
> Usually, '--' is used to separate two lists (cf. git).

I've not seen this syntax in git. Are you referring the the double and
triple dot notation git uses?  Can you give me an example of how git
uses -- as a list separator?

Typically -- on a command line means that's the end of the any special
switches and anything else, even if it looks like a command-line switch,
should not be parsed, and passed straight through as a normal parameter.

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

[issue34782] Pdb raises exception when code is executed in a mapping that does not define `__contains__`

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

You cannot expect that running code under debugger does not have any effect. 
Otherwise there would not be any meaning in debugger. Running code under 
debugger has some side effects, and setting locals __return__ and __exception__ 
is one of them. If it exposes bugs in user code -- well, it is a purpose of 
debugger.

I think that there are two options for this issue.

1. Add a type check for locals in the frame constructor (and maybe at higher 
levels).

2. Close it as "not a bug". Using functions outside of documented scope has 
undefined behavior. Python usually does not check types of arguments. If it 
works -- it works, if not -- blame on you.

--

___
Python tracker 

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

[issue30256] Adding a SyncManager Queue proxy to a SyncManager dict or Namespace proxy raises an exception

[Ken Jin]

Ken Jin  added the comment:

> Just chiming in to say that this is still broken for me on Python 3.9.6

>From what I understand, the patch landed on 2021-07-02, 4 days after Python 
>3.9.6's release date of 2021-06-28, so it wasn't included.

It should come in 3.9.7, which should be out on 2021-08-30 according to PEP 596.

--

___
Python tracker 

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

[issue30256] Adding a SyncManager Queue proxy to a SyncManager dict or Namespace proxy raises an exception

[Stephen Carboni]

Stephen Carboni  added the comment:

Just chiming in to say that this is still broken for me on Python 3.9.6, 
Win10/64: https://pastebin.com/64F2iKaj

But, works for 3.10.0b4.

--
nosy: +stephen.entropy

___
Python tracker 

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

[issue44756] In ./Doc, "make html" and "make build" should depend on "make venv"

[Petr Viktorin]

Petr Viktorin  added the comment:

I'm one of those who disagree with "make html" suddenly downloading code from 
the internet and running it, but I guess I'm in a minority. I'll switch to 
using `sphinx-build` directly.

Still, I'd have appreciated a heads-up notice.

--
nosy: +petr.viktorin

___
Python tracker 

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

[issue44301] Is there a way to provide destructor for module written using C API?

[Petr Viktorin]

Petr Viktorin  added the comment:

You are missing m_free.
The clear function is used to break reference counts. In this case, there are 
no reference counts to be broken, so it is not called.

Your custom_clear function is idempotent, so you can use it in both free and 
clear and let Python call it either once or twice:
.m_clear = custom_clear,
.m_free = custom_clear,

I agree that this is not at all clear from the documentation. I'm going to 
spend some time organizing the info around the GC API and writing it up.

--
nosy: +petr.viktorin

___
Python tracker 

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

[issue44808] test_inspect fails in refleak mode

[miss-islington]

miss-islington  added the comment:


New changeset bc2841c7a9fe2b05ef77ebdf77701188dc83b2ce by Miss Islington (bot) 
in branch '3.10':
bpo-44808: fixes test for interactive inspect getsource of a class (GH-27571)
https://github.com/python/cpython/commit/bc2841c7a9fe2b05ef77ebdf77701188dc83b2ce


--

___
Python tracker 

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

[issue44808] test_inspect fails in refleak mode

[Łukasz Langa]

Change by Łukasz Langa :


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

[issue44808] test_inspect fails in refleak mode

[Łukasz Langa]

Łukasz Langa  added the comment:


New changeset 58325971de0faf330c9c38269dae8315a0746e59 by andrei kulakov in 
branch 'main':
bpo-44808: fixes test for interactive inspect getsource of a class (GH-27571)
https://github.com/python/cpython/commit/58325971de0faf330c9c38269dae8315a0746e59


--

___
Python tracker 

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

[issue44808] test_inspect fails in refleak mode

[miss-islington]

Change by miss-islington :


--
pull_requests: +26084
pull_request: https://github.com/python/cpython/pull/27578

___
Python tracker 

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

[issue41737] Improper NotADirectoryError when opening a file in a fake directory

[miss-islington]

miss-islington  added the comment:


New changeset 84494db41902774ea6ac72e5b308b429850bbf71 by Miss Islington (bot) 
in branch '3.10':
bpo-41737: expand doc for NotADirectoryError (GH-27471)
https://github.com/python/cpython/commit/84494db41902774ea6ac72e5b308b429850bbf71


--

___
Python tracker 

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

[issue41737] Improper NotADirectoryError when opening a file in a fake directory

[Łukasz Langa]

Łukasz Langa  added the comment:


New changeset b5f026112768eb0a06622263bdea86d7d85981c5 by Miss Islington (bot) 
in branch '3.9':
bpo-41737: expand doc for NotADirectoryError (GH-27471) (GH-27577)
https://github.com/python/cpython/commit/b5f026112768eb0a06622263bdea86d7d85981c5


--

___
Python tracker 

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

[issue18255] CPython setup.py problems

[Ronald Oussoren]

Ronald Oussoren  added the comment:

This is no longer relevant now that distutils is deprecated.

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

[issue41737] Improper NotADirectoryError when opening a file in a fake directory

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 5.0 -> 6.0
pull_requests: +26082
pull_request: https://github.com/python/cpython/pull/27576

___
Python tracker 

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

[issue41737] Improper NotADirectoryError when opening a file in a fake directory

[Łukasz Langa]

Łukasz Langa  added the comment:


New changeset f7c23a99cd4f8179b6ba2cffaeb78b852c0f6488 by andrei kulakov in 
branch 'main':
bpo-41737: expand doc for NotADirectoryError (GH-27471)
https://github.com/python/cpython/commit/f7c23a99cd4f8179b6ba2cffaeb78b852c0f6488


--
nosy: +lukasz.langa

___
Python tracker 

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

[issue41737] Improper NotADirectoryError when opening a file in a fake directory

[miss-islington]

Change by miss-islington :


--
pull_requests: +26083
pull_request: https://github.com/python/cpython/pull/27577

___
Python tracker 

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

[issue27275] KeyError thrown by optimised collections.OrderedDict.popitem()

[Łukasz Langa]

Change by Łukasz Langa :


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

[issue27275] KeyError thrown by optimised collections.OrderedDict.popitem()

[Łukasz Langa]

Łukasz Langa  added the comment:


New changeset 8c9f847997196aa76500d1ae104cbe7fe2a467ed by Serhiy Storchaka in 
branch 'main':
bpo-27275: Change popitem() and pop() methods of collections.OrderedDict 
(GH-27530)
https://github.com/python/cpython/commit/8c9f847997196aa76500d1ae104cbe7fe2a467ed


--
nosy: +lukasz.langa

___
Python tracker 

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

[issue39091] _PyErr_CreateException() must check that the result is an exception (CPython Segfault in 5 lines of code)

[Łukasz Langa]

Łukasz Langa  added the comment:


New changeset 0b551db04a99a97abb1e44a071c688c3ca704b67 by Miss Islington (bot) 
in branch '3.9':
bpo-39091: Fix segfault when Exception constructor returns non-exception for 
gen.throw. (GH-17658) (GH-27573)
https://github.com/python/cpython/commit/0b551db04a99a97abb1e44a071c688c3ca704b67


--

___
Python tracker 

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

[issue39091] _PyErr_CreateException() must check that the result is an exception (CPython Segfault in 5 lines of code)

[Łukasz Langa]

Łukasz Langa  added the comment:


New changeset 8ce7f2f4ef04e19209f1dfd2a0cf50ddcd0e999f by Miss Islington (bot) 
in branch '3.10':
bpo-39091: Fix segfault when Exception constructor returns non-exception for 
gen.throw. (GH-17658) (GH-27572)
https://github.com/python/cpython/commit/8ce7f2f4ef04e19209f1dfd2a0cf50ddcd0e999f


--
nosy: +lukasz.langa

___
Python tracker 

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

[issue44818] '\t' (tab) support

[Steven D'Aprano]

Steven D'Aprano  added the comment:

I don't understand what you mean by "Python can't use '\t' character." Can you 
demonstrate an example? It works for me.

--
nosy: +steven.daprano

___
Python tracker 

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

Re: Defining a Python enum in a C extension - am I doing this right?

[Bartosz Golaszewski]

On Sat, Jul 31, 2021 at 3:01 PM Bartosz Golaszewski  wrote:
>
> On Fri, Jul 30, 2021 at 2:41 PM Serhiy Storchaka  wrote:
> >
> > 23.07.21 11:20, Bartosz Golaszewski пише:
> > > I'm working on a Python C extension and I would like to expose a
> > > custom enum (as in: a class inheriting from enum.Enum) that would be
> > > entirely defined in C.
> >
> > I think that it would be much easier to define it in Python, and then
> > either import a Python module in your C code, or exec a Python code as a
> > string.
> >
>
> You mean: evaluate a string like this:
>
> '''
> import enum
>
> class FooBar(enum.Enum):
> FOO = 1
> BAR = 2
> BAZ = 3
> '''
>
> And then pull in the FooBar type from the resulting dictionary into my
> C code? Sounds good actually. I think I'll be able to add the FooBar
> type to another type's tp_dict too - because some enums I want to
> create will be nested in other classes.
>
> Bart

Just a follow-up: this is how I did it eventually:

```
#include 

typedef struct {
PyObject_HEAD;
} dummy_object;

PyDoc_STRVAR(dummy_type_doc, "Dummy type in which the enum will be nested.");

static PyTypeObject dummy_type = {
PyVarObject_HEAD_INIT(NULL, 0)
.tp_name = "pycenum.DummyType",
.tp_basicsize = sizeof(dummy_object),
.tp_flags = Py_TPFLAGS_DEFAULT,
.tp_doc = dummy_type_doc,
.tp_new = PyType_GenericNew,
.tp_dealloc = (destructor)PyObject_Del,
};

PyDoc_STRVAR(module_doc,
"C extension module defining a class inheriting from enum.Enum.");

static PyModuleDef module_def = {
PyModuleDef_HEAD_INIT,
.m_name = "pycenum",
.m_doc = module_doc,
.m_size = -1,
};

static int add_foobar_enum(PyObject *module)
{
static const char *foobar_src =
"class FooBar(enum.Enum):\n"
"FOO = 1\n"
"BAR = 2\n"
"BAZ = 3\n";

PyObject *main_mod, *main_dict, *enum_mod, *result, *foobar_type;
int ret;

main_mod = PyImport_AddModule("__main__");
if (!main_mod)
return -1;

main_dict = PyModule_GetDict(main_mod);
if (!main_dict) {
Py_DECREF(main_mod);
return -1;
}

enum_mod = PyImport_ImportModule("enum");
if (!enum_mod) {
Py_DECREF(main_mod);
return -1;
}

ret = PyDict_SetItemString(main_dict, "enum", enum_mod);
Py_DECREF(enum_mod);
if (ret) {
Py_DECREF(main_mod);
return -1;
}

result = PyRun_String(foobar_src, Py_single_input,
  main_dict, main_dict);
if (!result) {
Py_DECREF(main_mod);
return -1;
}

foobar_type = PyDict_GetItemString(main_dict, "FooBar");
if (!foobar_type) {
Py_DECREF(main_mod);
return -1;
}

ret = PyDict_SetItemString(dummy_type.tp_dict, "FooBar", foobar_type);
Py_DECREF(foobar_type);
Py_DECREF(main_mod);
if (ret)
return -1;

PyType_Modified(_type);

return ret;
}

PyMODINIT_FUNC PyInit_pycenum(void)
{
PyObject *module;
int ret;

module = PyModule_Create(_def);
if (!module)
return NULL;

ret = PyModule_AddStringConstant(module, "__version__", "0.0.1");
if (ret) {
Py_DECREF(module);
return NULL;
}

ret = PyType_Ready(_type);
if (ret) {
Py_DECREF(module);
return NULL;
}

ret = add_foobar_enum(module);
if (ret) {
Py_DECREF(module);
return NULL;
}

Py_INCREF(_type);
ret = PyModule_AddObject(module, "DummyType", (PyObject *)_type);
if (ret) {
Py_DECREF(_type);
Py_DECREF(module);
return NULL;
}

return module;
}
```

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

[issue44818] '\t' (tab) support

[Pooia]

New submission from Pooia :

Python can't use '\t' character. if I want fix it I will work a long time but a 
shorter fashion is replacing '\t' character with 4 space (by first clause of 
pep: 8)

--
components: Parser
messages: 398815
nosy: Pooia, lys.nikolaou, pablogsal
priority: normal
severity: normal
status: open
title: '\t' (tab) support
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