[issue43817] Add inspect.get_annotations()

[Larry Hastings]

Change by Larry Hastings :


--
title: Add typing.get_annotations() -> Add inspect.get_annotations()

___
Python tracker 

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

[issue37355] SSLSocket.read does a GIL round-trip for every 16KB TLS record

[Josh Snyder]

Change by Josh Snyder :


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

___
Python tracker 

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

Re: do ya still use python?

[Dan Stromberg]

On Mon, Apr 19, 2021 at 5:55 PM Jon Ribbens via Python-list <
python-list@python.org> wrote:

> On 2021-04-20, Paul Rubin  wrote:
> > Ethan Furman  writes:
> >> List, my apologies -- not sure how that one got through.
> >
> > It was trollishly written but was a reasonable observation on the state
> > of the Usenet group.  I didn't realize it had come through (or reached)
> > the mailing list.  Anyway the state of affairs for us Usenet die-hards
> > isn't so great.
>
> Why do you say that? The group seems quite lively to me
> (and no I'm not counting spam etc).
>
Actually, this list is less busy than it was a decade or two ago, but
that's probably because of things like stackoverflow, python-dev, pypy-dev,
cython-devel, python-ideas, distutils-sig, issue trackers, code-quality,
and probably others.

There was a time when most python-related discussion happened here on
python-list/comp.lang.python.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue38659] enum classes cause slow startup time

[Ethan Furman]

Ethan Furman  added the comment:


New changeset 503cdc7c124cebbd777008bdf7bd9aa666b25f07 by Ethan Furman in 
branch 'master':
Revert "bpo-38659: [Enum] add _simple_enum decorator (GH-25285)" (GH-25476)
https://github.com/python/cpython/commit/503cdc7c124cebbd777008bdf7bd9aa666b25f07


--

___
Python tracker 

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

[issue38659] enum classes cause slow startup time

[Ethan Furman]

Change by Ethan Furman :


--
pull_requests: +24202
pull_request: https://github.com/python/cpython/pull/25476

___
Python tracker 

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

[issue38659] enum classes cause slow startup time

[Ethan Furman]

Ethan Furman  added the comment:


New changeset dbac8f40e81eb0a29dc833e6409a1abf47467da6 by Ethan Furman in 
branch 'master':
bpo-38659: [Enum] add _simple_enum decorator (GH-25285)
https://github.com/python/cpython/commit/dbac8f40e81eb0a29dc833e6409a1abf47467da6


--

___
Python tracker 

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

[issue42854] OpenSSL 1.1.1: use SSL_write_ex() and SSL_read_ex()

[Ethan Furman]

Ethan Furman  added the comment:

I'm getting this error:

test test_ssl failed -- Traceback (most recent call last):
  File "/source/python/cpython/Lib/test/test_ssl.py", line 1061, in 
test_read_write_zero
self.assertEqual(s.send(b""), 0)
  File "/source/python/cpython/Lib/ssl.py", line 1198, in send
return self._sslobj.write(data)
ssl.SSLEOFError: EOF occurred in violation of protocol (_ssl.c:2484)

Let me know if there's any other info I can provide (and how to get it).

--
nosy: +ethan.furman

___
Python tracker 

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

Re: do ya still use python?

[Jon Ribbens via Python-list]

On 2021-04-20, Paul Rubin  wrote:
> Ethan Furman  writes:
>> List, my apologies -- not sure how that one got through.
>
> It was trollishly written but was a reasonable observation on the state
> of the Usenet group.  I didn't realize it had come through (or reached)
> the mailing list.  Anyway the state of affairs for us Usenet die-hards
> isn't so great.

Why do you say that? The group seems quite lively to me
(and no I'm not counting spam etc).
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue39298] add BLAKE3 to hashlib

[Jack O'Connor]

Jack O'Connor  added the comment:

Hey Christian, yes these are new bindings, and also incomplete. See comments in 
https://github.com/oconnor663/cpython/commit/dc6f6163ad9754c9ad53e9e3f3613ca3891a77ba,
 but in short only x86-64 Unix is in working order. If 3.10 doesn't seem 
realistic, I'm happy to go the PyPI route. That said, this is my first time 
using the Python C API. (My code in that branch is going to make that pretty 
obvious.) Could you recommend any existing packages that I might be able to use 
as a model?

For OpenSSL, I'm very interested in the abstract but less familiar with their 
project and their schedules. Who might be a good person to get in touch with?

> I assume there's a completely generic platform-agnostic C implementation, for 
> build environments where the assembly won't work, yes?

Yes, that's the vendored file blake3_portable.c. One TODO for my branch here is 
convincing the Python build system not to try to compile the x86-64-specific 
stuff on other platforms. The vendored file blake3_dispatch.c abstracts over 
all the different implementations and takes care of #ifdef'ing 
platform-specific function calls. (It also does runtime CPU feature detection 
on x86.)

> written using the Rust implementation, which I understand is even more 
> performant

A few details here: The upstream Rust and C implementations have been matched 
in single threaded performance for a while now. They share the same assembly 
files, and the rest is a direct port. The big difference is that Rust also 
includes multithreading support, using the Rayon work-stealing runtime. The 
blake3-py module based on the Rust crate exposes this with a simple boolean 
flag, though we've been thinking about ways to give the caller more control 
over the number of threads used.

--

___
Python tracker 

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

[issue43834] Use context manager in StringIO example

[Benjamin Peterson]

Benjamin Peterson  added the comment:

I agree that closing or using a context manager with StringIO (or BytesIO) is 
not something one normally has to do, so it doesn't need to be in the example.

--
resolution:  -> rejected
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: Current thinking on required options

[Avi Gross via Python-list]

Sidestepping the wording of "options" is the very real fact that providing
names for even required parts can be helpful in many cases.

There re programs that may not require anything on the command line to be
done but many need something to provide some flexibility.

So, I tend to agree that in many cases you need an explicit or implicit
argument for a program to do something useful. If I have a simple program
that looks up a phone number when given a name, it would require a name
UNLESS the default behavior is to show ALL entries or repeat whatever I
asked for last time by keeping track or provide the number I ask for most or
pick a random one or return silently having done nothing ...

But I want to point out something OBVIOUS. The requested program in my view
HAS NO required arguments! All are in a sense optional but at the same time
are all mandatory in some circumstances.

It can be called two equally valid ways:

grocli [-h]

OR

grocli -o {check,add,delete} -u USERS [USERS ...]] -g GROUP

When called to ask for help, none of the other arguments are required or are
ignored or worse. When called with the second properly formed set of
arguments, in any order, I assume any "-h" is either ignored or an error.

So I would possibly have TWO usage statements and in both cases, NO optional
arguments! Either you ask for help or you provide everything else.

Clearly your actual code can be designed many ways including allowing all
combinations and throwing in help when asked for in addition to doing what
is requested or allowing multiple -u arguments instead of multiple arguments
following a single -u and so forth. Heck, it can perhaps accept random
additional arguments and pass them along to another command it uses
internally without question in a "..." situation. 

So a syntax for defining a program as documentation like the above may need
an OR approach or be even more complex when say two or more arguments can be
used but only ONE is allowed and then it may be mandatory. Picture a -m to
suggest units are metric versus ...

And this "-h" notation is very common in programs and can cause the
description of how a program should be used more complex than it needs to be
if you insist on just one line showing how to use it rather than giving
several valid usages.

-Original Message-
From: Python-list  On
Behalf Of Dan Stromberg
Sent: Monday, April 19, 2021 12:04 PM
To: Loris Bennett 
Cc: Python List 
Subject: Re: Current thinking on required options

On Mon, Apr 19, 2021 at 2:55 AM Loris Bennett 
wrote:

> However, the options -o, -u, and -g are required, not optional.
>
> The documentation
>
>   https://docs.python.org/3/library/argparse.html#required
>
> advises against required options and here
>
>
> https://stackoverflow.com/questions/24180527/argparse-required-argumen
> ts-listed-under-optional-arguments
>
> a way of adding a section 'required arguments' to the usage is 
> described.
>

