David Edelsohn added the comment:
Victor: https://en.wikipedia.org/wiki/31-bit_computing :-)
--
___
Python tracker
<https://bugs.python.org/issue43179>
___
___
David Edelsohn added the comment:
I am not aware of significant use of 31 bit mode.
But I don't see the benefit of annoying and discouraging users who want to
experiment with Python and with Linux on Z in 31 bit mode. Yes, maintenance
theoretically is a burden, but there have been
David Edelsohn added the comment:
gcc -dM -E - < /dev/null
--
Added file: https://bugs.python.org/file49818/gcc-s390x.txt
___
Python tracker
<https://bugs.python.org/issu
David Edelsohn added the comment:
gcc -m31 -dM -E - < /dev/null
--
Added file: https://bugs.python.org/file49817/gcc-s390.txt
___
Python tracker
<https://bugs.python.org/issu
David Edelsohn added the comment:
I understand the issue is s390, not s390x. I am offering that there already is
an s390x worker, so would it be sufficient to build and test Python in 31 bit
mode on that worker as opposed to installing a complete s390 Debian system
David Edelsohn added the comment:
I already am running a Debian s390x buildbot for Python. Someone can adjust
the rules for the buildbot to include a 31-bit builder. The Debian buildbot
has relatively few builder variants relative to the other s390x targets
David Edelsohn added the comment:
This has nothing to do with AIX.
This conversation should include Charalampos Stratakis, but I don't see him as
an option for Nosy.
It probably is easy to add a s390 31-bit build to one of the buildbots.
--
nosy: -aixto...@gmail.com
R. David Murray added the comment:
The return value is correct. Interpreted as an email address, 'randomstring'
is a local mailbox.
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracke
R. David Murray added the comment:
This has nothing to do with python other than the fact that you are using it to
capture stdout. You have to figure out how to get the output you want to be
what shows up on stdout, python has no knowledge of what commands you put in
your shell script
Change by David Murphy :
--
pull_requests: +23080
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/24226
___
Python tracker
<https://bugs.python.org/issu
Change by David CARLIER :
--
components: FreeBSD
nosy: devnexen, koobs
priority: normal
pull_requests: 23073
severity: normal
status: open
title: resources module, FreeBSD update adding RLIMIT_KQUEUES constant
versions: Python 3.10
___
Python
Change by David Bordeynik :
--
keywords: +patch
nosy: +DavidBord
nosy_count: 2.0 -> 3.0
pull_requests: +23051
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/24228
___
Python tracker
<https://bugs.python.org/i
David Lukeš added the comment:
Any updates on this? Making Executor.map lazier would indeed be more consistent
and very useful, it would be a shame if the PR went to waste :) It's a feature
I keep wishing for in comparison with the older and process-only
multiprocessing API. And eventually
David Murphy added the comment:
Forgive any process/workflow errors first time, submitting to Python
--
___
Python tracker
<https://bugs.python.org/issue42
New submission from David Murphy :
>From porting Python 3.7.8 to Solaris 11.4 (base open version) found that the
>handling of crle output has changed between Solaris 11.3 and 11.4 and
>accommodation has not been made for the change.
For example:
Solaris 11.3
root@sol11:~/sol_build/p
David Justo added the comment:
Hi folks! I'm interested in contributing to this issue, but I'm unsure about
the context.
Can `>>>>` prompts be toggled on-and-off in the docs? I do not see that option.
I read that this is possible in javascript-enabled versions of the site
David Justo added the comment:
Hi folks,
I'd be interested in contributing to this issue, since it seems "easy" enough,
but I'm unsure that consensus was reached about the right solution.
>From what I gathered from Giampaolo's comments, we have solutions that should
>work fo
David Steele added the comment:
For those looking for a solution now, see
https://pypi.org/project/argparse-formatter/
--
___
Python tracker
<https://bugs.python.org/issue12
Change by David Beazley :
--
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue7946>
___
___
Python-bugs-list
Change by David Beazley :
--
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue16894>
___
___
Python-bugs-list
Change by David Beazley :
--
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue24844>
___
___
Python-bugs-list
Change by David Beazley :
--
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue32810>
___
___
Pyth
Change by David Beazley :
--
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue27436>
___
___
Python-bugs-list
Change by David Beazley :
--
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue16132>
___
___
Python-bugs-list
New submission from David :
pathlib.WindowsPath[0] does not implement is_mount but ntpath implements and
offers a ismount[1] method. Perhaps WindowsPath is_mount can make use of
ntpath.ismount ?
[0] https://github.com/python/cpython/blob/master/Lib/pathlib.py#L1578
[1] https://github.com
R. David Murray added the comment:
After thinking about it some more, I think given that when there is no
non-ascii mbox will happily treat *anything* as valid on the "From " line, that
we should consider blowing up on non-ascii t
R. David Murray added the comment:
Yep, you've found another in a category of bugs that have shown up in the
parser: places where there is a missing check for there being any value at all
before checking character [0].
In this case, the fix should be to add
if not obs_local_part
David Bolen added the comment:
I was wondering if there was any update on whether or not this new behavior can
be corrected?
I was attempting to review a buildbot failure today and it's actually pretty
tough to "race the refresh" when trying to review the build step
David Bolen added the comment:
This change to the 3.8 branch appears to be consistently failing on the Windows
7 buildbot (first failing build at
https://buildbot.python.org/all/#/builders/270/builds/126).
It's all failures in the new test_configure_custom_copy and
test_map_custom_copy
R. David Murray added the comment:
The problem with that archive is that it is not in proper mbox format. It
contains the following line (5689):
From here I was hoping to run something like “dbus-send –system
–dest=Test.Me –print-reply /Japan Japan.Reset.Test string:”Hello””
You
New submission from David Salač :
The logic as it is implemented now does not allow to user to override floatstr
function. That makes things enormously inconvenient for people who need any
different of behaviour (for example return string values defining Infinity, NaN
or -Infinity
New submission from David Hewitt :
I'm unsure if this is a packaging error or a misunderstanding by me.
I'm trying to link a binary on windows with Py_LIMITED_API set. According to
https://www.python.org/dev/peps/pep-0384/#linkage I _think_ I'm supposed to be
linking against python3.lib
David Edelsohn added the comment:
I believe that Michael was trying to probe under what circumstances the failure
appears. But, not GCC 4.7 is not relevant.
--
___
Python tracker
<https://bugs.python.org/issue42
Change by David CARLIER :
--
components: Extension Modules
nosy: devnexen
priority: normal
pull_requests: 22211
severity: normal
status: open
title: subprocess DragonFlyBSD build update
type: enhancement
versions: Python 3.10
___
Python tracker
David Edelsohn added the comment:
I investigated another problem with nextafter() in 2015 and opened an internal
IBM AIX PMR. At the time it was not using decimal float code.
The earlier problem was the handling of -0.0. At the time, the code was
hand-written assembly language that did
David Edelsohn added the comment:
I think that it is reasonable to drop support for AIX 5.3.
--
___
Python tracker
<https://bugs.python.org/issue42087>
___
___
David Lord added the comment:
I'm using Arch Linux. After your reply I tried again and now I'm seeing the
same result as you, negligible difference from inheriting `Generic` on Python
3.9. I can't explain it, I ran the timings repeatedly before I posted here, but
I guess it was a weird
David Lord added the comment:
Is this performance issue supposed to be fixed in 3.9? I'm still observing
severe slowdown by inheriting from `Generic[T]`.
I'm currently adding typing to Werkzeug, where we define many custom data
structures such as `MultiDict`. It would be ideal
David Edelsohn added the comment:
nextafter is a known problem on AIX. I believe that it is being addressed in
newer releases of AIX.
Michael and I are helping the IBM AIX Open Source team to increase their
attention on Python, but things only move so fast
Change by David Martinez :
Added file: https://bugs.python.org/file49575/Cellular-Z 20200909 14:25:47
SLOT1.CSV
___
Python tracker
<https://bugs.python.org/issue42
New submission from David Mandelberg :
The traceback in the output of the attached test (see below) doesn't include
line 5, which is where the original exception is raised. I think this is
because
https://github.com/python/cpython/blob/b9ee4af4c643a323779fd7076e80b29d611f2709/Lib/unittest
Change by David CARLIER :
--
components: macOS
nosy: devnexen, ned.deily, ronaldoussoren
priority: normal
pull_requests: 21996
severity: normal
status: open
title: mmap module add Darwin specific madvise options
type: enhancement
___
Python tracker
David Antonini added the comment:
Somehow I missed the follow up here until now. I don't remember the original
code, but I'm fairly confident that mocked_print is the patched print function
eg
with patch('dionysus_app.class_functions.print') as mocked_print:
Probably solved in this commit
David Edelsohn added the comment:
If Python has been defaulting to dlopen() on AIX systems that support it, there
is no reason to maintain the historical, AIX-specific load() support in
dynload_aix.c
I believe that dlopen() was introduced on AIX in release 4.3. The official end
of support
Change by David CARLIER :
--
keywords: +patch
pull_requests: +21681
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/22714
___
Python tracker
<https://bugs.python.org/issu
Change by David CARLIER :
--
components: Extension Modules
nosy: devnexen
priority: normal
severity: normal
status: open
title: DragonFlyBSD thread native id support missing
type: enhancement
versions: Python 3.10
___
Python tracker
<ht
David Grellscheid added the comment:
OK, having read
https://blog.ganssle.io/articles/2018/02/aware-datetime-arithmetic.html, this
bizarreness is actually intended behaviour. It goes completely against my
intuitive understanding of how this should come out. No additions are involved,
just
David Grellscheid added the comment:
Here's a third example, without fold= involved. The spring transition also does
not work when the timezone in the difference is equal:
01:59:00 to 03:01:00 should be 2 minutes
All these should be 0:02:00 apart
1:02:00 Oslo_1 - Oslo_0
0:02:00 Berlin_1
David Grellscheid added the comment:
To make it clear that this issue is not covered by ...
"Two such instances that differ only by the value of the fold attribute will
not be distinguishable by any means other than an explicit access to the fold
value." (PEP 495)
I hav
New submission from David Grellscheid :
I'm comparing two aware timestamps during a clock transition that differ only
in their fold= value.
When taking the difference of two aware timestamps with the *same* tzinfo, the
fold parameter is ignored.
A difference between two timestamps
David Beazley added the comment:
About nine years ago, I stood in front of a room of Python developers,
including many core developers, and gave a talk about the problem described in
this issue. It included some live demos and discussion of a possible fix.
https://www.youtube.com/watch?v
David Williams added the comment:
Thanks also for your input and feedback, Ammar.
--
___
Python tracker
<https://bugs.python.org/issue41743>
___
___
Python-bug
David Williams added the comment:
Thanks Victor, I will submit a change request for both of the documents you
specified.
https://www.python.org/dev/peps/pep-3136/
https://github.com/python/devguide/issues/605
Steven, it sounds like we agree to the change proposal, which is to remove
New submission from David Williams :
The Python documentation contains unnecessarily verbose and gendered language
which does not enhance clarity, and rather, serves as non-inclusive to the
LGTBQ community
For example:
https://www.python.org/dev/peps/pep-3136/
"Introduction
The
David Steele added the comment:
I've submitted FlexiHelpFormatter as PR22129.
This adds the FlexiHelpFormatter class to argparse.
It supports wrapping text, while preserving paragraphs. Bullet lists are
supported.
There are a number of differences, relative to the latest patch in the issue
Change by David Steele :
--
keywords: +patch
pull_requests: +21210
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/22129
___
Python tracker
<https://bugs.python.org/issu
Change by David Edelsohn :
--
nosy: +David.Edelsohn
___
Python tracker
<https://bugs.python.org/issue41401>
___
___
Python-bugs-list mailing list
Unsubscribe:
David Edelsohn added the comment:
It's the same system. It doesn't fail alone. Didn't we both previously see
issues with the interaction of tests due to the other of tests, that previous
tests left things in the environment that affected later tests
David Edelsohn added the comment:
Bisection failed after 101 iterations and 0:20:29
--
___
Python tracker
<https://bugs.python.org/issue41717>
___
___
Python-bug
David Crespo added the comment:
Thanks for your answers. I tried to search if the bug was already reported
using some text searches but I couldn't find it so I opened a new one. Next
time I'll try what you recommend.
Regards and thanks for keeping Python in good shape
David Edelsohn added the comment:
I have updated
edelsohn-aix-ppc64
edelsohn-debian-z
edelsohn-fedora-ppc64
edelsohn-fedora-rawhide-z
edelsohn-fedora-z
edelsohn-rhel-z
edelsohn-rhel8-z
edelsohn-sles-z
aixtools-aix-power6
--
___
Python tracker
New submission from David Crespo :
Idle won't save a file if it didn't include a newline when it was opened (ex:
opening empty file)
Steps for reproducing the error:
1) get into some folder in Windows File Explorer
2) right-click on empty space for context menu
3) click new -> create t
David Bolen added the comment:
I'm guessing the warning appears odd as we're seeing a thread shutdown data
race. The message is produced by threading_cleanup in
support/threading_helper.py, and it appears that between the first and second
lines one of the initially dangling threads goes
David Bolen added the comment:
I've been seeing failures on the Win10 buildbot 3.x branch that seem to
correlate with the timing of this change - could there be some further work
needed on Windows? Or, if it's a test-only artifact and the warnings are
innocuous, something to ignore
David Edelsohn added the comment:
I can provide some information from the logs of one of the buildbots, or change
a parameter. Let me know.
--
___
Python tracker
<https://bugs.python.org/issue41
David Edelsohn added the comment:
I have found a large number of un-removed files in /tmp. Things seem to
function better with Buildbots running older 0.x "buildslave" as opposed to
newer "builtbot-worker" instances.
--
nosy: +David.Edelsohn
title: Buildbot: wo
David Edelsohn added the comment:
If they want to discuss here, fine, but the failing bot is a symptom not the
problem. The Buidlbot infrastructure is unstable, causing disconnects and
leaving un-removed files. If one looks at the workers, one can see many of the
architectures
David Edelsohn added the comment:
It really would be better to discuss this in the builtbot mailing list and not
Python issue tracker.
I have been seeing problems with many buildbots for the past few weeks, not
just the s390x bots. I receive messages that all of the bots disconnected
David Edelsohn added the comment:
Yes, export file generation still is required.
Python does not need to utilize runtime linking. Using -G is a very bad choice
and severely discouraged with severe performance and other penalties.
--
___
Python
David Edelsohn added the comment:
> About PSALLOC=early , I confirm that it perfectly fixes the issue.
> I'm surprised, because it is unspeakably slow on this machine,
These statements are not contradictory. No one is suggesting that Python
always should run with PSALLOC
R. David Murray added the comment:
Yes for the registry changes. I thought we had fixed the bug that was causing
message-id to get encoded, but maybe it still exists in 3.7? I don't remember
when we fixed it (and I may be remembering wrong!)
As for X- "unstructured headers&quo
New submission from David Byrne :
Sub-classing and overriding json.JSONEncoder.default allows users to create
custom serialisation for objects that can’t otherwise be serialized. However,
this method is only called for dictionary values such that dictionary supported
keys (i.e. hashable types
David Edelsohn added the comment:
Yes, it doesn't appear that it will be solved in libffi. I don't fully
understand the need for the work-around because it should gracefully overflow
to the stack. I can't tell if the issue is a problem with arguments passed by
value that need to be passed
David Edelsohn added the comment:
AIX uses a "late" memory allocation scheme by default. If the test wants to
malloc(52631578947368422ULL) and intends it to fail, it should run with the AIX
$ export PSALLOC=early
environment variable. More than all of the other maxdata changes.
R. David Murray added the comment:
It's not really an abuse. It is, however, buggy. It should be being applied
*only* when the header contains unstructured text. Unfortunately I made the
choice to treat any header that doesn't have a specific parser as unstructured,
and that was a wrong
David Edelsohn added the comment:
AIX systems at OSUOSL have been part of the GNU Compile Farm for a decade. It
also is the system on which I have been running the Python Buildbot. Any
Compile Farm user has access to AIX.
https://cfarm.tetaneutral.net/users/new/
Also, IBM
David Edelsohn added the comment:
Core developers have full access to AIX system for the asking. Back to you,
Stefan.
--
___
Python tracker
<https://bugs.python.org/issue41
David Edelsohn added the comment:
+Eryksun,Vinay
The patch to address array passing described in issue #22273 introduced
regressions for other targets. The 16 byte struct size is specific to x86 ABI
and register passing convention. I appreciate that the 16-32 byte size
structure causes
David Halter added the comment:
I second this. I just see people complaining about this not working in a lot of
tools. This is really not necessary for a feature that should not be used
anyway and puts work onto the greater Python ecosystem for no good reason
Change by David Halter :
--
nosy: +davidhalter
___
Python tracker
<https://bugs.python.org/issue41506>
___
___
Python-bugs-list mailing list
Unsubscribe:
David Bolen added the comment:
It looks like there was an underlying asyncio.recv_into bug that was the likely
root issue here. It's recently been fixed in bpo-41467, and test_asyncio is
passing on at least the Win10 buildbot.
--
___
Python
David Bolen added the comment:
Just for the record, this fix also appears to have resolved the issue with the
Win10 buildbot from bpo-41273, which was related to the same unraisable
exceptions mentioned in bpo-38912.
--
nosy: +db3l
___
Python
David Edelsohn added the comment:
As mentioned in the stgdict.c comment, this relates back to #22273 and #29565.
The passing of arrays/structs is fragile, to use a euphemism. The ctypes
behavior conforms to the x64 Linux ABI and x64 libffi, even the comment from
#22273,
"St
David Edelsohn added the comment:
The example with memchr() never will be correct because it is invalid to call a
function with an argument list that doesn't match the function signature.
Your comment mentions that the AIX structure is size 16, but it looks like
Python calculates the AIX
David Edelsohn added the comment:
I thought that the ctypes documentation mentioned that Arrays passed by Value
are converted to Structures. I cannot find it in the ctypes documentation at
the moment. But Modules/_ctypes/stgdict.c has a large comment about passing
Arrays by Value
R. David Murray added the comment:
The fix looks good to me. Don't know how I made that mistake, and obviously I
didn't write a test for it...
--
___
Python tracker
<https://bugs.python.org/issue41
David Halter added the comment:
@gvanrossum
> Does parso have to be pure Python? If not, we could generate C code like we
> do for CPython's parser.
I would rather write the parser either in C or Rust. So no, parso does not need
to be pure Python.
> Now, that doesn't work for in
David MacIver added the comment:
I should say, I don't actually care about this bug at all: I only ran into it
because of trying to recreate the random API and testing that my recreation
worked sensibly. I thought I'd do the good citizen thing and report it, but I'm
totally fine with any
David MacIver added the comment:
I guess on actual inspection of the code (which I should have done before,
sorry) it's obvious why this happens: u ** (1.0 / alpha) will round to 0.0 for
small values of u, and the smaller alpha is the higher the probability of that
happening
New submission from David MacIver :
The following code raises a ZeroDivisionError:
from random import Random
Random(14064741636871487939).paretovariate(0.01)
This raises:
random.py, line 692, in paretovariate
return 1.0 / u ** (1.0/alpha)
ZeroDivisionError: float division by zero
David Edelsohn added the comment:
Tony, Please see my reply from 2020-02-05. This is a known "bug" in Python
ctypes. This is documented in Python ctypes. This will not be fixed. This
cannot be fixed.
Python ctypes converts the array to a structure and creates an incorr
David Halter added the comment:
Parso's incremental parser is a terrible idea. It also works and is pretty
fast, but the design is pretty terrible (it took me a lot of fuzzing to make
sure that it works decently well).
The basic problem is that it's reusing nodes in a mutable way. If I were
Change by R. David Murray :
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
David Bolen added the comment:
First, I also no longer see the error with a local PR 21446 build on the Win10
buildbot.
As for timing, I believe policy is to revert, but in my view it can probably
depend on how short "a bit" is for the fix. We've been in this state for 4-5
da
David Bolen added the comment:
I can at least confirm that this commit is the source of the issue on the
Windows 10 buildbot. Interactively, it fails every time with it in place
(unlike the buildbot which has had the occasional success) and passes reliably
with it reverted.
The error
David Friedman added the comment:
I know this is 6 years too late, but I had this problem a few minutes ago on
Python2.7. Googling didn't find me anything relevant except this bug entry.
However, I found the cause myself: I had a test file named argparse.py (and an
argparse.pyc
David K. Hess added the comment:
@michael-lazar a documentation change seems the path of least resistance given
the complicated history of this module. +1 from me.
--
___
Python tracker
<https://bugs.python.org/issue38
David Caro added the comment:
> David, which issue number is this?
It's issue41295, pr #21473
--
___
Python tracker
<https://bugs.python.org/issu
David Caro added the comment:
Just sent a PR that fixes the issue (a first approach), let me know if it's
addressing the issue correctly or if there's a better way.
Thanks!
--
___
Python tracker
<https://bugs.python.org/issue41
Change by David Caro :
--
keywords: +patch
nosy: +David Caro
nosy_count: 5.0 -> 6.0
pull_requests: +20617
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/21473
___
Python tracker
<https://bugs.python.org/i
201 - 300 of 12771 matches
Mail list logo