Ionel Cristian Mărieș added the comment:
Alright so to get all the package paths, included distro-managed ones would be
this right?
for scheme in sysconfig.get_scheme_names():
for name in ['purelib', 'platlib']:
sysconfig.get_path(name, scheme
Ionel Cristian Mărieș added the comment:
That seems fine, tho for some of distros that do lots of python customizations
(tried the docker ubuntu image for 18.04.3) it get a bit strange:
Python 3.6.9 (default, Jan 26 2021, 15:33:00)
[GCC 8.4.0] on linux
Type "help", "copyr
Ionel Cristian Mărieș added the comment:
Hello everyone,
How are we supposed to use get_python_lib now (a function that returned the
site-packages location)?
`from setuptools._distutils.sysconfig import get_python_lib` doesn't really
seem like the right solution and the sysconfig stdlib
Ionel Cristian Mărieș added the comment:
Note that coveragepy ain't the sole usecase for this.
https://pypi.org/project/manhole/ - a debugging tool
https://pypi.org/project/hunter/ - a tracer
In addition to those there's https://pypi.org/project/pytest-cov/ which
packages the pth trick so
Change by Ionel Cristian Mărieș :
--
nosy: +ionelmc
___
Python tracker
<https://bugs.python.org/issue29759>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Ionel Cristian Mărieș :
--
nosy: +ionelmc
___
Python tracker
<https://bugs.python.org/issue40442>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Ionel Cristian Mărieș :
--
nosy: +ionelmc
___
Python tracker
<https://bugs.python.org/issue30744>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ionel Cristian Mărieș added the comment:
No. You can't put an usercustomize in a wheel.
--
___
Python tracker
<https://bugs.python.org/issue33944>
___
___
Pytho
Ionel Cristian Mărieș added the comment:
atexit proved time and time again to be unreliable, not really an option. Not
all programs shutdown nicely enough for atexit.
Should I tell users "use forkserver on 3.8 because broken stuff"?
--
Change by Ionel Cristian Mărieș :
--
components: +Library (Lib)
___
Python tracker
<https://bugs.python.org/issue38227>
___
___
Python-bugs-list mailing list
Unsub
New submission from Ionel Cristian Mărieș :
Running `python3.8 mp-bug-python2.8.py` usually gets stuck after a dozen
iterations or so.
It appears that if I stop setting that signal handler it doesn't get stuck.
Unfortunately I need it to perform critical cleanup.
This is what I got from gdb
Ionel Cristian Mărieș added the comment:
What module? That check should be done directly in the pth file.
--
___
Python tracker
<https://bugs.python.org/issue33
Ionel Cristian Mărieș added the comment:
> because you’re on the same machine and you pip installed it, I have no
> choice but to pay those costs, which I haven’t explicitly opted in to.
>
> At least for the coverage plugins there is a required opt in from
> environment variable
Ionel Cristian Mărieș added the comment:
> * coverage, debugging, demo, except-hook - application/user
responsibility, not a package's
Elaborate please, as it sounds like you're simply dismissing my usecase.
--
___
Python tracker
<
Ionel Cristian Mărieș added the comment:
> Doesn’t that kind of prove my point? :)
So basically you'd remove the whole feature just cause one package no one
installs abuses it. Doesn't make sense.
--
___
Python tracker
<https://bugs.pyth
Ionel Cristian Mărieș added the comment:
> There was a single .pth file that I deemed "malicious" since it
completely breaks the `subprocess` module (`subprocess-run`)
It only seems to set an attribute. What's wrong with that? Does the early
import of subprocess c
Ionel Cristian Mărieș added the comment:
On Wed, Feb 27, 2019 at 1:41 AM Barry A. Warsaw
wrote:
> Basically yes, I’ve done this. But think of the poor user who doesn’t
have that expertise or ability to hack on an installed Python’s site.py
file. When their application breaks because s
Ionel Cristian Mărieș added the comment:
On Wed, Feb 27, 2019 at 1:31 AM Barry A. Warsaw
wrote:
> Your sudo may not be my sudo. :) Let’s say I update my Ubuntu desktop
and a new version of package with a pth breaks.
> Maybe I didn’t even know I was doing that, via automated u
Ionel Cristian Mărieș added the comment:
> Because there’s no good place to stick a pdb/breakpoint to debug such issues
> other than site.py, and that usually requires sudo.
Something bad was installed with sudo but suddenly sudo is not acceptable for
debugging? This seems crazy
Ionel Cristian Mărieș added the comment:
FYI I have 3 projects that use pth files to activate various features (an env
var is usually the trigger):
https://pypi.org/project/pytest-cov - enables coverage measurement in any
subprocess
https://pypi.org/project/manhole - installs a debug service
Ionel Cristian Mărieș <cont...@ionelmc.ro> added the comment:
Alright, now it makes sense. Thank you for writing a thoughtful response.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Ionel Cristian Mărieș <cont...@ionelmc.ro> added the comment:
It should be open for getting some visibility, as I need some help here -
Raymond, I hope you can find a way to be hospitable here and stop with the
kindergarten behavior.
--
status: closed -
Ionel Cristian Mărieș <cont...@ionelmc.ro> added the comment:
Hello everyone,
Is anyone still interested in fixing this bug and help with whatever PEP
drafting was needed for convincing people?
I would sketch up a draft but for me at least it's not clear what are the
disadva
Ionel Cristian Mărieș added the comment:
Okay ... is anyone interested in helping with this (reviewing drafts)? Who
would be the BDFL?
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Ionel Cristian Mărieș added the comment:
On Mon, May 23, 2016 at 11:04 PM, Ethan Furman <rep...@bugs.python.org>
wrote:
> `issubclass` doesn't "do the right thing", as evidenced by another dev.
>
Hmmm. Technically, in that case, the problem is in
collections.abc.Iterable,
Ionel Cristian Mărieș added the comment:
On Mon, May 23, 2016 at 9:34 PM, Ethan Furman <rep...@bugs.python.org>
wrote:
> "Add proxy support to builtins" and should address such things as
> callable, issubclass, and whatever else is is appropriate.
As previously stated th
Changes by Ionel Cristian Mărieș <cont...@ionelmc.ro>:
Added file: http://bugs.python.org/file42957/callable2.diff
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Ionel Cristian Mărieș added the comment:
On Mon, Apr 20, 2015 at 5:08 PM, Eric Snow <rep...@bugs.python.org> wrote:
> FYI, I'll re-iterate something I said before, there is a different
> approach you can take here if this is just an issue of proxying. Use two
> different proxy
Changes by Ionel Cristian Mărieș <cont...@ionelmc.ro>:
--
nosy: +ionelmc
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue19072>
___
Ionel Cristian Mărieș added the comment:
As I understood it the issue is not with the order but with the iteration being
"unstable" (eg: same key appears multiple times). Yes, the dict is mutated
while it's being iterated on, but no keys are added or removed, only values ar
Changes by Ionel Cristian Mărieș <cont...@ionelmc.ro>:
--
nosy: +ionelmc
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26060>
___
Changes by Ionel Cristian Mărieș <cont...@ionelmc.ro>:
--
nosy: +ionelmc
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25920>
___
Changes by Ionel Cristian Mărieș <cont...@ionelmc.ro>:
--
nosy: +ionelmc
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue16500>
___
Ionel Cristian Mărieș added the comment:
I think those warning are about the fact that stuff that ain't in the packages
list are added on PYTHONPATH. Not 100% sure tho.
Nothing to do with MANIFEST.in (not used for develop). Plus it's more specific
to setuptools (where develop is implemented
New submission from Ionel Cristian Mărieș:
It appears that the new installer has some overlap issue when displaying
progress info. Attached a screenshot.
--
components: Installation
files: installer-display-bug.png
messages: 244579
nosy: ionelmc, steve.dower
priority: normal
severity
New submission from Ionel Cristian Mărieș:
I get this:
Traceback (most recent call last):
File
c:\Python27\lib\site-packages\virtualenv\_wheels\pip-7.0.1-py2.py3-none-any.whl\pip\basecommand.py,
line 223, in main
status = self.run(options, args)
File
c:\Python27\lib\site-packages
Ionel Cristian Mărieș added the comment:
Ooops, sorry for the noise, I had some weird breakage in my virtualenv.
--
resolution: - not a bug
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24353
Changes by Ionel Cristian Mărieș cont...@ionelmc.ro:
--
nosy: +ionelmc
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23275
___
___
Python-bugs
Ionel Cristian Mărieș added the comment:
My point was about consistency in descriptor handling, not consistency of
fault (eg: broken everywhere). I don't understand why that's not clear
here.
The big idea here is to harmonize capability checking with descriptor
handling. Justifying breakage
Ionel Cristian Mărieș added the comment:
Also, descriptors are a core mechanism in new-style classes - you can't
have methods without descriptors. Why would you even consider removing
descriptors from the special method lookup if that's part of the object
model design?
On Monday, April 20, 2015
Ionel Cristian Mărieș added the comment:
On Mon, Apr 20, 2015 at 7:02 AM, Raymond Hettinger rep...@bugs.python.org
wrote:
AFAICT, there isn't a real problem here and the API for better-or-worse
has proven to be usable in practice (the callable() API has been around
practically forever
Ionel Cristian Mărieș added the comment:
On Mon, Apr 20, 2015 at 4:50 AM, Eric Snow rep...@bugs.python.org wrote:
We should
simply leave callable alone (and consistent with the other helpers
that inspect the special *capability* of objects).
Which are the other helpers?
Thanks,
-- Ionel
Ionel Cristian Mărieș added the comment:
On Mon, Apr 20, 2015 at 5:42 PM, Raymond Hettinger rep...@bugs.python.org
wrote:
That is clear but also isn't sufficient motivation. The proposed change
is unnecessary and not rooted in real use cases. It is a semantic change
to a long-standing
Ionel Cristian Mărieș added the comment:
I want to address the four main points of criticism in fixing this issue, just
in case it's not clear why I think those lines of thought are wrong:
#1. It's specified/documented, therefore it's intended
The first thing a maintainer does is check
Ionel Cristian Mărieș added the comment:
On Sun, Apr 19, 2015 at 9:01 PM, Eric Snow rep...@bugs.python.org wrote:
Finally, instead of changing callable, why not use a metaclass that does
the right thing? I believe MagicMock does something along those lines.
What would be the right thing
Ionel Cristian Mărieș added the comment:
On Sun, Apr 19, 2015 at 10:01 PM, Ethan Furman rep...@bugs.python.org
wrote:
The right thing, using a meta-class, is to have the meta-class check if
the proxied object is callable, and if so, put in the __call__ function in
the class that is being
Ionel Cristian Mărieș added the comment:
On Sun, Apr 19, 2015 at 10:29 PM, Steven D'Aprano rep...@bugs.python.org
wrote:
This bug report seems to be completely based on a false premise. In the
very first message of this issue, Ionel says:
it return True even if __call__ is actually
Ionel Cristian Mărieș added the comment:
On Mon, Apr 20, 2015 at 2:59 AM, Eric Snow rep...@bugs.python.org wrote:
However, that is consistent across Python and has been this
way for a long time (so there are backward compatibility concerns that
cannot be ignored).
It's not. Did you see
Ionel Cristian Mărieș added the comment:
On Mon, Apr 20, 2015 at 2:59 AM, Eric Snow rep...@bugs.python.org wrote:
It not a problem currently for callable. It is one you are proposing
to introduce. It is one which current users of callable don't have to
worry about.
Were do we draw
Ionel Cristian Mărieș added the comment:
This is exactly analogous to what you are seeing with __call__ and callable().
Your example is incorrect, __next__ is what makes an object iterable but not
what makes an object have an iterator (what __iter__ does).
This correctly characterises
Ionel Cristian Mărieș added the comment:
On Sat, Apr 18, 2015 at 7:23 PM, Ethan Furman rep...@bugs.python.org
wrote:
class GenericProxy:
def __init__(self, proxied):
self.proxied = proxied
# in case proxied is an __iter__ iterator
@property
def
Ionel Cristian Mărieș added the comment:
Turns out I've replied through email, and code got mangled. This is the correct
version:
class GenericProxy:
def __init__(self, proxied):
self.proxied = proxied
@property
def __iter__(self):
if not hasattr(self.proxied
Ionel Cristian Mărieș added the comment:
On Sat, Apr 18, 2015 at 8:35 PM, Christian Heimes rep...@bugs.python.org
wrote:
You also haven't shown that this behavior violates the documentation and
language spec.
How can I show it violates the spec when there's not such thing? :-)
AFAIK
Ionel Cristian Mărieș added the comment:
Christian, it's not clear why you're closing this. You basically just described
the current broken behaviour. That by itself is not a reason enough (it's a
sort of circular argument ;-).
Can you please explain what prevents this to be fixed or how we
Ionel Cristian Mărieș added the comment:
Ethan, those sections you have linked to have nothing to do with special
methods that are descriptors, or behaviour regarding descriptors.
As seen in this example, descriptors are working even for special methods:
class B:
... @property
... def
Ionel Cristian Mărieș added the comment:
Actually it does address it, as AttributeError is very special:
a.__call__
Traceback (most recent call last):
File stdin, line 1, in module
File stdin, line 4, in __call__
AttributeError: go away
hasattr(a, '__call__')
False
Ionel Cristian Mărieș added the comment:
Some more discussions happened here:
https://mail.python.org/pipermail/python-ideas/2015-April/033027.html
So for Christian or Ethan, can you reconsider this issue?
Joe has already kindly provided a patch for this that just does one extra
check
Ionel Cristian Mărieș added the comment:
But somehow defining them with @property works (I guess because @property
is in the class).
IMO, this is the bug and not the callable() behavior.
By the same reasoning we shouldn't be able to use staticmethod or classmethod
for special methods
58 matches
Mail list logo