Of _course_ some options need to be required.

I can't imagine what the author of that page was thinking.
--
https://mail.python.org/mailman/listinfo/python-list

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

[issue43834] Use context manager in StringIO example

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Except for that, the PR looks fine.  Leaving this open to see what Benjamin 
thinks.

--
resolution: rejected -> 
status: closed -> open

___
Python tracker 

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

[issue43834] Use context manager in StringIO example

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Let's leave the example as-is.   The principal use case for these objects is to 
pass them into other APIs that require file-like objects.  Those can't always 
be put in a context manager.  For this example, we mainly want to communicate 
that getvalue() must be called before the object is closed.  The current form 
communicates that clearly.

Thanks for the suggestion.

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

[issue43891] co_annotations branch caused a crash in stackeffect() in compile.c

[Larry Hastings]

Larry Hastings  added the comment:

(Sorry, the name of the function is stackdepth(), not stackeffect().)

--

___
Python tracker 

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

[issue43891] co_annotations branch caused a crash in stackeffect() in compile.c

[Larry Hastings]

New submission from Larry Hastings :

I'm working on a branch to implement PEP 649:

https://github.com/larryhastings/co_annotations/

Inada Naoki discovered a crash in that branch, discussed here, including steps 
to reproduce:

https://github.com/larryhastings/co_annotations/issues/10

valgrind showed me what the problem was.  stackeffect() allocates a "stack" 
variable, used to store pushed/popped context while iterating over the basic 
blocks of the function being assembled.  Most of the time, the stack is way 
bigger than it needs to be--we allocate 4 or 5 entries and it only uses 1 or 2. 
 But, somehow, in the co_annotations branch, the "stack" was occasionally *way 
too small*.  As in, it allocated 66 entries (!) but used 150 (!!).

I don't understand exactly how stackeffect works, so I don't know under what 
circumstances it would go so deep, much less what would cause it to so severely 
underestimate how many entries it needed.  I *did* make modifications to code 
generation in compile.c, so it *could* be my bug--but my changes were all much 
earlier in the process, and AFAIK I never touched any of the code under 
assemble().

Well, not until I worked around this problem, anyway.  My fix: if "stack" is 
too small, double the size and realloc().  Certainly it makes the problem go 
away.  That's checked in to my branch here:

https://github.com/larryhastings/co_annotations/commit/63b415c3607af8ba9263b179fb05bb89ccd2e036

But it doesn't address the underlying bug, whatever it is.

If anybody who understands stackeffect() could take a look and figure it out?  
That would be neat-o keen.

--
components: Interpreter Core
messages: 391413
nosy: larry
priority: normal
severity: normal
stage: patch review
status: open
title: co_annotations branch caused a crash in stackeffect() in compile.c
type: crash
versions: Python 3.10

___
Python tracker 

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

[issue43888] GitHub Actions CI/CD `Coverage` job is broken on master

[Brett Cannon]

Brett Cannon  added the comment:

It might be time to just kill the coverage report since people are obviously 
not looking at the results.

--

___
Python tracker 

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

[issue25460] Misc/.gdbinit uses preprocessor macro

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:


New changeset 7a041162468b83f6cad667b78ed5c786286aed2b by Pablo Galindo in 
branch 'master':
bpo-25460: Surround suggestions by quotes (GH-25473)
https://github.com/python/cpython/commit/7a041162468b83f6cad667b78ed5c786286aed2b


--

___
Python tracker 

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

Re: Determine what the calling program is

[Barry]

> On 19 Apr 2021, at 22:49, Cameron Simpson  wrote:
> 
> On 19Apr2021 23:13, Peter J. Holzer  wrote:
>>> On 2021-04-19 08:54:06 +1000, Cameron Simpson wrote:
>>> My personal preference is lock directories. Shell version goes like
>>> this:
>>> 
>>>if mkdir /my/lock/directory/name-of-task
>>>then
>>>   .. do task ..
>>>   rmdir /my/lock/directory/name-of-task
>>>else
>>>  echo "lock /my/lock/directory/name-of-task already taken"
>>>fi
>>> 
>>> Simple, reliable, even works over NFS if you care.
>> 
>> Reliable only if "fail locked" is acceptable. If that process dies for
>> some reason the lock directory will stay behind, blocking other
>> processes until somebody notices the problem and removes it.
> 
> A Python context manager narrows the range of circumstances for this 
> failure quite a lot. But yes.
> 
>> The fcntl method suggested by several people has the advantage that the
>> lock vanished with the process which holds it.
> 
> This is very true. OTOH, mkdir's easy to debug if it hangs around.

Only the fcntl method is robust. Your suggestion with mkdir is not
reliable in practice. If you need a lock in the sh env then there are
standard patterns using the flock command. See the man page
for examples.

Barry



> 
> Cheers,
> Cameron Simpson 
> -- 
> https://mail.python.org/mailman/listinfo/python-list
> 

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

[issue31213] __context__ reset to None in nested exception

[Irit Katriel]

Change by Irit Katriel :


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

[issue43284] sys.getwindowsversion().platform_version is incorrect

[Steve Dower]

Steve Dower  added the comment:

> In that case, would you want to deprecate 
> sys.getwindowsversion().platform_version?

Yeah, but I'm not so concerned about raising a warning on use. Just in 
the docs will be fine. We should also add a mention that it is 
extracting the value from efficient but unstable system locations that 
may change in future releases. (That is not my suggested wording btw, 
just the gist of what we should mention.)

--

___
Python tracker 

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

[issue43284] sys.getwindowsversion().platform_version is incorrect

[Eryk Sun]

Eryk Sun  added the comment:

> If we're going to launch cmd.exe, I'd prefer to only do that in the 
> platform module and not the sys function. Nothing in sys should 
> start a subprocess (if we can at all avoid it).

In that case, would you want to deprecate 
sys.getwindowsversion().platform_version?

platform._syscmd_ver() is already implemented to parse the output of CMD's VER 
command. The result has to be post-processed because the regex isn't as exact 
as it could be. It supports versions back to Windows 2000, which returned 
"Microsoft Windows 2000 [Version maj.min.build]". Starting with Windows Vista 
up to early versions of Windows 10, the format is "Microsoft Windows [Version 
maj.min.build]". In more recent versions of Windows 10, it includes the update 
build revision number -- "Microsoft Windows [Version maj.min.build.ubr]".

--

___
Python tracker 

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

Re: Determine what the calling program is

[Cameron Simpson]

On 19Apr2021 23:13, Peter J. Holzer  wrote:
>On 2021-04-19 08:54:06 +1000, Cameron Simpson wrote:
>> My personal preference is lock directories. Shell version goes like
>> this:
>>
>> if mkdir /my/lock/directory/name-of-task
>> then
>>.. do task ..
>>rmdir /my/lock/directory/name-of-task
>> else
>>   echo "lock /my/lock/directory/name-of-task already taken"
>> fi
>>
>> Simple, reliable, even works over NFS if you care.
>
>Reliable only if "fail locked" is acceptable. If that process dies for
>some reason the lock directory will stay behind, blocking other
>processes until somebody notices the problem and removes it.

A Python context manager narrows the range of circumstances for this 
failure quite a lot. But yes.

>The fcntl method suggested by several people has the advantage that the
>lock vanished with the process which holds it.

This is very true. OTOH, mkdir's easy to debug if it hangs around.

Cheers,
Cameron Simpson 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Determine what the calling program is

[Peter J. Holzer]

On 2021-04-19 08:54:06 +1000, Cameron Simpson wrote:
> My personal preference is lock directories. Shell version goes like 
> this:
> 
> if mkdir /my/lock/directory/name-of-task
> then
>.. do task ..
>rmdir /my/lock/directory/name-of-task
> else
>   echo "lock /my/lock/directory/name-of-task already taken"
> fi
> 
> Simple, reliable, even works over NFS if you care.

