Carl Meyer added the comment:
Thanks for the extended example.
I think in order for this example to answer the question I asked, a few more
assumptions should be made explicit:
1) Either `spam_var` and/or `eggs_var` are frequently re-bound to new values in
a hot code path somewhere. (Given
Carl Meyer added the comment:
> There should not be much of a slowdown for this code when watching `CONST`:
How and when (and based on what data?) would the adaptive interpreter make the
decision that for this code sample the key `CONST`, but not the key `var`,
should be watc
Carl Meyer added the comment:
I've updated the PR to split `PyDict_EVENT_MODIFIED` into separate
`PyDict_EVENT_ADDED`, `PyDict_EVENT_MODIFIED`, and `PyDict_EVENT_DELETED` event
types. This allows callbacks only interested in e.g. added keys (case #2) to
more easily and cheaply skip
Carl Meyer added the comment:
Thanks for outlining the use cases. They make sense.
The current PR provides a flexible generic API that fully supports all three of
those use cases (use cases 2 and 3 are strict subsets of use case 1.) Since the
callback is called before the dict is modified
Carl Meyer added the comment:
> have you considered watching dict keys rather than whole dicts?
Just realized that I misunderstood this suggestion; you don't mean per-key
watching necessarily, you just mean _not_ notifying on dict values changes. Now
I understand better how that conne
Carl Meyer added the comment:
Hi Dennis, thanks for the questions!
> A curiosity: have you considered watching dict keys rather than whole dicts?
There's a bit of discussion of this above. A core requirement is to avoid any
memory overhead and minimize CPU overhead on unwatched di
Carl Meyer added the comment:
Draft PR is up for consideration. Perf data in
https://gist.github.com/carljm/987a7032ed851a5fe145524128bdb67a
Overall it seems like the base implementation is perf neutral -- maybe a slight
impact on the pickle benchmarks? With all module global dicts
Change by Carl Meyer :
--
keywords: +patch
pull_requests: +29891
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/31787
___
Python tracker
<https://bugs.python.org/issu
Carl Meyer added the comment:
Thanks for the feedback!
> Why so coarse?
Simplicity of implementation is a strong advantage, all else equal :) And the
coarse version is a) at least somewhat proven as useful and usable already by
Cinder / Cinder JIT, and b) clearly doable without introduc
Carl Meyer added the comment:
> Could we (or others) end up with unguarded stale caches if some buggy
> extension forgets to chain the calls correctly?
Yes. I can really go either way on this. I initially opted for simplicity in
the core support at the cost of asking a bit more of c
Carl Meyer added the comment:
Thanks gps! Working on a PR and will collect pyperformance data as well.
We haven't observed any issues in Cinder with the callback just being called at
shutdown, too, but if there are problems with that it should be possible to
just have CPython clear
Change by Carl Meyer :
--
title: add support for watching writes to selecting dictionaries -> add support
for watching writes to selected dictionaries
___
Python tracker
<https://bugs.python.org/issu
New submission from Carl Meyer :
CPython extensions providing optimized execution of Python bytecode (e.g. the
Cinder JIT), or even CPython itself (e.g. the faster-cpython project) may wish
to inline-cache access to frequently-read and rarely-changed namespaces, e.g.
module globals. Rather
Carl Meyer added the comment:
Good idea to check with the PEP authors.
I don’t think allowing both ClassVar and Final in dataclasses requires general
intersection types. Neither ClassVar nor Final are real types; they aren’t part
of the type of the value. They are more like special
Carl Meyer added the comment:
> Are Final default_factory fields real fields or pseudo-fields? (i.e. are they
> returned by dataclasses.fields()?)
They are real fields, returned by `dataclasses.fields()`.
In my opinion, the behavior change proposed in this bug is a bad idea all
Carl Meyer added the comment:
Created a PR that fixes this by being more consistent in how urllib wraps
network errors. If there are backward-compatibility concerns with this change,
another option could be some really ugly regex-matching code in
`test.support.transient_internet
Change by Carl Meyer :
--
keywords: +patch
pull_requests: +23699
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/24938
___
Python tracker
<https://bugs.python.org/issu
New submission from Carl Meyer :
In general it seems the CPython test suite takes care to skip instead of
failing networked tests when the network is unavailable (c.f.
`support.transient_internet` test helper).
In this case of the 5 FTP tests in `test_urllib2net` (that is, `test_ftp
Change by Carl Meyer :
--
title: some tests in test_urllib2net fail instead of skipping on unreachable
network -> ftp tests in test_urllib2net fail instead of skipping on unreachable
network
___
Python tracker
<https://bugs.python.org/issu
Change by Carl Meyer :
--
keywords: +patch
pull_requests: +23697
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/24937
___
Python tracker
<https://bugs.python.org/issu
New submission from Carl Meyer :
In general it seems the CPython test suite takes care to not fail if the
network is unreachable, but `test_timeout_connect_ex` fails because the result
code of the connection is checked without any exception being raised that would
reach
Carl Meyer added the comment:
> Coul you please add a what's new entry for this change?
The committed change already included an entry in NEWS. Is a "What's New" entry
something different?
> I don't understand why there is a PendingDeprecationWarning and not a
> Deprecat
Carl Meyer added the comment:
Right, although I think it still makes sense to link both LibCST and parso
since they provide different levels of abstraction that would be suitable for
different types of tools (e.g. I would rather write an auto-formatter on top of
parso, because LibCST's
Carl Meyer added the comment:
@gregory.p.smith
What do you think about the question I raised above about how to make this
deprecation visible to users of the 2to3 CLI tool, assuming the plan is to
remove both?
--
___
Python tracker
<ht
Carl Meyer added the comment:
I opened a PR. It deprecates the lib2to3 library to discourage future use of it
for Python3, but not the 2to3 tool. This of course means that the lib2to3
module will in practice stick around in the stdlib as long as 2to3 is still
bundled with Python.
It seems
Change by Carl Meyer :
--
pull_requests: +18987
pull_request: https://github.com/python/cpython/pull/19663
___
Python tracker
<https://bugs.python.org/issue40
Carl Meyer added the comment:
I volunteered in the python-dev thread to write a patch to the docs clarifying
future status of lib2to3; happy to include the PendingDeprecationWarning as
well.
Re linking to alternatives, we want to make sure we link to alternatives that
are committed
Carl Meyer added the comment:
Makes sense. Yes, caution is required about what code runs before fork, but
forkserver’s solution for that would be a non-starter for us, since it would
ensure that we can share no basically no memory at all between worker processes
Carl Meyer added the comment:
> I would be interested to hear the answer to Antoine's question which is
> basically: why not using the multiprocessing fork server?
Concretely, because for a long time we have used the uWSGI application server
and it manages forking worker processes
Carl Meyer added the comment:
> Is it a common use case to load big data and then fork to use preloaded data?
A lot of the "big data" in question here is simply lots of Python
module/class/code objects resulting from importing lots of Python modules.
And yes, this &qu
Carl Meyer added the comment:
I think the concerns about "perfect" behavior in corner cases are in general
irrelevant here.
In the scenarios where this optimization matters, there is no quantitative
change that occurs at 100% coverage. Preventing 99% of CoW is 99% as good as
prev
Carl Meyer added the comment:
> This may break the garbage collector algorithm that relies on the balance
> between strong references between objects and its reference count to do the
> calculation of the isolated cycles.
I don't think it really breaks anything. Wha
Carl Meyer added the comment:
> An immortalized object will never start participating in reference counting
> again after it is immortalized.
Well, "passed to an extension compiled with no-immortal headers" is an
exception to this.
But for the "not GC tracked but lat
Carl Meyer added the comment:
> Anything that is touched by the immortal object will be leaked. This can also
> happen in obscure ways if reference cycles are created.
I think this is simply expected behavior if you choose to create immortal
objects, and not really an issue. How cou
New submission from Carl Meyer :
Currently the "symtable entry" extension type (PySTEntry_Type) defined in
`Python/symtable.c` defines no `tp_new` or `tp_init`, making it impossible to
create instances of this type from Python code.
I have a use case for pickling symbol table
Carl Meyer added the comment:
Making `source_to_code` a staticmethod on the `InspectLoader` abc but not in
the `importlib.machinery` implementation causes awkwardness for anyone trying
to inherit `SourceFileLoader` and override `source_to_code` in typechecked
code, since typeshed assumes
Change by Carl Meyer :
--
nosy: +carljm
___
Python tracker
<https://bugs.python.org/issue31033>
___
___
Python-bugs-list mailing list
Unsubscribe:
Carl Meyer added the comment:
FWIW, it seems to me (author of `cached_property` patch) that while just using
`@property` on the abstract method plus a comment is a reasonable and
functional workaround that sacrifices only a small documentation value, there's
no reason why `@cached_property
Carl Meyer added the comment:
Thanks everyone for the thoughtful and careful reviews! Patch is much improved
from where it started. And thanks Nick for merging.
--
___
Python tracker
<https://bugs.python.org/issue21
Carl Meyer <c...@oddbird.net> added the comment:
Awkwardly, the motivating use case in issue21145 is a TypeError that we wanted
to raise within __set_name__, and not have replaced. It feels a little ugly to
special case TypeError this way.
I like the _PyErr_TrySetFromCaus
Carl Meyer <c...@oddbird.net> added the comment:
Nick, I think the reason this exception wrapping was added is because the stack
trace for these exceptions is currently a bit lacking. The "caller" for the
`__set_name__` function is the `class` line for the class containing
Change by Carl Meyer <c...@oddbird.net>:
--
keywords: +patch
pull_requests: +6637
stage: needs patch -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Carl Meyer <c...@oddbird.net> added the comment:
Oops, never mind; closed mine as dupe.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Carl Meyer <c...@oddbird.net> added the comment:
Oops, duplicate of issue33576.
--
resolution: -> duplicate
stage: -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<https://bu
Carl Meyer <c...@oddbird.net> added the comment:
Makes sense to me. Sounds like a separate issue and PR; I filed issue33577 and
will work on a patch.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
New submission from Carl Meyer <c...@oddbird.net>:
Per Nick Coghlan in discussion on issue21145:
"I think it would make sense to remove the exception wrapping from the
__set_name__ calls - I don't think we're improving the ease of understanding
the tracebacks by converting
Carl Meyer <c...@oddbird.net> added the comment:
Sent a PR with the patch.
Nick, I tried your `__set_name__` proposal to get an earlier error in case of
an object with slots, but it has the downside that Python seems to always raise
a new chained exception if `__set_name__` rais
Change by Carl Meyer <c...@oddbird.net>:
--
pull_requests: +6636
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Carl Meyer <c...@oddbird.net> added the comment:
Cool, thanks for the pointer on -X. PR is updated with `-X bytecode_path=PATH`;
don't think it's critical to have it, but it wasn't that hard to add.
--
___
Python tracker <rep...@bugs.p
Carl Meyer <c...@oddbird.net> added the comment:
Can we have a named -X option that also takes a parameter? I don't see any
existing examples of that. This option needs to take the path where bytecode
should be written.
Are there strong use-cases for having a CLI arg for this? I don'
Carl Meyer <c...@oddbird.net> added the comment:
> a way to invalidate or clear the cache
This is already supported by the simple implementation in the patch, it's
spelled `del obj.the_cached_property`.
> mock patching the underlying function for testing
This is easy to do with
Carl Meyer <c...@oddbird.net> added the comment:
> a system-wide environment variable
Environment variables aren't system-wide, they are per-process (though they can
be inherited by child processes).
--
___
Python tracker <rep...@bug
Carl Meyer <c...@oddbird.net> added the comment:
Environment variable seems to make a bit more sense for this, since it's not
per-invocation; there's no point writing bytecode cache to a particular
location unless the next invocation reads the cache from there.
Our use case in
Change by Carl Meyer <c...@oddbird.net>:
--
keywords: +patch
pull_requests: +6517
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Carl Meyer <c...@oddbird.net> added the comment:
Per vstinner Python prefers to not have underscores in environment variable
names, for historical reasons. So I'm using `PYTHONBYTECODEPATH` as the env var.
Other open questions:
1) Does there need to be a corresponding CLI flag, or is e
Carl Meyer <c...@oddbird.net> added the comment:
> I don't think it makes sense to try to make cached_property itself work
> implicitly with both normal attributes and slot entries - instead,
> cached_property can handle the common case as simply and efficiently
New submission from Carl Meyer <c...@oddbird.net>:
It doesn't make sense for e.g. docstring-stripping to necessarily imply
assert-stripping. These are totally separate options, useful for separate
reasons, but currently tied together in the `-O` option.
This is not just a theoretical p
New submission from Carl Meyer <c...@oddbird.net>:
We would like to set an environment variable that would cause Python to read
and write `__pycache__` directories from a separate location on the filesystem
(outside the source code tree). We have two reasons for this:
1. In our devel
New submission from Carl Meyer:
The inspect module contains a getattr_static() function, for accessing an
arbitrary attribute on a Python object without risking descriptor or
__getattr__ code execution. This is useful for introspection tools that don't
want to trigger any side effects
Carl Meyer added the comment:
Speaking of this hypothetical C version, what's the current policy on shipping
stdlib C code that can't be emulated in pure Python? (I'm thinking of e.g.
PyPy).
--
___
Python tracker <rep...@bugs.python.org>
Carl Meyer added the comment:
Thanks, Danny. Uploaded a version of the patch that adds thread-safety (with a
test). Unlike in your lib, I didn't make it a separate version of the
decorator; since the lock is not checked on cached access, its slight overhead
on the initial computation
Carl Meyer added the comment:
(We wouldn't be able to match the set/delete behavior in a slots-supporting
fallback implemented in Python.)
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Carl Meyer added the comment:
Uploaded a patch updated per Nick's comment.
Not opposed to waiting to see if someone is motivated to implement a version in
C that supports __slots__, but if that doesn't happen by the Python 3.7 feature
deadline, I don't think it should block this proven
Changes by Carl Meyer <c...@dirtcircle.com>:
Added file: http://bugs.python.org/file45450/cached_property.diff
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Carl Meyer added the comment:
Makes sense, Nick, thanks. The current error message for that situation is
pretty cryptic indeed. I'll update the patch with your suggestion. Do you think
a documentation note about slots is also warranted
Carl Meyer added the comment:
How do you propose that slots should be supported?
Part of the value of cached_property is that cached access is a normal Python
attribute access with no function call overhead. I am not interested in adding
support for slots if it loses that benefit. I would
Carl Meyer added the comment:
Attaching a patch with the simplest version of cached_property (tehnique is not
original, similar code is found in Django, Bottle, Flask, the cached_property
lib, and many other places).
--
components: +Library (Lib)
keywords: +patch
versions: +Python 3.7
Carl Meyer added the comment:
I've used the cached_property pattern across many different projects, and never
yet wanted a TTL. The simple "cache for the lifetime of the instance" behavior
is easy to implement, easy to understand, and useful for a wide range of
scenarios where
Carl Meyer added the comment:
Greg, there was also a (different!) typo of the issue number in the code
comment committed with this fix; that typo hasn't been fixed. Sent me on quite
the chase looking for this bug. (I tracked down the bug independently, then
wasn't able to repro it on trunk
Carl Meyer added the comment:
`hg clean --all` resolved the compilation issues; confirmed that
https://hg.python.org/cpython/rev/b888c9043566/ is at fault.
Also, the exception trace I provided above looks wrong; it must be from when I
was messing about with `autospec=True` or passing
Changes by Carl Meyer <c...@dirtcircle.com>:
Removed file: http://bugs.python.org/file44054/mock-method.example.py
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Carl Meyer added the comment:
It seems likely that this regression originated with
https://hg.python.org/cpython/rev/b888c9043566/ (can't confirm via bisection as
the commits around that time fail to compile for me).
--
nosy: +michael.foord, pitrou
Carl Meyer added the comment:
(This bug is also present in Python 3.4.4.)
--
type: -> crash
versions: +Python 3.4
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.or
New submission from Carl Meyer:
When constructing call-matchers to match expected vs actual calls, if
`spec=True` was used when patching a function, mock attempts to bind the
recorded (and expected) call args to the function signature. But if a method
was mocked, the signature includes `self
Carl Meyer added the comment:
FWIW, this bug has bitten Django; see
https://code.djangoproject.com/ticket/25246
We can easily work around it for future versions, but we have code in released
versions that assumed that `__path__` wouldn't contain dupes; it causes us to
raise an error
Carl Meyer added the comment:
FWIW, my assumption was that the typical usage pattern would be `import mock`
rather than separate imports of all the assertions, so I don't think there'd
really be an increase in what users need to know about or import. (They already
need to know about
Carl Meyer added the comment:
Er, I meant `AttributeError`, of course...
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24651
___
___
Python
Carl Meyer added the comment:
As a frequent and long-time user of mock, the `assert_*` methods being on the
mock object itself has always struck me as an unfortunate wart on an otherwise
great library. The change to raise `AssertionError` on `assert_*` and
`assret_*` feels like piling an ugly
Carl Meyer added the comment:
Makes sense to me.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19139
___
___
Python-bugs-list mailing list
Carl Meyer added the comment:
What OS are you on, Marco?
It looks to me like pyvenv probably does need the same hack as virtualenv here,
to deal with OSes who set posix_local as the default installation scheme.
--
___
Python tracker rep
Carl Meyer added the comment:
Here is the bug filed against virtualenv that led to the addition of the local/
directory: https://github.com/pypa/virtualenv/issues/118
As Vinay pointed out, the original fix was later modified to be friendlier to
tools that dislike recursive symlinks.
That's
Carl Meyer added the comment:
On cursory inspection, I agree that this is precisely what the if win32 block
in `virtualenv_embedded/distutils-init.py` is intended to fix, and it seems to
me the correct fix is likely to just make the equivalent fix directly in
distutils: change
Carl Meyer added the comment:
(Actually, to match virtualenv's fix it should add the paths based on both
exec_prefix and base_exec_prefix, if they are different.)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16116
Carl Meyer c...@dirtcircle.com added the comment:
Yes, there are a number of third-party utility packages (and many, many e.g.
personal custom bash prompts) that check the value of the $VIRTUAL_ENV variable
to detect whether one is currently active, and display its name. Unless there's
Carl Meyer c...@dirtcircle.com added the comment:
Alternatively, the conditional definition of urandom in os.py (removed in
http://hg.python.org/cpython/rev/a0f43f4481e0#l7.1) could be reintroduced,
allowing the new stdlib to be used with older interpreters. (Thanks to Dave
Malcolm
Carl Meyer c...@dirtcircle.com added the comment:
There's no question that this is a case of virtualenv allowing users to do
something that's not supported.
Nonetheless, virtualenv is very widely used, and in practice it does not break
more often. This, however, will break for lots of users
Carl Meyer c...@dirtcircle.com added the comment:
I'd been thinking the escape the security fix argument didn't apply, because
the security fix requires opt-in anyway and the -R flag would fail immediately
on a non-updated virtualenv.
But there is also the environment variable. It is quite
Carl Meyer c...@dirtcircle.com added the comment:
Here's an example real-world case where the only solution I could find was to
simply avoid non-ASCII characters entirely (which is obviously not a real
solution): https://github.com/pypa/virtualenv/issues/201#issuecomment-3145690
distutils
New submission from Carl Meyer c...@dirtcircle.com:
If the test suite is run with PYTHONNOUSERSITE=true, the test_s_option test in
test_site fails, because it implicitly assumes that site.ENABLE_USER_SITE is
True and that site.USER_SITE should unconditionally be in sys.path
Carl Meyer c...@dirtcircle.com added the comment:
Added a patch implementing my proposed fix.
--
hgrepos: +87
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13304
Changes by Carl Meyer c...@dirtcircle.com:
--
keywords: +patch
Added file: http://bugs.python.org/file23575/cea40c2d7323.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13304
Changes by Carl Meyer c...@dirtcircle.com:
Removed file: http://bugs.python.org/file23575/cea40c2d7323.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13304
Changes by Carl Meyer c...@dirtcircle.com:
Added file: http://bugs.python.org/file23576/d851c64c745a.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13304
Carl Meyer c...@dirtcircle.com added the comment:
This is what I proposed earlier: we’d need to record all directories that
would have been created, but I’m not sure if it will be possible. For
example, if one uses --prefix /tmp/usr and pysetup install creates /tmp/usr,
/tmp/usr/lib
Carl Meyer c...@dirtcircle.com added the comment:
Carl: Can you tell us how pip removes directories?
In short - pip would _love_ to have directories recorded as well as files,
exactly as Vinay has proposed. We don't have that info (even the distutils
--record option currently doesn't record
New submission from Carl Meyer c...@dirtcircle.com:
As discussed at
http://groups.google.com/group/the-fellowship-of-the-packaging/browse_frm/thread/3b7a8ddd307d1020
, distutils2 should not allow a distribution to install files into a top-level
package that is already installed from
Carl Meyer c...@dirtcircle.com added the comment:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Éric Araujo mer...@netwok.org added the comment:
[Carl]
there's an implicit assumption that a .pth file is the most likely
strategy.
If you have other ideas, please share them.
No, I think
Carl Meyer c...@dirtcircle.com added the comment:
I don't really think the invalid PEP 376 issue is a problem: PEP
376 describes the metadata for installed distributions; it has
nothing to say about built metadata for a distribution which has not
yet been installed.
The problem
Carl Meyer c...@dirtcircle.com added the comment:
Ah, higery’s code already has an answer for me: it writes *two* paths in the
.pth file, one to the build dir (so that .dist-info is found) and one to the
modules root (for modules, built in place). Anyone sees a problem
Carl Meyer c...@dirtcircle.com added the comment:
I’ve reviewed the last patch. It looks like the code only installs
to the global site-packages, and there is no support to install to
the user site-packages or to another arbitrary location.
On Windows, normal users seem to be able
1 - 100 of 114 matches
Mail list logo
