[issue46896] add support for watching writes to selected dictionaries

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

[issue46896] add support for watching writes to selected dictionaries

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

[issue46896] add support for watching writes to selected dictionaries

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

[issue46896] add support for watching writes to selected dictionaries

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

[issue46896] add support for watching writes to selected dictionaries

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

[issue46896] add support for watching writes to selected dictionaries

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

[issue46896] add support for watching writes to selected dictionaries

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

[issue46896] add support for watching writes to selected dictionaries

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

[issue46896] add support for watching writes to selected dictionaries

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

[issue46896] add support for watching writes to selected dictionaries

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

[issue46896] add support for watching writes to selected dictionaries

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

[issue46896] add support for watching writes to selected dictionaries

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

[issue46896] add support for watching writes to selecting dictionaries

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

[issue45384] Accept Final as indicating ClassVar for dataclass

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

[issue45384] Accept Final as indicating ClassVar for dataclass

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

[issue43564] ftp tests in test_urllib2net fail instead of skipping on unreachable network

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

[issue43564] ftp tests in test_urllib2net fail instead of skipping on unreachable network

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

[issue43564] some tests in test_urllib2net fail instead of skipping on unreachable network

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

[issue43564] ftp tests in test_urllib2net fail instead of skipping on unreachable network

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

[issue43562] test_ssl.NetworkedTests.test_timeout_connect_ex fails if network is unreachable

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

[issue43562] test_ssl.NetworkedTests.test_timeout_connect_ex fails if network is unreachable

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