Reliable only if "fail locked" is acceptable. If that process dies for
some reason the lock directory will stay behind, blocking other
processes until somebody notices the problem and removes it.

The fcntl method suggested by several people has the advantage that the
lock vanished with the process which holds it.

hp

-- 
   _  | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| |   | h...@hjp.at |-- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |   challenge!"


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Determine what the calling program is

[Peter J. Holzer]

On 2021-04-19 08:04:10 +1200, dn via Python-list wrote:
> In a similar situation, one of my teams used an (OpSys) environment
> variable (available in both *nux and MS-Win).
> - when the application starts, it checks for the variable
> - if exists, stops running, else may proceed

That doesn't work on Unix-like OSs. An environment variable can only be
passwd to child processes, not to the parent or unrelated processes. So
it can't be used to lock out other processes - they wouldn't ever see
the variable.

hp

-- 
   _  | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| |   | h...@hjp.at |-- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |   challenge!"


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue43878] ./configure fails on Apple Silicon with coreutils uname

[Keith Smiley]

Keith Smiley  added the comment:

Yep for sure, this is the first time I've hit a difference with uname 
specifically

--
title: ./configure fails on Apple Silicon -> ./configure fails on Apple Silicon 
with coreutils uname

___
Python tracker 

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

[issue43878] ./configure fails on Apple Silicon

[Ned Deily]

Ned Deily  added the comment:

Thanks for the additional info and the PR. Yes, it probably does make sense to 
update them. But it also makes sense to avoid getting into problems building 
(Python and likely some other projects) with replacements for Apple-supplied 
utilities :)  I note that MacPorts installs coreutils with a "g" prefix (e.g. 
"guname") for just this reason.

--
type: compile error -> 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

[issue38530] Offer suggestions on AttributeError and NameError

[Pablo Galindo Salgado]

Change by Pablo Galindo Salgado :


--
pull_requests: +24201
pull_request: https://github.com/python/cpython/pull/25473

___
Python tracker 

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

[issue43466] ssl/hashlib: Add configure option to set or auto-detect rpath to OpenSSL libs

[Pablo Galindo Salgado]

Change by Pablo Galindo Salgado :


--
pull_requests: +24200
pull_request: https://github.com/python/cpython/pull/25475

___
Python tracker 

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

[issue43878] ./configure fails on Apple Silicon

[Keith Smiley]

Keith Smiley  added the comment:

Thanks for checking, I was able to debug further and it turns out the actual 
issue is if you use `uname` from `coreutils`, you get different results:

```
% /opt/homebrew/opt/coreutils/libexec/gnubin/uname -p
arm64
% /usr/bin/uname -p
arm
```

I have this in my $PATH (not specifically for uname but for other coreutils 
binaries) which is what lead to this. This update fixes this because the newer 
config.sub version contains a case for `arm64` that didn't exist before 
https://github.com/python/cpython/pull/25450/files#diff-9c966208fd0a0c8e24a1526da6904887c378283b9b645b9740c19339884174d9R1107

So this isn't as big of an issue as I thought, but I still think it makes sense 
to update these files.

--

___
Python tracker 

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

[issue43878] ./configure fails on Apple Silicon

[Ned Deily]

Ned Deily  added the comment:

I'm unable to reproduce the failure you see using the current top of the master 
branch (or the 3.9 branch) when running ./configure on an M1 Mac with macOS 
11.2.3 and Xcode 12.4. The results I see are:

checking build system type... arm-apple-darwin20.3.0
checking host system type... arm-apple-darwin20.3.0

How are you producing the source that you are building from?

--
nosy: +ned.deily

___
Python tracker 

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

[issue43882] urllib.parse should sanitize urls containing ASCII newline and tabs.

[Mike Lissner]

Change by Mike Lissner :


--
nosy: +Mike.Lissner

___
Python tracker 

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

[issue43883] Making urlparse WHATWG conformant

[Mike Lissner]

Change by Mike Lissner :


--
nosy: +Mike.Lissner

___
Python tracker 

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

[issue32951] Prohibit direct instantiation of SSLSocket and SSLObject

[Christian Heimes]

Change by Christian Heimes :


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

[issue34391] test_ftplib is failing with TLS 1.3

[Christian Heimes]

Christian Heimes  added the comment:

I don't think there is anything left to do.

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

[issue43811] Run GHA CI with multiple OpenSSL versions

[Christian Heimes]

Change by Christian Heimes :


--
dependencies:  -Run GHA CI with multiple OpenSSL versions
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

[issue42166] corrupted size vs. prev_size

[Christian Heimes]

Christian Heimes  added the comment:

Python 3.7 no longer receives regular updates. Please feel free to reopen the 
bug if you can reproduce the issue with a more recent Python and OpenSSL 
version.

--
resolution:  -> out of date
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

[issue43284] sys.getwindowsversion().platform_version is incorrect

[Steve Dower]

Steve Dower  added the comment:

Python is a volunteer built project, so someone will need to volunteer 
to write the fix. Until there is a volunteer, there is no plan. (One of 
the core devs might volunteer, but there's no guarantee of that.)

If we're going to launch cmd.exe, I'd prefer to only do that in the 
platform module and not the sys function. Nothing in sys should start a 
subprocess (if we can at all avoid it).

--

___
Python tracker 

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

[issue37355] SSLSocket.read does a GIL round-trip for every 16KB TLS record

[Christian Heimes]

Christian Heimes  added the comment:

Josh, could you please rebase your branch and create a pull request? The PR 
process will verify that you have submitted a CLA.

--

___
Python tracker 

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

[issue36011] ssl - tls verify on Windows fails

[Tianon]

Change by Tianon :


--
nosy: +tianon

___
Python tracker 

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

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

[Christian Heimes]

Christian Heimes  added the comment:

There is no progress on the OpenSSL bug yet.

--
versions: +Python 3.10, Python 3.9

___
Python tracker 

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

[issue34028] Python 3.7.0 wont compile with SSL Support 1.1.0 > alledged missing X509_VERIFY_PARAM_set1_host() support

[Christian Heimes]

Christian Heimes  added the comment:

Python 3.10 contains various improvements that make it easier to compile and 
link Python with a custom OpenSSL installation. You can find more information 
in ticket bpo-43466.

--
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
superseder:  -> ssl/hashlib: Add configure option to set or auto-detect rpath 
to OpenSSL libs
versions: +Python 3.10 -Python 3.8

___
Python tracker 

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

[issue25460] Misc/.gdbinit uses preprocessor macro

[Pablo Galindo Salgado]

Change by Pablo Galindo Salgado :


--
nosy: +pablogsal
nosy_count: 2.0 -> 3.0
pull_requests: +24199
pull_request: https://github.com/python/cpython/pull/25473

___
Python tracker 

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

[issue37666] urllib.requests.urlopen: deprecate cafile=None, capath=None, cadefault=False

[Christian Heimes]

Change by Christian Heimes :


--
assignee: christian.heimes -> 
components:  -SSL
title: urllib.requests.urlopen doesn't support cadata= -> 
urllib.requests.urlopen: deprecate cafile=None, capath=None, cadefault=False
versions: +Python 3.10 -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

[issue37120] Provide knobs to disable session ticket generation on TLS 1.3

[Christian Heimes]

Change by Christian Heimes :


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

[issue35422] misleading error message from ssl.get_server_certificate() when bad port

[Christian Heimes]

Christian Heimes  added the comment:

There is no easy fix for that. The TLS handskae is performed by OpenSSL 
internally. You could open a feature request with OpenSSL and ask them to 
implement better error detection and reporting.

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

[issue40432] Pegen regenerate project for Windows not working

[Steve Dower]

Steve Dower  added the comment:

That'll be a change to PCbuild/find_python.bat that needs to be backported 
then. It probably defaults to 3.7 in all branches right now, but since 3.9 is 
out we can update them all to that (it downloads on demand if necessary).

--

___
Python tracker 

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

[issue43866] Installation files of the Python

[Steve Dower]

Steve Dower  added the comment:

Yeah, it's a known limitation of the installer technology we're using. 
issue25166 is the same issue, so we'll track it there.

--
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Windows AllUsers installation places uninstaller in user profile

___
Python tracker 

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

[issue36137] SSL verification fails for some sites inside windows docker container

[Christian Heimes]

Christian Heimes  added the comment:

I'm closing this issue as duplicate of #36137. There is no need to keep two 
issues open for the same problem.

--
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> SSL verification fails for some sites inside windows docker 
container

___
Python tracker 

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

[issue34670] Add set_post_handshake_auth for TLS 1.3

[Christian Heimes]

Christian Heimes  added the comment:

I don't think is anything left to do here. PHA has been supported for a while 
and I haven't seen any problems.

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

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

Re: Current thinking on required options

[Dan Stromberg]

On Mon, Apr 19, 2021 at 12:36 PM Grant Edwards 
wrote:

> On 2021-04-19, Dan Stromberg  wrote:
> > On Mon, Apr 19, 2021 at 2:55 AM Loris Bennett <
> loris.benn...@fu-berlin.de> wrote:
> >
> >> However, the options -o, -u, and -g are required, not optional.
> >>
> >> The documentation
> >>
> >>   https://docs.python.org/3/library/argparse.html#required
> >>
> >> advises against required options and here
> >>
> >>
> >>
> https://stackoverflow.com/questions/24180527/argparse-required-arguments-listed-under-optional-arguments
> >>
> >> a way of adding a section 'required arguments' to the usage is
> >> described.
> >>
> >
> > Of _course_ some options need to be required.
>
> Traditionally, required "things" were called arguments and were not
> prefixed with a hyphen. Optional "things" were called options (hence
> the similarity in spelling between "optional" and "option").
>

This is a silly thread.  "option" should be conflated with "optional" no
more than "argument" should be conflated with "a logician's disagreement".

$ cpio
below cmd output started 2021 Mon Apr 19 12:47:07 PM PDT
cpio: You must specify one of -oipt options.
Try `cpio --help' or `cpio --usage' for more information.

Try 'cpio --help' or 'cpio --usage' for more information.


$ tar
below cmd output started 2021 Mon Apr 19 12:49:47 PM PDT
tar: You must specify one of the '-Acdtrux', '--delete' or '--test-label'
options
Try 'tar --help' or 'tar --usage' for more information.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue32813] SSL shared_ciphers implementation wrong - returns configured but not shared ciphers

