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.g
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", "copyright
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 s
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 pt
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>
___
___
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 fro
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 tr
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:/
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 subproc
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 updat
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ș added the comment:
Alright, now it makes sense. Thank you for writing a thoughtful response.
--
___
Python tracker
<https://bugs.python.org/issue23
Ionel Cristian Mărieș 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 -> o
Ionel Cristian Mărieș 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
disadvantages of not fixing this, so I
Ionel Cristian Mărieș added the comment:
Okay ... is anyone interested in helping with this (reviewing drafts)? Who
would be the BDFL?
--
___
Python tracker
<http://bugs.python.org/issue23
Ionel Cristian Mărieș added the comment:
On Mon, May 23, 2016 at 11:04 PM, Ethan Furman
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, not issubclass. I can ex
Ionel Cristian Mărieș added the comment:
On Mon, May 23, 2016 at 9:34 PM, Ethan Furman
wrote:
> "Add proxy support to builtins" and should address such things as
> callable, issubclass, and whatever else is is appropriate.
As previously stated this builtin is the only one not
Changes by Ionel Cristian Mărieș :
Added file: http://bugs.python.org/file42957/callable2.diff
___
Python tracker
<http://bugs.python.org/issue23990>
___
___
Python-bug
Ionel Cristian Mărieș added the comment:
On Mon, Apr 20, 2015 at 5:08 PM, Eric Snow 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 types depending on if the
Changes by Ionel Cristian Mărieș :
--
nosy: +ionelmc
___
Python tracker
<http://bugs.python.org/issue19072>
___
___
Python-bugs-list mailing list
Unsubscribe:
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 valu
Changes by Ionel Cristian Mărieș :
--
nosy: +ionelmc
___
Python tracker
<http://bugs.python.org/issue26060>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Ionel Cristian Mărieș :
--
nosy: +ionelmc
___
Python tracker
<http://bugs.python.org/issue25920>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Ionel Cristian Mărieș :
--
nosy: +ionelmc
___
Python tracker
<http://bugs.python.org/issue16500>
___
___
Python-bugs-list mailing list
Unsubscribe:
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 i
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
<http://bugs.python.org/i
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\li
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
Changes by Ionel Cristian Mărieș :
--
nosy: +ionelmc
___
Python tracker
<http://bugs.python.org/issue23275>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ionel Cristian Mărieș added the comment:
On Mon, Apr 20, 2015 at 5:42 PM, Raymond Hettinger
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 v
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, Apri
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 b
Ionel Cristian Mărieș added the comment:
On Mon, Apr 20, 2015 at 7:02 AM, Raymond Hettinger
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 and
Ionel Cristian Mărieș added the comment:
On Mon, Apr 20, 2015 at 4:50 AM, Eric Snow 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 Cristian Mărieș added the comment:
On Mon, Apr 20, 2015 at 2:59 AM, Eric Snow 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.
>
> >
> >
Ionel Cristian Mărieș added the comment:
On Mon, Apr 20, 2015 at 2:59 AM, Eric Snow 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:
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 mai
Ionel Cristian Mărieș added the comment:
On Sun, Apr 19, 2015 at 10:29 PM, Steven D'Aprano
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 an
Ionel Cristian Mărieș added the comment:
On Sun, Apr 19, 2015 at 10:01 PM, Ethan Furman
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 b
Ionel Cristian Mărieș added the comment:
On Sun, Apr 19, 2015 at 9:01 PM, Eric Snow 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 Sat, Apr 18, 2015 at 8:35 PM, Christian Heimes
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? :-
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.pr
Ionel Cristian Mărieș added the comment:
On Sat, Apr 18, 2015 at 7:23 PM, Ethan Furman
wrote:
>
> class GenericProxy:
> def __init__(self, proxied):
> self.proxied = proxied
> # in case proxied is an __iter__ iterator
> @property
>
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:
Actually it does address it, as AttributeError is very special:
>>> a.__call__
Traceback (most recent call last):
File "", line 1, in
File "", line 4, in __call__
AttributeError: go away
>
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 clas
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. It
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
Ionel Cristian Mărieș added the comment:
The docs do not explain that the check is performed against type(a). Nor that
makes any sense - it's not very explicit.
AFAIK Python doesn't have any specification, the behaviour is defined by
cpython implementation, and I hope that you re
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
59 matches
Mail list logo
