Michał Górny added the comment:
Could you make a PR to fix the test failures? I suppose that could speed
things up and if not, I'd at least have something to pull into Gentoo.
--
___
Python tracker
<https://bugs.python.org/issue46
Michał Górny added the comment:
BTW there are test regressions with expat 2.4.5, apparently due to some test
snippets now being rejected as invalid XML:
==
ERROR: test_issue3151 (test.test_xml_etree.BugsTest
Michał Górny added the comment:
After updating PyPy3 to use Python 3.9's stdlib, we hit very bad hangs because
of this — literally compiling a single file with "parallel" compileall could
hang. In the end, we had to revert the change in how Python 3.9 starts workers
because
Michał Górny added the comment:
I would still find it helpful to have a "proper" "blake3-c" package on normal
pypi, for those of us who can't rely on Rust being present immediately.
--
___
Python tracker
<https://bug
Michał D added the comment:
Please see the changes I suggested in my PR.
--
___
Python tracker
<https://bugs.python.org/issue46033>
___
___
Python-bugs-list m
New submission from Michał D :
In for statement description, there seem to be two sentences meant to mean the
same:
> The suite is then executed once for each item provided by the iterator, in
> the order returned by the iterator. Each item in turn is assigned to the
> target l
Michał Górny added the comment:
I've already asked that, and the author said it's fine but with the deprecated
text file support removed:
https://github.com/hukkin/tomli/issues/141#issuecomment-968056905
That said, for consistency with json and so on we'd probably want to combine
tomli
New submission from Michał Bartoszkiewicz :
The following code, which seems reasonable:
import io
import pickle
class Pickler(pickle.Pickler):
def persistent_id(self, obj):
return super().persistent_id(obj)
Pickler(io.BytesIO()).dump(42)
crashes with:
RecursionError: maximum recursion
Michał Górny added the comment:
Is there any progress happening? FWIU the common "toml" module on pypi has
been discontinued now, projects are switching to yet another one and this is
exactly the kind of problem a built-in module would ha
Michał Górny added the comment:
Jack, are you still working on this? I was considering allocating the time to
write the bindings for the C library myself but I've stumbled upon this bug and
I suppose there's no point in duplicating work. I'd love to see it on pypi, so
we could play
Michał Górny added the comment:
The test added for this bug is insufficient to verify the fix. If I revert the
Lib/http/client.py change, the test still passes. This is because a subclass
of client.HTTPException is still raised.
If I add an explicit begin() call to trigger the exception
Michał Górny added the comment:
In my opinion, raising an exception would have been safer.
Botocore and django do precisely what you say — provide a validator. To make
this validator easier, they do the validation on splitted up URL parts.
I disagree with the premise that they were stupid
Michał Górny added the comment:
I hate to be the bearer of bad news but I've already found this change to be
breaking tests of botocore and django. In both cases, the test failure is
apparently because upstream used to reject URLs after finding newlines in the
split components, and now
Michał Górny added the comment:
> If it takes years for users to get to 3.10, we should reevaluate our
> release cycle, not whether we aggressively break maintenance releases.
I don't really understand how that would help. The problem is that users have
major inertia for switching to
Change by Michał Górny :
--
versions: +Python 3.10 -Python 3.4
___
Python tracker
<https://bugs.python.org/issue18232>
___
___
Python-bugs-list mailing list
Unsub
Change by Michał Górny :
--
keywords: +patch
pull_requests: +23655
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/24893
___
Python tracker
<https://bugs.python.org/issu
Michał Górny added the comment:
I'm not convinced we need something that complex here but I think it would make
sense to make 'unittest discover' fail when it doesn't discover a single test.
As packagers, we've been bitten more than once by packages whose tests suddenly
stopped being
New submission from Michał Górny :
There is a race condition in distutils' build_ext implementation. When the
same source file is used to build multiple extensions, distutils attempts to
build it multiple times using the same output file, in parallel. This means
that the link editor can
Michał Górny added the comment:
Nevermind, I've been testing wrong and this is most likely our fault. I'm
sorry about the noise. I am going to investigate further and reopen if it
turns out the problem's on CPython end.
--
stage: -> resolved
status: open ->
New submission from Michał Górny :
So I've finally found time to bisect this.
Long story short, test_ctypes started hanging on Gentoo package builds since
3.10.0a2. Previously, the test took less than a second. Now, it just keeps
running for minutes until I kill it.
The weird thing
New submission from Michał Kozik :
Tuples (datetime, description) all are sorted by the date except one entry
(2021-03-09) which is out of order:
Expected order: Actual order:
2021-03-04 Event E 2021-03-04 Event E
2021-03-07 Event B 2021-03
Michał Górny added the comment:
It seems that the spec has reached 1.0.0:
> 1.0.0 / 2021-01-11
I guess that there are still ~2 months left to do this before 3.10 reaches beta.
--
___
Python tracker
<https://bugs.python.org/issu
Michał Górny added the comment:
Thank you for debugging this. I can confirm that this patch resolves my issue.
--
___
Python tracker
<https://bugs.python.org/issue42
Michał Górny added the comment:
A more complete backtrace:
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:49
#1 0x7fa633b20536 in __GI_abort () at abort.c:79
#2 0x7fa633b79bf7 in __libc_message (action=action@entry=do_abort,
fmt=fmt@entry=0x7fa633c8c3b5 "
Michał Górny added the comment:
aeb66c1abbf4ec214e2e80eb972546996d1a1571 is the first bad commit
commit aeb66c1abbf4ec214e2e80eb972546996d1a1571
Author: Miss Skeleton (bot) <31488909+miss-isling...@users.noreply.github.com>
Date: Thu Oct 15 08:51:48 2020 -0700
bpo-41984: GC tra
New submission from Michał Górny :
I'm still investigating the problem and I will include more information
shortly. However, I'm filing the bug early, as I'd like to prevent this
regression from hitting 3.8.7 release.
When running backports-zoneinfo-0.2.1 test suite using cpython 3.8.7rc1
Michał Górny added the comment:
Any reason this wasn't backported to 3.6? FWICS it's supposed to be security
supported still.
--
nosy: +mgorny
___
Python tracker
<https://bugs.python.org/issue40
Michał Górny added the comment:
> An OSError for a file the OS can read seems a bit off. What is the
> accompanying message?
For example:
OSError: Invalid data stream
(I've just put random string into a file, and opened it as bzip2)
> Would something like ValueError("
New submission from Michał Górny :
Currently, the bz2 extension functions raise a generic OSError() on
BZ_DATA_ERROR and BZ_DATA_ERROR_MAGIC. When working on files, this makes it
unnecessarily hard to catch compressor errors (i.e. invalid bz2 input file)
without catching system I/O errors
Michał Górny added the comment:
Given that a CVE was assigned for this, I think it'd be better if the news were
in the 'Security' category and not 'Library'.
--
nosy: +mgorny
___
Python tracker
<https://bugs.python.org/issue39
Michał Górny added the comment:
I can reproduce test_socket hanging in 2 out of 3 runs. However, in my case
testPeek doesn't seem to be the (only) culprit. Disabling whole RDSTest helps.
--
nosy: +mgorny
___
Python tracker
<ht
Michał Górny added the comment:
I wonder if it would be feasible to support new behavior in earlier versions of
Python via __future__. I suppose that could help software avoid having Python
version-dependent behavior in the long run
Michał Górny added the comment:
Thank you!
--
___
Python tracker
<https://bugs.python.org/issue1294959>
___
___
Python-bugs-list mailing list
Unsubscribe:
Michał Górny added the comment:
I'm sorry but does this change mean that it's not final or...?
My main concern is whether we should be adjusting our packages to the new
behavior in py3.9, or wait for further changes.
--
___
Python tracker
<ht
Michał Górny added the comment:
Do I understand correctly that the new behavior is intentional in 3.9, or is
that still being discussed?
--
nosy: +mgorny
___
Python tracker
<https://bugs.python.org/issue27
Michał Górny added the comment:
Ok, it seems that I misunderstood it at first. Judging by the code, it also
affects extensions installed into site-packages, so I've tried to make that
clear and add one more example to the bullet list
Change by Michał Górny :
--
pull_requests: +19600
pull_request: https://github.com/python/cpython/pull/20332
___
Python tracker
<https://bugs.python.org/issue1294
Michał Górny added the comment:
> Can you please propose a different wording? English is not my first language.
Mine neither but I'll try. How about:
'Name of the platform-specific library directory. It is used to build the path
of the standard library and C extension modu
Michał Górny added the comment:
Can we clarify the wording to clearly indicate it's to be used only for Python
modules/extensions and not system dynamic libs?
--
___
Python tracker
<https://bugs.python.org/issue1294
Michał Górny added the comment:
> Not at all. This means that it is possible to do so. It remains optional.
...but then sys.platlibdir is going to incorrectly list 'lib', isn't it?
According to https://docs.python.org/3.9/library/sys.html#sys.platlibdir it's
used 'to build the p
Michał Górny added the comment:
Does this mean that platforms using /usr/lib64 for shared libraries are now
forced to install Python into /usr/lib64/python*?
--
nosy: +mgorny
___
Python tracker
<https://bugs.python.org/issue1294
New submission from Michał Górny :
PEP 518 uses the TOML format to specify build system requirements. AFAIU this
means that all new build systems will require a TOML parser. Could you
consider adding one to the standard library to reduce the number of chicken-egg
problems?
The referenced
Change by Michał Górny :
--
nosy: +mgorny
___
Python tracker
<https://bugs.python.org/issue39503>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Michał Górny :
--
nosy: +mgorny
___
Python tracker
<https://bugs.python.org/issue38826>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Michał Szymaniak :
When user lacks rights to read on of the mimetypes.knownfiles, mimetypes init()
will throw PermissionError and library becomes unusable.
Reproduction steps:
# mkdir -p /etc/httpd/conf/
# touch /etc/httpd/conf/mime.types
# chmod a-r /etc/httpd/conf
Michał Fronczyk added the comment:
A link to my stackoverflow question with further rationale -
https://stackoverflow.com/questions/58122752/provide-additional-location-of-site-packages-to-python?noredirect=1#comment102637846_58122752
--
___
Python
New submission from Michał Fronczyk :
An environment variable to point to an additional site-packages directory
(without disabling the one in Python itself) location would allow having
different sets of extra packages that can be enabled by the users in their or
shared Python installations
Michał Górny added the comment:
This is not really an upstream issue, it is due to Gentoo-specific patching.
--
nosy: +mgorny
___
Python tracker
<https://bugs.python.org/issue36
Michał Górny added the comment:
Thanks a lot! I've left a few comments based on eyeball review. I'm going to
test it later today.
--
___
Python tracker
<https://bugs.python.org/issue35
Michał Górny added the comment:
> Adding this API would require to provide a way to set file status like mode,
> uid, gid, mtime, type, linkname, uname and gname.
That's why I mentioned addfile() -- it takes TarInfo object for that purpose.
I suppose the new function should have th
New submission from Michał Górny :
Currently, the tarfile module only supports adding files if their size is known
prior to adding. However, I think it'd be helpful to be able to store large
dynamically generated streams straight into the (uncompressed) .tar file
without being able
New submission from Michał Górny :
xz-utils has four options to configure codecs supported by liblzma:
--enable-encoders
--enable-decoders
--enable-match-finders
--enable-checks
In Gentoo, we're using those options to optionally provide smaller footprint
liblzma builds that include
Michał Radwański added the comment:
So this format is just a series of JSON, delimited by a newline.
Instead of changing API, you might consider this piece of code:
def ndjsondump(objects):
return '\n'.join(json.dumps(obj) for obj in objects)
Conversely, first you `str.splitlines
Michał Radwański added the comment:
Serhiy, would it be ok to put '__module__' + '.' + __qualname__ here?
--
nosy: +enedil
___
Python tracker
<https://bugs.python.org/issue34
Michał Radwański added the comment:
But if the error message is set, then for consistency, it should be also the
case that the later checks set some kind of error message.
--
nosy: +enedil
___
Python tracker
<https://bugs.python.org/issue34
Michał Radwański added the comment:
The change is not only in the added `isinstance` check:
~ $ python3.6 -q
>>> import typing
>>> isinstance(typing.Sequence, type)
True
>>>
~ $ python3.7 -q
>>> import typing
>>> isinstance(typing.Sequen
Michał Radwański added the comment:
The point is that the specification is not complete and thus left for the
implementations to decide. Python's version hits the sweet spot between
inclusive and correct - as long as a version is unambiguous, it is accepted
Michał Radwański added the comment:
According to the RFC ( https://tools.ietf.org/html/rfc4291#section-2.2 ), last
four bytes can be an address in the format of IPv4 address. The latter doesn't
specify whether leading zeros are permitted or not. For illustration let's look
Michał Radwański added the comment:
Although you're right - this issue is specific to pytime.c, when
_Py_InIntegralTypeRange() is used with a double, it is actually true that
_Py_InIntegralTypeRange() is used with double, in pytime.c only (as a quick
recursive grep discovers).
Perhaps
Change by Michał Radwański :
--
keywords: +patch
pull_requests: +8278
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue34423>
___
___
Py
Change by Michał Radwański :
--
pull_requests: +8277
___
Python tracker
<https://bugs.python.org/issue32367>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Michał Radwański :
Code triggering bug:
import time
time.sleep(2**63 / 10**9)
Result:
ValueError: sleep length must be non-negative
The problem is with the macro that checks the range of provided double:
Line 228 of Include/pymath.h:
#define _Py_InIntegralTypeRange(type
Change by Michał Górny :
--
keywords: +patch
pull_requests: +8198
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue34366>
___
___
Py
New submission from Michał Górny :
The _uuid extension fails to build on my Gentoo/FreeBSD system:
building '_uuid' extension
x86_64-gentoo-freebsd11.1-gcc -pthread -fPIC -Wno-unused-result -Wsign-compare
-DNDEBUG -O2 -pipe -march=native -fwrapv -std=c99 -Wextra -Wno-unused-result
-Wno-unused
Michał Górny <mgo...@gentoo.org> added the comment:
Well, according to the reporters disabling GC doesn't help at all. Maybe it's
another issue.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Michał Górny <mgo...@gentoo.org> added the comment:
Could you get this fixed in earlier versions of CPython? Given that 3.7 is not
yet released, having this broken in 3.5 and 3.6 is highly undesirable. This
apparently seems to affect our tooling [1] and telling our users to use 3.7
Michał Górny <mgo...@gentoo.org> added the comment:
Well, my two main concerns are:
1) whether it is acceptable for PyPy to not raise TypeError in this case, or if
I should report it to PyPy upstream as a bug,
2) and whether programmers can appropriately rely on PySequence_Length()
r
Michał Górny <mgo...@gentoo.org> added the comment:
So is the documentation mistaken or just confusing? It says straight:
> For objects that do not provide sequence protocol, this is equivalent to the
> Python expression len(o).
So it the 'do not' mistaken or does it
New submission from Michał Górny <mgo...@gentoo.org>:
While debugging PyPy test failure on backports.lzma [1], I've noticed that
PySequence_Check() on a dict type raises TypeError, e.g.:
Traceback (most recent call last):
File "test/test_lzma.py", line 273, in test_
Michał <krassowski.mic...@gmail.com> added the comment:
I've got confused with the "TypeError: unhashable type: 'dict'" error creating
a choose-from-dictionary argument in Python 3.6. I used lambda as a workaround,
but IMO it would be great to have this patch merged.
Change by Michał Górny <mgo...@gentoo.org>:
--
keywords: +patch
pull_requests: +4036
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
New submission from Michał Górny <mgo...@gentoo.org>:
The setup.py file for Python states:
if (not cross_compiling and
os.uname().machine == "x86_64" and
sys.maxsize > 2**32):
# Every x86_64 machine has at least SSE2. Ch
Michał Górny added the comment:
I've submitted a pull request with another fix. I've tried to keep the changes
at minimal but I couldn't stand keeping meaningless 'echo $x | sed -e s/$x/$y/'
;-).
I have to point out that the attached patch is wrong since it does readlink on
CFLAGS
Changes by Michał Górny <mgo...@gentoo.org>:
--
keywords: +patch
pull_requests: +3754
stage: needs patch -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Changes by Michał Górny <mgo...@gentoo.org>:
--
nosy: +mgorny
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue22140>
___
__
Changes by Michał Radwański <lisklusow...@gmail.com>:
--
pull_requests: +
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Michał Radwański added the comment:
Docs mention:
ast.parse(source, filename='', mode='exec')
Parse the source into an AST node. Equivalent to compile(source, filename,
mode, ast.PyCF_ONLY_AST).
If you just parse code into AST, you first check whether it is possible to turn
such source
Michał Bultrowicz added the comment:
I guess that it's worth noting that the same problem is being talked about in
an issue on the asynctest library:
https://github.com/Martiusweb/asynctest/issues/29
--
nosy: +butla
___
Python tracker <
Michał Górny added the comment:
Christian, since the code is now integrated in Python 3.6+ (with some bugfixes
AFAICS), could you consider updating your bitbucket package to match it? It
would be helpful as a backport package for older Python versions.
--
nosy: +mgorny
Michał Bultrowicz added the comment:
One more update - I had the problem, because I was using monkeypatch.setattr()
from Pytest, and assumed that it will work the same as patch(). This assumption
turned out to be wrong.
--
___
Python tracker <
Changes by Michał Bultrowicz <michal.bultrow...@gmail.com>:
--
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pyt
Michał Bultrowicz added the comment:
Ok, I've checked again and now patching "file_writer.open" works. I have no
idea what I was doing wrong the last time I checked... So I guess I'll close
the issue.
--
___
Python tracker <rep...@bu
Michał Bultrowicz added the comment:
Then where it should be patched in? Can you give an example? From what I've
checked patching only works in __main__ and builtins.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
New submission from Michał Bultrowicz:
Documentation of mock_open doesn't say how to use it in real-life test
situations (when you're probably not mocking in __main__). I've spent some time
scratching my head and googling for the way to mock-out the "open" function,
want to spare ot
Michał Klich added the comment:
The documentation for argparse still does not mention this behaviour.
I decided to make a patch based no the optparse issue.
Hopefully it is good enough to be merged.
--
keywords: +patch
nosy: +michal.klich
Added file: http://bugs.python.org/file44934
Michał Górny added the comment:
Yes, you could put it like this.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27226>
___
___
Michał Górny added the comment:
Brett, .pyc was controlled by --compile and .pyo by --optimize (either 1 or 2).
Technically only two variants could be used simultaneously, and distutils
accounted for that.
Now you have .pyc + .opt-1.pyc + .opt-2.pyc, so three variants instead of two
Changes by Michał Górny <mgo...@gentoo.org>:
--
keywords: +patch
Added file:
http://bugs.python.org/file43231/0001-distutils-make-OO-enable-both-opt-1-and-opt-2-optimi.patch
___
Python tracker <rep...@bugs.python.org>
<http://
New submission from Michał Górny:
Since 3.5, optimized Python modules for -O and -OO are installed using
different names. The Python build system itself seems to been prepared for this
as Python itself is built with both .opt-1.pyc and .opt-2.pyc files built.
However, distutils at the moment
Michał Bednarski added the comment:
> You should now sign the PSF Contributor Agreement
Done.
> (Well, in fact it would be better to do that *before* merging your change,
> but well, your change is short enough ;-))
Well on https://docs.python.org/devguide/patch.html was said "F
Michał Bednarski added the comment:
> Hum, I'm surprised that SELinux blocks such safe function. Maybe the SELinux
> policy should be completed to allow it?
The ioctl is blocked for given file type regardless of request argument. As I'm
running Python on non-rooted Android updating
New submission from Michał Bednarski:
When SELinux forbids ioctl() it fails with EACCES and whole os.set_inheritable
raises exception.
As in https://bugs.python.org/issue22258 code was added to fall back to fcntl
when ioctl() fails with ENOTTY I'm adding EACCES value to same condition
New submission from Michał Jan Warecki:
This should speak for itself:
>>> 3*4.35
13.049
>>>
The error is reproducible, and applies to all decimal numbers ending with
\.[0-9]5, and \.[0-4] as well as \.[6-9], when multiplied by 3. Examples:
>>> 3*4.1
1
Changes by Michał Jan Warecki <mwarec...@gmail.com>:
--
components: +Interpreter Core
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Michał Górny added the comment:
In CPython, the _ssl module is compiled in C. How can we check if libssl
provides RAND_egd() or not at compile time?
How about... checking whether the function is provided? Unless I'm missing some
major point, AC_CHECK_FUNC should be good enough
Michał Pasternak added the comment:
I just hit this bug on 2.7.6, running on polish WinXP (I need to build some
packages there, I hope I'll avoid a nasty py2exe bug). Any reasons this is not
fixed yet? Do you need any assistance?
--
nosy: +Michał.Pasternak
Michał Pasternak added the comment:
Another REG file, encoded with CP1250, I believe.
--
Added file: http://bugs.python.org/file34188/issue9291-key.reg
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9291
Michał Pasternak added the comment:
Martin: the problematic key is [HKEY_CLASSES_ROOT\BDATuner.Składniki]. I am
pasting its name, because I suppose, that as bugs.python.org is utf-8, special
characters will be pasted properly.
Included you will find a .REG file, which is Windows Registry
Michał Pasternak added the comment:
As for the fix, sitecustomize.py works for me, too, but I somehow believe, that
adding sitecustomize.py for new Python installations would propably do more
harm than good. I'll check those 2 patches and I'll let you know
Michał Pasternak added the comment:
9291.patch works for me too, but I am unsure about its idea. Silently ignoring
non-ASCII registry entries - does it sound like a good idea? Maybe. Is it
pythonic? I doubt so.
I don't exactly understand what 9291a.patch is doing. For me it does look like
1 - 100 of 130 matches
Mail list logo