[Christian Heimes]

Christian Heimes  added the comment:

3.10 now supports only OpenSSL versions that return the correct value. Older 
Python versions may return wrong value when they are linked with OpenSSL 1.1.0 
or 1.0.2.

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

Re: do ya still use python?

[Ethan Furman]

On 4/19/21 11:22 AM, Unbreakable Disease wrote:

[offensive drivel]

List, my apologies -- not sure how that one got through.

--
~Ethan~
Python List Moderator
--
https://mail.python.org/mailman/listinfo/python-list

[issue43888] GitHub Actions CI/CD `Coverage` job is broken on master

[Ned Deily]

Change by Ned Deily :


--
nosy: +brett.cannon, pablogsal

___
Python tracker 

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

[issue43284] sys.getwindowsversion().platform_version is incorrect

[Shreyan Avigyan]

Shreyan Avigyan  added the comment:

Ok. So are you planning to implement this fix?

--

___
Python tracker 

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

[issue43885] ResourceWarning: unclosed test_pha_required_nocert

[STINNER Victor]

STINNER Victor  added the comment:

Duplicate of bpo-37322 that I reported at 2019-06-17.

--

___
Python tracker 

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

[issue43284] sys.getwindowsversion().platform_version is incorrect

[Eryk Sun]

Eryk Sun  added the comment:

> But isn't calling CMD's VER command risky? A process can overwrite its 
> PEB OSMajorVersion, OSMinorVersion, and OSBuildNumber. 

As long as VER is executed without quotes, the shell will not search for an 
external command. CMD is not going to intentionally overwrite the OS version 
and build number in the PEB, so that would be due to some kind of weird, 
unlikely bug. (CMD's code base is stable. It hasn't seen a new feature since 
MKLINK was added 15 years ago.) If malware messes with this, for some strange 
reason, it's not Python's problem. For example, I'll attach a debugger and do 
just that:

0:000> ?? @$peb->OSMajorVersion = 11
unsigned long 0xb
0:000> ?? @$peb->OSMinorVersion = 0
unsigned long 0
0:000> ?? @$peb->OSBuildNumber = 0x8000
unsigned short 0x8000

C:\>ver
Microsoft Windows [Version 11.0.32768.0]

Hi from the future. :)

> If the cmd has been set to compatibility mode 

"%SystemRoot%\System32\cmd.exe" is exempt from compatibility mode (e.g. the 
"__COMPAT_LAYER" environment variable).

--

___
Python tracker 

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

[issue43880] 3.10 SSL module deprecations

[Christian Heimes]

Christian Heimes  added the comment:

I'm leaving the issue open as a reminder to improve whatsnew documentation.

--
priority: high -> normal

___
Python tracker 

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

Re: Current thinking on required options

[Grant Edwards]

On 2021-04-19, Dan Stromberg  wrote:
> On Mon, Apr 19, 2021 at 2:55 AM Loris Bennett  
> wrote:
>
>> However, the options -o, -u, and -g are required, not optional.
>>
>> The documentation
>>
>>   https://docs.python.org/3/library/argparse.html#required
>>
>> advises against required options and here
>>
>>
>> https://stackoverflow.com/questions/24180527/argparse-required-arguments-listed-under-optional-arguments
>>
>> a way of adding a section 'required arguments' to the usage is
>> described.
>>
>
> Of _course_ some options need to be required.

Traditionally, required "things" were called arguments and were not
prefixed with a hyphen. Optional "things" were called options (hence
the similarity in spelling between "optional" and "option").

> I can't imagine what the author of that page was thinking.

--
Grant

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

[issue38748] 32 bit ctypes stdcall callback fails to restore stack pointer

[Steve Dower]

Steve Dower  added the comment:

Even better, one that doesn't crash but safely returns a value that can be 
checked. (IIRC, we have a test that does this to ensure that structs smaller 
than 9 bytes are passed on the stack.)

Half C/half Python is fine - the C bits would go into _ctypes_test.c

Given how well you reported the issue in the first place, I'm confident the 
quick start in the devguide will get you up and building quickly: 
https://devguide.python.org/  Adding the test might be a bit more of an 
adventure (though not as much as fixing it...)

--

___
Python tracker 

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

[issue43492] Upgrade to SQLite 3.35.5 in macOS and Windows

[Erlend Egeberg Aasland]

Erlend Egeberg Aasland  added the comment:

SQLite 3.35.5 is out today. Let's wait until next weekend and see if fossil and 
forum is quiet. If they are, I'll open PRs for the installers.

https://www.sqlite.org/releaselog/3_35_5.html

--
title: Upgrade to SQLite 3.35.4 in macOS and Windows -> Upgrade to SQLite 
3.35.5 in macOS and Windows

___
Python tracker 

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

[issue43890] Deadlock when mixing event loops and subprocesses

[Thomas Buhrmann]

New submission from Thomas Buhrmann :

When mixing code that spawns subprocesses with code that creates event loops, 
Python appears to deadlock.

In the attached example, when WORKERS = 16 and ASYNC_WORKERS = 8, Python will 
sometimes (50% of the time?) deadlock, never exiting, with no exceptions 
raised. Oddly, if ASYNC_WORKERS is set to 0 or 16 (i.e., only subprocesses or 
only event loops), it runs reliably.

I tested this in an x86_64 Ubuntu 20.04.2 VM with Python 3.8.6. I was only able 
to reproduce it when the VM had more than one CPU, and I was unable to 
reproduce it on x86_64 MacOS.

