[issue38558] Data Structures documentation out of sync with new Walrus operator

[Ammar Askar]

Ammar Askar  added the comment:

Thank you for the report Matt!

--
nosy: +ammar2
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
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

[issue35714] Document that the null character '\0' terminates a struct format spec

[Zackery Spytz]

Change by Zackery Spytz :


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

___
Python tracker 

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

Re: a regex question

[dieter]

Maggie Q Roth  writes:
> There are two primary types of lines in the log:
>
> 60.191.38.xx/
> 42.120.161.xx   /archives/1005
>
> I know how to write regex to match each line, but don't get the good result
> with one regex to match both lines.
>
> Can you help?

When I look at these lines, I see 2 fields separated by whitespace
(note that two example lines are very very few to guess the
proper pattern). I would not use a regular expression
in this case, but the `split` string method.

A regular expression for this pattern could be `(\S+)\s+(.*)` which reads
a non-empty sequences of none whitespace (assigned to group 1),
whitespace, any sequence (assigned to group 2)
(note that the regular expression above is given on the
regex level. The string in your Python code may look slightly different).

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

[issue38595] io.BufferedRWPair doc warning may need clarification

[Ryan Govostes]

Ryan Govostes  added the comment:

The origin of this warning involves interleaving read and write operations, and 
was added here: https://bugs.python.org/issue12213

I'm not sure if it applies to sockets, pipes, etc. though.

The pySerial documentation advises using io.BufferedRWPair(x, x) where x is a 
serial device. But this StackOverflow post reports that it is problematic, in 
line with the warning. (The author appears to be talking about Windows.)

https://stackoverflow.com/questions/24498048/python-io-modules-textiowrapper-or-buffererwpair-functions-are-not-playing-nice

--
nosy: +benjamin.peterson, pitrou, stutzbach

___
Python tracker 

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

[issue38595] io.BufferedRWPair doc warning may need clarification

[Ryan Govostes]

New submission from Ryan Govostes :

The documentation for the io.BufferedRWPair class gives this warning:

> BufferedRWPair does not attempt to synchronize accesses to its underlying raw 
> streams. You should not pass it the same object as reader and writer; use 
> BufferedRandom instead.

I have a hard time understanding what this warning is trying to tell me.

1. What does it mean to "synchronize accesses"?

2. Why can't I pass the same object as reader and writer? The docstring in 
_pyio.py says, "This is typically used with a socket or two-way pipe."

3. How does BufferedRandom, which adds the seek() and tell() interfaces, 
address the issue of "synchroniz[ing] accesses"? Is synchronization automatic? 
What does this do for sockets or pipes which cannot seek?

--
assignee: docs@python
components: Documentation
messages: 355404
nosy: docs@python, rgov
priority: normal
severity: normal
status: open
title: io.BufferedRWPair doc warning may need clarification
type: behavior
versions: Python 3.7

___
Python tracker 

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

Re: keying by identity in dict and set

[dieter]

Steve White  writes:
> Regarding my question
>  "Is there some fatal reason that this approach must never be
> used, besides the lack of documentary support for it?"
> If finally dawned on me that there is a use-case for containers that
> would preclude using object identity for keys.  That is, if the object
> is to be serialized, or otherwise stored past the run-time of the
> program.  Of course, all the identities (all the id() values) will be
> meaningless once the current run ends.

One motivation to base dict key management on equality
(rather than identity) are literals:

Consider a dict "d" with at some place
`d["my example key"] = 1` and at a different place
(maybe another function, another module) you access
`d["my example key"]`. You would expect to get `1`
as result as for your eyes the two literals are equal.
Would the key management be based on identity, then
you could get either the expected `1` or a `KeyError`.
The reason: Python does not manage (most) literals globally;
this means, if you use the same literal in different places
you may (or may not) have non-identical objects.

Basing on equality, you are also more flexibal than
with identity, because can can change the equality
rules for a class while you cannot change the identity rules.
Thus, if you need identity based key management,
define your `__eq__` accordingly.

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

[issue38570] Shlex does not parse commands containing single quotes correctly

[Anthony Sottile]

Anthony Sottile  added the comment:

Try with `sh`:

(it prompts for continuation, I pressed ^D to end it)

$ export F=$'\''
> 
> 
> 
> 
> sh: 8: Syntax error: Unterminated quoted string


dollar-sign strings are a `bash` extension, I don't think they're supported by 
*sh*lex (maybe if there was a bashlex module :D)

There's the `posix=False` option to `shlex.split` -- I'm not sure what it 
does/doesn't enable though (the docs aren't thorough here and the code is a bit 
non-obvious):

>>> shlex.split(s, posix=False)
['export', "F=$'\\''"]

--
nosy: +Anthony Sottile

___
Python tracker 

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

[issue38594] importlib.metadata documentation deficiencies

[Gregory Szorc]

New submission from Gregory Szorc :

As I was attempting to implement the find_distributions() interface for 
PyOxidizer, I got confused by importlib.metadata's documentation.

The documentation for this module states:

```
What this means in practice is that to support finding distribution package
metadata in locations other than the file system, you should derive from
``Distribution`` and implement the ``load_metadata()`` method. Then from
your finder, return instances of this derived ``Distribution`` in the
``find_distributions()`` method.
```

The reference to `load_metadata()` is the only occurrence of the string 
`load_metadata` in the CPython and importlib_metadata code bases. I therefore 
believe the documentation in both CPython and the importlib_metadata standalone 
package are wrong because they are referring to a method that is never 
implemented nor called.

Looking at the documentation and source code for importlib.metadata, I'm also a 
bit confused about how exactly I'm supposed to implement a custom Distribution 
which isn't based on filesystems. For example, I see that certain APIs return 
Path-like objects (which I will need to implement). But it isn't clear exactly 
which attributes are mandated to exist! Am I expected to implement the full 
pathlib.Path interface or just a subset?

Regarding how find_distributions() is called, I also don't understand why the 
Context is optional and how Context could be used in some situations. For 
example, the implementation of discover() can construct Context instances with 
no arguments, which is then fed into find_distributions(). So I guess 
context=None or context.name=None implies "return Distribution's for every 
known package?" If so, this behavior is undocumented.

I'm also not sure what Context.path is for. I /think/ it is only used for the 
path-based finder/distribution. But the way it is documented implies it should 
always exist, which doesn't seem appropriate for cases like PyOxidizer which 
will retrieve metadata from in-memory without filesystem I/O.

I think what I'm trying to say is that the existing documentation for 
importlib.metadata is not sufficient to robustly implement a custom 
find_distributions() + Distribution type. I would kindly request that a domain 
expert revise the documentation such that a 3rd party can implement a custom 
solution. My preferred solution would be for there to be formal interfaces in 
importlib.abc like there are for everything else in the importlib realm. (The 
interfaces for finders and loaders are super useful when implementing a 
finder/loader from scratch.)

FWIW I think I like the new metadata API and I think it is flexible enough to 
allow tools like PyOxidizer to do crazy things like divorce resources from the 
filesystem! But it is hard to say for sure since the interfaces aren't clearly 
defined at present.

--
assignee: docs@python
components: Documentation
messages: 355402
nosy: barry, docs@python, indygreg, jaraco
priority: normal
severity: normal
status: open
title: importlib.metadata documentation deficiencies
type: enhancement
versions: 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

Re: How to decode UTF strings?

[MRAB]

On 2019-10-26 03:10, Arne Vajhøj wrote:

On 10/25/2019 4:52 PM, DFS wrote:

