New submission from Adrian Chan:
I uninstalled python 2.7 and 3.4, then performed a fresh install of 3.5.3.
Running pip with `python -m pip` as per https://docs.python.org/3.5/installing
gives the following error:
C:\Python\Python35-32\python.exe: No module named pip.__main__; 'pip&
Adrian Chan added the comment:
There is no traceback, that is the entirety of the output of the command.
Python bin is C:\Python\Python35-32\python.exe
PYTHONHOME is not set.
PYTHONPATH is C:\python27\lib\site-packages\
I don't know why PYTHONPATH was set. I cleared it but it ma
Adrian Chan added the comment:
Thanks, but I know how to drive a terminal ;)
Your hunch was basically correct though. I ran again with `python -v -m pip`
(see with_pip_dir.txt), and see that python is attempting to import pip from my
user directory (C:\Users\amc2\pip). This is an empty
Adrian Chan added the comment:
It's all working fine now, thanks.
If one of the installer/windows guys wants to dig more into why this didn't
install properly I'm happy to run things in my environment as necessary.
--
___
Python
Adrian Chan added the comment:
Install logs attached.
First set from initial install, second set from repair.
--
Added file: http://bugs.python.org/file46645/py_install_logs.tar.gz
___
Python tracker
<http://bugs.python.org/issue29
Adrian Chan added the comment:
Ah, I'd forgotten about that. When I first tried to run python I got an error
complaining about a missing api-ms-win-crt-runtime-l1-1.0.dll
I installed the necessary VC redistributable and it solved that problem. So
that's why I could successfully
Adrian Wielgosik added the comment:
I'm pretty sure this is undefined behavior. Here's how similar code was fixed
in Chromium:
https://codereview.chromium.org/9117014/patch/1/2
--
nosy: +Adrian Wielgosik
___
Python tracker
<http://bu
Adrian Chan added the comment:
Is this still being worked on? I have a potential fix for this.
--
nosy: +adchanw
___
Python tracker
<http://bugs.python.org/issue24
Adrian Chan added the comment:
I've attached a potential fix for this issue.
While trying to fix this, I noticed that I coudn't assume that I just need to
ensure that each line has a newline. If I always ensure each line in diffline
has a newline, then the four
New submission from Adrian Wielgosik:
The attached patch uses an existing function bits_in_digit() in two other
functions:
- in long_bit_length() - it already had identical logic
- in _PyLong_NumBits() - it used a naive, slower way of calculating bit length,
so as an added bonus the patch
Changes by Adrian Wielgosik :
--
keywords: +patch
Added file: http://bugs.python.org/file45367/bit_length.patch
___
Python tracker
<http://bugs.python.org/issue28
Adrian Garcia Badaracco added the comment:
While this is figured out, would it be possible to remove the silent
overriding? This seems like something type checkers should be doing, not silent
runtime modification of classes. Pyright already (correctly) checks this, so I
think it would just
Adrian Garcia Badaracco added the comment:
Apologies if that was noise, I filed an issue on the MyPy issue tracker:
https://github.com/python/mypy/issues/12261
--
___
Python tracker
<https://bugs.python.org/issue44
Change by Adrian Garcia Badaracco :
--
pull_requests: +29750
stage: test needed -> patch review
pull_request: https://github.com/python/cpython/pull/31628
___
Python tracker
<https://bugs.python.org/issu
Adrian Garcia Badaracco added the comment:
Agreed.
What if we allow protocols that implement `__init__` but still disallow
instantiating a protocol that does not? It's a 1 line change, all existing
tests pass and it would still catch what I think was the original intention
(tryi
Adrian Garcia Badaracco added the comment:
Guido, it looks like you replied while I was typing my reply out.
Yurii can correct me here but I believe PR #27543 was an attempt to disallow
defining `__init__` on a Protocol completely. What I proposed above is the
opposite behavior, while still
Adrian Garcia Badaracco added the comment:
I am not sure if that solves anything (other than the fact that __new__ is much
less common to implement than __init__), but I may just be slow to pick up the
implications of moving the check to __new__
Adrian von Bidder added the comment:
On Thursday 02 December 2010 22.51:51 you wrote:
> Committed to py3k in r86936 with minor fixups.
thanks, great! (Wheee! my first patch to Python ;-)
cheers
-- vbi
--
___
Python tracker
&l
New submission from Adrian Garcia Badaracco :
I recently tried to use `contextvars.Context.run` w/ coroutines, expecting the
same behavior as with regular functions, but it seems that
`contextvars.Context.run` does not work w/ coroutines.
I'm sorry if this is something obvious to do wit
Change by Adrian Garcia Badaracco :
--
nosy: +adriangb
___
Python tracker
<https://bugs.python.org/issue42815>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Adrian Garcia Badaracco :
--
nosy: +yselivanov
___
Python tracker
<https://bugs.python.org/issue44834>
___
___
Python-bugs-list mailing list
Unsub
Change by Adrian Garcia Badaracco :
--
nosy: +adriangb
___
Python tracker
<https://bugs.python.org/issue26175>
___
___
Python-bugs-list mailing list
Unsubscribe:
Adrian Garcia Badaracco added the comment:
As part of working on a tool that deals with dependencies, I was building my
own topological sort. I iterated through various APIs (iterable of tasks,
iterable of parallelizable groups of tasks, etc.) until I found the (now
stdlib) version which
New submission from Adrian von Bidder :
Using the hostname for the domain part of a Message-Id is probably the right
thing usually but users may want to override this.
Please consider this rather trivial patch:
=
--- utils.py.orig 2010-06-13 16:59:30.533861099 +0200
+++ utils.py
Adrian von Bidder added the comment:
Thanks for the positive feedback. I'll try to do the diff against top of tree
and the unit test soon-ish.
Use case:
* In my specific case, I'm writing a sort of cross between mailing list and
blog system and I'd like to use a sta
Adrian von Bidder added the comment:
I'm sure several of you have worked with the Python source code before and know
by heart how to run the testsuite. In other words: I admit that I've only
written the code and have not tried it.
Given how trivial the patch is, I have
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
101 - 147 of 147 matches
Mail list logo
