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
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
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 clea
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 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
New submission from Carl Meyer :
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 a different distribution
Carl Meyer 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 dire
Carl Meyer 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,
New submission from Carl Meyer :
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.
This is a practical problem in the
Carl Meyer added the comment:
Added a patch implementing my proposed fix.
--
hgrepos: +87
___
Python tracker
<http://bugs.python.org/issue13304>
___
___
Pytho
Changes by Carl Meyer :
--
keywords: +patch
Added file: http://bugs.python.org/file23575/cea40c2d7323.diff
___
Python tracker
<http://bugs.python.org/issue13
Changes by Carl Meyer :
Removed file: http://bugs.python.org/file23575/cea40c2d7323.diff
___
Python tracker
<http://bugs.python.org/issue13304>
___
___
Python-bugs-list m
Changes by Carl Meyer :
Added file: http://bugs.python.org/file23576/d851c64c745a.diff
___
Python tracker
<http://bugs.python.org/issue13304>
___
___
Python-bugs-list m
Carl Meyer 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/distribute re
Carl Meyer added the comment:
Can someone post a link here to the page of use cases that Michael just
reviewed? I think the link came through on the Fellowship mailing list, but I'm
not quickly finding it...
--
___
Python tracker
Carl Meyer added the comment:
On 07/11/2011 09:17 AM, Michael Mulich wrote:
> * Cases 2, 3, 5 and 6 are strongly related. I'd suggest you condense them
> into a single use case. I agree with case 2 and 6 most, but have questions:
> ** Why wouldn't one simply use a virtualenv
Carl Meyer added the comment:
You guys are more familiar with the codebase than I am, but it seems to me that
the RECORD file should clearly either be not present or empty when metadata has
been built but not yet installed. I don't really think the "invalid PEP 376"
issue is
Carl Meyer 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 instal
Carl Meyer 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 with that?
> (For
Carl Meyer 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
Carl Meyer added the comment:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> Éric Araujo 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 th
Changes by Carl Meyer :
--
nosy: +carljm
___
Python tracker
<http://bugs.python.org/issue9878>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.pyth
New submission from Carl Meyer :
If python is run with the -S flag, that declares the intent of the user to not
have site-specific additions to sys.path.
However, some code in that process may have a legitimate need for a function
defined in site.py - for instance, addsitedir. But the act of
Changes by Carl Meyer :
--
keywords: +patch
Added file: http://bugs.python.org/file21274/87df1d37c88e.diff
___
Python tracker
<http://bugs.python.org/issue11
Carl Meyer added the comment:
Adding a test is easier said than done. The behavior change here depends on
python being run with -S. Currently test_site skips itself if the test suite is
run with -S, and if I remove that skip it crashes under -S.
Options as I see it:
1. Declare this one
New submission from Carl Meyer :
By opening up pcbuild.sln in VS2008 Express, I was able to successfully build
python and pythonw, but when I tried to build bdist_wininst it failed with
"Fatal Error RC1015: cannot open include file afxres.h"
Googling turned up a number of comments
Carl Meyer added the comment:
Added documentation to Doc/library/site.rst and Misc/NEWS.
--
hgrepos: +5
___
Python tracker
<http://bugs.python.org/issue11
Changes by Carl Meyer :
Added file: http://bugs.python.org/file21327/ebe5760afa08.diff
___
Python tracker
<http://bugs.python.org/issue11591>
___
___
Python-bugs-list m
Carl Meyer added the comment:
> Did you have to manually click “Create Patch” to make roundup generate it?
Yes - the first time too.
> Did you try first to click on the button of the existing repo before adding a
> new repo entry?
That would probably have worked fine. The "
Changes by Carl Meyer :
--
nosy: +carljm
___
Python tracker
<http://bugs.python.org/issue6087>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.pyth
New submission from Carl Meyer :
The opening paragraph of the "lifecycle of a patch" devguide page contains a
confusing parenthetical aside implying that an "svn-like" workflow would mean
never *saving* anything to your working copy and using "hg diff" to genera
New submission from Carl Meyer:
Both urllib and urllib2 call urllib.unquote() multiple times on data in
the userinfo section of an FTP URL. One call occurs at the end of the
urllib.splituser() function. In urllib, the other call appears in
URLOpener.open_ftp(). In urllib2, the other two occur
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:
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
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 unwatch
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 con
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:
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
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 watched in
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
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
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 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: +23699
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/24938
___
Python tracker
<https://bugs.python.org/issu
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
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
aroun
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
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 tables (as
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
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:
> 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. What happe
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:
> 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 "
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 proce
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 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 to
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 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
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:
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&#
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
Carl Meyer 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 for pointing this out.) This
Carl Meyer 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 us
Carl Meyer 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
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
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.
Change by Carl Meyer :
--
nosy: +carljm
___
Python tracker
<https://bugs.python.org/issue31033>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Carl Meyer :
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 development setup (with a
New submission from Carl Meyer :
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 problem; at work we
Carl Meyer 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 as
> possible, and the cached
Carl Meyer 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 env-var-only
suffi
Change by Carl Meyer :
--
keywords: +patch
pull_requests: +6517
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue33499>
___
___
Python-
Carl Meyer 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 includes a webserver pr
Carl Meyer 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
<https://bugs.python.org
Carl Meyer 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 the current implemen
Carl Meyer 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't mind
Carl Meyer 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
<https://bugs.pyt
Change by Carl Meyer :
--
pull_requests: +6636
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue21145>
___
___
Python-bugs-list mai
Carl Meyer 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__` raises any exception. So instead of
New submission from Carl Meyer :
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 everything to a gener
Carl Meyer 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
<https://bugs.python.org/issue21
Carl Meyer added the comment:
Oops, duplicate of issue33576.
--
resolution: -> duplicate
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Carl Meyer added the comment:
Oops, never mind; closed mine as dupe.
--
___
Python tracker
<https://bugs.python.org/issue21145>
___
___
Python-bugs-list mailin
Change by Carl Meyer :
--
keywords: +patch
pull_requests: +6637
stage: needs patch -> patch review
___
Python tracker
<https://bugs.python.org/issue33576>
___
_
Carl Meyer 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 the
descriptors.
For
Carl Meyer 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_TrySetFromCause idea. That function is a bit ugly
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 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_pro
Carl Meyer 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
an overriding reaso
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:
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
<http://bugs.python.org/is
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&#
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
<h
Carl Meyer added the comment:
Makes sense to me.
--
___
Python tracker
<http://bugs.python.org/issue19139>
___
___
Python-bugs-list mailing list
Unsubscribe:
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:
(This bug is also present in Python 3.4.4.)
--
type: -> crash
versions: +Python 3.4
___
Python tracker
<http://bugs.python.org/issu
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, p
Changes by Carl Meyer :
Removed file: http://bugs.python.org/file44054/mock-method.example.py
___
Python tracker
<http://bugs.python.org/issue27715>
___
___
Python-bug
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 in the
1 - 100 of 114 matches
Mail list logo
