[issue40255] Fixing Copy on Writes from reference counting

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

[issue40078] asyncio subprocesses allow pids to be reaped, different behavior than regular subprocesses

Carl Lewin added the comment: Very first time engaging in such a forum. Apologies is advance if I am doing it wrong! Observation: ps -ef shows "Defunct" process until calling script terminates Scenario: equivalent test scripts in BASH, Python 2.7 and 3.6 that: 1. Start a ping

[issue40360] Deprecate lib2to3 (and 2to3) for future removal

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

[issue40360] Deprecate lib2to3 (and 2to3) for future removal

Change by Carl Meyer : -- pull_requests: +18987 pull_request: https://github.com/python/cpython/pull/19663 ___ Python tracker <https://bugs.python.org/issue40

[issue40360] Deprecate lib2to3 (and 2to3) for future removal

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

[issue40360] Deprecate lib2to3 (and 2to3) for future removal

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

[issue40360] Deprecate lib2to3 (and 2to3) for future removal

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&#

[issue40360] Deprecate lib2to3 (and 2to3) for future removal

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

[issue41567] multiprocessing.Pool from concurrent threads failure on 3.9.0rc1

New submission from Carl Drougge : If several threads try to start a multiprocessing.Pool at the same time when no pool has been started before this often fails with an exception like this (the exact import varies): Exception in thread Thread-2: Traceback (most recent call last): File

[issue14444] Virtualenv not portable from Python 2.7.2 to 2.7.3 (os.urandom missing)

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

[issue14444] Virtualenv not portable from Python 2.7.2 to 2.7.3 (os.urandom missing)

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

[issue14444] Virtualenv not portable from Python 2.7.2 to 2.7.3 (os.urandom missing)

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

[issue21156] Consider moving importlib.abc.InspectLoader.source_to_code() to importlib.abc.Loader

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

[issue30533] missing feature in inspect module: getmembers_static

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.

[issue36568] Typo in socket.CAN_RAW_FD_FRAMES library documentation

New submission from Carl Cerecke : https://docs.python.org/3/library/socket.html#socket.CAN_RAW_FD_FRAMES The wording "...however, you one must accept..." doesn't make sense. I think the "you one" should be "your application", but I'm not sure. ---

[issue36568] Typo in socket.CAN_RAW_FD_FRAMES library documentation

Carl Cerecke added the comment: See section 4.1.5 at https://www.kernel.org/doc/Documentation/networking/can.txt -- ___ Python tracker <https://bugs.python.org/issue36

[issue36596] tarfile module considers anything starting with 512 bytes of zero bytes to be a valid tar file

Change by Carl Harris : -- nosy: +hitbox ___ Python tracker <https://bugs.python.org/issue36596> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue31033] Add argument to .cancel() of Task and Future

Change by Carl Meyer : -- nosy: +carljm ___ Python tracker <https://bugs.python.org/issue31033> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33499] Environment variable to set alternate location for pycache tree

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

[issue33501] split existing optimization levels into granular options

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

[issue21145] Add the @cached_property decorator

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

[issue33499] Environment variable to set alternate location for pycache tree

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

[issue33499] Environment variable to set alternate location for pycache tree

Change by Carl Meyer : -- keywords: +patch pull_requests: +6517 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue33499> ___ ___ Python-

[issue33499] Environment variable to set alternate location for pycache tree

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

[issue33499] Environment variable to set alternate location for pycache tree

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

[issue21145] Add the @cached_property decorator

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

[issue33499] Environment variable to set alternate location for pycache tree

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

[issue33499] Environment variable to set alternate location for pycache tree

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

[issue21145] Add the @cached_property decorator

Change by Carl Meyer : -- pull_requests: +6636 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue21145> ___ ___ Python-bugs-list mai

[issue21145] Add the @cached_property decorator

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

[issue33577] remove wrapping of __set_name__ exceptions in RuntimeError

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

[issue21145] Add the @cached_property decorator

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

[issue33577] remove wrapping of __set_name__ exceptions in RuntimeError

Carl Meyer added the comment: Oops, duplicate of issue33576. -- resolution: -> duplicate stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue21145] Add the @cached_property decorator

Carl Meyer added the comment: Oops, never mind; closed mine as dupe. -- ___ Python tracker <https://bugs.python.org/issue21145> ___ ___ Python-bugs-list mailin

[issue33576] Remove exception wrapping from __set_name__ calls

Change by Carl Meyer : -- keywords: +patch pull_requests: +6637 stage: needs patch -> patch review ___ Python tracker <https://bugs.python.org/issue33576> ___ _