=?iso-8859-9?b?T/B1eg==?= 
=?utf-8?Q?=EB=AF=B8?= 
=?GBK?B?0Pu66A==?= 
=?UTF-8?B?zp3Or866zr/PgiDOks6tz4HOs86/z4I=?= 


How does something like:

from email.header import decode_header

def test(s):
  print(s)
  s2 = decode_header(s)
  print(s2[0][0])
  print(s2[1][0].strip())

test('=?iso-8859-9?b?T/B1eg==?= ')
test('=?utf-8?Q?=EB=AF=B8?= ')
test('=?GBK?B?0Pu66A==?= ')
test('=?UTF-8?B?zp3Or866zr/PgiDOks6tz4HOs86/z4I=?=
')

work?

When you decode the header you get a number of parts, each with its own 
encoding.


Here's a simple example, based in your code:

from email.header import decode_header

def test(header, default_encoding='utf-8'):
 parts = []

 for data, encoding in decode_header(header):
 if isinstance(data, str):
parts.append(data)
 else:
parts.append(data.decode(encoding or default_encoding))

 print(''.join(parts))

test('=?iso-8859-9?b?T/B1eg==?= ')
test('=?utf-8?Q?=EB=AF=B8?= ')
test('=?GBK?B?0Pu66A==?= ')
test('=?UTF-8?B?zp3Or866zr/PgiDOks6tz4HOs86/z4I=?= 
')

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

[issue38582] re: backreference number in replace string can't >= 100

[Matthew Barnett]

Matthew Barnett  added the comment:

If we did decide to remove it, but there was still a demand for octal escapes, 
then I'd suggest introducing \oXXX.

--

___
Python tracker 

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

[issue38582] re: backreference number in replace string can't >= 100

[Ma Lin]

Ma Lin  added the comment:

> I'd still retain \0 as a special case, since it really is useful.

Yes, maybe \0 is used widely, I didn't think of it.
Changing is troublesome, let's keep it as is.

--

___
Python tracker 

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

Re: How to decode UTF strings?

[Arne Vajhøj]

On 10/25/2019 4:52 PM, DFS wrote:

=?iso-8859-9?b?T/B1eg==?= 
=?utf-8?Q?=EB=AF=B8?= 
=?GBK?B?0Pu66A==?= 
=?UTF-8?B?zp3Or866zr/PgiDOks6tz4HOs86/z4I=?= 


How does something like:

from email.header import decode_header

def test(s):
print(s)
s2 = decode_header(s)
print(s2[0][0])
print(s2[1][0].strip())

test('=?iso-8859-9?b?T/B1eg==?= ')
test('=?utf-8?Q?=EB=AF=B8?= ')
test('=?GBK?B?0Pu66A==?= ')
test('=?UTF-8?B?zp3Or866zr/PgiDOks6tz4HOs86/z4I=?= 
')


work?

Arne

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

[issue38582] re: backreference number in replace string can't >= 100

[Vedran Čačić]

Vedran Čačić  added the comment:

Not very useful, surely (now that we have hex escapes).
[I'd still retain \0 as a special case, since it really is useful.] But a lot 
more useful than a hundred backreferences.

And I'm as a matter of principle opposed to changing something that's been in 
the language for decades for the benefit of someone that's by their own words 
"just learned Python". [Changing documentation is fine.] They by definition 
don't see the whole picture. Now that we don't have a BDFL anymore, I think 
it's vitally important to have some principles such as this one.

--

___
Python tracker 

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

[issue38582] re: backreference number in replace string can't >= 100

[Ma Lin]

Ma Lin  added the comment:

Octal escape:
\oooCharacter with octal value ooo
As in Standard C, up to three octal digits are accepted.

It only accepts UCS1 characters (ooo <= 0o377):
>>> ord('\377')
255
>>> len('\378')
2
>>> '\378' == '\37' + '8'
True

IMHO this is not useful, and creates confusions.
Maybe it can be deprecated in language level.

--

___
Python tracker 

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

[issue38593] Python 3.7 does not catch infinite recursion for some values of sys.getrecursionlimit()

[Valentyn Tymofieiev]

Valentyn Tymofieiev  added the comment:

I observed this issue in Python 3.7.2, 3.7.4, 3.7.5, however it seems to be 
fixed in 3.8.0.

--

___
Python tracker 

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

[issue38591] Deprecate Process Child Watchers

[STINNER Victor]

STINNER Victor  added the comment:

> Regarding pidfd and kqueue -- I love to see pull requests with proposals. Now 
> nothing exists. The pidfd is available starting from the latest released 
> Linux 5.3;  we need to wait for a decade before all Linux distros adopt it 
> and we can drop all other implementations.

I hope that it will take less time to expose pidfd_open() in Python! It is 
*already* available in the Linux kernel 5.3. My laptop is already running Linux 
5.3! (Thanks Fedora 30.)

I would prefer to keep an API to choose the child watcher since it seems like 
even in 2019, there are still new APIs (pidfd) to wait for a process 
completion. I expect that each implementation will have advantages and 
drawbacks.

--

___
Python tracker 

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

[issue38591] Deprecate Process Child Watchers

[STINNER Victor]

STINNER Victor  added the comment:

> ThreadedChildWatcher starts a thread per process but has O(1) complexity.

But it spawns a new Python thread per process which can be a blocker issue if a 
server memory is limited. What if you want to spawn 100 processes? Or 1000 
processes? What is the memory usage?

I like FastChildWatcher!

> ... but working with asyncio subprocess API is still super complicated if 
> asyncio code is running from multiple threads

Well, I like the ability to choose the child watcher implementation depending 
on my use case. If asyncio is only run from the main thread, FastChildWatcher 
is safe, fast and has low memory footprint, no?

--

___
Python tracker 

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

[issue38591] Deprecate Process Child Watchers

[Kyle Stanley]

Kyle Stanley  added the comment:

> I think FastChildWatcher and SafeChildWatcher should go, ThreadedChildWatcher 
> should be kept default and MultiLoopChildWatcher is an option where 
> ThreadedChildWatcher is not satisfactory.

Okay, I think I can understand the reasoning here. Do you think that 
FastChildWatcher and SafeChildWatcher could be deprecated starting in 3.9 and 
removed in 3.11? If so, I'd be glad to start working on adding the deprecation 
warnings and the 3.9 Whats New entries.

> MultiLoopChildWatcher problems can and should be fixed; there is nothing bad 
> in the idea but slightly imperfect implementation.

Yeah my largest concern was just that the current issues seem especially 
complex to fix and I interpreted your previous comment as "I'd like to 
deprecate all the process watchers in the near future". Thus, it seemed to make 
sense to me that we could start removing them rather than sinking time into 
fixing something that might be removed soon. 

By "slightly imperfect implementation", do you have any ideas for particularly 
imperfect parts of it that could use improvement? 

I feel that I've developed a decent understanding of the implementation for 
ThreadedChildWatcher, but after looking at the race conditions for 
MultiLoopChildWatcher in https://bugs.python.org/issue38323, I'll admit that I 
felt a bit lost for where to find a solution. Primarily because my 
understanding of the signal module is quite limited in comparison to others; 
it's not an area that I've strongly focused on.

--

___
Python tracker 

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

[issue38334] zipfile: Seeking encrypted file breaks after seeking backwards

[Daniel Hillier]

Daniel Hillier  added the comment:

Hi,

I have another patch I would like to contribute to the zipfile module but would 
like to request a review of this one to minimise conflicts with later patches. 
If anyone is able to review the patch, I would really appreciate it :)

Also, with regards to selecting Python versions for this issue, is there any 
rule of thumb I should be following?

Thanks,
Dan

--

___
Python tracker 

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

[issue38558] Data Structures documentation out of sync with new Walrus operator

[miss-islington]

miss-islington  added the comment:


New changeset cf028b57169499f82b73dd0977fe0bab40778a60 by Miss Skeleton (bot) 
in branch '3.8':
bpo-38558: Mention `:=` in conditions tutorial (GH-16919)
https://github.com/python/cpython/commit/cf028b57169499f82b73dd0977fe0bab40778a60


--
nosy: +miss-islington

___
Python tracker 

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

[issue38589] Bad target address assigned in Python Manuals shortcut on Python installation

[Ned Deily]

Change by Ned Deily :


--
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware

___
Python tracker 

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

[issue38592] Add pt-br to the language switcher at the Python docs website

[Ned Deily]

Change by Ned Deily :


--
assignee:  -> mdk
components: +Documentation
nosy: +mdk

___
Python tracker 

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

[issue38558] Data Structures documentation out of sync with new Walrus operator

[Zachary Ware]

Zachary Ware  added the comment:


New changeset cb2cf06b0aad1851f54999497c1b50c381d1fdd8 by Zachary Ware (Ammar 
Askar) in branch 'master':
bpo-38558: Mention `:=` in conditions tutorial (GH-16919)
https://github.com/python/cpython/commit/cb2cf06b0aad1851f54999497c1b50c381d1fdd8


--
nosy: +zach.ware

___
Python tracker 

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

[issue38558] Data Structures documentation out of sync with new Walrus operator

[miss-islington]

Change by miss-islington :


--
pull_requests: +16456
pull_request: https://github.com/python/cpython/pull/16926

___
Python tracker 

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

[issue38533] v3.7.5 py script run ok with python.exe but not pythonw.exe (python silent console not working)

[Steve Dower]

Steve Dower  added the comment:

> FWIW, the very first thing that I checked was the dependencies of pythonw.exe

The version in the Store has a different build of pythonw.exe (because it has 
to be able to determine its user site-packages location differently).

Dump of file C:\Program 
Files\WindowsApps\PythonSoftwareFoundation.Python.3.7_3.7.1520.0_x64__hd69rhyc2wevp\pythonw.exe

File Type: EXECUTABLE IMAGE

  Image has the following dependencies:

api-ms-win-core-libraryloader-l1-2-0.dll
api-ms-win-core-com-l1-1-0.dll
api-ms-win-core-errorhandling-l1-1-0.dll
SHELL32.dll
python37.dll
MSVCP140.dll  ** bug here, but already fixed for next release
VCRUNTIME140.dll
api-ms-win-crt-runtime-l1-1-0.dll
api-ms-win-crt-environment-l1-1-0.dll
api-ms-win-crt-heap-l1-1-0.dll
api-ms-win-crt-math-l1-1-0.dll
api-ms-win-crt-stdio-l1-1-0.dll
api-ms-win-crt-locale-l1-1-0.dll
api-ms-win-crt-string-l1-1-0.dll
api-ms-win-core-handle-l1-1-0.dll
api-ms-win-core-synch-l1-1-0.dll
api-ms-win-core-rtlsupport-l1-1-0.dll
api-ms-win-core-processthreads-l1-1-0.dll
api-ms-win-core-processthreads-l1-1-1.dll
api-ms-win-core-debug-l1-1-0.dll
api-ms-win-core-profile-l1-1-0.dll
api-ms-win-core-sysinfo-l1-1-0.dll
api-ms-win-core-interlocked-l1-1-0.dll
KERNEL32.dll
api-ms-win-core-winrt-l1-1-0.dll
api-ms-win-core-winrt-string-l1-1-0.dll
OLEAUT32.dll
api-ms-win-core-winrt-error-l1-1-1.dll
api-ms-win-core-winrt-error-l1-1-0.dll

--

___
Python tracker 

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

[issue38592] Add pt-br to the language switcher at the Python docs website

[Marco Rougeth]

Change by Marco Rougeth :


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

___
Python tracker 

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

[issue38580] select()'s documentation claims only sequences are accepted, but it allows all iterables

[Brandt Bucher]

Change by Brandt Bucher :


--
nosy: +brandtbucher

___
Python tracker 

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

[issue38538] dictobject dictviews don't return NotImplemented for unrecognized types.

[Terry J. Reedy]

Change by Terry J. Reedy :


--
stage:  -> test needed
versions:  -Python 3.5, Python 3.6

___
Python tracker 

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

[issue38591] Deprecate Process Child Watchers

[Andrew Svetlov]

Andrew Svetlov  added the comment:

ThreadedChildWatcher starts a thread per process but has O(1) complexity.

MultiLoopChildWatcher doesn't spawn threads, it can be used safely with asyncio 
loops spawn in multiple threads. The complexity is O(N) plus no other code 
should contest for SIG_CHLD subscription.

FastChildWatcher has O(1), this is the good news. All others are bad: the 
watcher conflicts even with blocking `subprocess.wait()` call, even if the call 
is performed from another thread.

SafeChildWatcher is safer than FastChildWatcher but working with asyncio 
subprocess API is still super complicated if asyncio code is running from 
multiple threads. SafeChildWatcher works well only if asyncio is run from the 
main thread only. Complexity is O(N).

I think FastChildWatcher and SafeChildWatcher should go, ThreadedChildWatcher 
should be kept default and MultiLoopChildWatcher is an option where 
ThreadedChildWatcher is not satisfactory.

MultiLoopChildWatcher problems can and should be fixed; there is nothing bad in 
the idea but slightly imperfect implementation.

Regarding pidfd and kqueue -- I love to see pull requests with proposals. Now 
nothing exists.
The pidfd is available starting from the latest released Linux 5.3;  we need to 
wait for a decade before all Linux distros adopt it and we can drop all other 
implementations.

--

___
Python tracker 

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

[issue38583] The activate script in Windows is not correct for venvs created in git-bash

[Steve Dower]

Steve Dower  added the comment:

I agree this would be better, though it may not be that easy to do.

If you're running Windows Python from WSL, then your "bash style" path should 
be "/mnt/c/some/path", not "/c/some/path". So the answer isn't as simple as 
.replace('\\', '/').

I did some quick testing with posixpath and pathlib and neither has an obvious 
conversion from a Windows path to a POSIX path, though 
pathlib.PurePosixPath(pathlib.PureWindowsPath(p)) comes closest.

Perhaps the best approach here is to improve `activate` to determine its path 
when run, like we did for `activate.ps1`? Then we don't need to substitute the 
path in at creation time.

--
versions: +Python 3.9 -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

[issue38557] PyTuple_GetSlice docs minor inaccuracy

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

The part about "new tuple" can be removed. The documentation olready contains 
an automatically generated note about a new reference.

PR 16925 improves the documentation for getting/setting items/slices of lists 
and tuples.

--
nosy: +serhiy.storchaka
stage: patch review -> 

___
Python tracker 

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

[issue28866] Type cache is not correctly invalidated on a class defining mro()

[Terry J. Reedy]

Terry J. Reedy  added the comment:

#38541 reports a severe attribute access slowdown in 3.7.4 in some situations.  
(Fixed by the enhancement in #36922, which I presume cannot be backported.)

--
nosy: +terry.reedy

___
Python tracker 

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

[issue38591] Deprecating MultiLoopChildWatcher

[Kyle Stanley]

Kyle Stanley  added the comment:

> Kyle, why are you resetting the status to "Pending"?

That was an accident, I think I had that set already on the page and submitted 
my comment just after you did yours.

I'm going to change the title of the issue to "Deprecate Process Child 
Watchers". I started the proposal bit more conservatively because I thought 
that it might be easier to just deprecate MultiLoopChildWatcher at first. But 
seeing as it was just added in 3.8, I don't think it would make as much sense 
to deprecate that one by itself.

--

___
Python tracker 

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

ANN: czml3 0.3.0 released 

[Juan Luis Cano]

Hi all,

It fills us with astronomical joy to announce the release of czml3 0.3.0! 

czml3 is a Python (3.6+) library to write CZML. Copying from the CZML Guide:

> CZML is a JSON format for describing a time-dynamic graphical scene,
> primarily for display in a web browser running Cesium. It describes
> lines, points, billboards, models, and other graphical primitives, and
> specifies how they change with time. While Cesium has a rich
> client-side API, CZML allows it to be data-driven so that a generic
> Cesium viewer can display a rich scene without the need for any custom
> code. In many ways, the relationship between Cesium and CZML is
> similar to the relationship between Google Earth and KML.

czml3 aims to be useful for interactive use:

>>> from czml3 import Packet
>>> Packet()
{
"id": "adae4d3a-7087-4fda-a70b-d18a262a890e"
}
>>> packet0 = Packet(id="Facility/AGI", name="AGI")
>>> packet0
{
"id": "Facility/AGI",
"name": "AGI"
}
>>> packet0.dumps()
'{"id": "Facility/AGI", "name": "AGI"}'

This new release brings some new properties (Box, BoxDimensions,
EyeOffset), better validation for Position, and a widget for Jupyter
notebook:

  In [1]: from czml3.examples import simple

  In [2]: from czml3.widget import CZMLWidget

  In [3]: CZMLWidget(simple)

You can install it with pip:

pip install --upgrade czml3

And check out the repository on GitHub, which contains a more detailed
README, tests (>99 % coverage) and the issue tracker:

https://github.com/poliastro/czml3

If you have any questions or want to contribute, join our chat!

https://chat.openastronomy.org/#/room/#poliastro-czml:matrix.org

czml3 is similar in intent to czml, a Python library written by
Christian Ledermann. czml3 is implemented from scratch and tries to be
easier to use on an interactive interpreter, and (for the moment)
focuses only on writing.

Per Python ad astra!
--
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/

Support the Python Software Foundation:
http://www.python.org/psf/donations/

[issue38593] Python 3.7 does not catch infinite recursion for some values of sys.getrecursionlimit()

[Valentyn Tymofieiev]

Change by Valentyn Tymofieiev :


--
type:  -> crash

___
Python tracker 

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

[issue38593] Python 3.7 does not catch infinite recursion for some values of sys.getrecursionlimit()

[Valentyn Tymofieiev]

New submission from Valentyn Tymofieiev :

While investigating an issue[1] in Apache Beam, we observed that Python 3.7 
does not catch an infinite recursion for some values of sys.getrecursionlimit().

Repro steps:

docker run -it --entrypoint=/bin/bash python:3.7-stretch
git clone https://github.com/tvalentyn/beam.git
cd beam
git checkout origin/reproduce_uncaught_recursion_error
cd sdks/python
pip install nose
pip install -e .[gcp,test]
python ./setup.py nosetests --nocapture --tests 
'apache_beam/runners/dataflow/dataflow_runner_test.py:DataflowRunnerTest.test_remote_runner_display_data'

On Python 3.7, the test output is:

==
Recursion limit set to: 1002
Caught maximum recursion depth exceeded while calling a Python object. Current 
recursionlimit is 1002
Recursion limit set to: 1003
Caught maximum recursion depth exceeded. Current recursionlimit is 1003
Recursion limit set to: 1004
Caught maximum recursion depth exceeded while calling a Python object. Current 
recursionlimit is 1004
Recursion limit set to: 1005
Caught maximum recursion depth exceeded while calling a Python object. Current 
recursionlimit is 1005
Recursion limit set to: 1006
Fatal Python error: Cannot recover from stack overflow.

Current thread 0x7fd9f28a5700 (most recent call first):
  File "/usr/local/lib/python3.7/site-packages/dill/_dill.py", line 424 in get
...
==

So, if we set recursion limit to 1006 in [2], Python 3.7 interpreter does not 
throw/catch RecursionError in [3]. On Python 3.5, 3.6 the same code 
successfully catches RecursionError.  
 
[1] https://issues.apache.org/jira/browse/BEAM-8397 
[2] 
https://github.com/tvalentyn/beam/blob/158cc9006fef74fc17d52a4220172758f7a82820/sdks/python/apache_beam/runners/dataflow/dataflow_runner_test.py#L235
 
[3] 
https://github.com/tvalentyn/beam/blob/158cc9006fef74fc17d52a4220172758f7a82820/sdks/python/apache_beam/pipeline.py#L599

--
components: Interpreter Core
messages: 355389
nosy: Valentyn Tymofieiev
priority: normal
severity: normal
status: open
title: Python 3.7 does not catch infinite recursion for some values of 
sys.getrecursionlimit()
versions: Python 3.7

___
Python tracker 

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

[issue38557] PyTuple_GetSlice docs minor inaccuracy

[Serhiy Storchaka]

Change by Serhiy Storchaka :


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

___
Python tracker 

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

[issue38571] Segfault with StopIteration

[Kevin Chen]

Kevin Chen  added the comment:

Sorry for the noise.  I upgraded my gevent (1.3.5 to 1.4.0) and greenlet 
(0.4.13 to 0.4.15) libraries, and that appears to have resolved the issue.  I 
assume there was an incompatibility in one or both of the older versions of 
these libraries with python 3.7, but I had not previously realized that they 
were causing the issue.

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

[issue38434] sys.addaudithook event is not documented

[Steve Dower]

Steve Dower  added the comment:

The import audit event is also not documented.

--

___
Python tracker 

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

[issue38592] Add pt-br to the language switcher at the Python docs website

[Marco Rougeth]

New submission from Marco Rougeth :

The translation of the Python docs for Brazilian Portuguese is at around 20%. 
The Brazilian community have been working hard on it for the past 2 years, and 
as discussed with Julien, we believe this is a good moment to add the pt-br 
language switcher.

--
messages: 355384
nosy: rougeth
priority: normal
severity: normal
status: open
title: Add pt-br to the language switcher at the Python docs website

___
Python tracker 

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

[issue38557] PyTuple_GetSlice docs minor inaccuracy

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Verified from Python.
>>> t = (1,2,3)
>>> t2 = t[:]
>>> id(t), id(t2)
(1672756229504, 1672756229504)

A partial slice cannot the original tuple, so I presume that the emphasis is 
about returning a (new) *tuple*, rather than some sort of view of the original. 
 However,
Py_INCREF(a);
return (PyObject *)a;
date back to at least 1997 (GvR), so the optimization is not new.  I don't know 
what should replace 'New reference.'  'Old or new reverence.'?

"Take a slice of the tuple pointed to by p from low to high and return it **as 
a new tuple**."

could be replaces with

"Return the slice of the tuple point to by p for low to high.  If it is a 
proper subslice, return a new tuple."

This leave it undefined when a complete slice.

--
nosy: +terry.reedy
versions:  -Python 3.5, Python 3.6

___
Python tracker 

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

[issue38591] Deprecate Process Child Watchers

[Kyle Stanley]

Change by Kyle Stanley :


--
title: Deprecating MultiLoopChildWatcher -> Deprecate Process Child Watchers

___
Python tracker 

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

[issue38591] Deprecating MultiLoopChildWatcher

[Yury Selivanov]

Yury Selivanov  added the comment:

Kyle, why are you resetting the status to "Pending"?

> I think it will be necessary to fix the issues in the near future if we want 
> to keep MultiLoopChildWatcher in 3.8 (as they apply to 3.8 and 3.9). I would 
> certainly not be ecstatic about the idea of removing something that was just 
> recently added (similar to how we had to revert the new streaming changes due 
> to API design), but I'm even less in favor of keeping something around that's 
> not stable in a final release. 

Your opinion on this is duly noted.  

It would be great to hear what Andrew and Victor think about this.

--
status: pending -> open

___
Python tracker 

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

[issue38591] Deprecating MultiLoopChildWatcher

[Kyle Stanley]

Kyle Stanley  added the comment:

> Speaking of watchers -- big +1 from me to drop them all at some point. I 
> would start as early as 3.9.

Yeah that was my initial plan, to start the deprecation in 3.9 and finalize the 
removal in 3.11. We might be able to make an exception for 
MultiLoopChildWatcher and just remove it from 3.8 though. 

I think it will be necessary to fix the issues in the near future if we want to 
keep MultiLoopChildWatcher in 3.8 (as they apply to 3.8 and 3.9). I would 
certainly not be ecstatic about the idea of removing something that was just 
recently added (similar to how we had to revert the new streaming changes due 
to API design), but I'm even less in favor of keeping something around that's 
not stable in a final release. 

Based on my investigation of https://bugs.python.org/issue38323, it seems like 
it will be a rather complex issue to solve.

--
status: open -> pending

___
Python tracker 

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

[issue38541] Performance degradation of attribute accesses in Python 3.7.4

[Terry J. Reedy]

Terry J. Reedy  added the comment:

I added a note to #28866 about this.  The fix in #36922 is likely an 
enhancement that cannot be backported.  Please retest with 3.7.5 if you can, 
though I have no expectation of any change.

--
nosy: +serhiy.storchaka, terry.reedy

___
Python tracker 

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

[issue38591] Deprecating MultiLoopChildWatcher

[Yury Selivanov]

Yury Selivanov  added the comment:

> but perhaps if we go through with that we should remove MultiLoopChildWatcher 
> from 3.8 (if it's not too late to do so) instead of deprecating it.

I'll leave that up to Andrew to decide, but I'd be +1 to drop it asap, 
especially if we want to eventually deprecate watchers.  

Speaking of watchers -- big +1 from me to drop them all at some point. I would 
start as early as 3.9.

Linux has pidfd now, freebsd/macos has kqueue, windows has its own apis for 
watching processes. Threads can be the backup method for OSes that lack proper 
APIs for watching multiple processes (without using SIGCHLD etc).

--

___
Python tracker 

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

[issue38591] Deprecating MultiLoopChildWatcher

[Kyle Stanley]

Kyle Stanley  added the comment:

> Didn't we just add MultiLoopChildWatcher in 3.8?

Yep, that's correct: 
https://docs.python.org/3/library/asyncio-policy.html#asyncio.MultiLoopChildWatcher

I wasn't aware of that, but it would explain the current lack of usage. I'm 
generally in favor of Andrew's idea to deprecate the watchers subsystem, but 
perhaps if we go through with that we should remove MultiLoopChildWatcher from 
3.8 (if it's not too late to do so) instead of deprecating it.

--

___
Python tracker 

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

[issue38533] v3.7.5 py script run ok with python.exe but not pythonw.exe (python silent console not working)

[Terry J. Reedy]

Terry J. Reedy  added the comment:

For me, 'pyw -3.7 -m idlelib' in Command Prompt opens IDLE with 3.7.5.  So does 
the equivalent run by clicking the IDLE icon:
C:\Programs\Python37\pythonw.exe "C:\Programs\Python37\Lib\idlelib\idle.pyw"

This report reminds me that I should continue to install and minimally test 
each release.

--
nosy: +terry.reedy

___
Python tracker 

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

[issue38591] Deprecating MultiLoopChildWatcher

[Yury Selivanov]

Yury Selivanov  added the comment:

Didn't we just add MultiLoopChildWatcher in 3.8?

--
status: pending -> open

___
Python tracker 

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

[issue38591] Deprecating MultiLoopChildWatcher

[Kyle Stanley]

Change by Kyle Stanley :


--
assignee:  -> aeros
nosy: +vstinner
status: open -> pending

___
Python tracker 

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

[issue38591] Deprecating MultiLoopChildWatcher

[Kyle Stanley]

New submission from Kyle Stanley :

Proposal: 
Deprecate the alternative process watcher implementation to 
ThreadedChildWatcher, MultiLoopChildWatcher.

Motivation:
The idea for this proposal came from a comment from Andrew Svetlov in GH-16552:
"I believe after polishing ThreadedChildWatcher we can start deprecation of 
watchers subsystem at all, it generates more problems than solves."

Although Andrew suggested the idea of deprecating the process watchers 
subsystem entirely, I think that it would be adequate to start with just 
deprecating MultiLoopChildWatcher and proceeding from there. This is because 
the other three watcher implementations are significantly more stable in 
comparison (based on number of issues), have less complex implementations, and 
have far more widespread usage across public repositories. I would not be 
opposed to deprecating the other alternative watchers as well, but 
MultiLoopChildWatcher likely has the most justification for removal.

Details:
The class MultiLoopChildWatcher has a fairly complex implementation, causes a 
number of issues, is fairly unstable, is rarely utilized in comparison with the 
rest of the watchers API. It seems to have become a significant burden on 
maintenance for asyncio development without providing a significant benefit to 
the vast majority of users. 

Current unresolved MultiLoopChildWatcher issues:
https://bugs.python.org/issue38323
https://bugs.python.org/issue38182
https://bugs.python.org/issue37573

(3 out of the 5 open process watcher issues are caused by MultiLoopChildWatcher)

GitHub code usage comparison:
MultiLoopChildWatcher: 
https://github.com/search?l=Python=MultiLoopChildWatcher=Code (20 
results)
ThreadedChildWatcher: 
https://github.com/search?l=Python=ThreadedChildWatcher=Code (77 
results) 
FastChildWatcher: 
https://github.com/search?l=Python=FastChildWatcher=Code (4,426 results)
SafeChildWatcher: 
https://github.com/search?l=Python=SafeChildWatcher=Code (7,007 results)
All of asyncio usage: https://github.com/search?l=Python=asyncio=Code 
(599,131 results)

Note that for the above results, it also includes matches in the CPython 
repository and for repositories that have exact copies of 
Lib/asyncio/unix_events.py. Also, ThreadedChildWatcher likely has significantly 
less results since it's already the default watcher returned by 
asyncio.get_child_watcher(), so there's less need to explicitly declare it 
compared to the others. There are of course private repositories and non-GitHub 
repositories this doesn't include, but it should provide a general idea of 
overall usage.

My experience in interacting with asyncio users is similar to the results. The 
process watchers subsystem seems to be minimally used compared to the rest of 
asyncio, with ThreadedChildWatcher likely being the most used as the default 
returned from `asyncio.get_child_watcher()`. I have not personally seen a 
realistic example of usage of MultiLoopChildWatcher outside of python/cpython, 
and all of the results returned on GitHub were copies of 
Lib/asyncio/unix_events.py or Lib/test/test_asyncio/test_subprocess.py.

I would be interested in working on this issue if it is approved, as I think it 
would provide a significant long term reduction in maintenance for asyncio; 
allowing us to focus on the improvement and development of other features that 
benefit a far larger audience.

--
components: asyncio
messages: 355372
nosy: aeros, asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Deprecating MultiLoopChildWatcher
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

[issue35448] ConfigParser .read() - handling of nonexistent files

[Batuhan]

Batuhan  added the comment:

> I do not think that adding an extra parameter to .read() will solve any 
> problem.

There is a use case of this (which some of tools depends) about checking if 
configuration exists and if not, raising an error. Now, they can solve this by 
just adding check_exist argument. 

> Changing the default behavior will break existing code.

Can you give an example of how this feature can/could break existing code?

--

___
Python tracker 

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

[issue38590] argparse unexpected behavior with argument group inside mutually exclusive group

[Tim Sanders]

New submission from Tim Sanders :

argparse allows adding argument_groups inside of mutually_exclusive_groups, but 
the behavior is unintuitive and a bit buggy.

Demo:


import argparse

parser = argparse.ArgumentParser()
single_group = parser.add_argument_group(title='single_group')
single_group.add_argument('--a', action='store_true')

mutex_group = parser.add_mutually_exclusive_group()
mutex_group.add_argument('--b', action='store_true')

nested_group = mutex_group.add_argument_group(title='nested_group')
nested_group.add_argument('--c', action='store_true')
nested_group.add_argument('--d', action='store_true')

parser.print_help()
print(parser.parse_args())


Example output:


$ ~/test_args.py --a --b --c --d
usage: test_args.py [-h] [--a] [--b] [--c] [--d]

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

single_group:
  --a
Namespace(a=True, b=True, c=True, d=True)



Two issues I've noticed with this:
 - Arguments in the nested group show up in the usage string, but not in the 
help text.  The nested arguments are still parsed and available in the result, 
as normal.
 - Arguments in the nested group are not mutually exclusive with any arguments 
in the containing mutually_exclusive_group.  
   - I would expect:
   --b  ok
   --c  ok
   --d  ok
   --b --c  error
   --b --d  error
   --c --d  error*
   --b --c --d  error

*From a design perspective, it seems like argument_groups are meant to control 
display, and mutually_exclusive_groups are meant to control logic, so I think 
"error" makes sense here.  I personally would like the ability to allow "--c 
--d", but I think that's a separate discussion and probably a new type of group.

--
components: Library (Lib)
messages: 355370
nosy: Tim Sanders
priority: normal
severity: normal
status: open
title: argparse unexpected behavior with argument group inside mutually 
exclusive group
type: behavior
versions: Python 2.7, 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

Re: Fwd: python 8.0

[Batuhan Taskaya]

> but python is only up to version 3.8
He probably meant 3.8.0 but there was a python 8 (as an april 1 joke by
victor stinner)
https://mail.python.org/archives/list/python-...@python.org/thread/4P46WYJTZUKJ2EABQSASI7CD643YY5QL/

On Fri, Oct 25, 2019, 6:32 PM Gene Heskett  wrote:

> On Friday 25 October 2019 02:35:06 Ebuka Amadi wrote:
>
> > -- Forwarded message -
> > From: Ebuka Amadi 
> > Date: Thu, 24 Oct 2019 at 22:31
> > Subject: python 8.0
> > To: 
> >
> >
> > Dear team i downloaded python 8.0 am finding it hard to install it i
> > hope to get a step by stem instructions to do this on my PC its a core
> > i5
>
> I am just a lurker here, but python is only up to version 3.8. If that is
> python 8, I would wipe it off the system and go get the real thing from
> a genuine python site.  If you paid for it (its free), take whatever
> actions you have to, to get your money back.
>
> Cheers, Gene Heskett
> --
> "There are four boxes to be used in defense of liberty:
>  soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author)
> If we desire respect for the law, we must first make the law respectable.
>  - Louis D. Brandeis
> Genes Web page 
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Fwd: python 8.0

[Gene Heskett]

On Friday 25 October 2019 02:35:06 Ebuka Amadi wrote:

> -- Forwarded message -
> From: Ebuka Amadi 
> Date: Thu, 24 Oct 2019 at 22:31
> Subject: python 8.0
> To: 
>
>
> Dear team i downloaded python 8.0 am finding it hard to install it i
> hope to get a step by stem instructions to do this on my PC its a core
> i5

I am just a lurker here, but python is only up to version 3.8. If that is 
python 8, I would wipe it off the system and go get the real thing from 
a genuine python site.  If you paid for it (its free), take whatever 
actions you have to, to get your money back.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue38529] Python 3.8 improperly warns about closing properly closed streams

[Jeong-Min Lee]

Change by Jeong-Min Lee :


--
nosy: +falsetru

___
Python tracker 

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

Re: python 8.0

[Igor Korot]

Hi,

On Fri, Oct 25, 2019 at 9:19 AM Ebuka Amadi  wrote:
>
> -- Forwarded message -
> From: Ebuka Amadi 
> Date: Thu, 24 Oct 2019 at 22:31
> Subject: python 8.0
> To: 
>
>
> Dear team i downloaded python 8.0 am finding it hard to install it i hope
> to get a step by stem instructions to do this on my PC its a core i5

Where did you download it from?
How are you trying it to install?
What error message do you get?

What OS do you run on you PC?

Thank you.

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

Multi-language programing playground

[Vishal Rana via Python-list]

Folks,

I wanted to share a multi-language programming playground that I created
recently. I hope you will find it useful.

https://code.labstack.com/program

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

Fwd: python 8.0

[Ebuka Amadi]

-- Forwarded message -
From: Ebuka Amadi 
Date: Thu, 24 Oct 2019 at 22:31
Subject: python 8.0
To: 


Dear team i downloaded python 8.0 am finding it hard to install it i hope
to get a step by stem instructions to do this on my PC its a core i5
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue38286] tarfile forgets set sgid when targetpath has it

[Charles Coulombe]

Change by Charles Coulombe :


Removed file: https://bugs.python.org/file48626/tarfile_sgid.patch

___
Python tracker 

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

[issue38286] tarfile forgets set sgid when targetpath has it

[Charles Coulombe]

Change by Charles Coulombe :


Added file: https://bugs.python.org/file48678/tarfile_sgid.patch

___
Python tracker 

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

[issue28833] cross compilation of third-party extension modules

[pmp-p]

Change by pmp-p :


--
nosy: +pmpp

___
Python tracker 

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

[issue38589] Bad target address assigned in Python Manuals shortcut on Python installation

[Y3Kv Bv]

New submission from Y3Kv Bv :

Since Python 3.7 I'm getting broken shortcut to Python 3.x Manuals:
the installer doesn't seem to check for correct path to hh.exe; sets "C" as 
drive letter. (Yet path to python3xx.chm starts with correct drive letter.)

--
messages: 355369
nosy: Y3Kv Bv
priority: normal
severity: normal
status: open
title: Bad target address assigned in Python Manuals shortcut on Python 
installation
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

[issue29270] super call in ctypes sub-class fails in 3.6

[Clement Rouault]

Clement Rouault  added the comment:

Hello,

I have a Python2 project that relies heavily on ctypes and I cannot migrate 
this project to Python3 due to this bug. (I target 3.6)
I have some experience with CPython and submitting patchs and I would like to 
know what I can do to help moving this issue forward.

Thanks !

--
nosy: +hakril

___
Python tracker 

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

[issue38588] Use-after-free in dict/list

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Thank you for your investigation LCatro! Do you mind to create a pull request?

--
components: +Interpreter Core
type: security -> crash
versions: +Python 2.7, Python 3.7, Python 3.9

___
Python tracker 

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

[issue38588] Use-after-free in dict/list

[LCatro]

New submission from LCatro :

Code :

The varanit bval forget call Py_INCREF to add reference in dict_equal()

b->ma_keys->dk_lookup(b, key, ep->me_hash, );  <--- ...
if (bval == NULL) {
Py_DECREF(key);
Py_DECREF(aval);
if (PyErr_Occurred())
return -1;
return 0;
}
cmp = PyObject_RichCompareBool(aval, bval, Py_EQ);


PoC 1 :

class poc() :
def __eq__(self,other) :
dict2.clear()
return NotImplemented

dict1 = {0:poc()}
dict2 = {0:set()}
dict1 == dict2   ##  dict_equal() -> PyObject_RichCompareBool


Crash Detail :


(gdb) run ../python_poc_info/dict_poc_1.py 
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /home/fuzzing/Desktop/Python-3.8.0/python 
../python_poc_info/dict_poc_1.py
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x0046e445 in do_richcompare (v=v@entry=0x77e767d0, 
w=w@entry=0x76dd88c0, op=op@entry=2)
at Objects/object.c:725
725 if (!checked_reverse_op && (f = w->ob_type->tp_richcompare) != 
NULL) {


==

Code :

The varanit wl->ob_item[i] forget call Py_INCREF to add reference in 
list_richcompare()

for (i = 0; i < Py_SIZE(vl) && i < Py_SIZE(wl); i++) {
int k = PyObject_RichCompareBool(vl->ob_item[i],
 wl->ob_item[i], Py_EQ);  <---


PoC 2 :

class poc() :
def __eq__(self,other) :
list1.clear()
return NotImplemented


list1 = [poc()]
list2 = [1]
list1 == list2  #  list_richcompare() -> PyObject_RichCompareBool


Crash Detail :


(gdb) run ../python_poc_info/list_poc_1.py 
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /home/fuzzing/Desktop/Python-3.8.0/python 
../python_poc_info/list_poc_1.py
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x0044bd07 in long_richcompare (self=0x961200 , 
other=0x77e767d0, op=2)
at Objects/longobject.c:3083
3083CHECK_BINOP(self, other);


==

Code :

The varanit PyList_GET_ITEM(a, i) forget call Py_INCREF to add reference in 
list_contains()

list_contains(PyListObject *a, PyObject *el)
{
Py_ssize_t i;
int cmp;

for (i = 0, cmp = 0 ; cmp == 0 && i < Py_SIZE(a); ++i)
cmp = PyObject_RichCompareBool(el, PyList_GET_ITEM(a, i),
   Py_EQ);   <


PoC 3 :

class poc() :
def __eq__(self,other) :
list1.clear()
return NotImplemented

list1 = [ set() ]
poc() in list1  #  list_contains() -> PyObject_RichCompareBool


Crash Detail :


(gdb) run ../python_poc_info/list_poc_2.py 
Starting program: /home/fuzzing/Desktop/Python-3.8.0/python 
../python_poc_info/list_poc_2.py
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x0046e445 in do_richcompare (v=v@entry=0x77e766e0, 
w=w@entry=0x76dd88c0, op=op@entry=2)
at Objects/object.c:725
725 if (!checked_reverse_op && (f = w->ob_type->tp_richcompare) != 
NULL) {

--
messages: 355366
nosy: LCatro, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Use-after-free in dict/list
type: security
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

[issue38564] test_asyncio: test_run_coroutine_threadsafe_with_timeout() has a race condition

[Kyle Stanley]

Kyle Stanley  added the comment:

> IHMO a test must not depend on time.

I would agree, the tests should optimally not depend on time. My above comment 
was primarily to confirm that the failure was able to be consistently 
reproduced, along with the minimum conditions to do so.

Yury had been the one to change it to "asyncio.sleep(0.05)" from the previous 
"asyncio.sleep(1)" in the following commit: 
https://github.com/python/cpython/commit/abe9625eeb71e40f042ccfccfe6a4489a6dcdf35
 (Nov 13, 2015).

Perhaps he might have some insight or ideas as to how we could improve the test 
to use a more reliable means of synchronization that has been implemented since 
that change was made. I'll add him to the nosy list.

--
nosy: +yselivanov

___
Python tracker 

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

[issue35448] ConfigParser .read() - handling of nonexistent files

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

I do not think that adding an extra parameter to .read() will solve any problem.

You need to read the documentation of read() to use this feature. You need to 
change your code, and this will work only in new version of Python, so you will 
need to support two versions of the code in any way. If you change your code, 
it is easier to make it using read_file(), this way is compatible with old 
Python versions, and you can use it today.

If you do not read the documentation and do not change your code this feature 
cannot help you. Changing the default behavior will break existing code.

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue38323] asyncio: MultiLoopWatcher has a race condition (test_asyncio: test_close_kill_running() hangs on AMD64 RHEL7 Refleaks 3.x)

[STINNER Victor]

STINNER Victor  added the comment:

I did my tests on Fedora 30 on my laptop which has 4 cores (8 logical CPUs).

--

___
Python tracker 

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

[issue38323] asyncio: MultiLoopWatcher has a race condition (test_asyncio: test_close_kill_running() hangs on AMD64 RHEL7 Refleaks 3.x)

[Kyle Stanley]

Kyle Stanley  added the comment:

> I'm able to reproduce the issue locally using the command:
./python -m test test_asyncio 
--match=test.test_asyncio.test_subprocess.SubprocessMultiLoopWatcherTests.test_close_kill_running
 -v -F -j20 --timeout=30.0

I was unable to reproduce this locally on OS: Arch Linux 5.3.7 x86_64 and CPU: 
Intel i5-4460 from the latest commit (heads/master:96b06aefe2) within a 
reasonable number of tests (~1). I also tried differing number of jobs, up 
to 100. What OS were you able to reproduce it locally on using that 
configuration?

This is of course still an issue since it's still occurring on multiple 
buildbots intermittently and Victor was able to reproduce it locally, but I was 
not able to do so on my local setup. This will be significantly harder to debug 
without a reliable means of reproducing the failure.

--

___
Python tracker 

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

[issue38564] test_asyncio: test_run_coroutine_threadsafe_with_timeout() has a race condition

[STINNER Victor]

STINNER Victor  added the comment:

IHMO a test must not depend on time.

--

___
Python tracker 

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

[issue38564] test_asyncio: test_run_coroutine_threadsafe_with_timeout() has a race condition

[Kyle Stanley]

Kyle Stanley  added the comment:

I can confirm Victor's method of reproducing the failure consistently, by using 
asyncio.sleep(1e-9) within `RunCoroutineThreadsafeTests.add()` instead of the 
current asyncio.sleep(0.05).

I also experimented with adjusting the sleep time, to figure out the "breaking 
point" where I could no longer run `./python -m test test_asyncio -m 
test_run_coroutine_threadsafe_with_timeout -v -F` without failures (within 
~10,000 tests). From my results, the lowest reliable value was 0.001. At 1e-4, 
I was able to consistently reproduce the failure reported above:

FAIL: test_run_coroutine_threadsafe_with_timeout 
(test.test_asyncio.test_tasks.RunCoroutineThreadsafeTests)
Test coroutine submission from a thread to an event loop
--
Traceback (most recent call last):
  File "/home/aeros/repos/cpython/Lib/test/test_asyncio/test_tasks.py", line 
3210, in test_run_coroutine_threadsafe_with_timeout
self.loop.run_until_complete(future)
AssertionError: TimeoutError not raised

The failure becomes increasingly consistent with lowered time as expected, but 
at 1e-5 I was able to repeatedly reproduce the failure within 10 iterations of 
the test. At 1e-4 it took around 3000 iterations before failing (across 
multiple runs).

--
nosy: +aeros

___
Python tracker 

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

Re: a regex question

[Antoon Pardon]

On 25/10/19 12:22, Maggie Q Roth wrote:
> Hello
>
> There are two primary types of lines in the log:
>
> 60.191.38.xx/
> 42.120.161.xx   /archives/1005
>
> I know how to write regex to match each line, but don't get the good result
> with one regex to match both lines.

Could you provide the regexes that you have for each line?

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

Re: a regex question

[Brian Oney via Python-list]

On October 25, 2019 12:22:44 PM GMT+02:00, Maggie Q Roth  
wrote:
>Hello
>
>There are two primary types of lines in the log:
>
>60.191.38.xx/
>42.120.161.xx   /archives/1005
>
>I know how to write regex to match each line, but don't get the good
>result
>with one regex to match both lines.

What is a good result?

The is an re.MULTILINE flag. Did you try that? What does that do?

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

a regex question

[Maggie Q Roth]

Hello

There are two primary types of lines in the log:

60.191.38.xx/
42.120.161.xx   /archives/1005

I know how to write regex to match each line, but don't get the good result
with one regex to match both lines.

Can you help?

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

[issue38582] re: backreference number in replace string can't >= 100

[Vedran Čačić]

Vedran Čačić  added the comment:

The documentation clearly says:

> This special sequence can only be used to match one of the first 99 groups. 
> If the first digit of number is 0, or number is 3 octal digits long, it will 
> not be interpreted as a group match, but as the character with octal value 
> number.

Maybe it should also mention Serhiy's technique at that place, something like

"If you need more than 99 groups, you can name them using..."

--

___
Python tracker 

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

[issue38582] re: backreference number in replace string can't >= 100

[veaba]

veaba <908662...@qq.com> added the comment:

Aha, it's me. It's the mysterious power from the East. I just learned python.

I've solved my problem. It's a very simple replace replacement, and it's solved 
in three lines.

I'm trying to solve the problem of inadvertently finding out in the process of 
translating HTML text into markdown file. The document contains very complex 
strings, so I do that. Now it seems that the method I used before is a very 
inappropriate and inappropriate way to implement, which is a mistake.

However, I insist that this regular overflow is still a problem. It doesn't 
even translate a bunch of meaningless strings without any error.

I didn't find such a bug until I randomly selected and checked 2. K documents. 
I don't know if it's unlucky or lucky.

Then, I will not participate in the discussion of the remaining high-end issues.

Good luck.

--

___
Python tracker 

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

[issue38582] re: backreference number in replace string can't >= 100

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

I do not believe somebody uses handwritten regular expressions with more than 
100 groups. But if you generate regular expression, you can use named groups 
(?P...) (?P=g12345).

--

___
Python tracker 

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

[issue38583] The activate script in Windows is not correct for venvs created in git-bash

[Mo]

Mo  added the comment:

The issue comes as a result of abspath on line 59 of venv/__init__.py:
env_dir = os.path.abspath(env_dir)

This returns a Windows-style path, and os.path.abspath returning in this way is 
*probably* correct, as the OS is Windows, despite trying to forget that by 
using bash.

It is still my view that the activate script is a bash script, and therefore 
should only contain paths in that style, but the simple solution to this issue 
is to change the double quotes around the definition of $VIRTUAL_ENV in the 
activate script to single quotes. It works. The output of "which python" is a 
bit odd, but this is clearly a quirk beyond Python's control.

--

___
Python tracker 

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

[issue38582] re: backreference number in replace string can't >= 100

[veaba]

veaba <908662...@qq.com> added the comment:

Yes, this is not a good place to use regular expressions.

Using regular expressions：
def actual_re_demo():
import re
# This is an indefinite string...
text = "tf.where(condition, x=None, y=None, name=None) tf.batch_gather ..."

# Converting fields that need to be matched into regular expressions is 
also an indefinite string
pattern_str = re.compile('(tf\\.batch_gather)|(None)|(a1)')

#I don't know how many, so it's over \ \ 100 \ \ n
x = re.sub(pattern_str, '`'+'\\1\\2'+'`', text)

print(x)

# hope if：tf.Prefix needs to match,The result will be:`tf.xx`，

# But in fact, it's not just TF. As a prefix, it's a random character, it 
can be a suffix, it can be other characters.

#  If more than 100, the result 
is=>：989¡¢£¤¥¦§89¨©ª«¬­®¯89°±²³´µ¶·89¸¹º»¼½¾¿890123`, 
name=`None@ABCDEFG89HIJKLMNO89PQRSTUVW89XYZ[\]^_89`abcdefg89hijklmno89pqrstuvw89xyz{|}~8901234567890123456789

# I noticed in the comment area that it was caused by a confusion of Radix, 
which seems to be embarrassing.


Use replace to solve it. It looks much better.
def no_need_re():
text = "tf.where(condition, x=None, y=None, name=None) tf.batch_gather ..."
pattern_list = ['tf.batch_gather', 'None']
for item in pattern_list:
text=text.replace(item, '`'+item+'`')

print(text)

no_need_re()

Expect to report an error directly if it exceeds the limit, instead of 
overflowing the character, like this:

989¡¢£¤¥¦§89¨©ª«¬­®¯89°±²³´µ¶·89¸¹º»¼½¾¿890123`, 
name=`None@ABCDEFG89HIJKLMNO89PQRSTUVW89XYZ[\]^_89`abcdefg89hijklmno89pqrstuvw89xyz{|}~8901234567890123456789

--

___
Python tracker 

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

[issue38582] re: backreference number in replace string can't >= 100

[Vedran Čačić]

Vedran Čačić  added the comment:

I have no problem with long regexes. But those are not only long, those must be 
_deeply nested_ regexes, where simply 100 is an arbitrary limit. I'm quite sure 
if you really need depth 100, you must also need a dynamic depth of nesting, 
which you cannot really achieve with regexes.

Yes, if there is a will to change this, supporting \g would be a way to go.

--

___
Python tracker 

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

Re: installation problem

[Terry Reedy]

On 10/23/2019 9:43 PM, MRAB wrote:

On 2019-10-24 00:47, fateme jbr wrote:

Dear Python team

I have installed Python 3.7.4 on windows 10. I have access to IDLE and I
can run simple programs, but when I type python in command window nothing
happens.


What 'command window' do you mean?  Windows' Command Prompt? or IDLE's 
Shell?  If the latter, you will get a NameError.




 I wanna install pip and afterward some libraries and it is when

the problem occurs.

why doesn't prompt window recognize python. What shall I do?

what do you mean by "nothing happens"? It should either start Python or 
show an error.


Python 3.7 comes with pip; it should be installed already.

The recommended way of starting Python on Windows these days is to use 
the Python launcher "py". You can use it run to pip:


py -m pip install library_name


Do this in Command Prompt, with a 'path>' prompt.

--
Terry Jan Reedy

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