Changes by John Mark Vandenberg :
--
nosy: +John.Mark.Vandenberg
___
Python tracker
<http://bugs.python.org/issue25515>
___
___
Python-bugs-list mailing list
Unsub
Changes by John Mark Vandenberg :
--
nosy: +John.Mark.Vandenberg
___
Python tracker
<http://bugs.python.org/issue1650090>
___
___
Python-bugs-list mailin
Changes by John Mark Vandenberg :
--
nosy: +John.Mark.Vandenberg
___
Python tracker
<http://bugs.python.org/issue12790>
___
___
Python-bugs-list mailing list
Unsub
Changes by John Mark Vandenberg :
--
nosy: +John.Mark.Vandenberg
___
Python tracker
<http://bugs.python.org/issue2275>
___
___
Python-bugs-list mailing list
Unsub
Changes by John Mark Vandenberg :
--
nosy: +John.Mark.Vandenberg
___
Python tracker
<http://bugs.python.org/issue24925>
___
___
Python-bugs-list mailing list
Unsub
John Mark Vandenberg added the comment:
Might be useful to add a note to PEP 257 that f-strings are not valid as
docstrings .
Or should f-strings be valid docstrings and raise an error if any variables
present in the f-string do not exist in the outer scope?
--
nosy
John Mark Vandenberg added the comment:
Could it issue a UnicodeWarning?
--
nosy: +John.Mark.Vandenberg
___
Python tracker
<http://bugs.python.org/issue25
Changes by John Mark Vandenberg :
--
versions: +Python 3.4, Python 3.5, Python 3.6 -Python 3.1, Python 3.2
Added file: http://bugs.python.org/file40977/doctest_nested_functions-py3.6.diff
___
Python tracker
<http://bugs.python.org/issue1650
Changes by John Mark Vandenberg :
Added file: http://bugs.python.org/file40978/doctest_nested_functions-py3.6.diff
___
Python tracker
<http://bugs.python.org/issue1650
New submission from John Mark Vandenberg:
Currently doctest.testmod `globals` defaults to including everything in the
module scope, and tools like pyflakes assume that doctests run with globals as
a copy of __dict__ .
It is relatively simple to exclude everything using doctest.testmod(globs
Dimitri John Ledkov added the comment:
Whilst fixed in 3.5, it is not fixed in 2.7. And the reporter believes this is
a security vulnerability.
Can this be cherry-picked into the 2.7 branch?
--
nosy: +xnox
___
Python tracker
<h
John Mark Vandenberg added the comment:
It seems like there is already sufficient detection of invalid stack levels in
warnings.warn, and one of the code paths does `module = ""` and later
another does `filename = module`, so `filename` can be intentionally junk data,
which will be
Changes by John Mark Vandenberg :
--
nosy: +jayvdb
___
Python tracker
<http://bugs.python.org/issue25216>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by John Mark Vandenberg :
--
nosy: +jayvdb
___
Python tracker
<http://bugs.python.org/issue2636>
___
___
Python-bugs-list mailing list
Unsubscribe:
John Mark Vandenberg added the comment:
This looks a lot like the patch on http://bugs.python.org/issue850482
--
___
Python tracker
<http://bugs.python.org/issue25
John Mark Vandenberg added the comment:
See similar http://bugs.python.org/issue25216
--
nosy: +jayvdb
___
Python tracker
<http://bugs.python.org/issue850
Changes by John Mark Vandenberg :
--
nosy: +jayvdb
___
Python tracker
<http://bugs.python.org/issue25034>
___
___
Python-bugs-list mailing list
Unsubscribe:
John Mark Vandenberg added the comment:
In pyflakes we've looked at some of the strange scenarios where a raise without
argument is 'legal'. A patch to report errors for some of these was rejected
because they are legal. See https://github.com/pyflakes/pyflakes/pull/57 The
w
Changes by John Mark Vandenberg :
--
nosy: +jayvdb
___
Python tracker
<http://bugs.python.org/issue25381>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by John Mark Vandenberg :
--
nosy: +jayvdb
___
Python tracker
<http://bugs.python.org/issue26204>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by John Mark Vandenberg :
--
nosy: +jayvdb
___
Python tracker
<http://bugs.python.org/issue24294>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by John Mark Vandenberg :
--
nosy: +jayvdb
___
Python tracker
<http://bugs.python.org/issue26632>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by John Mark Vandenberg :
--
nosy: +jayvdb
___
Python tracker
<http://bugs.python.org/issue22247>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by John Mark Vandenberg :
--
nosy: +jayvdb
___
Python tracker
<http://bugs.python.org/issue25758>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by John Mark Vandenberg :
--
nosy: +jayvdb
___
Python tracker
<http://bugs.python.org/issue22888>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from John Mark Vandenberg:
After uninstalling pip on Fedora 24, ensurepip get_records_to_pack returns
None, causing rewheel.rewheel_from_record to raise TypeError: 'NoneType' object
is not iterable.
While this is probably not a scenario that CPython supports directly
John Mark Vandenberg added the comment:
Well, it wasnt my intention to remove the vendor package. There were two
versions, and I assume it would remove the older package which wasnt supplied
by the vendor, but it removed both.
Anyways, I see that most of the code path is in
https
John Mark Vandenberg added the comment:
pyflakes does assume doctest run with a copy of the module scope.
However when there is an __all__, the module scope as seen by other modules
'should' be only items in __all__. If a doctest is included in documentation,
it 'should'
John Paul Adrian Glaubitz added the comment:
I'm running into exactly this issue when using 'offlineimap' which is written
in Python.
--
nosy: +glaubitz
___
Python tracker
<https://bugs.pyt
John Paul Adrian Glaubitz added the comment:
Hi Serhiy!
> The simple fix is to add UnicodeEncodeError to "except LookupError". But
> there may be other places where we can get a similar error. They should be
> fixed too.
I would be very interested to test this as t
John Paul Adrian Glaubitz added the comment:
Awesome, thanks! I'll give it a try later today or tomorrow.
--
___
Python tracker
<https://bugs.python.org/is
John Paul Adrian Glaubitz added the comment:
> Awesome, thanks! I'll give it a try later today or tomorrow.
I have applied the patch and the problem seems to have been fixed. \o/
--
___
Python tracker
<https://bugs.python.org
John Paul Adrian Glaubitz added the comment:
I think there is one productive result of this discussion which is this patch
by Jessica Clark which gets rid of architecture-specific alignment code:
> https://github.com/python/cpython/pull/24624
Unfortunately, it has not seen any posit
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 bu
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 snippe
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 are there bu
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:
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
John Paul Adrian Glaubitz added the comment:
> I want to make it obvious that the platform has been dropped half a decade
> ago.
That's a political statement, not a technical one.
The change has zero functional impact on the other targets. It just makes the
use of Python in
John Paul Adrian Glaubitz added the comment:
> Moving forward, s390 will be unambiguously unsupported as we cannot test
> against this platform. Unless we get a buildbot provided for this purpose,
> as well as somebody willing to fix broken builds on that buildbot long-term,
>
John Paul Adrian Glaubitz added the comment:
> The guidelines for platform support are explained in PEP 11
> (https://www.python.org/dev/peps/pep-0011/#supporting-platforms). We don't
> support platforms unless we have maintainers and CI (builtbots) in place for
> the pla
John Paul Adrian Glaubitz added the comment:
> So IMO it's fine to remove the support.
You are not removing "support". You're just disallowing users to use the Python
interpreter - which works perfectly fine on all architectures we have in
current and previous relea
John Paul Adrian Glaubitz added the comment:
> This thread is an excellent example why ignoring platforms comes at a cost.
> It will only get worse when are going to introduce platform and architecture
> specific code for optimizations and features.
Which is purely hypothetic
John Paul Adrian Glaubitz added the comment:
> Are you sure about that? It seems SLE-12 support s390x not s390. Maybe it's
> multilib support in a similar manner that I've mentioned about RHEL7?
I work at SUSE. I looked at the internal build system. Debian also still buil
John Paul Adrian Glaubitz added the comment:
> What is the use case or benefit of building Python for 32-bit rather than
> 64-bit?
That's not really the question. The question is whether an upstream project
should prevent downstreams from using unsupported target configurations a
John Paul Adrian Glaubitz added the comment:
> To get a platform supported by Python, we also need a volunteer to fix issues
> specific to the 31 bit s390 platform: see PEP 11.
You do not need to support every platform. Just allow your users to use them.
If something breaks downstrea
John Paul Adrian Glaubitz added the comment:
> 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.
Fully agree.
> Yes, maintenance theoretically is a burden, but there have been no recent
>
John Paul Adrian Glaubitz added the comment:
> "Move support of legacy platforms/architectures outside Python"
> https://mail.python.org/archives/list/python-...@python.org/thread/F5BXISYP7RAINXUMYJSEYG7GCFRFAENF/
Motorola 68k isn't a 16-bit architecture, it's a 32-
John Paul Adrian Glaubitz added the comment:
Oh, and LLVM is currently gaining support M68k which you consider "legacy":
> https://reviews.llvm.org/D95315
It might be a good idea to do some research first before making su
1201 - 1249 of 1249 matches
Mail list logo