[issue33576] Remove exception wrapping from __set_name__ calls

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

[issue33576] Remove exception wrapping from __set_name__ calls

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

[issue33968] os.makedirs and empty string

New submission from Carl Andersson : os.makedirs does not handle the empty string the same way as the os.path.XX functions does. This is (to me) unexpected behaviour, since calls like `os.makedirs(os.path.dirname(filename), exist_ok=True)` raises an exception if `filename` does not contain

[issue33968] os.makedirs and empty string

Carl Andersson added the comment: I can see the point in keeping the behaviour close to the OS-level commands, but the discrepancy between os.mkdir (or os.makedirs) and os.path.dirname is not resolved. I still think that >>> os.makedirs(os.path.dirname(filename), exist_ok=True)

[issue33968] os.makedirs and empty string

Carl Andersson added the comment: That is in essence what I am looking for, yes. As you say, it's not pretty. My opinion is still that if the os.path convention is that '' is the same as '.', this should be respected. -- _

[issue32780] ctypes: memoryview gives incorrect PEP3118 format strings for both packed and unpacked structs

Carl Banks added the comment: I guess I'll weigh in since I was pinged. I agree with the approach in the patch. All the memoryview does is to use the format field verbatim from the underlying buffer, so if the format field is inaccurate then the only thing to do is to fix the o

[issue21145] Add the @cached_property decorator

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

[issue34995] functools.cached_property does not maintain the wrapped method's __isabstractmethod__

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

[issue1346874] httplib simply ignores CONTINUE

Carl Nobile added the comment: I was told some time ago that it was documentation changes. And, if I remember correctly CONTINUE (100) was not ignored, it was actually broken. Data was being read from stdin when a CONTINUE was received and this should never happen based on RFC 2616, because

[issue1346874] httplib simply ignores CONTINUE

Carl Nobile added the comment: Yes, exactly. I was not the one who posted the original bug report, but I found it when I ran into the same problem. I was not exactly sure if the original poster had the same issues as I had. I do know that my fix to the code eliminated some code making the code

[issue1346874] httplib simply ignores CONTINUE

Carl Nobile added the comment: André, As I said I'm not sure if I am fixing the same thing that this bug was originally posted for. However, after looking at my code I realized that I just did a quick work around for my situation and it shouldn't be put into any python release. Thi

[issue15374] venv environment variable should follow the conventions

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

[issue16116] Can not install C extension modules to inside a venv on Python 3.3.0 for Win32

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:

[issue16116] Can not install C extension modules to inside a venv on Python 3.3.0 for Win32

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

[issue16480] pyvenv 3.3 fails to create symlinks for /local/{bin, lib} to /{bin, lib}

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&#

[issue16480] pyvenv 3.3 fails to create symlinks for /local/{bin, lib} to /{bin, lib}

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

[issue19139] In venv, __VENV_NAME__ is the prompt, not the name

Carl Meyer added the comment: Makes sense to me. -- ___ Python tracker <http://bugs.python.org/issue19139> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue7418] hashlib : the names of the different hash algorithms