[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 > Deprecat

[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's

[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: 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

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

[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

[issue40255] Fixing Copy on Writes from reference counting

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

[issue40255] Fixing Copy on Writes from reference counting

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

[issue40255] Fixing Copy on Writes from reference counting

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

[issue40255] Fixing Copy on Writes from reference counting

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

[issue40255] Fixing Copy on Writes from reference counting

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

[issue40255] Fixing Copy on Writes from reference counting

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

[issue39428] allow creation of "symtable entry" objects from Python

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

[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

[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:

[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_property

[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

[issue33576] Remove exception wrapping from __set_name__ calls

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

[issue33576] Remove exception wrapping from __set_name__ calls

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

[issue33576] Remove exception wrapping from __set_name__ calls

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

[issue21145] Add the @cached_property decorator

Carl Meyer <c...@oddbird.net> added the comment: Oops, never mind; closed mine as dupe. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python

[issue33577] remove wrapping of __set_name__ exceptions in RuntimeError

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

[issue21145] Add the @cached_property decorator

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

[issue33577] remove wrapping of __set_name__ exceptions in RuntimeError

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

[issue21145] Add the @cached_property decorator

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

[issue21145] Add the @cached_property decorator

Change by Carl Meyer <c...@oddbird.net>: -- pull_requests: +6636 stage: -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.pyt

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

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

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

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'

[issue21145] Add the @cached_property decorator

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

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

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

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

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

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

Change by Carl Meyer <c...@oddbird.net>: -- keywords: +patch pull_requests: +6517 stage: -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.pyt

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

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

[issue21145] Add the @cached_property decorator

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

[issue33501] split existing optimization levels into granular options

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

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

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

[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

[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 <rep...@bugs.python.org>

[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 computation

[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 <rep...@bugs.python.org> <http://bugs.python.org/i

[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 block this proven

[issue21145] Add the @cached_property decorator

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

[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 warranted

[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

[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: 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

[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 it on trunk

[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

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

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

[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, pitrou

[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 <rep...@bugs.python.org> <http://bugs.python.or

[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

Re: How well do you know Python?

On 07/05/2016 05:50 AM, Chris Angelico wrote: > On Tue, Jul 5, 2016 at 9:33 PM, Peter Otten <__pete...@web.de> wrote: >> Chris Angelico wrote: >> >>> On Tue, Jul 5, 2016 at 6:36 PM, Peter Otten <__pete...@web.de> wrote: What will $ cat foo.py import foo class A: pass

Re: pytz and Python timezones

Hi Johannes, On 06/11/2016 05:37 AM, Johannes Bauer wrote: > I try to create a localized timestamp > in the easiest possible way. So, intuitively, I did this: > > datetime.datetime(2016,1,1,0,0,0,tzinfo=pytz.timezone("Europe/Berlin")) That is indeed intuitive, but unfortunately (due to a

Re: recursive methods require implementing a stack?

On 04/06/2016 03:08 PM, Random832 wrote: > On Wed, Apr 6, 2016, at 16:21, Charles T. Smith wrote: >> I just tried to write a recursive method in python - am I right that >> local >> variables are only lexically local scoped, so sub-instances have the same >> ones? Is there a way out of that? Do

Re: Missing something about timezones

Hi Skip, On 03/14/2016 09:32 AM, Skip Montanaro wrote: > On Mon, Mar 14, 2016 at 10:26 AM, Ian Kelly wrote: >> Why should it? You only asked pytz for the Chicago timezone. You >> didn't ask for it relative to any specific time. > > Thanks. I thought using America/Chicago

Re: Continuing indentation

On 03/02/2016 04:54 PM, Chris Angelico wrote: > On Thu, Mar 3, 2016 at 10:46 AM, wrote: >> On Wednesday, March 2, 2016 at 3:44:07 PM UTC-5, Skip Montanaro wrote: >>> >>> if (some_condition and >>> some_other_condition and >>> some_final_condition): >>>

Re: Importing two modules of same name

Hi Tim, On 02/09/2016 04:23 PM, Tim Johnson wrote: > Before proceding, let me state that this is to satisfy my > curiousity, not to solve any problem I am having. > > Scenario : > Web application developed at /some/dir/sites/flask/ > > If I have a package - let us call it app and in my >

Re: does the order in which the modules are placed in a file matters ?

Hi Ganesh, On 12/16/2015 09:09 AM, Ganesh Pal wrote: > Iam on python 2.7 and linux .I need to know if we need to place the > modules in a particular or it doesn't matter at all > > order while writing the program As you've probably already noticed, it usually doesn't matter to Python (though

Re: Python 3 virtualenvs

Hi Laura, On 11/29/2015 07:12 AM, Laura Creighton wrote: > pyenv is going away. python -m venv is the preferred way to get a venv > > https://bugs.python.org/issue25154 > > Of course if you try it, you may get: > > Error: Command '['/bin/python3.4', '-Im', 'ensurepip', > '--upgrade',

Re: Python 3 virtualenvs

On 11/30/2015 10:20 AM, Laura Creighton wrote: > In a message of Mon, 30 Nov 2015 09:32:27 -0700, Carl Meyer writes: >>> I think it is only meant to be used by people who want to install >>> packages but not site-wide, but I am not sure about that. >> >> I don't

Re: List comprehension with if-else

Hi Larry, On 10/28/2015 10:25 AM, Larry Martell wrote: > I'm trying to do a list comprehension with an if and that requires an > else, but in the else case I do not want anything added to the list. > > For example, if I do this: > > white_list = [l.control_hub.serial_number if l.wblist == >

Re: Understanding WSGI together with Apache

Hi Johannes, On 10/10/2015 08:24 AM, Johannes Bauer wrote: > I'm running an Apache 2.4 webserver using mod_wsgi 4.3.0. There are two > different applications running in there running on two completely > separate vhosts. > > I'm seeing some weird crosstalk between them which I do not understand.

Re: True == 1 weirdness

On 09/16/2015 02:29 PM, Mark Lawrence wrote: > On 16/09/2015 18:53, Sven R. Kunze wrote: >> On 16.09.2015 19:39, Steven D'Aprano wrote: >>> node = left <= ptr => right >> >> Wow. I have absolutely no idea what this is supposed to mean. Do you >> care to elaborate? >> >> >> Best, >> Sven > >

Re: [Datetime-SIG] Are there any "correct" implementations of tzinfo?

Can we please stop cross-posting this thread to python-list and move it to datetime-sig only? I think anyone here on python-list who is sufficiently interested in it can subscribe to datetime-sig. Or the other way around, whatever. I'd just like to stop getting all the messages twice. Carl

Re: Are there any "correct" implementations of tzinfo?

On 09/12/2015 12:23 PM, Random832 wrote: > I was trying to find out how arithmetic on aware datetimes is "supposed > to" work, and tested with pytz. When I posted asking why it behaves this > way I was told that pytz doesn't behave correctly according to the way > the API was designed. The tzlocal

[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

[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 about

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

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

[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

Re: Searching for a usable X509 implementation

Hi Dennis, On 07/03/2015 06:11 PM, Dennis Jacobfeuerborn wrote: Hi, I'm trying to implement certificate functionality in a python app but after fighting with pyOpenSSL and M2Crypto I'm thinking about writing wrapper functions for the OpenSSL command line tool instead or switching the app to

Re: Using a particular python binary with venv

On 06/01/2015 03:33 PM, greenbay.gra...@gmail.com wrote: According to this https://docs.python.org/3.4/library/venv.html#module-venv 'Each virtual environment has its own Python binary (allowing creation of environments with various Python versions)' So how would I create a virtual

Re: Using a particular python binary with venv

On 06/01/2015 04:07 PM, greenbay.gra...@gmail.com wrote: On Tuesday, 2 June 2015 09:43:37 UTC+12, Carl Meyer wrote: On 06/01/2015 03:33 PM, orotau wrote: According to this https://docs.python.org/3.4/library/venv.html#module-venv 'Each virtual environment has its own Python binary

Re: mixing set and list operations

Hi Tim, On 04/30/2015 10:07 AM, Tim wrote: I noticed this today, using Python2.7 or 3.4, and wondered if it is implementation dependent: You can use 'extend' to add set elements to a list and use 'update' to add list elements to a set. m = ['one', 'two'] p = set(['three', 'four'])

Re: Python 3 lack of support for fcgi/wsgi.

On 03/29/2015 09:30 PM, Michael Torrie wrote: What does this have to do with Python itself? I'm not completely sure, but maybe it's about the Python community. What's the way forward? I have no idea. At the very least John is frustrated by the community's lack of apparent interest in

Re: Daylight savings time question

Hi Dan, On 03/24/2015 04:24 PM, Dan Stromberg wrote: Is there a way of adding 4 hours and getting a jump of 5 hours on March 8th, 2015 (due to Daylight Savings Time), without hardcoding when to spring forward and when to fall back? I'd love it if there's some library that'll do this for me.

Re: Daylight savings time question

On 03/24/2015 04:56 PM, Chris Angelico wrote: On Wed, Mar 25, 2015 at 9:24 AM, Dan Stromberg drsali...@gmail.com wrote: Is there a way of adding 4 hours and getting a jump of 5 hours on March 8th, 2015 (due to Daylight Savings Time), without hardcoding when to spring forward and when to fall

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

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

  1   2   >