--
files: subprocess_asyncio_deadlock.py
messages: 391386
nosy: thomas
priority: normal
severity: normal
status: open
title: Deadlock when mixing event loops and subprocesses
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file49967/subprocess_asyncio_deadlock.py

___
Python tracker 

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

Re: do ya still use python?

[Unbreakable Disease]

On 19.04.2021 17:37, JWS wrote:

On Monday, April 19, 2021 at 11:44:11 AM UTC-5, Unbreakable Disease wrote:

almost no useful posts here for almost a year. is python dying?

I can't tell what group you are referencing.
comp.lang.python is still active.
I'm doing a tkinter project now.


Active for these moron spammers who keep it alive thanks to all stupid 
dudes who think Stack Overflow has an answer to every solution.



--
Tip me: bc1qtwmjzywve5v7z6jzk4dkg7v6masw2erpahsn9f

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

Re: Current thinking on required options

[Chris Angelico]

On Tue, Apr 20, 2021 at 4:18 AM Bill Campbell  wrote:
>
> On Mon, Apr 19, 2021, Loris Bennett wrote:
> >Hi,
> >
> >I have various small programs which tend to have an interface like the
> >following example:
> >
> >  usage: grocli [-h] [-o {check,add,delete}] [-u USERS [USERS ...]] [-g 
> > GROUP]
>
> I would do this with the action is first argument.
>
> Usage: grocli check|add|delete [-u USERS ...]
>

Which aligns well with a concept of subcommands (or, in argparse
terms, subparsers).

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

Re: Current thinking on required options

[Bill Campbell]

On Mon, Apr 19, 2021, Loris Bennett wrote:
>Hi,
>
>I have various small programs which tend to have an interface like the
>following example:
>
>  usage: grocli [-h] [-o {check,add,delete}] [-u USERS [USERS ...]] [-g GROUP]

I would do this with the action is first argument.

Usage: grocli check|add|delete [-u USERS ...]

Bill
-- 
INTERNET:   b...@celestial.com  Bill Campbell; Celestial Software LLC
URL: http://www2.celestial.com/ 6641 E. Mercer Way
Mobile: (206) 947-5591  PO Box 820
Fax:(206) 232-9186  Mercer Island, WA 98040-0820

Force always attracts men of low morality.  -- Albert Einstein
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Current thinking on required options

[Peter J. Holzer]

On 2021-04-19 16:38:24 -, Jon Ribbens via Python-list wrote:
> On 2021-04-19, Paul Bryan  wrote:
> > Calling them options—when they're required—seems like a problem. 
> 
> The option is what the value is, not whether there is a value at all.
> If you order a coffee then you may have an option as to what temperature
> it is, that doesn't mean the coffee having a temperature is optional.

No, but you having to specify the temperature is optional. Yoy might
order an extra-hot coffee or s luke-warm coffee, but most of the time
you will just order a coffee and accept it being at the default
temperature.

I would agree with others that options should in general be optional.

I do break that that rule sometimes, though: If there are several
required arguments and they have no obvious natural order, I might use
required options for those just to prevent the user (me) from swapping
them.

hp

-- 
   _  | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| |   | h...@hjp.at |-- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |   challenge!"


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue43710] Access violations in C extension modules on Python 3.9.3

[Sunday]

Change by Sunday :


Added file: https://bugs.python.org/file49966/logs.gz

___
Python tracker 

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

Re: Current thinking on required options

[Jon Ribbens via Python-list]

On 2021-04-19, Paul Bryan  wrote:
> Calling them options—when they're required—seems like a problem. 

The option is what the value is, not whether there is a value at all.
If you order a coffee then you may have an option as to what temperature
it is, that doesn't mean the coffee having a temperature is optional.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Current thinking on required options

[Dan Stromberg]

I guess maybe it seems like a problem to someone who hasn't used command
line tools much, based solely on a simplistic interpretation of the
terminology.

But strictly speaking, they're "command line options", or better "command
line arguments", not "options".

On Mon, Apr 19, 2021 at 9:30 AM Paul Bryan  wrote:

> Calling them options—when they're required—seems like a problem. 
>
> On Mon, 2021-04-19 at 09:04 -0700, Dan Stromberg wrote:
>
> On Mon, Apr 19, 2021 at 2:55 AM Loris Bennett 
> wrote:
>
> However, the options -o, -u, and -g are required, not optional.
>
> The documentation
>
>   https://docs.python.org/3/library/argparse.html#required
>
> advises against required options and here
>
>
>
> https://stackoverflow.com/questions/24180527/argparse-required-arguments-listed-under-optional-arguments
>
> a way of adding a section 'required arguments' to the usage is
> described.
>
>
> Of _course_ some options need to be required.
>
> I can't imagine what the author of that page was thinking.
>
>
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Current thinking on required options

[Paul Bryan]

Calling them options—when they're required—seems like a problem. 

On Mon, 2021-04-19 at 09:04 -0700, Dan Stromberg wrote:
> On Mon, Apr 19, 2021 at 2:55 AM Loris Bennett
> 
> wrote:
> 
> > However, the options -o, -u, and -g are required, not optional.
> > 
> > The documentation
> > 
> >   https://docs.python.org/3/library/argparse.html#required
> > 
> > advises against required options and here
> > 
> > 
> > https://stackoverflow.com/questions/24180527/argparse-required-arguments-listed-under-optional-arguments
> > 
> > a way of adding a section 'required arguments' to the usage is
> > described.
> > 
> 
> Of _course_ some options need to be required.
> 
> I can't imagine what the author of that page was thinking.

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

[issue43837] Operator precedence documentation could be more clear

[Raymond Hettinger]

Raymond Hettinger  added the comment:

* Changed the table order to match norms.

