[issue32696] Fix pickling exceptions with multiple arguments

[Ziga Seilnacht]

Change by Ziga Seilnacht :


--
nosy:  -zseil

___
Python tracker 

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

[issue46382] dataclass(slots=True) does not account for slots in base classes

[Arie Bovenberg]

Arie Bovenberg  added the comment:

There are already 2 complexities I can think of:

1. This behavior may break some people's code, if they use __slots__ to iterate 
over
   the fields of a dataclass. Solution: explicitly mention in the docs that
   not every field may get a slot on the new class. Advise them to use
   `fields()` to iterate over the fields.
2. It's technically allowed for __slots__ to be an iterator (which will then be 
   exhausted at class creation). Finding the __slots__ of such a class
   may require more elaborate introspection.

--

___
Python tracker 

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

[issue46376] PyMapping_Check returns 1 for list

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Here's question to focus on:  In what circumstances should a developer ever 
prefer PyMapping_Check() over PyType_HasFeature() with Py_TPFLAGS_MAPPING?

The latter doesn't give any new, useful information:

   return o && Py_TYPE(o)->tp_as_mapping &&
   Py_TYPE(o)->tp_as_mapping->mp_subscript;

I don't see any reason to build on top of this. It's best to just let it go 
gently into the good night without disrupting anything that currently happens 
to work.

--

___
Python tracker 

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

[issue46376] PyMapping_Check returns 1 for list

[Raymond Hettinger]

Raymond Hettinger  added the comment:

> what about simply excluding TPFLAGS_MAPPING from PySequence 
> and TPFLAGS_Sequence from PyMapping? It will remove the types 
> that are 100% not sequences or mappings, as these flags 
> are mutually exclusive by definition.

This is more plausible than the proposed breaking change.


> The result will be much more accurate

If they can't be made fully reliable, why would we ever recommend that someone 
use these functions in real code?  They can be made to guess better than they 
guess now, but there is still guesswork.  

ISTM developers should follow the structure pattern matching implementation and 
refuse the temptation to guess.  If a class declares itself as a mapping or 
sequence, that is reliable information.  In contrast, these functions attempt 
to divine meaning in the absence of a clear declaration.  Using these functions 
will likely result in subtle bugs.

Once Py_TPFLAGS_MAPPING and Py_TPFLAGS_SEQUENCE became available, we should 
have deprecated these functions.  No one should use them anymore. Their core 
design is flawed; they tried to deduce semantics from structural artifacts.

--

___
Python tracker 

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

[issue46376] PyMapping_Check returns 1 for list

[John Millikin]

Change by John Millikin :


--
nosy:  -jmillikin

___
Python tracker 

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

[issue46385] Remove parenthetical symbols for readability and nlp