New submission from Carl Chenet : Hi, The hashlib module could provide a tuple offering the names of the different hash algorithms which are guaranteed to be supported. The expected result: >>> import hashlib >>> hashlib.algorithms ('md5', 'sha1',

[issue7418] hashlib : the names of the different hash algorithms

Carl Chenet added the comment: flox : You're right, sorry about that. Here is a fixed patch. -- Added file: http://bugs.python.org/file15437/algorithms_constant_value_in_hashlib_module.diff ___ Python tracker <http://bugs.python.org/i

[issue7418] hashlib : the names of the different hash algorithms

Changes by Carl Chenet : Removed file: http://bugs.python.org/file15437/algorithms_constant_value_in_hashlib_module.diff ___ Python tracker <http://bugs.python.org/issue7

[issue7418] hashlib : the names of the different hash algorithms

Carl Chenet added the comment: The fixed file : algorithms_constant_attribute_in_hashlib_module_update1.diff -- Added file: http://bugs.python.org/file15438/algorithms_constant_attribute_in_hashlib_module_update1.diff ___ Python tracker <h

[issue7418] hashlib : the names of the different hash algorithms

Carl Chenet added the comment: Hi, Maybe you have some ideas on this patch? I think it could be a nice feature e.g in my app I need to support every hash algorithms available so with optparse module it is possible to write something like : for __hashtype in ('md5', '

[issue5794] pickle/cPickle of recursive tuples create pickles that cPickle can't load

New submission from Carl Witty : When I try to pickle a recursive tuple (that recurses through a list), pickle can load the result but cPickle fails with "unpickling stack overflow". (I just downloaded and built Python 2.6.2 on 64-bit x86 Debian testing to verify this bug; it als

[issue6038] Should collections.Counter check for int?

Carl Johnson added the comment: Sounds like a job for ABCs. -- nosy: +carlj ___ Python tracker <http://bugs.python.org/issue6038> ___ ___ Python-bugs-list mailin

[issue9304] unreproducible example in the memoryview documentation

New submission from Carl Chenet : Hi, In the current documentation at http://docs.python.org/library/stdtypes.html#memoryview, the first example announces : >>> v = memoryview('abcefg') >>> v[1] 'b' >>> v[-1] 'g' >>> v[1

[issue10740] sqlite3 module breaks transactions and potentially corrupts data

Carl George added the comment: While attempting to build a Python 3.6 RPM for RHEL/CentOS 6, I noticed the following warning. *** WARNING: renaming "_sqlite3" since importing it failed: build/lib.linux-i686-3.6-pydebug/_sqlite3.cpython-36dm-i386-linux-gnu.so: undefi

[issue29098] document minimum sqlite version

New submission from Carl George: While attempting to build a Python 3.6 RPM for RHEL/CentOS 6, I noticed the following warning. *** WARNING: renaming "_sqlite3" since importing it failed: build/lib.linux-i686-3.6-pydebug/_sqlite3.cpython-36dm-i386-linux-gnu.so: undefi

[issue27715] call-matcher breaks if a method is mocked with spec=True

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

[issue27715] call-matcher breaks if a method is mocked with spec=True

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

[issue27715] call-matcher breaks if a method is mocked with spec=True

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

[issue27715] call-matcher breaks if a method is mocked with spec=True

Changes by Carl Meyer : Removed file: http://bugs.python.org/file44054/mock-method.example.py ___ Python tracker <http://bugs.python.org/issue27715> ___ ___ Python-bug

[issue27715] call-matcher breaks if a method is mocked with spec=True

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

[issue23453] Opening a stream with tarfile.open() triggers a TypeError: can't concat bytes to str error

New submission from Carl Chenet: I'm trying to use a tar stream to a Python tarfile object but each time I do have a TypeError: can't concat bytes to str error Here is my test: -8<- #!/usr/bin/python3.4 import tarfile import sys tarobj = tarfile.open(mode='r|&#

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Carl Osterwisch added the comment: I need to have an external DLL open and read the named file but this current NamedTemporaryFile implementation prevents that from working on Windows. -- nosy: +Carl Osterwisch ___ Python tracker <h

[issue24385] libpython27.a in python-2.7.10 i386 (windows msi release) contains 64-bit objects

Carl Kleffner added the comment: The most robust way to support a specific mingw-w64 distribution is to copy a python import library generated by this specific toolchain and the provided import library for the corresponding msvcrXX.dll runtime into the libs folder. This has to be performed by

[issue24385] libpython27.a in python-2.7.10 i386 (windows msi release) contains 64-bit objects

Carl Kleffner added the comment: I experienced this behaviour by accident several times. Most likely this is due to inconsistenticies in different binutils and mingw-runtime versions/patches. See i.e. http://article.gmane.org/gmane.comp.gnu.binutils/46799 A robust solution is to exclusively

[issue24429] msvcrt error when embedded

Carl Kleffner added the comment: > Windows itself is the primary user of msvcrt.dll. > A Windows 7 installation has over 1500 DLLs and over > 350 executables in System32 that depend on msvcrt.dll. > Windows developers such as Raymond Chen get a bit annoyed > when projects lin

[issue24651] Mock.assert* API is in user namespace

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

[issue24651] Mock.assert* API is in user namespace

Carl Meyer added the comment: Er, I meant `AttributeError`, of course... -- ___ Python tracker <http://bugs.python.org/issue24651> ___ ___ Python-bugs-list mailin

[issue24651] Mock.assert* API is in user namespace

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

[issue19469] Duplicate namespace package portions (but not on Windows)

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

[issue4709] Mingw-w64 and python on windows x64

Carl Kleffner added the comment: The situation is not THAT bad. You can install a prerelease of mingwpy with pip: pip install -i https://pypi.anaconda.org/carlkl/simple mingwpy or with conda: (thanks to omnia-md) conda install -c https://conda.anaconda.org/omnia mingwpy It is not hosted

[issue28416] defining persistent_id in _pickle.Pickler subclass causes reference cycle

New submission from Carl Witty: On creation, _pickle.Pickler caches any .persistent_id() method defined by a subclass (in the pers_func field of PicklerObject). This causes a reference cycle (pickler -> bound method of pickler -> pickler), so the pickler is held in memory until th

[issue27122] Hang with contextlib.ExitStack and subprocess.Popen (regression)

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 i

[issue28563] Arbitrary code execution in gettext.c2py

New submission from Carl Ekerot: The c2py-function in the gettext module is seriously flawed in many ways due to its use of eval to create a plural function: return eval('lambda n: int(%s)' % plural) My first discovery was that nothing prevents an input plural string that r

[issue28563] Arbitrary code execution in gettext.c2py

Carl Ekerot added the comment: It doesn't solve the case when an identifier or number is used as a function: >>> import os >>> gettext.c2py("n()")(lambda: os.system("sh")) $ 0 >>> gettext.c2py("1()")(0) Tracebac

[issue28563] Arbitrary code execution in gettext.c2py

Carl Ekerot added the comment: Verified gettext.c2py with gettext_c2py.patch applied agains the plural forms actually used in localization, listed over at http://docs.translatehouse.org/projects/localization-guide/en/latest/l10n/pluralforms.html. I tested all of the none-trivial forms, and

[issue28563] Arbitrary code execution in gettext.c2py

Carl Ekerot added the comment: > The gettext module might be vulnerable to f-string attacks It is. See the example in the first comment: gettext.c2py('f"{os.system(\'sh\')}"')(0) This vulnerability seems to be solved in Xiang's patch. The DoS aspect is

[issue28563] Arbitrary code execution in gettext.c2py

Carl Ekerot added the comment: Judging by the code, this seems to be a much more rigid implementation. I've only run the unit tests and some variations of my initial examples, and everything seems to work as intended. Will look at it more closely this afternoon. One thing that caug

[issue28563] Arbitrary code execution in gettext.c2py

Carl Ekerot added the comment: Looks good to me. It behaves as intended on every input I can think of. -- ___ Python tracker <http://bugs.python.org/issue28

[issue21145] Add the @cached_property decorator

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 wher

[issue21145] Add the @cached_property decorator

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

[issue21145] Add the @cached_property decorator

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 not

[issue21145] Add the @cached_property decorator

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 warr

[issue21145] Add the @cached_property decorator

Changes by Carl Meyer : Added file: http://bugs.python.org/file45450/cached_property.diff ___ Python tracker <http://bugs.python.org/issue21145> ___ ___ Python-bugs-list m

[issue21145] Add the @cached_property decorator

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 bl

[issue21145] Add the @cached_property decorator

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 <http://bugs.python.org/is

[issue21145] Add the @cached_property decorator

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 computati

[issue21145] Add the @cached_property decorator

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 <http://bugs.pyt

[issue25731] Assigning and deleting __new__ attr on the class does not allow to create instances of this class

Changes by Carl Dunham : -- nosy: +Carl Dunham ___ Python tracker <http://bugs.python.org/issue25731> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue1433] marshal roundtripping for unicode

New submission from Carl Friedrich Bolz: Marshal does not round-trip unicode surrogate pairs for wide unicode-builds: marshal.loads(marshal.dumps(u"\ud800\udc00")) == u'\U0001' This is very annoying, because the size of unicode constants differs between when you run a

[issue13340] list.index does not accept None as start or stop

New submission from Carl Friedrich Bolz : The list.index method does not accept None as start and stop, which makes the error message quite confusing: >>> [1, 2, 3].index(2, None, None) Traceback (most recent call last): File "", line 1, in TypeError: slice indices must

[issue12422] When deepcopying, don't store immutable objects in the memo dict

Changes by Carl Friedrich Bolz : -- nosy: +Carl.Friedrich.Bolz ___ Python tracker <http://bugs.python.org/issue12422> ___ ___ Python-bugs-list mailing list Unsub

[issue11477] Bug in code dispatching based on internal slots

Changes by Carl Friedrich Bolz : -- nosy: +cfbolz ___ Python tracker <http://bugs.python.org/issue11477> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue11926] help("keywords") returns incomplete list of keywords

New submission from Carl M. Johnson : In Python 3.2, help("keywords") returns the following: Here is a list of the Python keywords. Enter any keyword to get more help. and elifimport raise as else

<    1   2   3   >