John Paul Adrian Glaubitz added the comment:
s390 is a 31-bit platform, not a 32-bit platform.
I also don't see what this change achieves other than making the use of Python
3.10 on s390 harder.
It's not like the removal of support for non-threaded builds which actually
saved quite some
John Paul Adrian Glaubitz added the comment:
> I opened this ticket after a user told me that they grepped the source code
> of Python, found the string "s390", and concluded that s390 is still
> supported by us.
Because one user was surprised by a few lines in configure
John Paul Adrian Glaubitz added the comment:
That's an argument I have personally never heard before and I have been dealing
with a lot of architecture support in many packages.
FWIW, lots of upstream projects have targets which are officially supported and
others which
John Paul Adrian Glaubitz added the comment:
And, FWIW, I generally don't quite understand what the problem with old triplet
definitions in configure.ac are. I assume they don't hurt anyone, do they?
You never know what usecases your users have and as long as a code snippet
doesn't
John Paul Adrian Glaubitz added the comment:
I'm a Debian Developer and maintainer for multiple Debian Ports architectures.
Please don't remove support for Alpha, HPPA, m68k, ia64, PowerPC, SuperH, SPARC
as we're still maintaining these in Debian.
Here are the latest build results
paul j3 added the comment:
It's not clear what your patch does that the existing 'store_const' doesn't.
Even 'append_const' does the same except for a extra level of list/tuple
nesting.
But I'll admit that I didn't much need for 'extend' addition, but others,
including the original
Paul Sokolovsky added the comment:
Thanks.
I would like to put this ticket in the context of other grammar-related
tickets/elaboration for the assignment operator:
https://bugs.python.org/issue42316 - allow foo[a:=1] instead of foo[(a:=1)]
https://bugs.python.org/issue42374 - allow (c := i
Change by Paul Sokolovsky :
--
nosy: +lys.nikolaou
___
Python tracker
<https://bugs.python.org/issue43143>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Paul Bryan :
--
nosy: +pbryan
___
Python tracker
<https://bugs.python.org/issue42269>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Paul Sokolovsky :
Currently (CPython 3.10.0a4) having a tuple on left-hand side of assignment
expression/operator (aka walrus operator) is not allowed:
>>> ((a, b) := (1, 2))
File "", line 1
((a, b) := (1, 2))
^
SyntaxError: cannot use ass
Paul Ganssle added the comment:
Re-opening because this was merged without tests.
@ZackerySpytz would you mind adding tests to hit these error cases? I've spent
some time satisfying myself that it's indeed possible, and I've detailed a
general outline here:
https://github.com/python
Paul Swirhun added the comment:
A workaround is using memoryview (as reported here:
https://stackoverflow.com/questions/53492716/python-writing-to-memory-in-a-single-operation).
This results in only 1 transaction on the bus for some reason.
import os, mmap
fd = os.open("/dev/mem",
New submission from Paul Swirhun :
mmap (example, as used in python-periphery) duplicates writes, compared to
devmem and a c-periphery on an ARM64 platform (Zynq/Petalinux/Yocto). There are
various other reports of duplicated writes using mmap suggesting it is a bug.
Example:
fd = os.open
Paul Moore added the comment:
That's specifically the ensurepip PR, which is now outdated since pip 21.0.1 is
in master. But for this bug report, Steve said "I still consider the changes a
release blocking regression, but if it's not blocking ensurepip then I guess
the updated package
Paul Moore added the comment:
It can be closed.
--
___
Python tracker
<https://bugs.python.org/issue41490>
___
___
Python-bugs-list mailing list
Unsubscribe:
Paul Moore added the comment:
I'm not sure why, but the PR to update the bundled pip to 21.0.1 (and
setuptools to 52.0.0) merged cleanly, so this may be obsolete now.
--
___
Python tracker
<https://bugs.python.org/issue41
Change by Paul Moore :
--
pull_requests: +23203
pull_request: https://github.com/python/cpython/pull/24388
___
Python tracker
<https://bugs.python.org/issue43
Change by Paul Moore :
--
keywords: +patch
pull_requests: +23202
pull_request: https://github.com/python/cpython/pull/24387
___
Python tracker
<https://bugs.python.org/issue43
Paul Moore added the comment:
New changeset 4d11ecbb5ed78e6259ee27289c7638aad795f473 by Paul Moore in branch
'master':
bpo-43077: Update bundled pip to 21.0.1 and setuptools to 52.0.0 (GH-24386)
https://github.com/python/cpython/commit/4d11ecbb5ed78e6259ee27289c7638aad795f473
Change by Paul Moore :
--
assignee: -> paul.moore
nosy: +Marcus.Smith, dstufft, ncoghlan, pradyunsg
stage: -> patch review
___
Python tracker
<https://bugs.python.org/i
New submission from Paul Moore :
I've just released pip 21.0.1, so this updates the bundled copy (as well as
updating setuptools).
I assume this should be backported to 3.8 and 3.9.
--
components: Library (Lib)
messages: 385986
nosy: paul.moore
priority: normal
pull_requests: 23201
paul j3 added the comment:
Sometimes patches have unforeseen benefits. My earlier patch for this issue,
parse_intermixed_args, has been useful beyond the OP's case.
https://stackoverflow.com/questions/50916124/allow-positional-command-line-arguments-with-nargs-to-be-seperated-by-a-flag
paul j3 added the comment:
So in the big picture, the purpose of this change is to treat the inputs like a
kind of state-machine.
In the bigger example, the `**` positional values are processed one by one,
using the interspersed optionals to set state parameters.
`args.sources` then ends
paul j3 added the comment:
I haven't had a chance to study your longer posts, but it seems to me that the
AddFruitAction example could just as well be implemented with
parser.add_argument('--color', nargs='*', action='append')
with post parsing processing to create the 'fruits' dicts
Paul Moore added the comment:
> PathAllocCombine() is Windows 8+, so sample code that uses it would only be
> for Python 3.9+.
Yeah, I'm probably going to remove that. I mainly used it because I'm *so*
spoiled by Python, writing code in C where I have to actually implement stuff
for
Paul Moore added the comment:
> I think here you're in a very small minority who could get away with this,
> and so I'd hesitate to make it sound like the recommended approach.
Well, the evidence here is that maybe even I shouldn't be doing this :-)
> What I'd actually recommend (o
Change by Paul Bryan :
--
nosy: +pbryan
___
Python tracker
<https://bugs.python.org/issue33129>
___
___
Python-bugs-list mailing list
Unsubscribe:
Paul Moore added the comment:
Confirmed. The following code works as I want:
Py_Main_t get_pymain(wchar_t *base_dir) {
wchar_t *dll_path;
HRESULT hr = PathAllocCombine(
base_dir, L"python\\python3.dll",
PATHCCH_ALLOW_LONG_PATHS, _path
);
if (
Paul Moore added the comment:
Thanks, I'll give that a try. It sounds like I'm just using the APIs
incorrectly, which would be good (in the sense that I can do what I wanted, I
just didn't know how ;-))
I wonder whether it would be worth having a section in the docs somewhere
explaining
Paul Moore added the comment:
Thinking about what you said, "the loader waits to load it until first accessed
via GetProcAddress()" did you mean by that, that the following code should work:
h = LoadLibraryW(L"some/path/to/python3.dll")
py_main = GetPro
Paul Moore added the comment:
So I need to dynamically load *both* python3.dll and python39.dll, but if I do
that I can get the functions from python3.dll? What's the point in doing that?
Surely I might as well just load python39.dll and get the functions from there,
in that case.
I hoped
New submission from Paul Moore :
I am writing a small application using the embedded distribution to run a
script supplied by the user. The requirements are very simple, so all I need to
do is set up argv and call Py_Main.
I'm trying to load the Py_Main function dynamically (for flexibility
paul j3 added the comment:
Years ago I proposed a `format_wrapper`, a Format class factory
https://bugs.python.org/issue12806#msg218395
also
https://bugs.python.org/issue39809
There I show that the formatter may be lambda
formatter = lambda prog: argparse.HelpFormatter(prog, width=100
paul j3 added the comment:
This issue is discussed in:
https://bugs.python.org/issue34724
argparse subparser help indent too short
and
https://stackoverflow.com/questions/3215/max-help-position-is-not-works-in-python-argparse-library
paul j3 added the comment:
I was thinking of a refactoring that included the ', '.join(...) loop, but on
further thought your refactoring might be enough for the case I raised.
For example:
def _format_option_with_args(self, option_string, args_string):
if option_string.startswith
paul j3 added the comment:
The refactoring looks reasonable.
But while we are tweaking:
def _format_action_invocation(self, action):
I wonder if we also give users more control over how multiple option strings
are formatted. Currently if
parser.add_argument('-f', '--foo', help
paul j3 added the comment:
Your patch is incomplete, without documentation or tests.
Your example is incomplete. That is _CustomAction? What namespace does your
patch produce.
It's been a while since I worked on the intermixed patch, but as I recall the
OP was happy with the fix. Also I
Paul Ganssle added the comment:
This particular grep statement is used to validate the `tzpath` variable.
Apparently it is easy enough to achieve what I was going for using vanilla grep
with no options, so I've created GH-24200 to fix the issue.
I notice that there are other uses of `-q
Change by Paul Ganssle :
--
keywords: +patch
pull_requests: +23025
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/24200
___
Python tracker
<https://bugs.python.org/issu
Paul Moore added the comment:
I thought that *all* versions of Python located the standard library by
searching for os.py...
--
___
Python tracker
<https://bugs.python.org/issue42
Change by Paul Bryan :
--
nosy: +larry
___
Python tracker
<https://bugs.python.org/issue42904>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Paul Bryan :
According to PEP 563:
> The get_type_hints() function automatically resolves the correct value of
> globalns for functions and classes. It also automatically provides the
> correct localns for classes.
This statement about providing correc
Paul Moore added the comment:
Many tools hard code the "if windows then 'Scripts' else 'bin'" logic. They
will simply fail to work with environments that don't have that layout. Yes,
they probably should use sysconfig, but many don't (and sometimes for arguably
good reasons, f
paul j3 added the comment:
Since this issue is closed it might be a good idea to open a new one with this
problem. And if possible identify the failed tests.
We forgot to allow for the fact that working code/tests might be checking for
specific help messages, checks the will fail when
Paul Moore added the comment:
So I guess the key question then is whether Path.exists() should trap
exceptions and interpret them as "does not exist" (on all platforms, although
it looks like the null character case in Unix has now been fixed). Which
doesn't seem unreasonabl
Paul Moore added the comment:
"http:" isn't a valid drive letter, I'd imagine.
--
___
Python tracker
<https://bugs.python.org/issue42855>
___
___
Paul Moore added the comment:
It's an invalid filename so it raises an exception.
You can get the same on Unix by using an invalid filename (embedded null):
>>> from pathlib import Path
>>> Path("/usr/\0").exists()
Traceback (most recent call last):
File "
Paul "TBBle" Hampson added the comment:
I just bounced off this issue and proposed a work-around for it in Black
(https://github.com/psf/black/pull/1897).
Since it wasn't mentioned here earlier, the `\` marker _is_ documented in the
GNU Diffutils documentation, under "I
New submission from Paul Watson :
Fresh install of 3.9.1
Created venv
Activated venv
(py3.9) 13:12:59.52 C:\venv\py3.9\Scripts
C:>pip search astronomy
ERROR: Exception:
Traceback (most recent call last):
File "c:\venv\py3.9\lib\site-packages\pip\_internal\cli\base_command.py&quo
Paul Sokolovsky added the comment:
> the idea was proposed purely to "close a gap"
That pinpoints it well. I was just writing a tutorial on implementing custom
import hooks, with the idea to show people how easy it to do it in Python. As
first step, I explained that it's bad i
Paul Sokolovsky added the comment:
> There is a considerable tension on exposed parts of the compiler pipeline for
> introspection and other capabilities and our ability to do optimizations.
> Given how painful it has been in the past to deal with this, my view is to
> av
Paul Sokolovsky added the comment:
> but the thing I don't quite get is the use case.
And if that went unanswered: the usecase, how I'd formulate it, is to not
expose CPython historical implementation detail of "tokenize" being
disconnected from the rest of the langua
Paul Sokolovsky added the comment:
> What prevents you from using ast.parse(tokenize.untokenize(token_stream))?
That's exactly the implementation in the patch now submitted against this
issue. But that's the patch for CPython, the motive of the proposal here is to
establish a standard
Change by Paul Sokolovsky :
--
keywords: +patch
pull_requests: +22773
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/23922
___
Python tracker
<https://bugs.python.org/issu
New submission from Paul Sokolovsky :
Currently, it's possible:
* To get from stream-of-characters program representation to AST representation
(AST.parse()).
* To get from AST to code object (compile()).
* To get from a code object to first-class function to the execute the program.
Python
Paul Ganssle added the comment:
For future reference, this bug is triggered only when `.fromutc` is called on a
subclass of `datetime` and the resulting date is the second ambiguous time
(e.g. if there's a DST transition from 02:00 → 01:00, and the result of the
`.fromutc` call
paul j3 added the comment:
I'd have to study the code (and docs), but I'm not sure setting the `dest` to
'SUPPRESS' does anything meaningful.
default=argparse.SUPPRESS
is useful, keeping the default out of the namespace. That argument appears
only if the user has used the option
paul j3 added the comment:
I'm closing the is as a duplicate of https://bugs.python.org/issue23487, which
is already closed.
--
resolution: -> duplicate
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bug
Change by Paul Moore :
--
nosy: +njs
___
Python tracker
<https://bugs.python.org/issue42683>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
New submission from Paul Moore :
See the comment on Discourse here:
https://discuss.python.org/t/feeding-data-generated-via-asyncio-into-a-synchronous-main-loop/5436/28
(and the thread leading up to this comment).
In the thread, @njs states that if the user hits Ctrl-C while the asyncio
paul j3 added the comment:
https://docs.python.org/3/library/argparse.html#customizing-file-parsing
in the docs describes how to customize the @file reading. This particular
extension handles several strings on a line, but that's not the limit of what
you could do.
You can also read
New submission from Paul Ganssle :
TZif files consist of a list of transitions followed by a POSIX TZ var-style
string of a form like "AAA3BBB,M3.2.0/01:30,M11.1.0/02:15:45", which decodes to
"AAA (UTC-3) is the standard time and BBB (UTC-2) is the DST time, DST applies
start
Paul Bryan added the comment:
Retracting.
--
resolution: -> not a bug
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Paul Bryan :
--
keywords: +patch
pull_requests: +22668
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/23808
___
Python tracker
<https://bugs.python.org/issu
New submission from Paul Bryan :
Currently the data model documentation does not specify the order of keys in
__annotations__ dictionary. It is currently in the order that arguments or
attributes are declared. I propose to make this explicit.
Rationale: Having order explicitly specified
Paul Ganssle added the comment:
> Adding a static assertion about the signedness of uint8_t looks meaningless
> to me.
My proposal is to add a static assertion that `day` is an unsigned type. In the
code it would look something like it does in the backports.zoneinfo code
Paul Ganssle added the comment:
There are at least two issues with this:
1. This is a constructor for a struct, and the struct would really
unnecessarily balloon in size if we switched everything over to be 32-bit
integers (which I think is your suggestion?). This is not a major concern
Paul Ganssle added the comment:
> Just my two cents, this isn't just "some compilers". Everything from gcc,
> msvc, C# to the rust compiler complain about this sort of code. As they
> should, this is effectively dead code.
They complain because most of the time it's a si
Paul Ganssle added the comment:
As I mentioned, it's a style issue. Yes this did not introduce any
user-observable bugs, nor should it have changed the machine code emitted by
the assembly on any competent compiler.
The issue is that I had deliberately chosen to do a "redundant&q
New submission from Paul Ganssle :
This is a code style issue — in https://github.com/python/cpython/pull/23614, a
regression was deliberately introduced to satisfy an overzealous compiler. The
`day` variable has logical bounds `0 <= day <= 6`. In the original code, both
paul j3 added the comment:
An existing parser can be included in a new subparser via the 'parents'
mechanism. With that the _actions and groups of the parent are copied (by
reference) to the new subparser.
There are some rough edges to the parents mechanism, but people have used it to
add
paul j3 added the comment:
In the subparser example, it's the `build` subparser that puts '--overwritte'
in the unrecognized list. That is then passed back to the main parser, which
then issues the 'unrecognized' error, along with its own usage.
The subparser is called
paul j3 added the comment:
One caution - the type parameter is a callable (function) that takes one string
as argument. I proposed `pathlib.Path` because it does that, returning a Path
object. It's a class instance creator. I believe the module has other class
initiators.
bool() has
paul j3 added the comment:
The pathlib.Path is new since I paid much attention to os matters (I cut my
teeth on py2.5).
Off hand it looks like the user could
import pathlib
parser.add_argument('-p', type=pathlib.Path)
to convert a string into a Path object.
A custom type function
paul j3 added the comment:
What exactly do you do with a path argument?
Admittedly I'm not expert with os and os.path modules, but isn't a path just a
string passed to a function such as cwd(), or joined to another create a
filename.
I don't know what a 'path' type or action would do
Paul Bryan added the comment:
Your patch LGTM, Brandt.
--
___
Python tracker
<https://bugs.python.org/issue42592>
___
___
Python-bugs-list mailing list
Unsub
New submission from Paul Bryan :
I believe "a" below should be an optional key, not a required one.
Python 3.9.0 (default, Oct 7 2020, 23:09:01)
[GCC 10.2.0] on linux
Type "help", "copyright", "credits" or "license" for more informatio
Paul Sokolovsky added the comment:
Raymond Hettinger: Thanks for acking it would be a useful change!
ZackerySpytz: Thanks for making a patch!
--
___
Python tracker
<https://bugs.python.org/issue42
New submission from Paul Sokolovsky :
Current docs for random.getrandbits() (
https://docs.python.org/3/library/random.html#random.getrandbits ) read
(3.9.1rc1 at the top of the page):
Returns a Python integer with k random bits. This method is supplied with the
MersenneTwister generator
paul j3 added the comment:
I'll reopen it - your patch, while not a complete resolution, does take care of
the immediate error.
--
resolution: duplicate ->
status: closed -> open
___
Python tracker
<https://bugs.python.org/i
paul j3 added the comment:
Duplicate of
https://bugs.python.org/issue14074
argparse allows nargs>1 for positional arguments but doesn't allow metavar to
be a tuple
--
resolution: -> duplicate
stage: patch review -> resolved
status: open
Paul Moore added the comment:
You need to learn about chained comparisons in Python. This is not a bug.
Please stop reopening it.
--
status: open -> closed
___
Python tracker
<https://bugs.python.org/issu
paul j3 added the comment:
choices is fine for a few strings, but quickly becomes awkward with other types
and large numbers. The testing isn't an issue, since it just does a simple
`in/contains` test. But display, whether in usage, help or error, is
problematic if you try anything too
Paul Ganssle added the comment:
New changeset 79d2e62c008446fbbc6f264bb8a30e2d38b6ff58 by Yaroslav Pankovych in
branch 'master':
Added support for negative indexes to PurePath.parents (GH-21799)
https://github.com/python/cpython/commit/79d2e62c008446fbbc6f264bb8a30e2d38b6ff58
Paul Ganssle added the comment:
New changeset 79d2e62c008446fbbc6f264bb8a30e2d38b6ff58 by Yaroslav Pankovych in
branch 'master':
Added support for negative indexes to PurePath.parents (GH-21799)
https://github.com/python/cpython/commit/79d2e62c008446fbbc6f264bb8a30e2d38b6ff58
New submission from Paul Ganssle :
Currently, it seems that the pathlib module uses `.. data::` to annotate the
properties of the PurePath type (e.g. .parts, .drive, .root, etc). See:
https://github.com/python/cpython/blob/ff420f0e08a2443339da0df7ace95e14177bac53/Doc/library/pathlib.rst
Paul Ganssle added the comment:
I think you may have confused my thoughts as to why this might be considered
ambiguous with an actual suggestion for what the semantics should be.
I think that we should stick with `p.parents[x] == tuple(p.parents)[x]` for any
valid value of `x`, which means
Change by Paul Ganssle :
--
dependencies: -pathlib.PurePath.parents rejects negative indexes
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Paul Ganssle added the comment:
New changeset 452058448335b39c784af9a047f9c4a1767c0b00 by Joshua Cannon in
branch 'master':
bpo-35498: Added slice support to PathLib parents attribute. (GH-11165)
https://github.com/python/cpython/commit/452058448335b39c784af9a047f9c4a1767c0b00
Paul Ganssle added the comment:
One question I would have about this is that `.parents` is a lazily-calculated
sequence, not a list or a tuple, so it's not immediately obvious what the
return type of a slice would be. I don't think it makes sense to return, e.g. a
`_PathParents` object
Paul Ganssle added the comment:
I am not seeing any compelling reasons to avoid supporting negative indexes
*or* slices here.
If I had to guess about the confusing semantics of negative indices, I would
guess it's the fact that the index in the -1 position for a non-empty Path will
always
Paul Ganssle added the comment:
What is an example of another Python implementation that has this property? Is
there a concrete issue open somewhere that this is solving?
I am not unsympathetic to the idea of accommodating other implementations of
Python, but this is very abstract and I
Paul Ganssle added the comment:
This is probably more feasible than the proposal in bpo-41254 since it's a
well-defined spec (mostly — it includes an optional alternative format and the
number of digits allowed is defined "by agreement", thus defeating the purpose
of us
Change by Paul Ganssle :
--
nosy: +p-ganssle
___
Python tracker
<https://bugs.python.org/issue42094>
___
___
Python-bugs-list mailing list
Unsubscribe:
Paul Ganssle added the comment:
Is this an actual problem for another implementation of Python?
Is there some reason to think that we intended the repr of a `datetime` object
to be implementation-defined?
--
nosy: +p-ganssle
___
Python tracker
Paul Ganssle added the comment:
This is the expected behavior of `.fromisoformat()`. A similar issue is
https://bugs.python.org/issue35829, which asks for the "Z" suffix to be
supported.
There is a note about this in the documentation:
https://docs.python.org/3/library/dat
Paul Moore added the comment:
I've raised https://github.com/pypa/pip/issues/9135 for this.
--
___
Python tracker
<https://bugs.python.org/issue42293>
___
___
Paul Moore added the comment:
Erik is correct, this is a pip bug. Please raise an issue on the pip tracker
linking to this issue and we can fix it.
--
___
Python tracker
<https://bugs.python.org/issue42
paul j3 added the comment:
We could look into using a different more compact 'prog' for these error
messages.
Currently the subparser 'prog' uses the main prog plus positionals plus the
subparser name. The goal is to construct a subparser usage that reflects
required input
paul j3 added the comment:
It's the subparser that's producing this error, specifically its 'prog'
attribute.
If I use a custom usage with a simple parser:
1129:~/mypy$ python3 issue42297.py --foo=on
usage: issue42297.py
one
two
three
issue42297.py: error: argument
201 - 300 of 3183 matches
Mail list logo
