Re: [Python-Dev] Smoothing the transition from Python 2 to 3
> One problem is that the str literals should be bytes
> literals. Comparison with None needs to be avoided.
>
> With Python 2 code runs successfully. With Python 3 the code
> crashes with a traceback. With my modified Python 3.6, the code
> runs successfully but generates the following warnings:
>
> test.py:13: DeprecationWarning: encoding bytes to str
> output.write('%d:' % len(s))
> test.py:14: DeprecationWarning: encoding bytes to str
> output.write(s)
> test.py:15: DeprecationWarning: encoding bytes to str
> output.write(',')
> test.py:5: DeprecationWarning: encoding bytes to str
> if c == ':':
> test.py:9: DeprecationWarning: encoding bytes to str
> size += c
> test.py:24: DeprecationWarning: encoding bytes to str
> data = data + s
> test.py:26: DeprecationWarning: encoding bytes to str
> if input.read(1) != ',':
> test.py:31: DeprecationWarning: default compare is depreciated
> if a > 0:
>
This seems _very_ useful; I'm surprised that other people don't think
so too. Currently, the easiest way to find bytes/str errors in a big
application is by running the program, finding where it crashes,
fixing that one line (or hopefully wherever the data entered the
system if you can find it), and repeating the process.
This is nice because you can get in "fix my encoding errors" mode for
more than just one traceback at a time; the new method would be to run
the program, look at the millions of bytes/str errors, and fix
everything that showed up in this round at once. That seems like a
big win for productivity to me.
Cody
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Recent changes to PyCodeObject
On Wed, Nov 16, 2016 at 6:18 PM, Ned Batchelder wrote: > > When I added Python 3.6 support to coverage.py, I posted a Mac wheel to > PyPI: https://pypi.python.org/pypi/coverage/ That wheel was built > against 3.6a3, the latest version at the time. When I use it now on > 3.6b3, it doesn't work right. The reason is that the co_firstlineno > field in PyCodeObject moved in September, as part of the PEP 523 work: > https://github.com/python/cpython/commit/f1e6d88b3ca2b56d51d87b6b38ea1870c5d9490c > > The docs say that PyCodeObject can change at any time, but I don't see > why the field had to move in the first place. Was this needed? Christian Heimes had the idea so that memory consumption wouldn't be impacted by adding co_extra to the struct: https://mail.python.org/pipermail/python-dev/2016-August/145961.html Cody ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 549: Instance Properties (aka: module properties)
On Wed, Sep 6, 2017 at 10:26 AM, Guido van Rossum wrote: > > So we've seen a real use case for __class__ assignment: deprecating things on > access. That use case could also be solved if modules natively supported > defining __getattr__ (with the same "only used if attribute not found > otherwise" semantics as it has on classes), but it couldn't be solved using > @property (or at least it would be quite hacky). > > Is there a real use case for @property? Otherwise, if we're going to mess > with module's getattro, it makes more sense to add __getattr__, which would > have made Nathaniel's use case somewhat simpler. (Except for the __dir__ > thing -- what else might we need?) > -- > --Guido van Rossum (python.org/~guido) I think a more natural way for the __dir__ problem would be to update module_dir() in moduleobject.c to check if __all__ is defined and then just return that list if it is defined. I think that would be a friendlier default for __dir__ anyway. Cody ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: PoC: Subinterpreters 4x faster than sequential execution or threads on CPU-bound workaround
On Tue, May 5, 2020 at 6:44 PM Joseph Jenne via Python-Dev wrote: > > I'm seeing a drop in performance of both multiprocess and subinterpreter > based runs in the 8-CPU case, where performance drops by about half > despite having enough logical CPUs, while the other cases scale quite > well. Is there some issue with python multiprocessing/subinterpreters on > the same logical core? This is not a Python issue at all, but a limitation of logical cores. The logical cores still share the same physical resources, so the logical cores are contending for the same execution resources. Actually it would probably be bad if Python *didn't* scale this way, because that would indicate that a Python process that should be running full-blast isn't actually utilizing all the physical resources of a CPU! -Cody ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/43N2VIRRE4Q2MDP7KFMIXDCPTP3SSEUC/ Code of Conduct: http://python.org/psf/codeofconduct/