[Steven D'Aprano]

Steven D'Aprano  added the comment:

Please don't reopen this issue.

If you really want to take it to the Python-Ideas mailing list, you can:

https://mail.python.org/mailman3/lists/python-ideas.python.org/

or to Discuss:

https://discuss.python.org/c/ideas/6

--
status: open -> closed

___
Python tracker 

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

[issue46376] PyMapping_Check returns 1 for list

[Bar Harel]

Bar Harel  added the comment:

I thought about it, what about simply excluding TPFLAGS_MAPPING from PySequence 
and TPFLAGS_Sequence from PyMapping? It will remove the types that are 100% not 
sequences or mappings, as these flags are mutually exclusive by definition. The 
result will be much more accurate, yet not cause a breaking change, apart from 
places where it is truly not a sequence or mapping.

--

___
Python tracker 

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

[issue46385] Remove parenthetical symbols for readability and nlp

[Devin Harper]

Devin Harper <345t...@gmail.com> added the comment:

Couldn't find that mailing list sorry. There's only 1 for developers like you. 
Removing tuples would be backwards compatible. My plan would automatically 
convert tuples to lists. Just keep all the list code besides parenthetical 
symbols. Merge tuple and list code besides parenthetical symbols if you have 
to. You can hash 1 item lists.

I do believe in keeping commas to delineate items on a list. Commas are used in 
natural language lists not parenthetical symbols. Just because natural language 
programming languages don't have natural language perfected yet doesn't mean we 
shouldn't perfect it in python 1st. Of course natural language is easier to 
read and understand than this bug. Why did you say it's not easier? You didn't 
say yet. 

I already tested tuples to confirm your other concern applies to them but not 
lists. I said keep list code. The mitigation for that tuple confusion is 
probably in there. Because lists don't have that problem. I never said get rid 
of lists. I only said get rid of parenthetical symbol complaints. It will just 
work with hard science. Just test it.

--
status: closed -> open

___
Python tracker 

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

[issue46376] PyMapping_Check returns 1 for list

[Inada Naoki]

Inada Naoki  added the comment:

collections.abc.Mapping is fixed by https://bugs.python.org/issue43977
We can be same thing if backward compatibility allows it.

--
nosy: +methane

___
Python tracker 

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

[issue46376] PyMapping_Check returns 1 for list

[Raymond Hettinger]

Raymond Hettinger  added the comment:

s/it isn't work breaking other things/it isn't worth breaking other things/

--

___
Python tracker 

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

[issue46385] Remove parenthetical symbols for readability and nlp

[Steven D'Aprano]

Steven D'Aprano  added the comment:

Dennis beat me to it in saying that tuples cannot be replaced by lists.

But I also wanted to say that it is *not true* that removing bracket symbols 
would increase readability. Natural language allows parenthetical phrases -- 
which can be bracketed using dashes (or with parentheses [commonly called round 
brackets in the British commonwealth]) or even commas -- so even in natural 
language they are used.

Even programming languages which are much, much closer to natural language than 
Python, like Hypertalk and Inform-7, use parentheses and delimiters for various 
purposes, for example:

http://inform7.com/book/WI_21_3.html

Ultimately, we simply can't remove brackets (square, round or curly) from the 
language. It would make it impossible to tell whether

func(1, 2, 3, 4, 5)

was a call to func() with 5 integer arguments, or a single 5-element list 
argument, or two 2-element lists and an integer, or three integers and a 
2-element list, etc.

So don't waste your time taking this proposal to Python-Ideas.

--
nosy: +steven.daprano

___
Python tracker 

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

[issue46376] PyMapping_Check returns 1 for list

[Raymond Hettinger]

Raymond Hettinger  added the comment:

> It changes behavior for objects not being iterable/sequences 
> if not inheriting from `abc.collections.Sequence`.

This would be a breaking change (for example, it broke the long stable 
sre_parse code).

The utility of PySequence_Check and PyMapping_Check is already so low that it 
isn't work breaking other things to just to marginally improve these two minor 
and rarely used functions.

These functions will never be fully reliable.  The documentation explains that 
in general, we can't tell if a class with __getitem__ is a mapping or a 
sequence.  Sometimes hints are present (such as the tp_flags), but the can't 
get a reliable result.  As Guido observed, "calling PyMapping_Check() was never 
particularly reliable, and extension modules depending on it probably always 
had subtle bugs."  That was true in 2011 and it is still true today.

I recommend closing this.  These functions are mostly unimportant and 
unreliable and cannot be made correct.  In contrast, iterability is important 
and needs to be stable.  Special cases aren't important enough to break the 
rules.

--
assignee:  -> rhettinger

___
Python tracker 

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

[issue46376] PyMapping_Check returns 1 for list

[Bar Harel]

Bar Harel  added the comment:

Another question we should ask is about duck typing. Is a sequence which 
doesn't inherit from abc.Sequence considered a sequence? Whatever the answer 
is, PySequence specifically looks for a sequence and removes duck typing out of 
the picture. The object will not pass static typing and will not pass 
isinstance check, so there's no reason for it to pass PySequence.

--

___
Python tracker 

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

[issue46385] Remove parenthetical symbols for readability and nlp

[Dennis Sweeney]

Dennis Sweeney  added the comment:

"Removing tuples" would be highly backwards-incompatible, as millions of 
programs rely on tuples, and we can't break them for no reason.

> Lists have everything tuples have and more.

Not true: tuples are hashable, so they can be used as keys in dicts and sets, 
while lists cannot.

The Python-Ideas mailing list, rather than this bug tracker, is probably a 
better location for these sorts of proposals, so I'll close this for now, but 
this ticket can be re-opened if you can arrive at some sort of consensus with 
others on that list.

--
nosy: +Dennis Sweeney
resolution:  -> rejected
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

Re: sharing data across Examples docstrings

[Martin Di Paola]

Hello,

I understand that you want to share data across examples (docstrings) 
because you are running doctest to validate them (and test).


The doctest implementation evaluates each docstring separately without 
sharing the context so the short answer is "no".


This is a limitation of doctest but it is not the only testing engine 
that you can use.


You could use "byexample" ( https://byexamples.github.io ) which it 
shares the context by default.


byexample has more features and fixes other caveats of doctests, but 
don't take me too serious, I have a natural bias because I'm its author.


If you want to go with byexample, you may want to try its "doctest 
compatibility mode" first so you don't have to rewrite any test.

( https://byexamples.github.io/byexample/recipes/python-doctest )

Let me know if it is useful for you.

Thanks,
Martin.

On Tue, Jan 11, 2022 at 04:09:57PM -0600, Sebastian Luque wrote:

Hello,

I am searching for a mechanism for sharing data across Examples sections
in docstrings within a class.  For instance:

class Foo:

   def foo(self):
   """Method foo title

   The example generating data below may be much more laborious.

   Examples
   
   >>> x = list("abc")  # may be very long and tedious to generate

   """
   pass

   def bar(self):
   """Method bar title

   Examples
   
   >>> # do something else with x from foo Example

   """
   pass


Thanks,
--
Seb
--
https://mail.python.org/mailman/listinfo/python-list

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

[issue46385] Remove parenthetical symbols for readability and nlp

[Devin Harper]

New submission from Devin Harper <345t...@gmail.com>:

Parenthetical symbols like ()[]{} are unneeded if you just remove the 
complaining in the compiler/interpreter/programming language. It will increase 
readability and natural language programming( NLP). Just treat the symbols as 
strings and optional even for lists removing tuples. Tuples are unneeded too. 
Lists have everything tuples have and more.

--
components: Tests
messages: 410616
nosy: 345trig
priority: normal
severity: normal
status: open
title: Remove parenthetical symbols for readability and nlp
type: compile error

___
Python tracker 

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

[issue46384] Request: make lzma._(encode|decode)_filter_properties public

[Hiroshi Miura]

New submission from Hiroshi Miura :

py7zr 3rd party project that use lzma module to compress/decompress 7-zip 
archive uses lzma._(encode|decode)_filter_properties.

These methods are public at first but become private in py3.4 at commit 
a425c3d5a264c556d31bdd88097c79246b533ea3

Here is a reason described in commit comment 
> These functions were originally added to support LZMA compression in the 
> zipfile module, and are not of interest for the majority of users.

This is a request these methods to be public.

ref: py7zr: https://github.com/miurahr/py7zr

--
components: Library (Lib)
messages: 410615
nosy: miurahr
priority: normal
severity: normal
status: open
title: Request: make  lzma._(encode|decode)_filter_properties public
type: enhancement
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

Re: keep getting a syntax error on the very first program I am running

[Jon Ribbens via Python-list]

On 2022-01-15, Bob Griffin  wrote:
>I am running this program and keep getting this error.  Is this normal?
>
>Invalid syntax.  Perhaps you forgot a comma?
>
>Also the t in tags is highlighted.
>
>I even tried different versions of Python also.
>
>Python 3.10.1 (tags/v3.10.1:2cd268a, Dec  6 2021, 19:10:37) [MSC v.1929 64
>bit (AMD64)] on win32
>
>Type "help", "copyright", "credits" or "license()" for more information.
>
>print("Hello World")
>
>Hello World
>
>input("\n\nPress the enter key to exit.")

You're only supposed to enter the lines:

print("Hello World")

and

input("\n\nPress the enter key to exit.")

The other lines are showing you the output you should see.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: keep getting a syntax error on the very first program I am running

[MRAB]

On 2022-01-15 01:12, Bob Griffin wrote:

I am running this program and keep getting this error.  Is this normal?



Invalid syntax.  Perhaps you forgot a comma?



Also the t in tags is highlighted.



I even tried different versions of Python also.



Python 3.10.1 (tags/v3.10.1:2cd268a, Dec  6 2021, 19:10:37) [MSC v.1929 64
bit (AMD64)] on win32

Type "help", "copyright", "credits" or "license()" for more information.

print("Hello World")

Hello World

input("\n\nPress the enter key to exit.")

I get an error only if I use the entirety of it as a program. Is that 
what you're doing, perhaps?


It's not actually a program, but the output from an interactive session.

You start IDLE (I'm assuming that what you're using) and it prints:

Python 3.10.1 (tags/v3.10.1:2cd268a, Dec  6 2021, 19:10:37) [MSC 
v.1929 64

bit (AMD64)] on win32

and then shows a prompt.

At the prompt you type:

print("Hello World")

and it print the response:

Hello World

and so on.
--
https://mail.python.org/mailman/listinfo/python-list

keep getting a syntax error on the very first program I am running

[Bob Griffin]

   I am running this program and keep getting this error.  Is this normal?



   Invalid syntax.  Perhaps you forgot a comma?



   Also the t in tags is highlighted.



   I even tried different versions of Python also.



   Python 3.10.1 (tags/v3.10.1:2cd268a, Dec  6 2021, 19:10:37) [MSC v.1929 64
   bit (AMD64)] on win32

   Type "help", "copyright", "credits" or "license()" for more information.

   print("Hello World")

   Hello World

   input("\n\nPress the enter key to exit.")







   Sent from [1]Mail for Windows



References

   Visible links
   1. https://go.microsoft.com/fwlink/?LinkId=550986
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue45522] Allow to build Python without freelists

[STINNER Victor]

STINNER Victor  added the comment:

> Freelists for object structs can now be disabled. A new configure option 
> --without-freelists can be used to disable all freelists except empty tuple 
> singleton. (Contributed by Christian Heimes in bpo-45522)

Can you please document the new configuration option in 
https://docs.python.org/dev/using/configure.html ?

When you write :option:`--without-freelists` in what's new in Python 3.11 to 
get a link ;-)

--
nosy: +vstinner

___
Python tracker 

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

[issue40255] Fixing Copy on Writes from reference counting

[STINNER Victor]

STINNER Victor  added the comment:

I just want to say that GOOGLE_ETERNAL_REFCOUNT_SUPPORT is a cool name :-D I 
love "eternal refcount"!

--

___
Python tracker 

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

[issue46367] multiprocessing's "spawn" doesn't actually use spawn

[STINNER Victor]

STINNER Victor  added the comment:

> It appears the `multiprocessing`'s "spawn" mode doesn't actually use POSIX 
> spawn, but instead uses fork+exec[1].

The documentation doesn't pretend to use posix_spawn(). It only says: "starts a 
fresh python interpreter process".
https://docs.python.org/dev/library/multiprocessing.html#contexts-and-start-methods

I suggest to close the issue as "not a bug". I don't see anything wrong in the 
current documentation.

--

posix_spawn() is a function of the C library. It is implemented as fork+exec on 
most operating systems. I'm only aware of macOS which has a dedicated syscall. 
Well, posix_spawn() implementation is usually faster thanks to some 
optimizations.

Python has os.posix_spawn() since Python 3.8.

The subprocess can use os.posix_spawn() on Linux under some conditions:
https://docs.python.org/dev/whatsnew/3.8.html#optimizations

Sadly, it's not used by default, since close_fds=True remains 
subprocess.Popen() default.

I'm open to use it on more platforms. os.posix_spawn() can only be used if it 
reports properly errors to the parent process, and some other things and bugs. 
It's a complex function!

--

Oh, about multiprocessing. Well, someone has to propose a patch! I don't know 
why multiprocessing uses directly _posixsubprocess.fork_exec() rather than the 
subprocess module. It's also a complex module with many specific constraints.

posix_spawn() looks nice, but it cannot be used in many cases :-(

--

___
Python tracker 

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

[issue20281] [doc] time.strftime %z format specifier is the same as %Z

[miss-islington]

miss-islington  added the comment:


New changeset f869b56fe4be416d356fffc94b8b18fe65039929 by Miss Islington (bot) 
in branch '3.9':
bpo-20281, bpo-29964: update datetime docs to refer %z and %Z to a pre-existing 
footnote (GH-30354)
https://github.com/python/cpython/commit/f869b56fe4be416d356fffc94b8b18fe65039929


--

___
Python tracker 

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

[issue29964] [doc] %z directive has no effect on the output of time.strptime

[miss-islington]

miss-islington  added the comment:


New changeset f869b56fe4be416d356fffc94b8b18fe65039929 by Miss Islington (bot) 
in branch '3.9':
bpo-20281, bpo-29964: update datetime docs to refer %z and %Z to a pre-existing 
footnote (GH-30354)
https://github.com/python/cpython/commit/f869b56fe4be416d356fffc94b8b18fe65039929


--

___
Python tracker 

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

[issue20281] [doc] time.strftime %z format specifier is the same as %Z

[miss-islington]

miss-islington  added the comment:


New changeset 93dc1654dc3c925c062e19f0ef8587aa8961ef8a by Miss Islington (bot) 
in branch '3.10':
bpo-20281, bpo-29964: update datetime docs to refer %z and %Z to a pre-existing 
footnote (GH-30354)
https://github.com/python/cpython/commit/93dc1654dc3c925c062e19f0ef8587aa8961ef8a


--

___
Python tracker 

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

[issue29964] [doc] %z directive has no effect on the output of time.strptime

[miss-islington]

miss-islington  added the comment:


New changeset 93dc1654dc3c925c062e19f0ef8587aa8961ef8a by Miss Islington (bot) 
in branch '3.10':
bpo-20281, bpo-29964: update datetime docs to refer %z and %Z to a pre-existing 
footnote (GH-30354)
https://github.com/python/cpython/commit/93dc1654dc3c925c062e19f0ef8587aa8961ef8a


--

___
Python tracker 

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

[issue46242] Improve error message when attempting to extend an enum with `__call__`

[Alex Waygood]

Change by Alex Waygood :


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

[Python-announce] [RELEASE] Python 3.10.2, 3.9.10, and 3.11.0a4 are now available

[Łukasz Langa]

Hi there,
before we begin the usual round of release notes, please do note that the three 
new versions of Python released today do not contain Windows installers yet. 
This is temporary, due to a more complex than expected code signing certificate 
renewal.
We’ve held the releases all week while the situation is getting resolved but 
the urgency of 3.10.2 in particular made us release without the Windows 
installers after all. We apologize for the inconvenience and are doing 
everything we can to put the Windows installer in place as soon as possible.

We’re rooting for both Ee Durbin and Steve Dower who are helping us resolve 
this. Thanks for your hard work! Hopefully, by this time next week, this will 
only be a footnote in release management history.

The releases you’re looking at were all cursed in some way. What a way to start 
2022! Besides the certificate hold up, Python 3.10.2 is an expedited release 
(you’ll want to upgrade, read below!), Python 3.11.0a4 had almost 20 (sic, 
twenty!) release blockers before being finally green, and Python 3.9.10 was 
made from a new M1 Mac on macOS Monterey which made the usually boring process 
quite a ride. We’re hoping 2022 won’t be this intense all year!


 
Python
 3.10.2

Get it here: https://www.python.org/downloads/release/python-3102/ 
  

This is a special bugfix release ahead of schedule to address a memory leak 
that was happening on certain function calls when using Cython 
. The memory leak consisted of a small 
constant amount of bytes in certain function calls from Cython code. Although 
in most cases this was not very noticeable, it was very impactful for 
long-running applications and certain usage patterns. Check bpo-46347 
 for more information.

Upgrading existing Python 3.10 installations is highly recommended. Even though 
this is an expedited release, it still contains over 100 other bug fixes. See 
the change log  
for details.

The next Python 3.10 maintenance release will be 3.10.3, currently scheduled 
for 2022-04-04.


 
Python
 3.9.10

Get it here: https://www.python.org/downloads/release/python-3910/  

Python 3.9.10 is the ninth maintenance release of the legacy 3.9 series. Note: 
Python 3.10 is now the latest feature release series of Python 3.

Python 3.9 micro-releases enter double digits! There’s been 130 commits since 
3.9.9 which is a higher number of fixes for this stage of the life cycle 
compared to 3.8. See the changelog 
 for details on 
what changed.

As a reminder, on macOS, the default installer is now the new universal2 
variant. It’s compatible with Mac OS X 10.9 and newer, including macOS 11 Big 
Sur and macOS 12 Monterey. Python installed with this variant will work 
natively on Apple Silicon processors.

The next Python 3.9 maintenance release will be 3.9.11, currently scheduled for 
Pi Day '22 (2022-03-14).


 
Python
 3.11.0a4

Get it here: https://www.python.org/downloads/release/python-3110a4/  

Python 3.11 is still in development. This release, 3.11.0a4, is the fourth of 
seven planned alpha releases.

Alpha releases are intended to make it easier to test the current state of new 
features and bug fixes by the community, as well as to test the release process.

During the alpha phase, features may be added up until the start of the beta 
phase (2022-05-06) and, if necessary, may be modified or deleted up until the 
release candidate phase (2022-08-01). Please keep in mind that this is a 
preview release and its use is not recommended for production environments.

Many new features for Python 3.11 are still being planned and written. Among 
the new major new features and changes so far:

PEP 657  – Include Fine-Grained 
Error Locations in Tracebacks
PEP 654  – Exception Groups and 
except*
The Faster CPython Project  is already 
yielding some exciting results: this version of CPython 3.11 is ~ 19% faster on 
the geometric mean of the PyPerformance benchmarks <>, compared to 3.10.0.
(Hey, fellow core developer, if a feature you find important is missing from 
this list, let Pablo know .)
The next pre-release of Python 3.11 will be 3.11.0a5, currently scheduled for 
Wednesday, 2022-02-02.


 

[issue46247] in xml.dom.minidom, Node and DocumentLS appear to be missing __slots__

[Éric Araujo]

Change by Éric Araujo :


--
versions:  -Python 3.7, Python 3.8

___
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.2, 3.9.10, and 3.11.0a4 are now available

[Łukasz Langa]

Hi there,
before we begin the usual round of release notes, please do note that the three 
new versions of Python released today do not contain Windows installers yet. 
This is temporary, due to a more complex than expected code signing certificate 
renewal.
We’ve held the releases all week while the situation is getting resolved but 
the urgency of 3.10.2 in particular made us release without the Windows 
installers after all. We apologize for the inconvenience and are doing 
everything we can to put the Windows installer in place as soon as possible.

We’re rooting for both Ee Durbin and Steve Dower who are helping us resolve 
this. Thanks for your hard work! Hopefully, by this time next week, this will 
only be a footnote in release management history.

The releases you’re looking at were all cursed in some way. What a way to start 
2022! Besides the certificate hold up, Python 3.10.2 is an expedited release 
(you’ll want to upgrade, read below!), Python 3.11.0a4 had almost 20 (sic, 
twenty!) release blockers before being finally green, and Python 3.9.10 was 
made from a new M1 Mac on macOS Monterey which made the usually boring process 
quite a ride. We’re hoping 2022 won’t be this intense all year!


 
Python
 3.10.2

Get it here: https://www.python.org/downloads/release/python-3102/ 
  

This is a special bugfix release ahead of schedule to address a memory leak 
that was happening on certain function calls when using Cython 
. The memory leak consisted of a small 
constant amount of bytes in certain function calls from Cython code. Although 
in most cases this was not very noticeable, it was very impactful for 
long-running applications and certain usage patterns. Check bpo-46347 
 for more information.

Upgrading existing Python 3.10 installations is highly recommended. Even though 
this is an expedited release, it still contains over 100 other bug fixes. See 
the change log  
for details.

The next Python 3.10 maintenance release will be 3.10.3, currently scheduled 
for 2022-04-04.


 
Python
 3.9.10

Get it here: https://www.python.org/downloads/release/python-3910/  

Python 3.9.10 is the ninth maintenance release of the legacy 3.9 series. Note: 
Python 3.10 is now the latest feature release series of Python 3.

Python 3.9 micro-releases enter double digits! There’s been 130 commits since 
3.9.9 which is a higher number of fixes for this stage of the life cycle 
compared to 3.8. See the changelog 
 for details on 
what changed.

As a reminder, on macOS, the default installer is now the new universal2 
variant. It’s compatible with Mac OS X 10.9 and newer, including macOS 11 Big 
Sur and macOS 12 Monterey. Python installed with this variant will work 
natively on Apple Silicon processors.

The next Python 3.9 maintenance release will be 3.9.11, currently scheduled for 
Pi Day '22 (2022-03-14).


 
Python
 3.11.0a4

Get it here: https://www.python.org/downloads/release/python-3110a4/  

Python 3.11 is still in development. This release, 3.11.0a4, is the fourth of 
seven planned alpha releases.

Alpha releases are intended to make it easier to test the current state of new 
features and bug fixes by the community, as well as to test the release process.

During the alpha phase, features may be added up until the start of the beta 
phase (2022-05-06) and, if necessary, may be modified or deleted up until the 
release candidate phase (2022-08-01). Please keep in mind that this is a 
preview release and its use is not recommended for production environments.

Many new features for Python 3.11 are still being planned and written. Among 
the new major new features and changes so far:

PEP 657  – Include Fine-Grained 
Error Locations in Tracebacks
PEP 654  – Exception Groups and 
except*
The Faster CPython Project  is already 
yielding some exciting results: this version of CPython 3.11 is ~ 19% faster on 
the geometric mean of the PyPerformance benchmarks <>, compared to 3.10.0.
(Hey, fellow core developer, if a feature you find important is missing from 
this list, let Pablo know .)
The next pre-release of Python 3.11 will be 3.11.0a5, currently scheduled for 
Wednesday, 2022-02-02.


 

[issue29985] make install doesn't seem to support --quiet

[Irit Katriel]

Change by Irit Katriel :


--
versions:  -Python 3.11, Python 3.6, Python 3.7, Python 3.8

___
Python tracker 

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

[issue46379] itertools.product reference implementation creates temporaries

[Markus Wallerberger]

Markus Wallerberger  added the comment:

> To a person well versed in recursion and in generator chains it makes sense 
> but not so much for anyone else.

There I pretty much fundamentally disagree.  I find the version in the docs 
much more magical in the sense that it builds up "laterally", i.e., 
level-by-level, rather than element-by-element.

Also, I think from a functional programming perspective, which, let's face it, 
is what these iteration/generator tools are really modelling, a recursive 
version is much more natural.  It also generalizes nicely to other problems 
which people may be having -- so it has the added benefit of explaining the 
code and teaching people useful patterns.

Take the itertools.permutation as an example:  writing that as it was in the 
reference implementation the code is IMHO pretty opaque and hard to reason 
about.  Write it in a recursive style and both its working and correctness is 
immediately obvious.

>  Plus it is hard to step through by hand to see what it is doing.

This I agree with.

Anyway, thanks for taking the time to explain the rejection.

--

___
Python tracker 

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

[issue29964] [doc] %z directive has no effect on the output of time.strptime

[Paul Pinterits]

Change by Paul Pinterits :


--
nosy:  -Paul Pinterits

___
Python tracker 

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

[issue29985] make install doesn't seem to support --quiet

[Ken Williams]

Ken Williams  added the comment:

Thanks Irit - yes, the behavior with 3.9 and 3.10 is the same, and their 
Makefiles seem to have the same unguarded `echo` statements emitting the output.

--

___
Python tracker 

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

[issue29964] [doc] %z directive has no effect on the output of time.strptime

[miss-islington]

Change by miss-islington :


--
pull_requests: +28811
pull_request: https://github.com/python/cpython/pull/30609

___
Python tracker 

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

[issue29964] [doc] %z directive has no effect on the output of time.strptime

[Brett Cannon]

Brett Cannon  added the comment:


New changeset 305588c67cdede4ef127ada90c1557bc1ef7c200 by Hugo van Kemenade in 
branch 'main':
bpo-20281, bpo-29964: update datetime docs to refer %z and %Z to a pre-existing 
footnote (GH-30354)
https://github.com/python/cpython/commit/305588c67cdede4ef127ada90c1557bc1ef7c200


--

___
Python tracker 

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

[issue29964] [doc] %z directive has no effect on the output of time.strptime

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 7.0 -> 8.0
pull_requests: +28809
pull_request: https://github.com/python/cpython/pull/30608

___
Python tracker 

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

[issue20281] [doc] time.strftime %z format specifier is the same as %Z

[miss-islington]

Change by miss-islington :


--
pull_requests: +28810
pull_request: https://github.com/python/cpython/pull/30609

___
Python tracker 

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

[issue20281] [doc] time.strftime %z format specifier is the same as %Z

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 7.0 -> 8.0
pull_requests: +28808
pull_request: https://github.com/python/cpython/pull/30608

___
Python tracker 

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

[issue20281] [doc] time.strftime %z format specifier is the same as %Z

[Brett Cannon]

Brett Cannon  added the comment:


New changeset 305588c67cdede4ef127ada90c1557bc1ef7c200 by Hugo van Kemenade in 
branch 'main':
bpo-20281, bpo-29964: update datetime docs to refer %z and %Z to a pre-existing 
footnote (GH-30354)
https://github.com/python/cpython/commit/305588c67cdede4ef127ada90c1557bc1ef7c200


--
nosy: +brett.cannon

___
Python tracker 

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

[issue46242] Improve error message when attempting to extend an enum with `__call__`

[Ethan Furman]

Ethan Furman  added the comment:


New changeset e674e48ddc2712f28cc7ecdc66a6c328066694b0 by Nikita Sobolev in 
branch 'main':
bpo-46242: [Enum] better error message for extending `Enum` with members 
(GH-30357)
https://github.com/python/cpython/commit/e674e48ddc2712f28cc7ecdc66a6c328066694b0


--

___
Python tracker 

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

[issue43476] Enabling access to showsyntaxerror for IDLE's shell

[Andre Roberge]

Andre Roberge  added the comment:

As far as I am concerned, this issue can be closed. I have found a workaround 
which allows me to reproduce and analyze the SyntaxError that are not captured 
by custom exception hook.

--

___
Python tracker 

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

[issue46382] dataclass(slots=True) does not account for slots in base classes

[Eric V. Smith]

Eric V. Smith  added the comment:

I'll have to do some more research. But your analysis looks correct to me, so 
far.

--
assignee:  -> eric.smith
nosy: +eric.smith

___
Python tracker 

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

[issue46380] `test_functools.TestLRU` must not use `functools` module directly

[Raymond Hettinger]

Change by Raymond Hettinger :


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

[issue46380] `test_functools.TestLRU` must not use `functools` module directly

[Raymond Hettinger]

Raymond Hettinger  added the comment:


New changeset c5640ef87511c960e339af37b486678788be910a by Nikita Sobolev in 
branch 'main':
bpo-46380: Apply tests to both C and Python version (GH-30606)
https://github.com/python/cpython/commit/c5640ef87511c960e339af37b486678788be910a


--

___
Python tracker 

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

Re: Using PIP in Python 3.10 on Windows 10

[Eryk Sun]

On 1/14/22, Mats Wichmann  wrote:
> On 1/14/22 10:40, Jonathan Gossage wrote:
>
> By this do you mean the python.org installer or the Microsoft Store
> installer - they're similar but have some differences.

Jonathan is not using the store app. The store app is installed to the
system in "%ProgramFiles%\WindowsApps" and "%ProgramData%\Packages",
and in each user's "%LocalAppData%\Packages". The user's enabled app
aliases are created in "%LocalAppData%\Microsoft\WindowsApps".

>> It looks as if the launcher is expecting to find Python installed at
>> c:\Program Files\Python3.10 whereas it has actually been installed at
>> D:\Users\jgoss\AppData\local\python\python3.10.
>
> earlier you said "non-standard location" but that's not non-standard at
> all, that's actually the standard place for the python.org installer to
> put it if you requested a single user install (as opposed to a
> system-wide one).

Jonathan did not install to a standard location. The standard location
for a per-user installation is
"%LocalAppData%\Programs\Python\PythonXY[-32]". If "%LocalAppdata%" is
"D:\Users\jgoss\AppData\local", then the standard location for 64-bit
3.10 would be "D:\Users\jgoss\AppData\local\Programs\Python\Python310".

> If you can find Python, whether it's called "python" or "py" in your
> case, then you should be able to reach pip with "python -m pip" or "py
> -m pip".  If you're using the python.org version, you probably want to
> use "py" to launch Python.

Upgrading pip in Windows always requires running the module with `-m
pip`. By default the py launcher is installed, in which case pip 3.10
can be upgraded with the following command:

py -3.10 -m pip install --upgrade pip

If Python is installed for all users, the above command may require
elevating to get administrator access. Afterwards you can use the
"pip.exe" launcher, but first check `where.exe pip` to make sure the
first one found is the right one. If not, modify your per-user and/or
system PATH to fix it.
-- 
https://mail.python.org/mailman/listinfo/python-list

[Python-announce] NumPy 1.22.1 has been released.

[Charles R Harris]

Hi All,

On behalf of the NumPy team, I'm pleased to announce the release of NumPy
1.22.1. NumPy 1.22.1 fixes several bugs discovered after the 1.22.0
release. Notable fixes are:

   - Fix for f2PY docstring problems (SciPy)
   - Fix for reduction type problems (AstroPy)
   - Fixes for various typing bugs.

The Python versions supported in this release are 3.8-3.10.  Wheels can be
downloaded from PyPI ; source
archives, release notes, and wheel hashes are available on Github
. Linux users will
need pip >= 0.19.3 in order to install the manylinux2014 wheels. A recent
version of pip is needed to install the universal2 macos wheels.

*Contributors*

A total of 14 people contributed to this release.  People with a "+" by
their
names contributed a patch for the first time.

   - Arryan Singh
   - Bas van Beek
   - Charles Harris
   - Denis Laxalde
   - Isuru Fernando
   - Kevin Sheppard
   - Matthew Barber
   - Matti Picus
   - Melissa Weber Mendonça
   - Mukulika Pahari
   - Omid Rajaei +
   - Pearu Peterson
   - Ralf Gommers
   - Sebastian Berg


*Pull requests merged*
A total of 20 pull requests were merged for this release.

   - #20702: MAINT, DOC: Post 1.22.0 release fixes.
   - #20703: DOC, BUG: Use pngs instead of svgs.
   - #20704: DOC: Fixed the link on user-guide landing page
   - #20714: BUG: Restore vc141 support
   - #20724: BUG: Fix array dimensions solver for multidimensional
   arguments...
   - #20725: TYP: change type annotation for ``__array_namespace__`` to
   ModuleType
   - #20726: TYP, MAINT: Allow ``ndindex`` to accept integer tuples
   - #20757: BUG: Relax dtype identity check in reductions
   - #20763: TYP: Allow time manipulation functions to accept ``date`` and
   ``timedelta``...
   - #20768: TYP: Relax the type of ``ndarray.__array_finalize__``
   - #20795: MAINT: Raise RuntimeError if setuptools version is too recent.
   - #20796: BUG, DOC: Fixes SciPy docs build warnings
   - #20797: DOC: fix OpenBLAS version in release note
   - #20798: PERF: Optimize array check for bounded 0,1 values
   - #20805: BUG: Fix that reduce-likes honor out always (and live in the...
   - #20806: BUG: ``array_api.argsort(descending=True)`` respects
   relative...
   - #20807: BUG: Allow integer inputs for pow-related functions in
   ``array_api``
   - #20814: DOC: Refer to NumPy, not pandas, in main page
   - #20815: DOC: Update Copyright to 2022 [License]
   - #20819: BUG: Return correctly shaped inverse indices in array_api
   set...

Cheers,

Charles Harris
___
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

[issue46379] itertools.product reference implementation creates temporaries

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Please do keep looking for improvements.  Suggestions are always welcome.

--

___
Python tracker 

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

[issue46379] itertools.product reference implementation creates temporaries

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Markus, thank you for the suggestion but I'm going to decline.  When this rough 
equivalent was first created, we looked at several recipes and chose this one 
as being one of the least magical.  Intentionally, we did not use the variant 
you've proposed.  To a person well versed in recursion and in generator chains 
it makes sense but not so much for anyone else.  Plus it is hard to step 
through by hand to see what it is doing.

In general, the rough equivalents were intended to a way to understand what 
output is going to be generated.  That is why they are mostly simple rather 
than being faithful to the actual implementations (otherwise, we would use 
classes rather than generators for all the equivalents).  Viewed in this light, 
we place almost zero weight to making the recipe memory efficient with respect 
to temporary variables.

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

[issue46379] itertools.product reference implementation creates temporaries

[Raymond Hettinger]

Change by Raymond Hettinger :


--
assignee: docs@python -> rhettinger

___
Python tracker 

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

[issue46380] `test_functools.TestLRU` must not use `functools` module directly

[Raymond Hettinger]

Change by Raymond Hettinger :


--
assignee:  -> rhettinger
nosy: +rhettinger

___
Python tracker 

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

[issue46133] Feature request: allow mechanism for creator of exec-generated code to provide source to pdb

[Matt B]

Matt B  added the comment:

Please treat this as a feature request to add the ability for pdb (and 
internals) to ingest sources for exec-generated code.

--

___
Python tracker 

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

[issue46133] Feature request: allow mechanism for creator of exec-generated code to provide source to pdb

[Irit Katriel]

Change by Irit Katriel :


--
nosy:  -iritkatriel

___
Python tracker 

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

[issue46133] Feature request: allow mechanism for creator of exec-generated code to provide source to pdb

[Irit Katriel]

Change by Irit Katriel :


--
stage: resolved -> 
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

[issue46133] Feature request: allow mechanism for creator of exec-generated code to provide source to pdb

[Matt B]

Change by Matt B :


--
resolution: not a bug -> 

___
Python tracker 

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

[issue46133] Feature request: allow mechanism for creator of exec-generated code to provide source to pdb

[Matt B]

Change by Matt B :


--
status: closed -> open
title: Unclear whether one can (or how to) provide source to exec-generated 
code -> Feature request: allow mechanism for creator of exec-generated code to 
provide source to pdb
type: behavior -> enhancement

___
Python tracker 

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

[issue46017] Tutorial incorrectly refers to skits rather than sketches.

[Irit Katriel]

Irit Katriel  added the comment:

I asked a Monty Python expert and he said I should close this.

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

[issue46317] Pathlib.rename isn't robust

[Barney Gale]

Barney Gale  added the comment:

shutil.move() accepts a `copy_function` argument:

shutil.move(src, dst, copy_function=copy2)

It's possible to set `copy_function=copy` to skip copying file metadata.

--

___
Python tracker 

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

[issue40280] Consider supporting emscripten/webassembly as a build target

[Christian Heimes]

Change by Christian Heimes :


--
dependencies: +_zoneinfo module_free has invalid function signature

___
Python tracker 

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

[issue46383] _zoneinfo module_free has invalid function signature

[Christian Heimes]

Change by Christian Heimes :


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

___
Python tracker 

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

[issue46383] _zoneinfo module_free has invalid function signature

[Christian Heimes]

New submission from Christian Heimes :

The zoneinfo C extension has the "freefunc m_free" function with signature 
"static void module_free(void)". The signature of freefunc is "void 
(*freefunc)(void *)". It takes a void * argument, but module_free() does not.

The signature mismatch is not a problem for most C compilers. But Web Assembly 
is more strict. wasm32-emscripten fails and aborts at runtime:

worker.js onmessage() captured an uncaught exception: RuntimeError: function 
signature mismatch
Pthread 0x8a1df0 sent an error! undefined:undefined: function signature mismatch

/python-wasm/cpython/builddir/node/python.js:158
   throw ex;
   ^
Error [RuntimeError]: function signature mismatch
at module_dealloc (:wasm-function[1883]:0x9a15e)
at _Py_Dealloc (:wasm-function[1959]:0x9eabe)
at insertdict (:wasm-function[1624]:0x87ccb)
at _PyDict_SetItem_Take2 (:wasm-function[1622]:0x8749c)
at dict_ass_sub (:wasm-function[1708]:0x8e604)
at PyObject_SetItem (:wasm-function[486]:0x34221)
at finalize_modules (:wasm-function[3644]:0x1703d0)
at Py_FinalizeEx (:wasm-function[3641]:0x16f986)
at Py_RunMain (:wasm-function[4055]:0x191124)
at pymain_main (:wasm-function[4058]:0x19174d)
Emitted 'error' event on process instance at:
at emitUnhandledRejectionOrErr (internal/event_target.js:579:11)
at MessagePort.[nodejs.internal.kHybridDispatch] 
(internal/event_target.js:403:9)
at MessagePort.exports.emitMessage 
(internal/per_context/messageport.js:18:26)

--
assignee: christian.heimes
components: Extension Modules
messages: 410594
nosy: christian.heimes, p-ganssle
priority: normal
severity: normal
status: open
title: _zoneinfo module_free has invalid function signature
type: crash
versions: Python 3.10, 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

[issue46317] Pathlib.rename isn't robust

[Oz Tiram]

Oz Tiram  added the comment:

@barney, I am not sure that I understand your question.

I think adding another method `Pathlib.Path` and `Pathlib._Accessor` is my 
preferred way. The would be something like:

class _NormalAccessor(_Accessor):
   ...
   self.move = shutil.move


class Path:
   

   def move(self, src, dest):
  self._accessor.move(self, target)
  return self.__class__(target)


Now, this is hardly a patch. I need to submit a PR with proper docs, tests and 
NEWS entry... I will be glad to work on it. However, I guess I need someone to 
"sponsor" it and merge it.

--

___
Python tracker 

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

[issue40255] Fixing Copy on Writes from reference counting

[Gregory P. Smith]

Gregory P. Smith  added the comment:

[data] I finally dug up the old YouTube doc at work with their findings. Mostly 
just posting this here for future public reference if anyone wants. Nothing 
surprising.

When youtube experimented with a modified 2.7 adding "eternal refcounts" in 
2015, they saw a 3-5% CPU performance regression. (not the 10% I had in my mind)

Their version of this simply set a high bit on the refcount as the indicator 
and added the obvious conditional into the Py_INCREF/Py_DECREF macros.

Unsurprisingly in line with what others have since found. For their preforked 
server and decision of what to mark eternal before forking, it saved them 10% 
ram (fewer copy on writes). The -ram vs +cpu +maintenance cost tradeoff wound 
up not being worthwhile to them though. Their motivation for trying was 
entirely COW memory savings.

=== CPython 2.7 object.h modification they used:

```
+#ifdef GOOGLE_ETERNAL_REFCOUNT_SUPPORT
+
+#define PY_ETERNAL_REFCOUNT (PY_SSIZE_T_MAX / 2)
+
+#define Py_IS_ETERNAL(op) (   \
+  ((PyObject*)(op))->ob_refcnt >= PY_ETERNAL_REFCOUNT)
+
+#define Py_SET_ETERNAL(op)\
+  do {\
+  ((PyObject*)(op))->ob_refcnt = PY_ETERNAL_REFCOUNT; \
+  if (PyObject_IS_GC(op)) {   \
+PyObject_GC_UnTrack(op);  \
+  }   \
+  } while (0)
+
+#define Py_INCREF(op) (   \
+  Py_IS_ETERNAL(op)   \
+?  PY_ETERNAL_REFCOUNT\
+:  (_Py_INC_REFTOTAL  _Py_REF_DEBUG_COMMA \
+   ((PyObject*)(op))->ob_refcnt++)\
+  )
+
+#define Py_DECREF(op)   \
+do {\
+if (Py_IS_ETERNAL(op)) break;   \
+if (_Py_DEC_REFTOTAL  _Py_REF_DEBUG_COMMA   \
+--((PyObject*)(op))->ob_refcnt != 0)\
+_Py_CHECK_REFCNT(op)\
+else\
+_Py_Dealloc((PyObject *)(op));  \
+} while (0)
+
+#else
```

--

___
Python tracker 

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

[issue46382] dataclass(slots=True) does not account for slots in base classes

[Arie Bovenberg]

New submission from Arie Bovenberg :

@dataclass(slots=True) adds slots to dataclasses. It adds a slot per field. 
However, it doesn't account for slots already present in base classes:

>>> class Base:
... __slots__ = ('a', )
...
>>> @dataclass(slots=True)
... class Foo(Base):
... a: int
... b: float
...
>>> Foo.__slots__
('a', 'b')  # should be: ('b', )


The __slots__ documentation says:

If a class defines a slot also defined in a base class, the instance 
variable 
defined by the base class slot is inaccessible (except by retrieving its 
descriptor 
directly from the base class). This renders the meaning of the program 
undefined. 
In the future, a check may be added to prevent this.

Solution: don't add slots which are already defined in any base classes:

>>> @dataclass
... class Bla(Base):
... __slots__ = ('b', )
... a: int
... b: float
...
>>> Bla(4, 5.65)
Bla(a=4, b=5.65)

If you agree, I'd like to submit a PR to fix this. I already have a prototype 
working.

--
components: Library (Lib)
messages: 410591
nosy: ariebovenberg
priority: normal
severity: normal
status: open
title: dataclass(slots=True) does not account for slots in base classes
type: behavior
versions: Python 3.10, Python 3.11

___
Python tracker 

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

[issue46317] Pathlib.rename isn't robust

[Barney Gale]

Barney Gale  added the comment:

Sounds good. Would you expose the `copy_function` argument in pathlib, or do 
something else (like `metadata=True`)?

--
nosy: +barneygale

___
Python tracker 

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

Re: Using PIP in Python 3.10 on Windows 10

[MRAB]

On 2022-01-14 17:40, Jonathan Gossage wrote:

I have installed Python 3.10.1 on Windows 10 using the recommended Windows
Installer. When I try to access PIP from the command line, I get the
following result, even though Python itself is accessible.


C:\Users\jgoss>python
Python 3.10.1 (tags/v3.10.1:2cd268a, Dec  6 2021, 19:10:37) [MSC v.1929 64
bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.

quit()


C:\Users\jgoss>pip install pip --upgrade
Fatal error in launcher: Unable to create process using '"C:\Program
Files\Python310\python.exe"  "C:\Program Files\Python310\Scripts\pip.exe"
install pip --upgrade': The system cannot find the file specified.
During the installation, I chose to install Python in a non-default
location and to set the Environment variables.
  The result of this attempt is shown below:


C:\Users\jgoss>python
Python 3.10.1 (tags/v3.10.1:2cd268a, Dec  6 2021, 19:10:37) [MSC v.1929 64
bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.

quit()


C:\Users\jgoss>pip install pip --upgrade
Fatal error in launcher: Unable to create process using '"C:\Program
Files\Python310\python.exe"  "C:\Program Files\Python310\Scripts\pip.exe"
install pip --upgrade': The system cannot find the file specified.

It looks as if the launcher is expecting to find Python installed at
c:\Program Files\Python3.10 whereas it has actually been installed at
D:\Users\jgoss\AppData\local\python\python3.10. It seems that the launcher
has not been updated to the latest installation location for python and
that it also needs to handle a non-default install location. The same
problem occurs if I take the install option to install to the default
location.
Is there any workaround as PIP is essential to my environment?

These days it's recommended that you use the Python Launcher and the pip 
module:


py -m pip install pip --upgrade
--
https://mail.python.org/mailman/listinfo/python-list

Re: Using PIP in Python 3.10 on Windows 10

[Mats Wichmann]

On 1/14/22 10:40, Jonathan Gossage wrote:
> I have installed Python 3.10.1 on Windows 10 using the recommended Windows
> Installer. When I try to access PIP from the command line, I get the
> following result, even though Python itself is accessible.

By this do you mean the python.org installer or the Microsoft Store
installer - they're similar but have some differences.

> 
> 
> C:\Users\jgoss>python
> Python 3.10.1 (tags/v3.10.1:2cd268a, Dec  6 2021, 19:10:37) [MSC v.1929 64
> bit (AMD64)] on win32
> Type "help", "copyright", "credits" or "license" for more information.
 quit()
> 
> C:\Users\jgoss>pip install pip --upgrade
> Fatal error in launcher: Unable to create process using '"C:\Program
> Files\Python310\python.exe"  "C:\Program Files\Python310\Scripts\pip.exe"
> install pip --upgrade': The system cannot find the file specified.
> During the installation, I chose to install Python in a non-default
> location and to set the Environment variables.
>  The result of this attempt is shown below:
> 
> 
> C:\Users\jgoss>python
> Python 3.10.1 (tags/v3.10.1:2cd268a, Dec  6 2021, 19:10:37) [MSC v.1929 64
> bit (AMD64)] on win32
> Type "help", "copyright", "credits" or "license" for more information.
 quit()
> 
> C:\Users\jgoss>pip install pip --upgrade
> Fatal error in launcher: Unable to create process using '"C:\Program
> Files\Python310\python.exe"  "C:\Program Files\Python310\Scripts\pip.exe"
> install pip --upgrade': The system cannot find the file specified.
> 
> It looks as if the launcher is expecting to find Python installed at
> c:\Program Files\Python3.10 whereas it has actually been installed at
> D:\Users\jgoss\AppData\local\python\python3.10.

earlier you said "non-standard location" but that's not non-standard at
all, that's actually the standard place for the python.org installer to
put it if you requested a single user install (as opposed to a
system-wide one).

>  It seems that the launcher
> has not been updated to the latest installation location for python and
> that it also needs to handle a non-default install location. The same
> problem occurs if I take the install option to install to the default
> location.
> Is there any workaround as PIP is essential to my environment?
> 

If you can find Python, whether it's called "python" or "py" in your
case, then you should be able to reach pip with "python -m pip" or "py
-m pip".  If you're using the python.org version, you probably want to
use "py" to launch Python.

It looks like you're stumbling over the little stub Microsoft leaves
around which isn't Python, but rather, if you call it, issues a prompt
to install from the Microsoft Store.  That might be why the sequnce
being issued doesn't work. That part of the issue might be solvable by
fiddling the order of your PATH environment vars.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue45737] assertLogs to optionally not disable existing handlers

[Irit Katriel]

Change by Irit Katriel :


--
versions:  -Python 3.10, 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

[issue45569] Drop support for 15-bit PyLong digits?

[Mark Dickinson]

Mark Dickinson  added the comment:


New changeset 025cbe7a9b5d3058ce2eb8015d3650e396004545 by Mark Dickinson in 
branch 'main':
bpo-45569: Change PYLONG_BITS_IN_DIGIT default to 30 (GH-30497)
https://github.com/python/cpython/commit/025cbe7a9b5d3058ce2eb8015d3650e396004545


--

___
Python tracker 

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

[issue46133] Unclear whether one can (or how to) provide source to exec-generated code

[Irit Katriel]

Irit Katriel  added the comment:

The source code is read from a file. If there is no file you get OSError, as 
the docstring states.

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

[issue37295] Possible optimizations for math.comb()

[Tim Peters]

Tim Peters  added the comment:

Another trick, building on the last one: computing factorial(k) isn't cheap, in 
time or space, and neither is dividing by it. But we know it will entirely 
cancel out. Indeed, for each outer loop iteration, prod(p) is divisible by the 
current k. But, unlike as in Stefan's code, which materializes range(n, n-k, 
-1) as an explicit list, we have no way to calculate "in advance" which 
elements of p[] are divisible by what.

What we _can_ do is march over all of p[], and do a gcd of each element with 
the current k. If greater than 1, it can be divided out of both that element of 
p[], and the current k. Later, rinse, repeat - the current k must eventually be 
driven to 1 then.

But that slows things down: gcd() is also expensive.

But there's a standard trick to speed that too: as in serious implementations 
of Pollard's rho factorization method, "chunk it". That is, don't do it on 
every outer loop iteration, but instead accumulate the running product of 
several denominators first, then do the expensive gcd pass on that product.

Here's a replacement for "the main loop" of the last code that delays doing 
gcds until the running product is at least 2000 bits:

fold_into_p(n)

kk = 1
for k in range(2, k+1):
n -= 1
# Merge into p[].
fold_into_p(n)
# Divide by k.
kk *= k
if kk.bit_length() < 2000:
continue
for i, pi in enumerate(p):
if pi > 1:
g = gcd(pi, kk)
if g > 1:
p[i] = pi // g
kk //= g
if kk == 1:
break
assert kk == 1
showp()
return prod(x for x in p if x > 1) // kk

That runs in under half the time (for n=100, k=50), down to under 7.5 
seconds. And, of course, the largest denominator consumes only about 2000 bits 
instead of 50!'s 8,744,448 bits.

Raising the kk bit limit from 2000 to 1 cuts another 2.5 seconds off, down 
to about 5 seconds.

Much above that, it starts getting slower again.

Seems to hard to out-think! And highly dubious to fine-tune it based on a 
single input case ;-)

Curious: at a cutoff of 1 bits, we're beyond the point where Karatsuba 
would have paid off for computing denominator partial products too.

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

[issue46367] multiprocessing's "spawn" doesn't actually use spawn

[Irit Katriel]

Change by Irit Katriel :


--
nosy: +vstinner
versions:  -Python 3.7, Python 3.8

___
Python tracker 

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

[issue46381] Improve documentation of CFLAGS_NODIST, LDFLAGS_NODIST

[Irit Katriel]

Change by Irit Katriel :


--
versions:  -Python 3.7, Python 3.8

___
Python tracker 

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

[issue28206] signal.Signals not documented

[Irit Katriel]

Change by Irit Katriel :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.11 -Python 3.6, Python 3.7, Python 3.8

___
Python tracker 

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

[issue46381] Improve documentation of CFLAGS_NODIST, LDFLAGS_NODIST

[Matthias Köppe]

New submission from Matthias Köppe :

The documentation of
- https://docs.python.org/3.11/using/configure.html#envvar-CFLAGS
- https://docs.python.org/3.11/using/configure.html#envvar-CFLAGS_NODIST
- https://docs.python.org/3.11/using/configure.html#envvar-LDFLAGS
- https://docs.python.org/3.11/using/configure.html#envvar-LDFLAGS_NODIST
should explain more clearly that flags such as `-I`, `-L`, etc. and strict 
compiler flags such as `-Werror...` should not be put into `CFLAGS`, `LDFLAGS`, 
or it will make the resulting Python unusable for compiling user packages with 
extension modules via `distutils` and `setuptools`.

Various downstream packagers have provided misconfigured Pythons:
- Homebrew (https://trac.sagemath.org/ticket/31132, 
https://github.com/Homebrew/homebrew-core/pull/68528, resolved)
- Cygwin (https://trac.sagemath.org/ticket/33078, 
https://cygwin.com/pipermail/cygwin/2021-December/250302.html, resolved in a 
proposed package update)
- pyenv (https://trac.sagemath.org/ticket/32531, 
https://github.com/pyenv/pyenv/issues/2204, open)

So this appears to be a documentation / user education issue in CPython.

--
assignee: docs@python
components: Documentation
messages: 410586
nosy: docs@python, matthiaskoeppe
priority: normal
severity: normal
status: open
title: Improve documentation of CFLAGS_NODIST, LDFLAGS_NODIST
type: enhancement
versions: Python 3.10, Python 3.11, 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

[issue46376] PyMapping_Check returns 1 for list

[Aviram]

Aviram  added the comment:

I submitted a draft patch. Using TPFlags alone doesn't cut it as some types are 
excluded (bytes, str, bytearray) in sequence and same for mapping. I'm thinking 
of checking for those cases specifically as those are very very specific 
casings. Would love some input.

--

___
Python tracker 

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

[issue29985] make install doesn't seem to support --quiet

[Irit Katriel]

Irit Katriel  added the comment:

Ken, the output you posted is for 3.7 and 3.8. Is this reproducible on 3.9+? 
(3.8 and lower are no longer maintained).

--
nosy: +iritkatriel

___
Python tracker 

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

[issue41403] Uncaught AttributeError in unittest.mock._get_target

[Irit Katriel]

Change by Irit Katriel :


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

___
Python tracker 

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

[issue46377] TimedRotatingFileHandler "midnight" misleading when interval > 1

[Mike Schiessl]

Mike Schiessl  added the comment:

Yes, enforcing interval == 1 or interval == None (which pulls the 
TimedRotatingFileHandler class __init__ default value which is also 1) works 
perfectly with midnight.

I do not see any urge on that topic - as I personally now know the issue :D - 
but I really feel this fix could save someones else's time someday ;) 

So going the "safe" way via deprecation cycle seems to be the right approach

--

___
Python tracker 

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

[issue46363] Two typos in versions 3.7 document translation of zh_CN

[Irit Katriel]

Irit Katriel  added the comment:

I copied the issue there: https://github.com/python/python-docs-zh-cn/issues/238

--
resolution:  -> third party
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

[issue46376] PyMapping_Check returns 1 for list

[Irit Katriel]

Change by Irit Katriel :


--
type: behavior -> enhancement
versions:  -Python 3.10, 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

[issue46377] TimedRotatingFileHandler "midnight" misleading when interval > 1

[Irit Katriel]

Change by Irit Katriel :


--
type: behavior -> enhancement
versions:  -Python 3.10, 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

[issue46045] NetBSD: do not use POSIX semaphores

[Thomas Klausner]

Thomas Klausner  added the comment:

ping - this patch needs a review

--

___
Python tracker 

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

[issue46053] NetBSD: ossaudio support incomplete

[Thomas Klausner]

Thomas Klausner  added the comment:

ping - this patch needs a review

--

___
Python tracker 

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

[issue31472] "Emulating callable objects" documentation misleading

[Irit Katriel]

Change by Irit Katriel :


--
resolution:  -> works for me
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

[issue46380] `test_functools.TestLRU` must not use `functools` module directly

[Nikita Sobolev]

Change by Nikita Sobolev :


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

___
Python tracker 

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

[issue46380] `test_functools.TestLRU` must not use `functools` module directly

[Nikita Sobolev]

New submission from Nikita Sobolev :

Right now there are two tests in Lib/test/test_functools.py that use 
`functools.lru_cache` directly:
1. 
https://github.com/python/cpython/blame/73140de97cbeb01bb6c9af1da89ecb9355921e91/Lib/test/test_functools.py#L1417
2. 
https://github.com/python/cpython/blame/73140de97cbeb01bb6c9af1da89ecb9355921e91/Lib/test/test_functools.py#L1429

But, I don't think it is correct. Why?

```python
class TestLRUPy(TestLRU, unittest.TestCase):
module = py_functools

class TestLRUC(TestLRU, unittest.TestCase):
module = c_functools
```

Source: 
https://github.com/python/cpython/blame/73140de97cbeb01bb6c9af1da89ecb9355921e91/Lib/test/test_functools.py#L1798-L1823

So, what can we do?

1. Use `self.module.lru_cache` instead (I think it is the right way)
2. Move them to `TestLRUPy`, but I don't think they should be python-specific

--
components: Tests
messages: 410579
nosy: sobolevn
priority: normal
severity: normal
status: open
title: `test_functools.TestLRU`  must not use `functools` module directly
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

[issue23183] timeit CLI best of 3: undocumented output format

[Irit Katriel]

Change by Irit Katriel :


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

[issue23183] timeit CLI best of 3: undocumented output format

[miss-islington]

miss-islington  added the comment:


New changeset 9badf6895a9bc1b01b2d6b2fb35419e7c5523ce6 by Miss Islington (bot) 
in branch '3.9':
bpo-23183: Document the timeit output (GH-30359)
https://github.com/python/cpython/commit/9badf6895a9bc1b01b2d6b2fb35419e7c5523ce6


--

___
Python tracker 

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

[issue40280] Consider supporting emscripten/webassembly as a build target

[Christian Heimes]

Christian Heimes  added the comment:


New changeset ee1a8b336d30476e9635a6826f61a99fc3604159 by Christian Heimes in 
branch 'main':
bpo-40280: Block more syscalls that are causing crashes in tests (GH-30601)
https://github.com/python/cpython/commit/ee1a8b336d30476e9635a6826f61a99fc3604159


--

___
Python tracker 

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

[issue23183] timeit CLI best of 3: undocumented output format

[miss-islington]

miss-islington  added the comment:


New changeset 26039d1e0a1da897d28688895126eb8bbd16f2c9 by Miss Islington (bot) 
in branch '3.10':
bpo-23183: Document the timeit output (GH-30359)
https://github.com/python/cpython/commit/26039d1e0a1da897d28688895126eb8bbd16f2c9


--

___
Python tracker 

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

[issue46379] itertools.product reference implementation creates temporaries

[Alex Waygood]

Alex Waygood  added the comment:

(I'm removing 3.6 and 3.7 from the "versions" field, since those two branches 
are now only accepting patches if it relates to security.)

--
nosy: +AlexWaygood, rhettinger
versions:  -Python 3.7, Python 3.8

___
Python tracker 

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

[issue33178] Add support for BigEndianUnion and LittleEndianUnion in ctypes

[David Goncalves]

David Goncalves  added the comment:

Any core developers available to review this PR?

--

___
Python tracker 

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

[issue46379] itertools.product reference implementation creates temporaries

[Markus Wallerberger]

Change by Markus Wallerberger :


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

___
Python tracker 

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

Using PIP in Python 3.10 on Windows 10

[Jonathan Gossage]

I have installed Python 3.10.1 on Windows 10 using the recommended Windows
Installer. When I try to access PIP from the command line, I get the
following result, even though Python itself is accessible.


C:\Users\jgoss>python
Python 3.10.1 (tags/v3.10.1:2cd268a, Dec  6 2021, 19:10:37) [MSC v.1929 64
bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> quit()

C:\Users\jgoss>pip install pip --upgrade
Fatal error in launcher: Unable to create process using '"C:\Program
Files\Python310\python.exe"  "C:\Program Files\Python310\Scripts\pip.exe"
install pip --upgrade': The system cannot find the file specified.
During the installation, I chose to install Python in a non-default
location and to set the Environment variables.
 The result of this attempt is shown below:


C:\Users\jgoss>python
Python 3.10.1 (tags/v3.10.1:2cd268a, Dec  6 2021, 19:10:37) [MSC v.1929 64
bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> quit()

C:\Users\jgoss>pip install pip --upgrade
Fatal error in launcher: Unable to create process using '"C:\Program
Files\Python310\python.exe"  "C:\Program Files\Python310\Scripts\pip.exe"
install pip --upgrade': The system cannot find the file specified.

It looks as if the launcher is expecting to find Python installed at
c:\Program Files\Python3.10 whereas it has actually been installed at
D:\Users\jgoss\AppData\local\python\python3.10. It seems that the launcher
has not been updated to the latest installation location for python and
that it also needs to handle a non-default install location. The same
problem occurs if I take the install option to install to the default
location.
Is there any workaround as PIP is essential to my environment?

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

[issue46379] itertools.product reference implementation creates temporaries

[Markus Wallerberger]

New submission from Markus Wallerberger :

The reference implementation of itertools.product creates large temporaries, 
which we need to remind people of at the top of the code block.

However, using generator magic, we don't need to do this and can even simplify 
the code in the process!  Basically,we iterate over a generator of 
product(*seq[:-1]), and extend each of the values by every value in seq[-1].

--
assignee: docs@python
components: Documentation
messages: 410573
nosy: docs@python, mwallerb
priority: normal
severity: normal
status: open
title: itertools.product reference implementation creates temporaries
type: enhancement
versions: Python 3.10, Python 3.11, 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

[issue23183] timeit CLI best of 3: undocumented output format

[miss-islington]

Change by miss-islington :


--
pull_requests: +28803
pull_request: https://github.com/python/cpython/pull/30604

___
Python tracker 

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

[issue23183] timeit CLI best of 3: undocumented output format

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 6.0 -> 7.0
pull_requests: +28802
pull_request: https://github.com/python/cpython/pull/30603

___
Python tracker 

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

[issue23183] timeit CLI best of 3: undocumented output format

[Irit Katriel]

Irit Katriel  added the comment:


New changeset 73140de97cbeb01bb6c9af1da89ecb9355921e91 by Hugo van Kemenade in 
branch 'main':
bpo-23183: Document the timeit output (GH-30359)
https://github.com/python/cpython/commit/73140de97cbeb01bb6c9af1da89ecb9355921e91


--

___
Python tracker 

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