Adam Williamson added the comment:
I'm not the best person to ask what I'd "consider" to be a bug or not, to be
honest. I'm just a Fedora packaging guy trying to make our packages build with
Python 3.9 :) If this is still an important question, I'd suggest asking the
folks from
Adam Williamson added the comment:
Realized I forgot to give it, so in case it's important, the context here is
the black test suite:
https://github.com/psf/black/issues/1441
that test suite has a file full of expressions that it expects to be able to
parse this way (it uses `ast.parse
New submission from Adam Williamson :
Not 100% sure this would be considered a bug, but it seems at least worth
filing to check. This is a behaviour difference between the new parser and the
old one. It's very easy to reproduce:
sh-5.0# PYTHONOLDPARSER=1 python3
Python 3.9.0b1 (default, May
New submission from Adam Williamson :
While debugging issues with the black test suite in Python 3.9, I found one
which black upstream says is a Cpython issue, so I'm filing it here.
Reproduction is very easy. Just use this four-line tester:
print("hello, world")
\
pr
Adam Williamson added the comment:
It's this function:
https://github.com/freeipa/freeipa/blob/master/ipalib/install/kinit.py#L66
The function `run` is imported from `ipapython.ipautil`, it's defined here:
https://github.com/freeipa/freeipa/blob/master/ipapython/ipautil.py#L391
all
Adam Williamson added the comment:
Well, now our (Fedora QA's) automated testing of FreeIPA is showing what looks
like a problem with preexec_fn (rather than fork) being disallowed:
https://bugzilla.redhat.com/show_bug.cgi?id=1759290
Login to the FreeIPA webUI is failing, and at the time
Adam Williamson <awill...@redhat.com> added the comment:
Yeah, I've added a comment there. I agree we can keep subsequent discussion in
that issue. Closing this as a dupe.
I actually have the same thought as you, but I suspect making something that
"worked" before start t
Adam Williamson <awill...@redhat.com> added the comment:
On the "attractive nuisance" angle: I just ran right into this problem, and
reported https://bugs.python.org/issue32988 .
As I suggested there, if Python doesn't try to fix this, I'd suggest it should
at least *exp
Adam Williamson <awill...@redhat.com> added the comment:
I'd suggest that if that is the case, it would be better for the docs to
*specifically mention* that `%s` is not supported and should not be used,
rather than simply not mentioning it.
When it's used in real code (note someone in
Adam Williamson <awill...@redhat.com> added the comment:
Paul: right. This is on Linux - specifically Fedora Linux, but I don't think it
matters. glibc strftime and strptime depend on an underlying struct called
'tm'. 'man strftime' says:
%s The number of seconds since the
New submission from Adam Williamson <awill...@redhat.com>:
Test script:
import pytz
import datetime
utc = pytz.timezone('UTC')
print(datetime.datetime(2017, 1, 1, tzinfo=utc).strftime('%s'))
Try running it with various system timezones:
[adamw@xps13k pagure (more-timezone-fun %)]$ T
Adam Williamson added the comment:
Hmm, after a bit more poking I found this:
https://docs.python.org/3/library/time.html#time.tzset
"Note
Although in many cases, changing the TZ environment variable may affect the
output of functions like localtime() without calling tzset(), this beh
New submission from Adam Williamson:
I can't figure out yet why this is, but it's very easy to demonstrate:
[adamw@adam anaconda (time-log %)]$ python35
Python 3.5.2 (default, Feb 11 2017, 18:09:24)
[GCC 7.0.1 20170209 (Red Hat 7.0.1-0.7)] on linux
Type "help", "copyr
New submission from Adam Williamson:
I'm not sure if this is really considered a bug or just an unavoidable
limitation, but as it involves part of the stdlib operating on Python itself, I
figured it was at least worth reporting.
In Fedora we have a fairly simple little script called python
Adam Williamson added the comment:
https://github.com/tiran/defusedxml/pull/4 should fix this, I hope.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Adam Williamson added the comment:
https://paste.fedoraproject.org/511245/14824393/ is my cut at a fix for this,
gonna test it out now.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Adam Williamson added the comment:
Digging some more, it looks like *only* Python 3.3 went so far out of its way
to hide the pure-Python iterparse() - the code was changed again in 3.4 and it
doesn't do that any more. So I think a way forward here is to make the code
that uses
Adam Williamson added the comment:
Aha, so thanks to my colleague Patrick Uiterwijk, we see the problem. Since
Python 3.3, Python doesn't actually use that pure-Python iterparse() function
if it can instead replace it with a C version:
https://github.com/python/cpython/blob/3.3/Lib/xml/etree
Adam Williamson added the comment:
serhiy: so, the funny thing is this: your fix is ultimately a reversion. Though
we have to dig way back into the bowels of defusedxml to see this.
Specifically, to this commit!
https://github.com/tiran/defusedxml/commit
Adam Williamson added the comment:
Ammar: yep, that's correct. There's code in defused's ElementTree.py - _
get_py3_cls() - which passes different values to _generate_etree_functions
based on the Python 3 version.
For Python 3.2+, defused 0.4.1 expects to use the _IterParseIterator class from
New submission from Adam Williamson:
The changes made to xml.etree.ElementTree in this commit:
https://github.com/python/cpython/commit/12a626fae80a57752ccd91ad25b5a283e18154ec
break defusedxml , Christian Heimes' library of modified parsers that's
intended to be safe for parsing untrusted
21 matches
Mail list logo