* Not adding and for variables because that is outside the norm (likely because 
variables aren't operators).

* Keeping the existing terminology which is standard and historically hasn't 
been a problem.  Also the tone and level matches that for the rest of the 
reference guide.

Thank you all for your input.

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

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

Re: Current thinking on required options

[Dan Stromberg]

On Mon, Apr 19, 2021 at 2:55 AM Loris Bennett 
wrote:

> However, the options -o, -u, and -g are required, not optional.
>
> The documentation
>
>   https://docs.python.org/3/library/argparse.html#required
>
> advises against required options and here
>
>
> https://stackoverflow.com/questions/24180527/argparse-required-arguments-listed-under-optional-arguments
>
> a way of adding a section 'required arguments' to the usage is
> described.
>

Of _course_ some options need to be required.

I can't imagine what the author of that page was thinking.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue43837] Operator precedence documentation could be more clear

[Raymond Hettinger]

Raymond Hettinger  added the comment:


New changeset 072ec69af592611f36349f5048569ab7e72b8b61 by Miss Islington (bot) 
in branch '3.9':
bpo-43837: Reverse order of precedence table to show tightly binding operators 
first (GH-25469) (GH-25472)
https://github.com/python/cpython/commit/072ec69af592611f36349f5048569ab7e72b8b61


--

___
Python tracker 

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

[issue43889] Pickle performance regression in 3.10

[Raymond Hettinger]

Change by Raymond Hettinger :


--
nosy: +rhettinger

___
Python tracker 

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

[issue43889] Pickle performance regression in 3.10

[Ken Jin]

Ken Jin  added the comment:

> It definitely shouldn't be related to any of these, all are unrelated code 
> paths.

Yeah I thought so too :(. After looking at the benchmark code in pyperformance, 
I can't find anything related in the commits that would cause such a big 
difference. Hmmm...

--

___
Python tracker 

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

[issue43889] Pickle performance regression in 3.10

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

It definitely shouldn't be related to any of these, all are unrelated code 
paths.

--

___
Python tracker 

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

[issue41370] PEP 585 and ForwardRef

[wyz23x2]

Change by wyz23x2 :


--
nosy:  -wyz23x2

___
Python tracker 

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

[issue43837] Operator precedence documentation could be more clear

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 10.0 -> 11.0
pull_requests: +24198
pull_request: https://github.com/python/cpython/pull/25472

___
Python tracker 

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

[issue43837] Operator precedence documentation could be more clear

[Raymond Hettinger]

Raymond Hettinger  added the comment:


New changeset 68ba0c67cac10c2545ea3b62d8b161e5b3594edd by Ammar Askar in branch 
'master':
bpo-43837: Reverse order of precedence table to show tightly binding operators 
first (GH-25469)
https://github.com/python/cpython/commit/68ba0c67cac10c2545ea3b62d8b161e5b3594edd


--

___
Python tracker 

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

Re: Current thinking on required options

[Barry]

> On 19 Apr 2021, at 10:57, Loris Bennett  wrote:
> 
> Hi,
> 
> I have various small programs which tend to have an interface like the
> following example:
> 
>  usage: grocli [-h] [-o {check,add,delete}] [-u USERS [USERS ...]] [-g GROUP]
> 
>  Command line grouper tool
> 
>  optional arguments:
>-h, --helpshow this help message and exit
>-o {check,add,delete}, --operation {check,add,delete}
>  operation to apply
>-u USERS [USERS ...], --users USERS [USERS ...]
>  users to apply operation to
>-g GROUP, --group GROUP
>  group to apply operation to
> 
> However, the options -o, -u, and -g are required, not optional.

You could use positional args like this:

grocli check user,user group

Barry

> 
> The documentation
> 
>  https://docs.python.org/3/library/argparse.html#required
> 
> advises against required options and here
> 
>  
> https://stackoverflow.com/questions/24180527/argparse-required-arguments-listed-under-optional-arguments
> 
> a way of adding a section 'required arguments' to the usage is
> described.
> 
> I would be interested to know what the general thinking on "required
> options" is.  Is there just a better way of designing such interfaces?
> 
> Cheers,
> 
> Loris
> 
> -- 
> This signature is currently under construction.
> -- 
> https://mail.python.org/mailman/listinfo/python-list
> 

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

[issue43889] Pickle performance regression in 3.10

[Ken Jin]

New submission from Ken Jin :

Hi everyone, I noticed on speed.python.org that the pickle benchmarks are 
noticeably slower:

Overall, pickle slowed down by >10%
https://speed.python.org/timeline/?exe=12==pickle=1=200=off=on=on

Pickling list and dict is also slower by >10%:
https://speed.python.org/timeline/?exe=12==pickle_list=1=200=off=on=on

https://speed.python.org/timeline/?exe=12==pickle_dict=1=200=off=on=on

For some reason, the pickle_pure_python benchmark which doesn't use the _pickle 
C library has no change.

The regression happened somewhere between commit 
11159d2c9d6616497ef4cc62953a5c3cc8454afb and 
3fc65b97d09fd29272fdf60d2e567bfb070da824. I don't know which commit caused it 
as there doesn't seem to be a change to _pickle.c. I have a weak hunch that it 
may be linked to Issue38530 (since the other commits in that time range are 
docs, sqllite3, ssl and unrelated python libraries) but I'm unsure. I'll try to 
bisect things this weekend if nobody's started on it by then.

Thanks for your time!

--
components: Library (Lib)
messages: 391380
nosy: alexandre.vassalotti, kj, pablogsal, serhiy.storchaka, vstinner
priority: normal
severity: normal
status: open
title: Pickle performance regression in 3.10
versions: Python 3.10

___
Python tracker 

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

Re: Determine what the calling program is

[Barry Scott]

> On 18 Apr 2021, at 14:46, Jason Friedman  wrote:
> 
> I should state at the start that I have a solution to my problem. I am
> writing to see if there is a better solution.
> 
> I have a program that runs via crontab every five minutes. It polls a
> Box.com folder for files and, if any are found, it copies them locally and
> performs a computation on them that can exceed five minutes. It pushes the
> results back up to Box. (Box.com ensures that only complete files are
> visible when I poll.) Files are dropped into this Box.com folder rarely,
> but to ensure a good customer experience I do not want to set my crontab to
> run less frequently. My hardware cannot support multiple simultaneous
> computations.
> 
> I have written a piece of code to detect if more than 1 instance of my
> program is running, and I put this code into a separate module (support.py)
> so that other programs can use it.

The way to do this simply on a unix system is to use a lock file and code like 
this:

lock_file = open(os.path.join(lock_dir, 'lockfile'), 'w')
try:
fcntl.flock(lock_file, fcntl.LOCK_EX|fcntl.LOCK_NB)
except IOError as e:
if e.errno == errno.EWOULDBLOCK:
log('CA base directory "%s" already locked, exiting', ca_base_dir)
sys.exit(0)
else:
log('Non-locking related IOError for file %s', lock_file)
raise

Only the first time the code runs will the lock be granted.
You can then do the possible long running task.

When a second copy of the program runs from cron it will get the
EWOULDBLOCK error and you can just exit.

Barry



> 
> support.py contains:
> 
> import sys
> def check(calling_program):
>import psutil
># some logic here to count
># count = N
>if count > 1:
>print(f"I was called by {calling_program}.")
>sys.exit()
> if __name__ == "__main__":
>check()
> 
> 
> actual-program.py contains:
> 
> import support.py
> support.check(__file__)
> # Poll, and if files download, perform expensive computations, push results
> 
> 
> To me it would be more elegant to be able to do something like this:
> 
> def check():
># Something here that tells me the name of the calling program
>import psutil
># ...
> 
> And then the calling program just does:
> support.check()
> -- 
> https://mail.python.org/mailman/listinfo/python-list
> 

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

[issue43884] Cannot cleanly kill a subprocess using high-level asyncio APIs

[Ronal Abraham]

Ronal Abraham  added the comment:

I see this on MacOS and Linux, but I suspect any Unix-like system would have 
the same behavior.

--

___
Python tracker 

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

[issue26779] pdb continue followed by an exception in the same frame shows incorrect frame linenumber

[Romuald Brunet]

Romuald Brunet  added the comment:

I meant: this issue is fixed in 3.10

--

___
Python tracker 

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

[issue26779] pdb continue followed by an exception in the same frame shows incorrect frame linenumber

[Romuald Brunet]

Romuald Brunet  added the comment:

Ran into a similar issue today

This issue (and mine is fixed) in python 3.10. Most probaly related to #24565 
fix

--
nosy: +Romuald
versions: +Python 3.7, Python 3.8, Python 3.9

___
Python tracker 

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

[issue43887] it seems that sorted built-in always return floats before int if they appear to be equal

[John Mish]

John Mish  added the comment:

Thanks, I should go deeper with it before filing. Wish You have great day 
Steven.

--

___
Python tracker 

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

[issue43887] it seems that sorted built-in always return floats before int if they appear to be equal

[Steven D'Aprano]

Steven D'Aprano  added the comment:

Hi John, you said:

> it seems that sorted built-in always return floats before int if they appear 
> to be equal

But that's not correct:

>>> sorted([5.0, 5])
[5.0, 5]
>>> sorted([5, 5.0])
[5, 5.0]


Python's sort is *stable*, which means that the order of two equal values will 
always be the same as before they were sorted.

You then ask:

> So, what about trying to "store" if some float is 12 "in limit" of 12 but 
> from "left/-"? So then it is < than 12.


Short answer: no.

Longer answer: no, we're not going to complicate and slow down both floats and 
sorting in order to give "do what I mean" results for sorting.

What you are seeing is a fundamental limitation of floating point arithmetic. 
On the web, you can find dozens of sites that talk about this, in pretty much 
every single programming language with floating point numbers. You might like 
to start with the Python FAQ:

https://docs.python.org/3/faq/design.html#why-are-floating-point-calculations-so-inaccurate

In your case, you are being tripped up by the fact that there is no such float 
as either 11. or 12.0001. Both of those are rounded 
to *exactly* 12.0, as the float data type only has (approximately) 17 decimal 
places of precision.

This is a fundamental feature of floating point numbers and there is nothing we 
can do about that without massively complicating and slowing down floats.

By the way, Decimal are floating point numbers too. They are equally affected 
by this, except that being stored in decimal with more digits by default, 
rather than binary, it is not so easy to trip over it. But it can certainly 
happen to Decimals as well.

--
nosy: +steven.daprano
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

EuroPython 2021: Ticket sales started

[M.-A. Lemburg]

We're pleased to announce the start of the EuroPython 2021 ticket sales:

* EuroPython 2021 Ticket Sales Open *

https://ep2021.europython.eu/registration/buy-tickets/


Updated ticket structure


For EuroPython 2021, we'll have more than 10 training sessions and
workshops spread across two days. There is a combined ticket available
for those who wish to attend both.

We also added a new livestream-only ticket for getting access to the
live streams. It's free, but you'll miss out on the interactivity.

Ticket types


- Combined tickets: Access to the whole seven day conference, including
  training sessions, workshops, conference days and sprints.

- Conference + sprint tickets: Access to conference days and sprints.

- Sprint-only tickets: Free access to the sprint days only.

- Livestream-only tickets: Free access to the live streams of the
  conference sessions only. No access to the conference system.

Ticket tiers


- Business tickets: For people using Python to make a living and people
  who want to support our grants program.

- Personal tickets: For people enjoying Python in their free time or as
  a freelancer.

More details


For full details, which include ticket prices, a comparison features and
the link to the ticket shop, please see our registration page.  Our
financial aid program will be available starting Wednesday, April 21.

Participate in Talk Voting
--

With a conference or combined ticket, you will also be able to tell us
what you’d like to see at EuroPython 2021 by voting on the submitted
talk proposals. Talk voting will start after the end of the Call for
Proposals (CFP).

Guido van Rossum Core Developer Grant
-

For Python Core Developers, we have put a special grant in place, which
will allow core developers to get free combined tickets to the
conference.

If you want to sign up, please check our grant page for details on how
to apply.

Quick Summary
-
EuroPython 2021 will be run online from July 26 - August 1:

- Two workshop/training days (July 26 - 27)
- Three conference days (July 28 - 30)
- Two sprint days (July 31 - August 1)

The sessions will be scheduled to ensure they are also accessible for
those in the Asian and Americas time zones.


Help spread the word


Please help us spread this message by sharing it on your social
networks as widely as possible. Thank you !

Link to the blog post:

https://blog.europython.eu/europython-2021-ticket-sales-started/

Tweet:

https://twitter.com/europython/status/1384076406418595846

Enjoy,
--
EuroPython 2021 Team
https://www.europython-society.org/

___
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

EuroPython 2021: Ticket sales started

[M.-A. Lemburg]

We're pleased to announce the start of the EuroPython 2021 ticket sales:

* EuroPython 2021 Ticket Sales Open *

https://ep2021.europython.eu/registration/buy-tickets/


Updated ticket structure


For EuroPython 2021, we'll have more than 10 training sessions and
workshops spread across two days. There is a combined ticket available
for those who wish to attend both.

We also added a new livestream-only ticket for getting access to the
live streams. It's free, but you'll miss out on the interactivity.

Ticket types


- Combined tickets: Access to the whole seven day conference, including
  training sessions, workshops, conference days and sprints.

- Conference + sprint tickets: Access to conference days and sprints.

- Sprint-only tickets: Free access to the sprint days only.

- Livestream-only tickets: Free access to the live streams of the
  conference sessions only. No access to the conference system.

Ticket tiers


- Business tickets: For people using Python to make a living and people
  who want to support our grants program.

- Personal tickets: For people enjoying Python in their free time or as
  a freelancer.

More details


For full details, which include ticket prices, a comparison features and
the link to the ticket shop, please see our registration page.  Our
financial aid program will be available starting Wednesday, April 21.

Participate in Talk Voting
--

With a conference or combined ticket, you will also be able to tell us
what you’d like to see at EuroPython 2021 by voting on the submitted
talk proposals. Talk voting will start after the end of the Call for
Proposals (CFP).

Guido van Rossum Core Developer Grant
-

For Python Core Developers, we have put a special grant in place, which
will allow core developers to get free combined tickets to the
conference.

If you want to sign up, please check our grant page for details on how
to apply.

Quick Summary
-
EuroPython 2021 will be run online from July 26 - August 1:

- Two workshop/training days (July 26 - 27)
- Three conference days (July 28 - 30)
- Two sprint days (July 31 - August 1)

The sessions will be scheduled to ensure they are also accessible for
those in the Asian and Americas time zones.


Help spread the word


Please help us spread this message by sharing it on your social
networks as widely as possible. Thank you !

Link to the blog post:

https://blog.europython.eu/europython-2021-ticket-sales-started/

Tweet:

https://twitter.com/europython/status/1384076406418595846

Enjoy,
--
EuroPython 2021 Team
https://www.europython-society.org/

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

[issue43888] GitHub Actions CI/CD `Coverage` job is broken on master

[Sviatoslav Sydorenko]

Change by Sviatoslav Sydorenko :


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

___
Python tracker 

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

Re: Current thinking on required options

[Loris Bennett]

Gisle Vanem  writes:

> Loris Bennett wrote:
>
>>usage: grocli [-h] [-o {check,add,delete}] [-u USERS [USERS ...]] [-g 
>> GROUP]
>>
>>Command line grouper tool
>>
>>optional arguments:
>>  -h, --helpshow this help message and exit
>>  -o {check,add,delete}, --operation {check,add,delete}
>>operation to apply
>>  -u USERS [USERS ...], --users USERS [USERS ...]
>>users to apply operation to
>>  -g GROUP, --group GROUP
>>group to apply operation to
>>
>> However, the options -o, -u, and -g are required, not optional.
>
> Just a nitpick.
>
> To quote from https://en.wikipedia.org/wiki/Usage_message
> "To indicate required arguments, Angled brackets are
>   commonly used, ..."
>
> So then it should better be written as:
>   grocli [-h] <-o {check,add,delete}> <-u USERS [USERS ...]> <-g GROUP>

I would take that with a pinch of salt.  The Wikipedia page doesn't give
any examples, let alone any that might be considered somehow typical or
representative.  Looking at a few tools I use regularly (awk, cat, grep,
sed, ssh, tmux) I couldn't find any which use the angled-bracket
notation.  So maybe the notation is not common or just not many programs
have this type of option.  The latter would correspond with sentiment in
the argparse documentation that it is an approach to be avoided.

In any case, the usage line is generated automatically by argsparse.

However, I am more interested in what an alternative approach might look
like.

Cheers,

Loris

-- 
This signature is currently under construction.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue40849] Expose X509_V_FLAG_PARTIAL_CHAIN ssl flag

[Christian Heimes]

Change by Christian Heimes :


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

[issue40849] Expose X509_V_FLAG_PARTIAL_CHAIN ssl flag

[miss-islington]

miss-islington  added the comment:


New changeset 64d975202f7a91cb8c61a050fafb4e934fcbaa4e by l0x in branch 
'master':
bpo-40849: Expose X509_V_FLAG_PARTIAL_CHAIN ssl flag (GH-20463)
https://github.com/python/cpython/commit/64d975202f7a91cb8c61a050fafb4e934fcbaa4e


--
nosy: +miss-islington

___
Python tracker 

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

[issue43888] GitHub Actions CI/CD `Coverage` job is broken on master

[Sviatoslav Sydorenko]

Change by Sviatoslav Sydorenko :


--
type: crash -> 

___
Python tracker 

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

[issue43888] GitHub Actions CI/CD `Coverage` job is broken on master

[Sviatoslav Sydorenko]

New submission from Sviatoslav Sydorenko :

I noticed that https://github.com/python/cpython/runs/2378199636 (a coverage 
job on the last commit on master at the time of writing) takes suspiciously 
long to complete.

I did some investigation and noticed that this job on the 3.9 branch succeeds 
(all of the job runs on the first page in the list are green — 
https://github.com/python/cpython/actions/workflows/coverage.yml?query=branch%3A3.9)

But then I took a look at the runs on master and discovered that the last 
successful run was 4 months ago — 
https://github.com/python/cpython/actions.html?query=is%3Asuccess+branch%3Amaster_file_name=coverage.yml.

The last success is https://github.com/python/cpython/actions/runs/444323166 
and after that, starting with 
https://github.com/python/cpython/actions/runs/05699, if fails consistently.

Notably, all of the failures are caused by the job timeout after *6 hours* — 
GitHub platform just kills those, 6h is a default per-job timeout in GHA.

It's also important to mention that before every job starting timing out 
effectively burning 6 hours of GHA time for each merge and producing no useful 
reports, there were occasional 6h-timeouts but they weren't consistent.

Looking into the successful runs from the past, on master and other jobs, I 
haven't noticed it taking more than 1h35m to complete with a successful 
outcome. Taking into account this as a baseline, I suggest changing the timeout 
of the whole job or maybe just one step that actually runs coverage.

Action items:
* Set job timeout in GHA to 1h40m (allowing a bit of extra time for 
exceptionally slow jobs) — this will make sure that the failure/timeout is 
reported sooner than 6h
* Figure out why this started happening in the first place.

I'm going to send a PR addressing the first point but feel free to pick up the 
investigation part — I don't expect to have time for this anytime soon.

P.S. FTR the last timeout of this type happened two months ago — 
https://github.com/python/cpython/actions.html?page=4=branch%3A3.9_file_name=coverage.yml.

--
messages: 391373
nosy: webknjaz
priority: normal
severity: normal
status: open
title: GitHub Actions CI/CD `Coverage` job is broken on master
type: crash

___
Python tracker 

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

[issue43887] it seems that sorted built-in always return floats before int if they appear to be equal

[John Mish]

New submission from John Mish :

A1
>>> sorted([12.001, 2, 1.999, 2.1, 4, 12])
[1.999, 2, 2.1, 4, 12, 12.002]
A2
>>> sorted([12.0001, 2, 1.999, 2.1, 4, 12])
[1.999, 2, 2.1, 4, 12.0, 12]
B1
>>> sorted([11.999, 2, 1.999, 2.1, 4, 12])
[1.999, 2, 2.1, 4, 11.998, 12]
B2
>>> sorted([11., 2, 1.999, 2.1, 4, 12])
[1.999, 2, 2.1, 4, 12.0, 12]

Hello,

In A2 and in B2 we see the same output for 2 not equal expected values.

It seems to be that floats are always first in list.

So, what about trying to "store" if some float is 12 "in limit" of 12 but from 
"left/-"? So then it is < than 12.

12.01 would be then 12 but in upper limit, right/+ 
so > 12

What do You think?

Best regards.

PS ofc I could use decimal, but if it shouldn't work, why it does not raise 
exception and ask for forgiveness... ?

--
components: Interpreter Core
messages: 391372
nosy: johnmish.iam
priority: normal
severity: normal
status: open
title: it seems that sorted built-in always return floats before int if they 
appear to be equal
type: behavior
versions: Python 3.8

___
Python tracker 

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

Re: Current thinking on required options

[Peter Otten]

On 19/04/2021 11:52, Loris Bennett wrote:

Hi,

I have various small programs which tend to have an interface like the
following example:

   usage: grocli [-h] [-o {check,add,delete}] [-u USERS [USERS ...]] [-g GROUP]

   Command line grouper tool

   optional arguments:
 -h, --helpshow this help message and exit
 -o {check,add,delete}, --operation {check,add,delete}
   operation to apply
 -u USERS [USERS ...], --users USERS [USERS ...]
   users to apply operation to
 -g GROUP, --group GROUP
   group to apply operation to

However, the options -o, -u, and -g are required, not optional.

The documentation

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

advises against required options and here

   
https://stackoverflow.com/questions/24180527/argparse-required-arguments-listed-under-optional-arguments

a way of adding a section 'required arguments' to the usage is
described.

I would be interested to know what the general thinking on "required
options" is.  Is there just a better way of designing such interfaces?


For the example above you could realize the operation through subparsers
and switch group and users. In cases where no such "natural" order of
arguments exists I'd have no qualms to use required options. Personally
I've not yet come across such a case.
--
https://mail.python.org/mailman/listinfo/python-list

Re: Current thinking on required options

[Gisle Vanem]

Loris Bennett wrote:


   usage: grocli [-h] [-o {check,add,delete}] [-u USERS [USERS ...]] [-g GROUP]

   Command line grouper tool

   optional arguments:
 -h, --helpshow this help message and exit
 -o {check,add,delete}, --operation {check,add,delete}
   operation to apply
 -u USERS [USERS ...], --users USERS [USERS ...]
   users to apply operation to
 -g GROUP, --group GROUP
   group to apply operation to

However, the options -o, -u, and -g are required, not optional.


Just a nitpick.

To quote from https://en.wikipedia.org/wiki/Usage_message
"To indicate required arguments, Angled brackets are
  commonly used, ..."

So then it should better be written as:
  grocli [-h] <-o {check,add,delete}> <-u USERS [USERS ...]> <-g GROUP>

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

Current thinking on required options

[Loris Bennett]

Hi,

I have various small programs which tend to have an interface like the
following example:

  usage: grocli [-h] [-o {check,add,delete}] [-u USERS [USERS ...]] [-g GROUP]

  Command line grouper tool

  optional arguments:
-h, --helpshow this help message and exit
-o {check,add,delete}, --operation {check,add,delete}
  operation to apply
-u USERS [USERS ...], --users USERS [USERS ...]
  users to apply operation to
-g GROUP, --group GROUP
  group to apply operation to

However, the options -o, -u, and -g are required, not optional.

The documentation

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

advises against required options and here

  
https://stackoverflow.com/questions/24180527/argparse-required-arguments-listed-under-optional-arguments

a way of adding a section 'required arguments' to the usage is
described.

I would be interested to know what the general thinking on "required
options" is.  Is there just a better way of designing such interfaces?

Cheers,

Loris

-- 
This signature is currently under construction.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue43886] Extending/embedding Python documentation outdated/incomplete

[Federico Pellegrin]

Federico Pellegrin  added the comment:

Just a small addition:

Specifically in the documentation it talks about embedding:

"
It is not necessarily trivial to find the right flags to pass to your compiler 
(and linker) in order to embed the Python interpreter into your application, 
particularly because Python needs to load library modules implemented as C 
dynamic extensions (.so files) linked against it.


To find out the required compiler and linker flags, you can execute the 
pythonX.Y-config script which is generated as part of the installation process 
(a python3-config script may also be available). This script has several 
options, of which the following will be directly useful to you:
"

But doesn't really say anything about extensions. Is the same python-config 
used therefore for extensions as well?

--

___
Python tracker 

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

[issue43886] Extending/embedding Python documentation outdated/incomplete

[Federico Pellegrin]

New submission from Federico Pellegrin :

Hello,
We had lately some issues with various possible variants of compilation (static 
vs dynamic) with reference to both embedding and extending Python. There are a 
bunch of tickets on the topic (ie. #21536 or #34309) but I guess one important 
point is that the documentation seems to be not very clear on this. Also 
various Linux distros seem to take very different approaches (static/dynamic).

Infact from the current documentation it seems unclear if python-config should 
be used for both or not. We found also some references to a newer --embed flag 
(see ie. #36721) which is not mentioned in the documentation.
Some other sources suggest that python-config should not be used when Python is 
build with Py_ENABLE_SHARED=1. (ref. here: 
https://github.com/conda/conda-build/issues/2738#issuecomment-371148021)

Also the example looks probably outdated, as it mentions Python 3.4

It would be nice if some light would be shed on the correct practice to use and 
the official documentation updated.

Thanks,
Federico

--
assignee: docs@python
components: Documentation
messages: 391370
nosy: docs@python, fede.evol
priority: normal
severity: normal
status: open
title: Extending/embedding Python documentation outdated/incomplete
type: behavior
versions: Python 3.9

___
Python tracker 

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