[Python-Dev] [RELEASED] Python 3.4.0 release candidate 3
On behalf of the Python development team, I'm pleased to announce the third and final** release candidate of Python 3.4. This is a preview release, and its use is not recommended for production settings. Python 3.4 includes a range of improvements of the 3.x series, including hundreds of small improvements and bug fixes. Major new features and changes in the 3.4 release series include: * PEP 428, a "pathlib" module providing object-oriented filesystem paths * PEP 435, a standardized "enum" module * PEP 436, a build enhancement that will help generate introspection information for builtins * PEP 442, improved semantics for object finalization * PEP 443, adding single-dispatch generic functions to the standard library * PEP 445, a new C API for implementing custom memory allocators * PEP 446, changing file descriptors to not be inherited by default in subprocesses * PEP 450, a new "statistics" module * PEP 451, standardizing module metadata for Python's module import system * PEP 453, a bundled installer for the *pip* package manager * PEP 454, a new "tracemalloc" module for tracing Python memory allocations * PEP 456, a new hash algorithm for Python strings and binary data * PEP 3154, a new and improved protocol for pickled objects * PEP 3156, a new "asyncio" module, a new framework for asynchronous I/O Python 3.4 is now in "feature freeze", meaning that no new features will be added. The final release is projected for March 16, 2014. To download Python 3.4.0rc3 visit: http://www.python.org/download/releases/3.4.0/ Please consider trying Python 3.4.0rc3 with your code and reporting any new issues you notice to: http://bugs.python.org/ Enjoy! ** This time we really mean it! No foolin'! -- Larry Hastings, Release Manager larry at hastings.org (on behalf of the entire python-dev team and 3.4's contributors) ___ 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] Python 3.4 change in importlib/__init__.py breaking cxFreeze?
Hi all.
Python 3.4 introduced a change to Lib/importlib/__init__.py that
added the following code to it:
else:
# importlib._bootstrap is the built-in import, ensure we don't create
# a second copy of the module.
_bootstrap.__name__ = 'importlib._bootstrap'
_bootstrap.__package__ = 'importlib'
_bootstrap.__file__ = __file__.replace('__init__.py', '_bootstrap.py')
sys.modules['importlib._bootstrap'] = _bootstrap
When attempting to use cxFreeze on a project, using Python 3.4. we
ran into a problem with '__file__' identifier not being defined.
Could this be a python bug? Why is this code expecting the module
loaded from importlib/__init__.py to always have a __file__ identifier?
What is supposed to happen when that code gets loaded from a ZIP archive?
Just wanted to check here before filing an issue... but if this is an
issue I hope it can be resolved before the final 3.4 release.
Best regards,
Jurko Gospodnetić
___
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] What is the precise problem? [was: Reference cycles in Exception.__traceback__]
On 08/03/14 15:30, Maciej Fijalkowski wrote: On Sat, Mar 8, 2014 at 5:14 PM, Victor Stinner wrote: 2014-03-08 14:33 GMT+01:00 Antoine Pitrou : Ok, it's actually quite trivial. The whole chain is kept alive by the "fut" global variable. If you arrange for it to be disposed of: fut = asyncio.Future() asyncio.Task(func(fut)) del fut [etc.] then the problem disappears: as soon as gc.collect() happens, the MyObject instance is destroyed, the future is collected, and the future's traceback is printed out. Well, the problem is more general than this specific example. I would like to implement a general solution which would not hold references to local variables, to destroy objects when Python exits the except block. It looks like a "exception summary" containing only data to format the traceback would fit asyncio needs. If you don't want it in the traceback module, I will try to implement it in asyncio. It would be nice to provide an "exception summary" in the traceback module, because it looks like reference cycles related to exception and/or traceback is a common issue (see the list of links I gave in a previous email). Victor How about fixing cyclic gc to deal with __del__ instead? That sounds like an awful change to the semantics. +1 Cheers, Mark. ___ 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] [python-committers] [RELEASED] Python 3.4.0 release candidate 3
Hi, I tested Python 3.4rc3 installer on Windows: - all menu entries work (doc, doc server, help, IDLE, command line, etc.) - pip is installed, yeah! - my tracemalloc module works on Windows too ;-) - The uninstaller fully removes C:\Python34 The major Windows installer issues are fixed in the RC3. Note: As fully, I got a popup telling me that the MSI is untrusted, and I had to click on [OK] to confirm that I trust python.org. I also tried to change pip version: I downgraded it from 1.5.4 to 1.5.3. In this case, C:\Python34 is not removed, I filled an issue for that, but it's maybe expected? http://bugs.python.org/issue20878 When I tested tracemalloc, I also found a "memory regression": the "base64 module of Python 3.4 uses 920 kB of memory". I filled an issue for this. It's not critical, it can wait Python 3.4.1. I'm happy that tracemalloc is now built in Python and so memory can be tracked more easily! http://bugs.python.org/issue20879 Victor 2014-03-10 8:47 GMT+01:00 Larry Hastings : > > > On behalf of the Python development team, I'm pleased to announce > the third and final** release candidate of Python 3.4. > > This is a preview release, and its use is not recommended for > production settings. > > Python 3.4 includes a range of improvements of the 3.x series, including > hundreds of small improvements and bug fixes. Major new features and > changes in the 3.4 release series include: > > * PEP 428, a "pathlib" module providing object-oriented filesystem paths > * PEP 435, a standardized "enum" module > * PEP 436, a build enhancement that will help generate introspection >information for builtins > * PEP 442, improved semantics for object finalization > * PEP 443, adding single-dispatch generic functions to the standard library > * PEP 445, a new C API for implementing custom memory allocators > * PEP 446, changing file descriptors to not be inherited by default >in subprocesses > * PEP 450, a new "statistics" module > * PEP 451, standardizing module metadata for Python's module import system > * PEP 453, a bundled installer for the *pip* package manager > * PEP 454, a new "tracemalloc" module for tracing Python memory allocations > * PEP 456, a new hash algorithm for Python strings and binary data > * PEP 3154, a new and improved protocol for pickled objects > * PEP 3156, a new "asyncio" module, a new framework for asynchronous I/O > > Python 3.4 is now in "feature freeze", meaning that no new features will be > added. The final release is projected for March 16, 2014. > > > To download Python 3.4.0rc3 visit: > > http://www.python.org/download/releases/3.4.0/ > > > Please consider trying Python 3.4.0rc3 with your code and reporting any > new issues you notice to: > > http://bugs.python.org/ > > > Enjoy! > > > ** This time we really mean it! No foolin'! > > -- > Larry Hastings, Release Manager > larry at hastings.org > (on behalf of the entire python-dev team and 3.4's contributors) > ___ > python-committers mailing list > python-committ...@python.org > https://mail.python.org/mailman/listinfo/python-committers ___ 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] What is the precise problem? [was: Reference cycles in Exception.__traceback__]
2014-03-08 16:30 GMT+01:00 Maciej Fijalkowski : > How about fixing cyclic gc to deal with __del__ instead? That sounds > like an awful change to the semantics. Hum? That's the purpose of the PEP 442 which is implemented in Python 3.4. As I wrote, it's not enough to fix all issues. Usually, I see an explicit call to gc.collect() as a workaround to a deeper issue. I prefer to modify my program to run smoothly without explict garbage collection. That's why I would prefer to avoid creating reference cycles from the beginning. Victor ___ 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] What is the precise problem? [was: Reference cycles in Exception.__traceback__]
On Mon, Mar 10, 2014 at 12:10 PM, Victor Stinner wrote: > 2014-03-08 16:30 GMT+01:00 Maciej Fijalkowski : >> How about fixing cyclic gc to deal with __del__ instead? That sounds >> like an awful change to the semantics. > > Hum? That's the purpose of the PEP 442 which is implemented in Python 3.4. > > As I wrote, it's not enough to fix all issues. > > Usually, I see an explicit call to gc.collect() as a workaround to a > deeper issue. I prefer to modify my program to run smoothly without > explict garbage collection. > > That's why I would prefer to avoid creating reference cycles from the > beginning. > > Victor It was agreed long time ago that the immediate finalization is an implementation specific detail and it's not guaranteed. You should not rely on __del__s being called timely one way or another. Why would you require this for the program to work correctly in the particular example of __traceback__? Cheers, fijal ___ 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] Windows 'for current user' installation - 32/64-bit registrations overwrite each other
Hi. When running the Python Windows installer 'for all users', the 32-bit installation and the 64-bit installation each gets a separate registration in the Windows registry. E.g. under: HKEY_LOCAL_MACHINE\Software\Python\PythonCore\3.4 and: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Python\PythonCore\3.4 However, when running the installer 'for the current user only', the 32-bit and the 64-bit installation both use the same Windows registry key: HKEY_CURRENT_USER\Software\Python\PythonCore\3.4 Note that a 64-bit installation does not automatically uninstall a previous 32-bit installation in either case, or vice versa. Why the mismatch? As I understand it, whichever installation you use, you should be able to run a specific Python interpreter using the py.exe runner, as it: py.exe -3.4 py.exe -3.4-32 As it stands now - both of those run the same interpreter when they have been installed 'for the current user only'. Is this as issue or desired behaviour? Should I open an issue for it? Best regards, Jurko Gospodnetić ___ 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] [Python-checkins] cpython: whatsnew: venv with_pip, pyvenv --without-pip (#19552)
On 10 Mar 2014 08:51, "r.david.murray" wrote: > > http://hg.python.org/cpython/rev/a140caad76bc > changeset: 89539:a140caad76bc > user:R David Murray > date:Sun Mar 09 18:09:51 2014 -0400 > summary: > whatsnew: venv with_pip, pyvenv --without-pip (#19552) > > files: > Doc/whatsnew/3.4.rst | 11 +++ > 1 files changed, 11 insertions(+), 0 deletions(-) > > > diff --git a/Doc/whatsnew/3.4.rst b/Doc/whatsnew/3.4.rst > --- a/Doc/whatsnew/3.4.rst > +++ b/Doc/whatsnew/3.4.rst > @@ -1507,6 +1507,12 @@ > :mod:`venv` now includes activation scripts for the ``csh`` and ``fish`` > shells (Contributed by Andrew Svetlov in :issue:`15417`.) > > +:class:`~venv.EnvBuilder` and the :func:`~venv.create` convenience function > +take a new keyword argument *with_pip*, which defaults to ``False``, that > +controls whether or not :class:`~venv.EnvBuilder` ensures that ``pip`` is > +installed in the virtual environment. (Contributed by Nick Coghlan in > +:issue:`19552` as part of the :pep:`453` implementation.) > + > > wave > > @@ -1772,6 +1778,11 @@ >to use copies rather than symlinks even on systems where symlinks are the >default. (Contributed by Vinay Sajip in :issue:`18807`.) > > +* The :ref:`pyvenv ` command also accepts a ``--without-pip`` > + option to suppress the otherwise-automatic bootstrapping of pip into > + the virtual environment. (Contributed by Nick Coghlan in :issue:`19552` > + as part of the :pep:`453` implementation.) It just occurred to me that we should probably have a porting note about that CLI change. We decided that changing the default CLI behaviour, while preserving the default module API was the best available compromise, but anyone that is invoking the CLI programmatically and wants to skip bootstrapping pip will still need to change their command. Cheers, Nick. > + > * The encoding name is now optional in the value set for the >:envvar:`PYTHONIOENCODING` environment variable. This makes it possible to >set just the error handler, without changing the default encoding. > > -- > Repository URL: http://hg.python.org/cpython > > ___ > Python-checkins mailing list > python-check...@python.org > https://mail.python.org/mailman/listinfo/python-checkins > ___ 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] [Python-checkins] cpython: whatsnew: 'U' mode deprecation (#15204).
On 10 Mar 2014 11:36, "r.david.murray" wrote: > > http://hg.python.org/cpython/rev/2d5544afb510 > changeset: 89547:2d5544afb510 > user:R David Murray > date:Sun Mar 09 20:33:35 2014 -0400 > summary: > whatsnew: 'U' mode deprecation (#15204). > > files: > Doc/whatsnew/3.4.rst | 14 +- > 1 files changed, 13 insertions(+), 1 deletions(-) > > > diff --git a/Doc/whatsnew/3.4.rst b/Doc/whatsnew/3.4.rst > --- a/Doc/whatsnew/3.4.rst > +++ b/Doc/whatsnew/3.4.rst > @@ -1948,6 +1948,11 @@ > * The :mod:`sysconfig` key ``SO`` is deprecated, it has been replaced by >``EXT_SUFFIX``. > > +* The ``U`` mode accepted by various ``open`` functions is deprecated. > + In Python3 it does not do anything useful, and should be replaced by > + appropriate uses of :class:`io.TextIOWrapper` (if needed) and its *newline* > + argument. > + Huh, I missed that change. Don't we still need U when writing 2/3 compatible code at this point? If so, perhaps we may want to reconsider this particular deprecation in 3.4.1. Cheers, Nick. > > Deprecations in the C API > - > @@ -2242,7 +2247,14 @@ > > * Since the *digestmod* argument to the :func:`hmac.new` function will in the >future have no default, all calls to :func:`hmac.new` should be changed to > - explicitly specify a *digestmod*. (:issue:`17276`). > + explicitly specify a *digestmod* (:issue:`17276`). > + > +* Any calls to ``open`` functions that specify ``U`` should be modified. > + ``U`` is ineffective in Python3 and will eventually raise an error if used. > + Depending on the function, the equivalent of its old Python2 behavior can be > + achieved using either a *newline* argument, or if necessary by wrapping the > + stream in :mod:`~io.TextIOWrapper` to use its *newline* argument > + (:issue:`15204`). > > > Changes in the C API > > -- > Repository URL: http://hg.python.org/cpython > > ___ > Python-checkins mailing list > python-check...@python.org > https://mail.python.org/mailman/listinfo/python-checkins > ___ 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] undocumented help() function change in Python 3.4?
Hi. On 8.3.2014. 6:48, Nick Coghlan wrote: Yeah, the changes to help() are doubly indirect - help() uses pydoc which uses inspect, and inspect saw a lot of changes. I'll make a few updates to the What's New to help make the consequences of this clearer. Just looked through the latest 3.4rc3 release and nothing related to this seems to have been included yet. Best regards, Jurko Gospodnetić ___ 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] [python-committers] [RELEASED] Python 3.4.0 release candidate 3
On 10 Mar 2014 19:50, "Victor Stinner" wrote: > > Hi, > > I tested Python 3.4rc3 installer on Windows: > > - all menu entries work (doc, doc server, help, IDLE, command line, etc.) > - pip is installed, yeah! > - my tracemalloc module works on Windows too ;-) > - The uninstaller fully removes C:\Python34 > > The major Windows installer issues are fixed in the RC3. Huzzah! :) > Note: As fully, I got a popup telling me that the MSI is untrusted, > and I had to click on [OK] to confirm that I trust python.org. > > I also tried to change pip version: I downgraded it from 1.5.4 to > 1.5.3. In this case, C:\Python34 is not removed, I filled an issue for > that, but it's maybe expected? > http://bugs.python.org/issue20878 Yeah, that's expected - if pip is used to install extra packages, the uninstaller has historically left them alone. Changing the version of pip causes it to be treated like an independently installed package, so the uninstaller leaves it behind. Cheers, Nick. ___ 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] [Python-checkins] cpython: whatsnew: 'U' mode deprecation (#15204).
On Mon, 10 Mar 2014 23:09:53 +1000, Nick Coghlan wrote: > On 10 Mar 2014 11:36, "r.david.murray" wrote: > > > > http://hg.python.org/cpython/rev/2d5544afb510 > > changeset: 89547:2d5544afb510 > > user:R David Murray > > date:Sun Mar 09 20:33:35 2014 -0400 > > summary: > > whatsnew: 'U' mode deprecation (#15204). > > > > files: > > Doc/whatsnew/3.4.rst | 14 +- > > 1 files changed, 13 insertions(+), 1 deletions(-) > > > > > > diff --git a/Doc/whatsnew/3.4.rst b/Doc/whatsnew/3.4.rst > > --- a/Doc/whatsnew/3.4.rst > > +++ b/Doc/whatsnew/3.4.rst > > @@ -1948,6 +1948,11 @@ > > * The :mod:`sysconfig` key ``SO`` is deprecated, it has been replaced by > >``EXT_SUFFIX``. > > > > +* The ``U`` mode accepted by various ``open`` functions is deprecated. > > + In Python3 it does not do anything useful, and should be replaced by > > + appropriate uses of :class:`io.TextIOWrapper` (if needed) and its > *newline* > > + argument. > > + > > Huh, I missed that change. Don't we still need U when writing 2/3 > compatible code at this point? If so, perhaps we may want to reconsider > this particular deprecation in 3.4.1. It's a deprecation, not a removal. I believe the idea is to not remove it before 4.0. --David ___ 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] What is the precise problem? [was: Reference cycles in Exception.__traceback__]
2014-03-10 13:11 GMT+01:00 Maciej Fijalkowski : > It was agreed long time ago that the immediate finalization is an > implementation specific detail and it's not guaranteed. You should not > rely on __del__s being called timely one way or another. Why would you > require this for the program to work correctly in the particular > example of __traceback__? For asyncio, it's very useful to see unhandled exceptions as early as possible. Otherwise, your program is blocked and you don't know why. Guido van Rossum suggests to run gc.collect() regulary: http://code.google.com/p/tulip/issues/detail?id=42 Victor ___ 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] Python 3.4 change in importlib/__init__.py breaking cxFreeze?
On 10 Mar 2014 19:15, "Jurko Gospodnetić" wrote:
>
> Hi all.
>
> Python 3.4 introduced a change to Lib/importlib/__init__.py that added
the following code to it:
>
>> else:
>> # importlib._bootstrap is the built-in import, ensure we don't create
>> # a second copy of the module.
>> _bootstrap.__name__ = 'importlib._bootstrap'
>> _bootstrap.__package__ = 'importlib'
>> _bootstrap.__file__ = __file__.replace('__init__.py',
'_bootstrap.py')
>> sys.modules['importlib._bootstrap'] = _bootstrap
>
>
> When attempting to use cxFreeze on a project, using Python 3.4. we ran
into a problem with '__file__' identifier not being defined.
>
> Could this be a python bug? Why is this code expecting the module
loaded from importlib/__init__.py to always have a __file__ identifier?
What is supposed to happen when that code gets loaded from a ZIP archive?
__file__ is expected to always be set (including when loaded from a zipfile
- in that case it's the zipfile name concatenated with the path within the
zip file). If it isn't set, there's a buggy loader involved somewhere that
isn't setting it properly.
Cheers,
Nick.
>
> Just wanted to check here before filing an issue... but if this is an
issue I hope it can be resolved before the final 3.4 release.
>
> Best regards,
> Jurko Gospodnetić
>
> ___
> 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/ncoghlan%40gmail.com
___
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] [Python-checkins] cpython: whatsnew: 'U' mode deprecation (#15204).
On 10 Mar 2014 23:26, "Antoine Pitrou" wrote: > > On Mon, 10 Mar 2014 23:09:53 +1000 > Nick Coghlan wrote: > > On 10 Mar 2014 11:36, "r.david.murray" wrote: > > > > > > +* The ``U`` mode accepted by various ``open`` functions is deprecated. > > > + In Python3 it does not do anything useful, and should be replaced by > > > + appropriate uses of :class:`io.TextIOWrapper` (if needed) and its > > *newline* > > > + argument. > > > + > > > > Huh, I missed that change. Don't we still need U when writing 2/3 > > compatible code at this point? > > Define "need" :-) I rarely if ever see "U" used in 2.x code, so I don't > think the need is very pressing in general. True, normal text mode is much more common. I'm OK with waiting to see if anyone actually complains about the deprecation :) Cheers, Nick. > > Regards > > Antoine. > > > ___ > Python-checkins mailing list > python-check...@python.org > https://mail.python.org/mailman/listinfo/python-checkins ___ 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] Python 4: don't remove anything, don't break backward compatibility
Hi, Last 5 years, I spend significant time to port a lot of Python 2 code on Python 3. First, using the 2to3 tool + extra manual patches. Sorry, it was not usable in practice. The conversion was very slow, it didn't fix doctests nor all other minor "details". "Fixing Python 2 code" was no always possible. I now use the six module (or a smaller subset) to port applications to Python 3. Today, they are still many dependencies blocking applications to be ported to Python 3. So can we please try to stop scheduling another major Python version breaking almost all modules and all applications just to be pendantic? No, we should not remove any old feature in Python 4. Python 4 should be just a minor release following the previous 3.x release. I don't want another six, nine or whatever module to fill the gap between Python 3 and Python 4. For example, I propose to release the next major Python version (3.5) with the version 4.0 but without removing anything. (It's just an example, it can wait another release.) I mean that any incompatible change must following the classic transition plan: tag the feature as deprecated and wait at least one major version before dropping it, or just keep it forever. We can expect that just changing the major version (3 => 4) will already break enough applications (where "python3" or "version == 3" is hardcoded")... Instead of asking application developers to try to follow each major Python release, we should try to keep the maintaince pain in Python core. What do you think? Victor ___ 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] Windows 'for current user' installation - 32/64-bit registrations overwrite each other
On 10 March 2014 13:03, Jurko Gospodnetić wrote: > Is this as issue or desired behaviour? Should I open an issue for it? Sounds like a bug, but a pretty long-standing one. I can't think that the registry schema Python uses would *ever* have distinguished (the WOW64 component of the all-users entries is a system-generated thing, AIUI). So yes, raise a bug, but (a) it would be useful to test whether the same bug exists in 3.3 and 2.7, and (b) it's going to be tricky to fix without a backward-incompatible change to the registry settings (which will affect things like the launcher and virtualenv, for a start). Paul ___ 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] Python 3.4 change in importlib/__init__.py breaking cxFreeze?
On Mar 10, 2014, at 11:25 PM, Nick Coghlan wrote: >__file__ is expected to always be set (including when loaded from a zipfile Actually, __file__ is an optional attribute on modules since PEP 420 and Python 3.2. It's *usually* there, but unlike in previous version of Python, if the module doesn't actually come from a "file", there's no longer a requirement to craft some mythical value for it if it doesn't make sense. -Barry ___ 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] Python 4: don't remove anything, don't break backward compatibility
On Mar 10, 2014, at 02:55 PM, Victor Stinner wrote: >So can we please try to stop scheduling another major Python version >breaking almost all modules and all applications just to be pendantic? > >What do you think? Just that it's crazy to be talking about Python 4 right now. We have at least 9 years before we have to worry about that. ((~3.10 - 3.4) * 18months)). -Barry ___ 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] Python 4: don't remove anything, don't break backward compatibility
On Mon, Mar 10, 2014 at 02:55:26PM +0100, Victor Stinner wrote: [...] > So can we please try to stop scheduling another major Python version > breaking almost all modules and all applications just to be pendantic? > > No, we should not remove any old feature in Python 4. Python 4 should > be just a minor release following the previous 3.x release. I often talk about "Python 4000" as the next possible opportunity for major backwards incompatible changes, but of course that's not decided yet, and given the long term pain of the 2->3 transition, it may be quite conservative, with no radical changes. Perhaps I ought to use Python 5000 as my target for radical language changes? > For example, I propose to release the next major Python version (3.5) > with the version 4.0 but without removing anything. (It's just an > example, it can wait another release.) If Python 4 is a conservative release, I don't see any reason to bump the major version number until after Python 3.9. So, assuming no further radical changes to the language like 2->3, we'd have five more point releases before needing to deal with 4.0. Perhaps we need a long-term schedule? 3.5: August 2015 3.6: February 2017 3.7: August 2018 3.8: February 2020 3.9: August 2021 4.0: February 2023 give or take a few months. -- Steven ___ 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] Python 3.4 change in importlib/__init__.py breaking cxFreeze?
On Mon, 10 Mar 2014 23:25:17 +1000, Nick Coghlan wrote:
> On 10 Mar 2014 19:15, "Jurko GospodnetiÄ" wrote:
> >
> > Hi all.
> >
> > Python 3.4 introduced a change to Lib/importlib/__init__.py that added
> the following code to it:
> >
> >> else:
> >> # importlib._bootstrap is the built-in import, ensure we don't create
> >> # a second copy of the module.
> >> _bootstrap.__name__ = 'importlib._bootstrap'
> >> _bootstrap.__package__ = 'importlib'
> >> _bootstrap.__file__ = __file__.replace('__init__.py',
> '_bootstrap.py')
> >> sys.modules['importlib._bootstrap'] = _bootstrap
> >
> >
> > When attempting to use cxFreeze on a project, using Python 3.4. we ran
> into a problem with '__file__' identifier not being defined.
> >
> > Could this be a python bug? Why is this code expecting the module
> loaded from importlib/__init__.py to always have a __file__ identifier?
> What is supposed to happen when that code gets loaded from a ZIP archive?
>
> __file__ is expected to always be set (including when loaded from a zipfile
> - in that case it's the zipfile name concatenated with the path within the
> zip file). If it isn't set, there's a buggy loader involved somewhere that
> isn't setting it properly.
I noticed while using cx_Freeze that __file__ is not set on the main
module that cx_Freeze calls (and I found that very annoying :). I'm
guessing this is a cx_Freeze artifact and will need to be fixed in
cx_Freeze.
--David
___
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] Python 4: don't remove anything, don't break backward compatibility
On Mon, Mar 10, 2014 at 8:55 AM, Victor Stinner wrote: > For example, I propose to release the next major Python version (3.5) > with the version 4.0 but without removing anything. People put a lot of weight behind version numbers, often much more than they should. Jumping to 4.0 would be a PR nightmare and would ultimately hurt this project as more people decide that switching to another language will solve their problem better than jumping from 2.x to 4.0. People already think 2.7 to 3.4 is enough of a burden. Please do not do this. ___ 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] Python 4: don't remove anything, don't break backward compatibility
I don't see the point in this discussion. As far as I know, the major version is INTENDED to indicate backward-incompatible changes. The meaning of the versioning scheme is literally [API compatibility].[new features].[bug fixes], isn't it? So all you are asking for is never do produce a Python 4.x This is not necessarily bad, for instance Java has never increased its major version ever (it is still 1.7.x). An indeed, it never dropped features, just "deprecated". > I don't see any reason to bump > the major version number until after Python 3.9. Even then, there is no need for 4.0; you can just have 3.10, 3.11 etc. Cheers Stefan > Gesendet: Montag, 10. März 2014 um 16:04 Uhr > Von: "Steven D'Aprano" > An: python-dev@python.org > Betreff: Re: [Python-Dev] Python 4: don't remove anything, don't break > backward compatibility > > On Mon, Mar 10, 2014 at 02:55:26PM +0100, Victor Stinner wrote: > [...] > > So can we please try to stop scheduling another major Python version > > breaking almost all modules and all applications just to be pendantic? > > > > No, we should not remove any old feature in Python 4. Python 4 should > > be just a minor release following the previous 3.x release. > > I often talk about "Python 4000" as the next possible opportunity for > major backwards incompatible changes, but of course that's not decided > yet, and given the long term pain of the 2->3 transition, it may be > quite conservative, with no radical changes. Perhaps I ought to use > Python 5000 as my target for radical language changes? > > > > For example, I propose to release the next major Python version (3.5) > > with the version 4.0 but without removing anything. (It's just an > > example, it can wait another release.) > > If Python 4 is a conservative release, I don't see any reason to bump > the major version number until after Python 3.9. So, assuming no further > radical changes to the language like 2->3, we'd have five more point > releases before needing to deal with 4.0. > > Perhaps we need a long-term schedule? > > 3.5: August 2015 > 3.6: February 2017 > 3.7: August 2018 > 3.8: February 2020 > 3.9: August 2021 > 4.0: February 2023 > > give or take a few months. > > > -- > Steven > ___ > 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/stefan.richthofer%40gmx.de > ___ 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] Python 3.4 change in importlib/__init__.py breaking cxFreeze?
Hi Nick. On 10.3.2014. 14:25, Nick Coghlan wrote:> What is supposed to happen when that code gets loaded from a ZIP archive? > > __file__ is expected to always be set (including when loaded from a > zipfile - in that case it's the zipfile name concatenated with the > path within the zip file). If it isn't set, there's a buggy loader > involved somewhere that isn't setting it properly. I don't recall seeing that ever explicitly stated. For that matter, Python 3.4.0rc3 documentation explicitly states: > __file__ is optional. If set, this attribute’s value must be a string. > The import system may opt to leave __file__ unset if it has no > semantic meaning (e.g. a module loaded from a database). and: > Ultimately, the loader is what makes use of __file__ and/or __cached__. Or is this some rule specific to the importlib/__init__.py stdlib module? As I recall, I first learned that not all loaded modules need to have their __file__ attribute set by researching a failure in some package when installed as a zipped-egg using setuptools. Admittedly though, that was some old setuptools version. Best regards, Jurko Gospodnetić ___ 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] Windows 'for current user' installation - 32/64-bit registrations overwrite each other
Hi Paul. On 10.3.2014. 14:54, Paul Moore wrote: On 10 March 2014 13:03, Jurko Gospodnetić wrote: Is this as issue or desired behaviour? Should I open an issue for it? Sounds like a bug, but a pretty long-standing one. I can't think that the registry schema Python uses would *ever* have distinguished (the WOW64 component of the all-users entries is a system-generated thing, AIUI). So yes, raise a bug, but (a) it would be useful to test whether the same bug exists in 3.3 and 2.7, and (b) it's going to be tricky to fix without a backward-incompatible change to the registry settings (which will affect things like the launcher and virtualenv, for a start). Reported as issue #20883 (http://bugs.python.org/issue20883). I'll report the extra details there then. Best regards, Jurko Gospodnetić ___ 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] Python 4: don't remove anything, don't break backward compatibility
On 2014-03-10 15:04, Steven D'Aprano wrote: On Mon, Mar 10, 2014 at 02:55:26PM +0100, Victor Stinner wrote: [...] So can we please try to stop scheduling another major Python version breaking almost all modules and all applications just to be pendantic? No, we should not remove any old feature in Python 4. Python 4 should be just a minor release following the previous 3.x release. I often talk about "Python 4000" as the next possible opportunity for major backwards incompatible changes, but of course that's not decided yet, and given the long term pain of the 2->3 transition, it may be quite conservative, with no radical changes. Perhaps I ought to use Python 5000 as my target for radical language changes? You mean that backwards-incompatible changes should be limited to prime- number major versions only? :-) [snip] ___ 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] Python 3.4 change in importlib/__init__.py breaking cxFreeze?
On Mon Mar 10 2014 at 11:41:27 AM, Jurko Gospodnetić < jurko.gospodne...@pke.hr> wrote: >Hi Nick. > > On 10.3.2014. 14:25, Nick Coghlan wrote:> What is supposed to happen > when that code gets loaded from a ZIP archive? > > > > __file__ is expected to always be set (including when loaded from a > > zipfile - in that case it's the zipfile name concatenated with the > > path within the zip file). If it isn't set, there's a buggy loader > > involved somewhere that isn't setting it properly. > >I don't recall seeing that ever explicitly stated. For that matter, > Python 3.4.0rc3 documentation explicitly states: > > > __file__ is optional. If set, this attribute’s value must be a string. > > The import system may opt to leave __file__ unset if it has no > > semantic meaning (e.g. a module loaded from a database). > >and: > > > Ultimately, the loader is what makes use of __file__ and/or __cached__. > >Or is this some rule specific to the importlib/__init__.py stdlib > module? > No, Nick was mistaken and Barry's response is accurate: __file__ is optional and left off when it doesn't make any sense. Since importlib._bootstrap is a frozen module by default it doesn't have __file__ set. -Brett > >As I recall, I first learned that not all loaded modules need to have > their __file__ attribute set by researching a failure in some package > when installed as a zipped-egg using setuptools. Admittedly though, that > was some old setuptools version. > >Best regards, > Jurko Gospodnetić > > ___ > 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/ > brett%40python.org > ___ 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] Python 4: don't remove anything, don't break backward compatibility
2014-03-10 16:25 GMT+01:00 Stefan Richthofer : > I don't see the point in this discussion. > As far as I know, the major version is INTENDED to > indicate backward-incompatible changes. This is not a strict rule. I would like to follow Linux 3 which didn't break the API between Linux 2 and Linux 3. > Even then, there is no need for 4.0; you can just have 3.10, 3.11 etc. The major version is sometimes seen as the age of a project. I propose to bump Python to version 4 because people understand that Python 4 is much better than Python 3 :-) Firefox changes its major version every 4 months or something like that. I suggest to wait less than 8 years for Python 4. http://en.wikipedia.org/wiki/Software_versioning#Political_and_cultural_significance_of_version_numbers Or maybe we should jump directly to Python 5 for asian users and to follow PHP version! http://en.wikipedia.org/wiki/Tetraphobia Victor ___ 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] Python 4: don't remove anything, don't break backward compatibility
On 10/03/2014 13:55, Victor Stinner wrote: So can we please try to stop scheduling another major Python version breaking almost all modules and all applications just to be pendantic? I've missed the announcement about this, can we have a link please? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com ___ 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] Python 4: don't remove anything, don't break backward compatibility
On Mar 10, 2014, at 04:25 PM, Stefan Richthofer wrote: >> I don't see any reason to bump >> the major version number until after Python 3.9. > >Even then, there is no need for 4.0; you can just have 3.10, 3.11 etc. Guido famously hates two digit minor version numbers. :) -Barry ___ 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] Python 4: don't remove anything, don't break backward compatibility
On Mon Mar 10 2014 at 11:50:54 AM, Victor Stinner wrote: > 2014-03-10 16:25 GMT+01:00 Stefan Richthofer : > > I don't see the point in this discussion. > > As far as I know, the major version is INTENDED to > > indicate backward-incompatible changes. > > This is not a strict rule. I would like to follow Linux 3 which didn't > break the API between Linux 2 and Linux 3. > I disagree. I don't think 3->4 will be as drastic as it was for 2->3, but I view Python 4 as a chance to drop all deprecated APIs that we left in for convenience in porting from Python 2 (e.g. the imp module). We can't put a removal date as we can't really declare Python 2 dead for the whole community. But when Python 4 does come out next decade I would like to say that we have moved entirely beyond Python 2 as a team and thus don't turn into Java and support deprecated code forever. > > > Even then, there is no need for 4.0; you can just have 3.10, 3.11 etc. > > The major version is sometimes seen as the age of a project. I propose > to bump Python to version 4 because people understand that Python 4 is > much better than Python 3 :-) Sure, but you also understand 3.5 is better than 3.4. You're also making the assumption that people are going to pick up on the fact that major version shifts from Python are suddenly not a big deal, even though it is still well known the shift from 2 to 3 was a big deal. > Firefox changes its major version every > 4 months or something like that. Sure, but we are not about to do 4 month release cycles. Releasing that often does make minor version numbers silly since they become double digits so quickly. But since we are not shifting from our 18 month cycle we don't have that issue; 15 years (typically) between a .0 and .9 release doesn't really lead to a worry of exhausting reasonable minor version numbers. > I suggest to wait less than 8 years > for Python 4. > Why? What's special about 8 years? ___ 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] Python 4: don't remove anything, don't break backward compatibility
> Guido famously hates two digit minor version numbers. :) This is no problem either. Simply switch to hexadecimal numbering ;) > Gesendet: Montag, 10. März 2014 um 16:59 Uhr > Von: "Barry Warsaw" > An: python-dev@python.org > Betreff: Re: [Python-Dev] Python 4: don't remove anything, don't break > backward compatibility > > On Mar 10, 2014, at 04:25 PM, Stefan Richthofer wrote: > > >> I don't see any reason to bump > >> the major version number until after Python 3.9. > > > >Even then, there is no need for 4.0; you can just have 3.10, 3.11 etc. > > Guido famously hates two digit minor version numbers. :) > > -Barry > ___ > 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/stefan.richthofer%40gmx.de > ___ 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] Python 4: don't remove anything, don't break backward compatibility
>> I suggest to wait less than 8 years >> for Python 4. > > Why? What's special about 8 years? It's the time between Python 2.0 and 3.0. Victor ___ 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] Python 3.4 change in importlib/__init__.py breaking cxFreeze?
Hi Brett. On 10.3.2014. 16:44, Brett Cannon wrote: > __file__ is optional and left off when it doesn't make any sense. > Since importlib._bootstrap is a frozen module by default it doesn't > have __file__ set. Issue #20884 opened for this (http://bugs.python.org/issue20884). Best regards, Jurko Gospodnetić ___ 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] cpython: whatsnew: 'U' mode deprecation (#15204).
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/10/2014 09:09 AM, Nick Coghlan wrote: > Don't we still need U when writing 2/3 compatible code at this point? io.TextIOWrapper was already the superior strategy for anyone straddling Python 2.6+ - Py3k. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMd56sACgkQ+gerLs4ltQ4+kQCgm2a0KDP/aGTCZD9eUdImjBC2 ny4AoLmyLOlBZOksvu3nwKawo6BTG0Ab =H7l+ -END PGP SIGNATURE- ___ 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] cpython: whatsnew: 'U' mode deprecation (#15204).
10.03.14 15:09, Nick Coghlan написав(ла): Huh, I missed that change. Don't we still need U when writing 2/3 compatible code at this point? If so, perhaps we may want to reconsider this particular deprecation in 3.4.1. In most cases the 'U' mode either no-op or forbidden in Python 3. It may be needed only when you use built-in open() in Python 2 and open without the encoding and newlines arguments in Python 3 (but it will be better to use io.open()). http://bugs.python.org/issue15204 ___ 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] Python 4: don't remove anything, don't break backward compatibility
On Mon Mar 10 2014 at 12:08:55 PM, Victor Stinner wrote: > >> I suggest to wait less than 8 years > >> for Python 4. > > > > Why? What's special about 8 years? > > It's the time between Python 2.0 and 3.0. > But I'm willing to bet that's going to be an anomaly. Python 3 came into existence when it did so we didn't wait too long for Python 2 to get even more of a foothold; the expectation is that long-term more non-Python 2 code will be written than not. There's no rush on Python 4 since there are no plans to try and tweak something as drastic as str/bytes. ___ 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] Python 4: don't remove anything, don't break backward compatibility
On Mon, Mar 10, 2014 at 8:04 AM, Steven D'Aprano wrote: > If Python 4 is a conservative release, I don't see any reason to bump > the major version number until after Python 3.9. and why even then? > Perhaps we need a long-term schedule? > why not: 3.5: August 2015 > 3.6: February 2017 > 3.7: August 2018 > 3.8: February 2020 > 3.9: August 2021 3.10: February 2023 > 3.11 August 2023 3.12 February 2024 version numbering is not decimal -- a bump to 4.0 should mean _something_ (Though from the above, we've got a few years before we need to worry about that!) -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ 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] Python 4: don't remove anything, don't break backward compatibility
On Mon Mar 10 2014 at 12:47:21 PM, Chris Barker wrote: > On Mon, Mar 10, 2014 at 8:04 AM, Steven D'Aprano wrote: > > >> If Python 4 is a conservative release, I don't see any reason to bump >> the major version number until after Python 3.9. > > > and why even then? > > >> Perhaps we need a long-term schedule? >> > > why not: > > 3.5: August 2015 >> 3.6: February 2017 >> 3.7: August 2018 >> 3.8: February 2020 >> 3.9: August 2021 > > 3.10: February 2023 >> > 3.11 August 2023 > 3.12 February 2024 > > > version numbering is not decimal -- a bump to 4.0 should mean _something_ > > (Though from the above, we've got a few years before we need to worry > about that!) > I think it got lost in email threading, but Barry pointed out that Guido famously hates double digit version numbers (as do I, probably partially because he does after all these years =). ___ 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] Python 4: don't remove anything, don't break backward compatibility
On 03/10/2014 06:55 AM, Victor Stinner wrote: What do you think? I think Python 4.0 will follow Python 3.9. No need to rush things [1]. -- ~Ethan~ [1] The Python 2 line ended early because we had a major paradigm shift with moving to Unicode by default. Unless we experience another major paradigm shift (which would absolutely require backwards incompatible changes), there is no need to end the 3.x line early. ___ 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] Python 4: don't remove anything, don't break backward compatibility
On Mon, 10 Mar 2014 16:50:12 +0100 Victor Stinner wrote: > 2014-03-10 16:25 GMT+01:00 Stefan Richthofer : > > I don't see the point in this discussion. > > As far as I know, the major version is INTENDED to > > indicate backward-incompatible changes. > > This is not a strict rule. I would like to follow Linux 3 which didn't > break the API between Linux 2 and Linux 3. > > > Even then, there is no need for 4.0; you can just have 3.10, 3.11 etc. > > The major version is sometimes seen as the age of a project. I propose > to bump Python to version 4 because people understand that Python 4 is > much better than Python 3 :-) Firefox changes its major version every > 4 months or something like that. I suggest to wait less than 8 years > for Python 4. But then, three is the number, not four, and five is right out: "First shalt thou take out the Holy Pin, then shalt thou count to three, no more, no less. Three shall be the number thou shalt count, and the number of the counting shall be three. Four shalt thou not count, neither count thou two, excepting that thou then proceed to three. Five is right out. Once the number three, being the third number, be reached, then lobbest thou thy Holy Hand Grenade of Antioch towards thy foe, who being naughty in My sight, shall snuff it." Regards Antoine. ___ 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] Python 4: don't remove anything, don't break backward compatibility
On Mon, 10 Mar 2014 17:04:08 +0100 "Stefan Richthofer" wrote: > > Guido famously hates two digit minor version numbers. :) > > This is no problem either. Simply switch to hexadecimal numbering ;) Or wrap around to negative numbers (a minus sign isn't technically a digit, is it?). Regards Antoine. ___ 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] Python 4: don't remove anything, don't break backward compatibility
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/10/2014 12:49 PM, Brett Cannon wrote: > I think it got lost in email threading, but Barry pointed out that > Guido famously hates double digit version numbers (as do I, probably > partially because he does after all these years =). "Guido hates them" isn't an argument: its a ukase. Version numbers are tuples, not decimal fractions. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMd78wACgkQ+gerLs4ltQ4s/ACdEkOvaYjP2d9IZ4g8bVJC/OZl h8gAoIu0IY1qYAhvZQzEo9Up9swJnZ60 =7tsf -END PGP SIGNATURE- ___ 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] Python 4: don't remove anything, don't break backward compatibility
On Tue, Mar 11, 2014 at 3:56 AM, Antoine Pitrou wrote: > On Mon, 10 Mar 2014 17:04:08 +0100 > "Stefan Richthofer" wrote: > >> > Guido famously hates two digit minor version numbers. :) >> >> This is no problem either. Simply switch to hexadecimal numbering ;) > > Or wrap around to negative numbers (a minus sign isn't technically a > digit, is it?). Terrible idea. Would wreak havoc with comparisons. No. Python 3 is all about Unicode, so the right way to proceed is 3.8, 3.9, 3.:, 3.;, 3.<, 3.=, 3.>, 3.?, 3.@, 3.A. ChrisA ___ 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] Python 4: don't remove anything, don't break backward compatibility
On Mon, 10 Mar 2014 16:06:22 -, Brett Cannon wrote: > On Mon Mar 10 2014 at 11:50:54 AM, Victor Stinner > wrote: > > > 2014-03-10 16:25 GMT+01:00 Stefan Richthofer : > > > I don't see the point in this discussion. > > > As far as I know, the major version is INTENDED to > > > indicate backward-incompatible changes. > > > > This is not a strict rule. I would like to follow Linux 3 which didn't > > break the API between Linux 2 and Linux 3. > > > > I disagree. I don't think 3->4 will be as drastic as it was for 2->3, but I > view Python 4 as a chance to drop all deprecated APIs that we left in for > convenience in porting from Python 2 (e.g. the imp module). We can't put a > removal date as we can't really declare Python 2 dead for the whole > community. But when Python 4 does come out next decade I would like to say > that we have moved entirely beyond Python 2 as a team and thus don't turn > into Java and support deprecated code forever. We had this discussion a bit ago, and my sense was that we tentatively decided that we were just going to deprecate and remove things as appropriate, irregardless of version number. I used "4.0" in my message about 'U' as a shorthand for "some time after python2 is no longer an issue". Sorry for the confusion. (That said, I do see some merit to doing some extra cleaning at the 4.0 boundary, just for mental convenience.) --David ___ 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] Python 4: don't remove anything, don't break backward compatibility
On Tue, Mar 11, 2014 at 4:08 AM, R. David Murray wrote: > (That said, I > do see some merit to doing some extra cleaning at the 4.0 > boundary, just for mental convenience.) A transition from 3.9 to 4.0 that removes a whole lot of deprecated aliases and such wouldn't be a bad thing. It's technically breaking backward compat (and thus justifying the major version bump), but any code broken by it would have been unidiomatic for the past X versions anyway. ChrisA ___ 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] What is the precise problem? [was: Reference cycles in Exception.__traceback__]
On Mon, Mar 10, 2014 at 3:23 PM, Victor Stinner wrote: > 2014-03-10 13:11 GMT+01:00 Maciej Fijalkowski : >> It was agreed long time ago that the immediate finalization is an >> implementation specific detail and it's not guaranteed. You should not >> rely on __del__s being called timely one way or another. Why would you >> require this for the program to work correctly in the particular >> example of __traceback__? > > For asyncio, it's very useful to see unhandled exceptions as early as > possible. Otherwise, your program is blocked and you don't know why. > > Guido van Rossum suggests to run gc.collect() regulary: > http://code.google.com/p/tulip/issues/detail?id=42 > > Victor twisted goes around it by attaching errback by hand. Would that work for tulip? ___ 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] What is the precise problem? [was: Reference cycles in Exception.__traceback__]
On Mon, Mar 10, 2014 at 10:30 AM, Maciej Fijalkowski wrote: > On Mon, Mar 10, 2014 at 3:23 PM, Victor Stinner > wrote: > > 2014-03-10 13:11 GMT+01:00 Maciej Fijalkowski : > >> It was agreed long time ago that the immediate finalization is an > >> implementation specific detail and it's not guaranteed. You should not > >> rely on __del__s being called timely one way or another. Why would you > >> require this for the program to work correctly in the particular > >> example of __traceback__? > > > > For asyncio, it's very useful to see unhandled exceptions as early as > > possible. Otherwise, your program is blocked and you don't know why. > > > > Guido van Rossum suggests to run gc.collect() regulary: > > http://code.google.com/p/tulip/issues/detail?id=42 > > > > Victor > > twisted goes around it by attaching errback by hand. Would that work for > tulip? > Can you describe that idea in more detail? -- --Guido van Rossum (python.org/~guido) ___ 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] What is the precise problem? [was: Reference cycles in Exception.__traceback__]
On Mon, Mar 10, 2014 at 7:35 PM, Guido van Rossum wrote: > On Mon, Mar 10, 2014 at 10:30 AM, Maciej Fijalkowski > wrote: >> >> On Mon, Mar 10, 2014 at 3:23 PM, Victor Stinner >> wrote: >> > 2014-03-10 13:11 GMT+01:00 Maciej Fijalkowski : >> >> It was agreed long time ago that the immediate finalization is an >> >> implementation specific detail and it's not guaranteed. You should not >> >> rely on __del__s being called timely one way or another. Why would you >> >> require this for the program to work correctly in the particular >> >> example of __traceback__? >> > >> > For asyncio, it's very useful to see unhandled exceptions as early as >> > possible. Otherwise, your program is blocked and you don't know why. >> > >> > Guido van Rossum suggests to run gc.collect() regulary: >> > http://code.google.com/p/tulip/issues/detail?id=42 >> > >> > Victor >> >> twisted goes around it by attaching errback by hand. Would that work for >> tulip? > > > Can you describe that idea in more detail? Essentially, instead of relying on deferred to be garbage collected, you attach an errback like this: deferred.addErrback(callback_that_writes_to_log) so in case of a failure, you get a traceback directly in the callback immediately, without relying on garbage collection. I'm sorry if I'm using twisted nomenclature here (it's also awfully off-topic for python-dev), but making programs rely on refcounting sounds like a bad idea for us (PyPy). Cheers, fijal ___ 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] Python 4: don't remove anything, don't break backward compatibility
Hi! On Mon, Mar 10, 2014 at 04:49:44PM +, Brett Cannon wrote: > I think it got lost in email threading, but Barry pointed out that Guido > famously hates double digit version numbers (as do I, probably partially > because he does after all these years =). There is one minor annoyance with double digits: $ ls -l total 16 drwx-- 2 phd phd 4096 Mar 10 21:42 3.1 drwx-- 2 phd phd 4096 Mar 10 21:42 3.10 drwx-- 2 phd phd 4096 Mar 10 21:42 3.2 ... ... drwx-- 2 phd phd 4096 Mar 10 21:42 4.0 Other than that I don't see any problem, and don't see any need to jump from 3.9 to 4.0. Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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] Python 4: don't remove anything, don't break backward compatibility
On Mon, Mar 10, 2014 at 04:37:45PM +, Brett Cannon wrote: > On Mon Mar 10 2014 at 12:08:55 PM, Victor Stinner > wrote: > > > >> I suggest to wait less than 8 years > > >> for Python 4. > > > > > > Why? What's special about 8 years? > > > > It's the time between Python 2.0 and 3.0. > > But I'm willing to bet that's going to be an anomaly. Python 3 came into > existence when it did so we didn't wait too long for Python 2 to get even > more of a foothold; the expectation is that long-term more non-Python 2 > code will be written than not. There's no rush on Python 4 since there are > no plans to try and tweak something as drastic as str/bytes. Well, the entire discussion is about "please don't do major changes -- we've got enough already". Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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] What is the precise problem? [was: Reference cycles in Exception.__traceback__]
On Mon, Mar 10, 2014 at 10:39 AM, Maciej Fijalkowski wrote: > On Mon, Mar 10, 2014 at 7:35 PM, Guido van Rossum > wrote: > > On Mon, Mar 10, 2014 at 10:30 AM, Maciej Fijalkowski > > wrote: > >> > >> On Mon, Mar 10, 2014 at 3:23 PM, Victor Stinner > >> wrote: > >> > 2014-03-10 13:11 GMT+01:00 Maciej Fijalkowski : > >> >> It was agreed long time ago that the immediate finalization is an > >> >> implementation specific detail and it's not guaranteed. You should > not > >> >> rely on __del__s being called timely one way or another. Why would > you > >> >> require this for the program to work correctly in the particular > >> >> example of __traceback__? > >> > > >> > For asyncio, it's very useful to see unhandled exceptions as early as > >> > possible. Otherwise, your program is blocked and you don't know why. > >> > > >> > Guido van Rossum suggests to run gc.collect() regulary: > >> > http://code.google.com/p/tulip/issues/detail?id=42 > >> > > >> > Victor > >> > >> twisted goes around it by attaching errback by hand. Would that work for > >> tulip? > > > > > > Can you describe that idea in more detail? > > Essentially, instead of relying on deferred to be garbage collected, > you attach an errback like this: > > deferred.addErrback(callback_that_writes_to_log) > > so in case of a failure, you get a traceback directly in the callback > immediately, without relying on garbage collection. > > I'm sorry if I'm using twisted nomenclature here (it's also awfully > off-topic for python-dev), but making programs rely on refcounting > sounds like a bad idea for us (PyPy). > IIUC the problem that Victor is trying to solve is what to do if nobody thought to attach an errback. Tulip makes a best effort to still log a traceback. We've found this very helpful (just as it is helpful that Python prints a traceback when synchronous code raises an exception and no except clause caught it). The best effort relies on GC. I am guessing that refcounting makes the traceback appear sooner, but there would be other ways to force it, like occasionally calling gc.collect() during idle times (presumably during busy times it will be called soon enough. :-) -- --Guido van Rossum (python.org/~guido) ___ 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] Windows 'for current user' installation - 32/64-bit registrations overwrite each other
Am 10.03.14 14:03, schrieb Jurko Gospodnetić: > Is this as issue or desired behaviour? See my response in the tracker. It's desired by Microsoft. Regards, Martin ___ 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] What is the precise problem? [was: Reference cycles in Exception.__traceback__]
On Mon, Mar 10, 2014 at 7:49 PM, Guido van Rossum wrote: > On Mon, Mar 10, 2014 at 10:39 AM, Maciej Fijalkowski > wrote: >> >> On Mon, Mar 10, 2014 at 7:35 PM, Guido van Rossum >> wrote: >> > On Mon, Mar 10, 2014 at 10:30 AM, Maciej Fijalkowski >> > wrote: >> >> >> >> On Mon, Mar 10, 2014 at 3:23 PM, Victor Stinner >> >> wrote: >> >> > 2014-03-10 13:11 GMT+01:00 Maciej Fijalkowski : >> >> >> It was agreed long time ago that the immediate finalization is an >> >> >> implementation specific detail and it's not guaranteed. You should >> >> >> not >> >> >> rely on __del__s being called timely one way or another. Why would >> >> >> you >> >> >> require this for the program to work correctly in the particular >> >> >> example of __traceback__? >> >> > >> >> > For asyncio, it's very useful to see unhandled exceptions as early as >> >> > possible. Otherwise, your program is blocked and you don't know why. >> >> > >> >> > Guido van Rossum suggests to run gc.collect() regulary: >> >> > http://code.google.com/p/tulip/issues/detail?id=42 >> >> > >> >> > Victor >> >> >> >> twisted goes around it by attaching errback by hand. Would that work >> >> for >> >> tulip? >> > >> > >> > Can you describe that idea in more detail? >> >> Essentially, instead of relying on deferred to be garbage collected, >> you attach an errback like this: >> >> deferred.addErrback(callback_that_writes_to_log) >> >> so in case of a failure, you get a traceback directly in the callback >> immediately, without relying on garbage collection. >> >> I'm sorry if I'm using twisted nomenclature here (it's also awfully >> off-topic for python-dev), but making programs rely on refcounting >> sounds like a bad idea for us (PyPy). > > > IIUC the problem that Victor is trying to solve is what to do if nobody > thought to attach an errback. Tulip makes a best effort to still log a > traceback. We've found this very helpful (just as it is helpful that Python > prints a traceback when synchronous code raises an exception and no except > clause caught it). > > The best effort relies on GC. I am guessing that refcounting makes the > traceback appear sooner, but there would be other ways to force it, like > occasionally calling gc.collect() during idle times (presumably during busy > times it will be called soon enough. :-) > > -- > --Guido van Rossum (python.org/~guido) I agree this sounds like a solution. However I'm very skeptical about changing details of __traceback__ and frames, just in order to make refcounting work (since it would create something that would not work on pypy for example). Cheers, fijal ___ 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] Python 4: don't remove anything, don't break backward compatibility
On 03/10/2014 08:59 AM, Barry Warsaw wrote: On Mar 10, 2014, at 04:25 PM, Stefan Richthofer wrote: I don't see any reason to bump the major version number until after Python 3.9. Even then, there is no need for 4.0; you can just have 3.10, 3.11 etc. Guido famously hates two digit minor version numbers. :) Yeah, but he'll be retired by then. So shh! No wonder he doesn't use Ubuntu, //arry/ ___ 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] What is the precise problem? [was: Reference cycles in Exception.__traceback__]
On Mon, Mar 10, 2014 at 10:56 AM, Maciej Fijalkowski wrote: > On Mon, Mar 10, 2014 at 7:49 PM, Guido van Rossum > wrote: > > On Mon, Mar 10, 2014 at 10:39 AM, Maciej Fijalkowski > > wrote: > >> > >> On Mon, Mar 10, 2014 at 7:35 PM, Guido van Rossum > >> wrote: > >> > On Mon, Mar 10, 2014 at 10:30 AM, Maciej Fijalkowski < > fij...@gmail.com> > >> > wrote: > >> >> > >> >> On Mon, Mar 10, 2014 at 3:23 PM, Victor Stinner > >> >> wrote: > >> >> > 2014-03-10 13:11 GMT+01:00 Maciej Fijalkowski : > >> >> >> It was agreed long time ago that the immediate finalization is an > >> >> >> implementation specific detail and it's not guaranteed. You should > >> >> >> not > >> >> >> rely on __del__s being called timely one way or another. Why would > >> >> >> you > >> >> >> require this for the program to work correctly in the particular > >> >> >> example of __traceback__? > >> >> > > >> >> > For asyncio, it's very useful to see unhandled exceptions as early > as > >> >> > possible. Otherwise, your program is blocked and you don't know > why. > >> >> > > >> >> > Guido van Rossum suggests to run gc.collect() regulary: > >> >> > http://code.google.com/p/tulip/issues/detail?id=42 > >> >> > > >> >> > Victor > >> >> > >> >> twisted goes around it by attaching errback by hand. Would that work > >> >> for > >> >> tulip? > >> > > >> > > >> > Can you describe that idea in more detail? > >> > >> Essentially, instead of relying on deferred to be garbage collected, > >> you attach an errback like this: > >> > >> deferred.addErrback(callback_that_writes_to_log) > >> > >> so in case of a failure, you get a traceback directly in the callback > >> immediately, without relying on garbage collection. > >> > >> I'm sorry if I'm using twisted nomenclature here (it's also awfully > >> off-topic for python-dev), but making programs rely on refcounting > >> sounds like a bad idea for us (PyPy). > > > > > > IIUC the problem that Victor is trying to solve is what to do if nobody > > thought to attach an errback. Tulip makes a best effort to still log a > > traceback. We've found this very helpful (just as it is helpful that > Python > > prints a traceback when synchronous code raises an exception and no > except > > clause caught it). > > > > The best effort relies on GC. I am guessing that refcounting makes the > > traceback appear sooner, but there would be other ways to force it, like > > occasionally calling gc.collect() during idle times (presumably during > busy > > times it will be called soon enough. :-) > > > > -- > > --Guido van Rossum (python.org/~guido) > > I agree this sounds like a solution. However I'm very skeptical about > changing details of __traceback__ and frames, just in order to make > refcounting work (since it would create something that would not work > on pypy for example). > Agreed, I think we knew what we were in for when we added __traceback__ to Python 3, and I don't think now is the time to reconsider. Now is the time to learn to live with it. -- --Guido van Rossum (python.org/~guido) ___ 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] Python 4: don't remove anything, don't break backward compatibility
Am 10.03.14 18:01, schrieb Tres Seaver: > On 03/10/2014 12:49 PM, Brett Cannon wrote: > >> I think it got lost in email threading, but Barry pointed out that >> Guido famously hates double digit version numbers (as do I, probably >> partially because he does after all these years =). > > "Guido hates them" isn't an argument: its a ukase. Indeed, it is - so obey it then :-) We live in a dictatorship, after all. Regards, Martin ___ 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] Python 4: don't remove anything, don't break backward compatibility
On 2014-03-10 17:06, Chris Angelico wrote: On Tue, Mar 11, 2014 at 3:56 AM, Antoine Pitrou wrote: On Mon, 10 Mar 2014 17:04:08 +0100 "Stefan Richthofer" wrote: > Guido famously hates two digit minor version numbers. :) This is no problem either. Simply switch to hexadecimal numbering ;) Or wrap around to negative numbers (a minus sign isn't technically a digit, is it?). Terrible idea. Would wreak havoc with comparisons. No. Python 3 is all about Unicode, so the right way to proceed is 3.8, 3.9, 3.:, 3.;, 3.<, 3.=, 3.>, 3.?, 3.@, 3.A. Let's stick to digits. We could move on to Devanagari or Gurmukhi digits. ___ 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] Python 4: don't remove anything, don't break backward compatibility
On 2014-03-10 17:08, R. David Murray wrote: On Mon, 10 Mar 2014 16:06:22 -, Brett Cannon wrote: On Mon Mar 10 2014 at 11:50:54 AM, Victor Stinner wrote: > 2014-03-10 16:25 GMT+01:00 Stefan Richthofer : > > I don't see the point in this discussion. > > As far as I know, the major version is INTENDED to > > indicate backward-incompatible changes. > > This is not a strict rule. I would like to follow Linux 3 which didn't > break the API between Linux 2 and Linux 3. > I disagree. I don't think 3->4 will be as drastic as it was for 2->3, but I view Python 4 as a chance to drop all deprecated APIs that we left in for convenience in porting from Python 2 (e.g. the imp module). We can't put a removal date as we can't really declare Python 2 dead for the whole community. But when Python 4 does come out next decade I would like to say that we have moved entirely beyond Python 2 as a team and thus don't turn into Java and support deprecated code forever. We had this discussion a bit ago, and my sense was that we tentatively decided that we were just going to deprecate and remove things as appropriate, irregardless of version number. I used "4.0" in my message about 'U' as a shorthand for "some time after python2 is no longer an issue". Sorry for the confusion. (That said, I do see some merit to doing some extra cleaning at the 4.0 boundary, just for mental convenience.) What does "irregardless" mean? ___ 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] Python 4: don't remove anything, don't break backward compatibility
You forgot 3., and 3.$. On Mon, Mar 10, 2014 at 12:06 PM, Chris Angelico wrote: > On Tue, Mar 11, 2014 at 3:56 AM, Antoine Pitrou > wrote: > > On Mon, 10 Mar 2014 17:04:08 +0100 > > "Stefan Richthofer" wrote: > > > >> > Guido famously hates two digit minor version numbers. :) > >> > >> This is no problem either. Simply switch to hexadecimal numbering ;) > > > > Or wrap around to negative numbers (a minus sign isn't technically a > > digit, is it?). > > Terrible idea. Would wreak havoc with comparisons. No. Python 3 is all > about Unicode, so the right way to proceed is 3.8, 3.9, 3.:, 3.;, 3.<, > 3.=, 3.>, 3.?, 3.@, 3.A. > > ChrisA > ___ > 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/rymg19%40gmail.com > -- Ryan If anybody ever asks me why I prefer C++ to C, my answer will be simple: "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was nul-terminated." ___ 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] Python 4: don't remove anything, don't break backward compatibility
On Mar 10, 2014, at 2:21 PM, MRAB wrote: > On 2014-03-10 17:08, R. David Murray wrote: >> On Mon, 10 Mar 2014 16:06:22 -, Brett Cannon wrote: >>> On Mon Mar 10 2014 at 11:50:54 AM, Victor Stinner >>> wrote: >>> >>> > 2014-03-10 16:25 GMT+01:00 Stefan Richthofer : >>> > > I don't see the point in this discussion. >>> > > As far as I know, the major version is INTENDED to >>> > > indicate backward-incompatible changes. >>> > >>> > This is not a strict rule. I would like to follow Linux 3 which didn't >>> > break the API between Linux 2 and Linux 3. >>> > >>> >>> I disagree. I don't think 3->4 will be as drastic as it was for 2->3, but I >>> view Python 4 as a chance to drop all deprecated APIs that we left in for >>> convenience in porting from Python 2 (e.g. the imp module). We can't put a >>> removal date as we can't really declare Python 2 dead for the whole >>> community. But when Python 4 does come out next decade I would like to say >>> that we have moved entirely beyond Python 2 as a team and thus don't turn >>> into Java and support deprecated code forever. >> >> We had this discussion a bit ago, and my sense was that we tentatively >> decided that we were just going to deprecate and remove things as >> appropriate, irregardless of version number. I used "4.0" in my >> message about 'U' as a shorthand for "some time after python2 >> is no longer an issue". Sorry for the confusion. (That said, I >> do see some merit to doing some extra cleaning at the 4.0 >> boundary, just for mental convenience.) >> > What does "irregardless" mean? http://www.merriam-webster.com/dictionary/irregardless > ___ > 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/donald%40stufft.io - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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] Python 4: don't remove anything, don't break backward compatibility
On 03/10/2014 02:21 PM, MRAB wrote: > On 2014-03-10 17:08, R. David Murray wrote: >> On Mon, 10 Mar 2014 16:06:22 -, Brett Cannon >> wrote: >>> On Mon Mar 10 2014 at 11:50:54 AM, Victor Stinner >>> >>> wrote: >>> >>> > 2014-03-10 16:25 GMT+01:00 Stefan Richthofer >>> : >>> > > I don't see the point in this discussion. >>> > > As far as I know, the major version is INTENDED to >>> > > indicate backward-incompatible changes. >>> > >>> > This is not a strict rule. I would like to follow Linux 3 which didn't >>> > break the API between Linux 2 and Linux 3. >>> > >>> >>> I disagree. I don't think 3->4 will be as drastic as it was for 2->3, >>> but I >>> view Python 4 as a chance to drop all deprecated APIs that we left in >>> for >>> convenience in porting from Python 2 (e.g. the imp module). We can't >>> put a >>> removal date as we can't really declare Python 2 dead for the whole >>> community. But when Python 4 does come out next decade I would like >>> to say >>> that we have moved entirely beyond Python 2 as a team and thus don't >>> turn >>> into Java and support deprecated code forever. >> >> We had this discussion a bit ago, and my sense was that we tentatively >> decided that we were just going to deprecate and remove things as >> appropriate, irregardless of version number. I used "4.0" in my >> message about 'U' as a shorthand for "some time after python2 >> is no longer an issue". Sorry for the confusion. (That said, I >> do see some merit to doing some extra cleaning at the 4.0 >> boundary, just for mental convenience.) >> > What does "irregardless" mean? Read it as "without regard to". ___ 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] Python 4: don't remove anything, don't break backward compatibility
This is my standpoint. The major releases would remove the code that's been marked as "deprecated". You probably would've know for the past 3 versions anyway... On Mon, Mar 10, 2014 at 12:13 PM, Chris Angelico wrote: > On Tue, Mar 11, 2014 at 4:08 AM, R. David Murray > wrote: > > (That said, I > > do see some merit to doing some extra cleaning at the 4.0 > > boundary, just for mental convenience.) > > A transition from 3.9 to 4.0 that removes a whole lot of deprecated > aliases and such wouldn't be a bad thing. It's technically breaking > backward compat (and thus justifying the major version bump), but any > code broken by it would have been unidiomatic for the past X versions > anyway. > > ChrisA > ___ > 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/rymg19%40gmail.com > -- Ryan If anybody ever asks me why I prefer C++ to C, my answer will be simple: "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was nul-terminated." ___ 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] Python 4: don't remove anything, don't break backward compatibility
On 10 March 2014 17:08, R. David Murray wrote: > We had this discussion a bit ago, and my sense was that we tentatively > decided that we were just going to deprecate and remove things as > appropriate, irregardless of version number. I used "4.0" in my > message about 'U' as a shorthand for "some time after python2 > is no longer an issue". Sorry for the confusion. (That said, I > do see some merit to doing some extra cleaning at the 4.0 > boundary, just for mental convenience.) I have seen a number of postings recently pointing to things as "not until Python 4000" or "not until Python 4.0" (yours was not one that I noticed, actually, this is a more general point). I do think it's a bad idea to start talking in terms of "the next big compatibility break", even if *we* know there's no immediate plan. People are very quick to pick up messages like "Now that Python 3 is out of the way, the Python devs are talking about Python 4" which is not a message we want to see getting traction. I'm neither averse to, nor in favour of, a Python 4 compatibility break in due course, but maybe we should avoid letting the idea take hold this soon. Users are still concerned about the Python 3 change, it wouldn't do any harm if they got the clear message "at least it's a one-off exercise". Paul ___ 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] Python 4: don't remove anything, don't break backward compatibility
On Tue, Mar 11, 2014 at 5:17 AM, Ryan Gonzalez wrote: > You forgot 3., and 3.$. > They're both earlier than digits. Comma is 2C and dollar is 24, I remember those from the earliest days of playing around in assembly language on an Epson PC-compatible running MS-DOS 5 :) But that's beside the point. I don't think there'd be huge problems with a 4.0 release that's just like 3.10 except that it's a little more free with removal of deprecateds. Maybe that could be the point at which 2.x compatibility is dropped, like the u"string" notation. Or maybe not :) ChrisA ___ 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] Python 4: don't remove anything, don't break backward compatibility
10.03.14 20:50, Paul Moore написав(ла): I have seen a number of postings recently pointing to things as "not until Python 4000" or "not until Python 4.0" (yours was not one that I noticed, actually, this is a more general point). This is just an euphemism for "not in observable future". ___ 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] Python 4: don't remove anything, don't break backward compatibility
On 3/10/2014 12:29 PM, Chris Angelico wrote: I don't think there'd be huge problems with a 4.0 release that's just like 3.10 except that it's a little more free with removal of deprecateds. Maybe that could be the point at which 2.x compatibility is dropped, ... and the point at which those of us on 2.x jump over 3.x to 4.x. :) Emile ___ 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] Python 4: don't remove anything, don't break backward compatibility
10.03.14 19:44, Oleg Broytman написав(ла): There is one minor annoyance with double digits: $ ls -l total 16 drwx-- 2 phd phd 4096 Mar 10 21:42 3.1 drwx-- 2 phd phd 4096 Mar 10 21:42 3.10 drwx-- 2 phd phd 4096 Mar 10 21:42 3.2 ... ... drwx-- 2 phd phd 4096 Mar 10 21:42 4.0 ls -lv ___ 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] Python 4: don't remove anything, don't break backward compatibility
On 03/10/2014 11:21 AM, MRAB wrote: What does "irregardless" mean? The same thing as "regardless", with an extra syllable just for fun. -- ~Ethan~ ___ 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] Python 4: don't remove anything, don't break backward compatibility
On Mon, Mar 10, 2014 at 09:47:32PM +0200, Serhiy Storchaka wrote: > 10.03.14 19:44, Oleg Broytman написав(ла): > >There is one minor annoyance with double digits: > > > >$ ls -l > >total 16 > >drwx-- 2 phd phd 4096 Mar 10 21:42 3.1 > >drwx-- 2 phd phd 4096 Mar 10 21:42 3.10 > >drwx-- 2 phd phd 4096 Mar 10 21:42 3.2 > >... ... > >drwx-- 2 phd phd 4096 Mar 10 21:42 4.0 > > ls -lv Not every filemanager can do that. Not even every ls: $ uname -a FreeBSD 9.2-RELEASE $ man ls | grep -F -- -v Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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] Python 4: don't remove anything, don't break backward compatibility
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/10/2014 02:50 PM, Paul Moore wrote: > I have seen a number of postings recently pointing to things as "not > until Python 4000" or "not until Python 4.0" (yours was not one that > I noticed, actually, this is a more general point). > > I do think it's a bad idea to start talking in terms of "the next big > compatibility break", even if *we* know there's no immediate plan. > People are very quick to pick up messages like "Now that Python 3 is > out of the way, the Python devs are talking about Python 4" which is > not a message we want to see getting traction. Exactly. If we can't do things sensibly / incrementally without learning from the painful lessons of the past eight years, we ought to give up on the prospect of doing language design altogether. > I'm neither averse to, nor in favour of, a Python 4 compatibility > break in due course I am. I don't think the community can stand another such break. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMeHRsACgkQ+gerLs4ltQ4p0QCeLWgr2/qOSHmRBLLD+Wz0/+k/ EcwAn2p4lXARRCEYhyqsDpwhq/SrVEak =ZpwN -END PGP SIGNATURE- ___ 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] Python 3.4 change in importlib/__init__.py breaking cxFreeze?
On 11 Mar 2014 01:44, "Brett Cannon" wrote: > > > > On Mon Mar 10 2014 at 11:41:27 AM, Jurko Gospodnetić < jurko.gospodne...@pke.hr> wrote: >> >>Hi Nick. >> >> On 10.3.2014. 14:25, Nick Coghlan wrote:> What is supposed to happen >> when that code gets loaded from a ZIP archive? >> > >> > __file__ is expected to always be set (including when loaded from a >> > zipfile - in that case it's the zipfile name concatenated with the >> > path within the zip file). If it isn't set, there's a buggy loader >> > involved somewhere that isn't setting it properly. >> >>I don't recall seeing that ever explicitly stated. For that matter, >> Python 3.4.0rc3 documentation explicitly states: >> >> > __file__ is optional. If set, this attribute’s value must be a string. >> > The import system may opt to leave __file__ unset if it has no >> > semantic meaning (e.g. a module loaded from a database). >> >>and: >> >> > Ultimately, the loader is what makes use of __file__ and/or __cached__. >> >>Or is this some rule specific to the importlib/__init__.py stdlib module? > > > No, Nick was mistaken and Barry's response is accurate: __file__ is optional and left off when it doesn't make any sense. Since importlib._bootstrap is a frozen module by default it doesn't have __file__ set. Yeah, I was thinking of the 3.4 changes to ensure that various *other* module attributes are always set, even in __main__ (and frozen modules). My apologies for the misinformation - I should have waited until I had a chance to look it up properly. Cheers, Nick. > > -Brett > >> >> >>As I recall, I first learned that not all loaded modules need to have >> their __file__ attribute set by researching a failure in some package >> when installed as a zipped-egg using setuptools. Admittedly though, that >> was some old setuptools version. >> >>Best regards, >> Jurko Gospodnetić >> >> ___ >> 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/brett%40python.org ___ 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] Python 4: don't remove anything, don't break backward compatibility
On Mon, Mar 10, 2014 at 12:42 PM, Serhiy Storchaka wrote: > This is just an euphemism for "not in observable future". > > is ANY of the future observable? Oh right, The Time Machine! -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ 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] Python 4: don't remove anything, don't break backward compatibility
On 10 March 2014 19:42, Serhiy Storchaka wrote:
> 10.03.14 20:50, Paul Moore написав(ла):
>
>> I have seen a number of postings recently pointing to things as "not
>> until Python 4000" or "not until Python 4.0" (yours was not one that I
>> noticed, actually, this is a more general point).
>
>
> This is just an euphemism for "not in observable future".
I understand that - my concern is that people reading such comments
out of context might not realise this ("after all, that was what
Python 3000 meant, then you went and implemented it").
Paul
___
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] Python 4: don't remove anything, don't break backward compatibility
On 10/03/2014 19:28, Ethan Furman wrote: On 03/10/2014 11:21 AM, MRAB wrote: What does "irregardless" mean? The same thing as "regardless", with an extra syllable just for fun. -- ~Ethan~ Is this the UK, US, Australian or some other "regardless"? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com ___ 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] Python 4: don't remove anything, don't break backward compatibility
Chris Angelico wrote: Terrible idea. Would wreak havoc with comparisons. No. Python 3 is all about Unicode, so the right way to proceed is 3.8, 3.9, 3.:, 3.;, 3.<, 3.=, 3.>, 3.?, 3.@, 3.A. And we have all of UCS-4 to play with, so for all practical purposes the 3.x line can live forever! The downside is that we'll get endless complaints from jmfauth about the Flexible Version Number Representation. :-( -- Greg ___ 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] Python 4: don't remove anything, don't break backward compatibility
MRAB wrote: What does "irregardless" mean? It's what people say when they misunderestimate the importance of correct prefix usage in English. -- Greg ___ 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] Python 4: don't remove anything, don't break backward compatibility
On 10/03/2014 22:28, Greg Ewing wrote: Chris Angelico wrote: Terrible idea. Would wreak havoc with comparisons. No. Python 3 is all about Unicode, so the right way to proceed is 3.8, 3.9, 3.:, 3.;, 3.<, 3.=, 3.>, 3.?, 3.@, 3.A. And we have all of UCS-4 to play with, so for all practical purposes the 3.x line can live forever! The downside is that we'll get endless complaints from jmfauth about the Flexible Version Number Representation. :-( Drat, drat and double drat, you beat me to it :) -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com ___ 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] Python 4: don't remove anything, don't break backward compatibility
I'm not a dev, so my comment doesn't have that much weight, but it is possible to stop flooding the mailing list with idle chitchat about something mostly irrelevant and non-productive? There's nothing wrong with the current Python versioning scheme. Python 4 is not planned for the near future. I don't see anything else worthy of discussion on this topic. Allen Li On Mon, Mar 10, 2014 at 10:35:29PM +, Mark Lawrence wrote: > On 10/03/2014 22:28, Greg Ewing wrote: > >Chris Angelico wrote: > >>Terrible idea. Would wreak havoc with comparisons. No. Python 3 is all > >>about Unicode, so the right way to proceed is 3.8, 3.9, 3.:, 3.;, 3.<, > >>3.=, 3.>, 3.?, 3.@, 3.A. > > > >And we have all of UCS-4 to play with, so for all > >practical purposes the 3.x line can live forever! > > > >The downside is that we'll get endless complaints > >from jmfauth about the Flexible Version Number > >Representation. :-( > > > > Drat, drat and double drat, you beat me to it :) > > -- > My fellow Pythonistas, ask not what our language can do for you, ask what > you can do for our language. > > Mark Lawrence > > --- > This email is free from viruses and malware because avast! Antivirus > protection is active. > http://www.avast.com > > > ___ > 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/cyberdupo56%40gmail.com ___ 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] What is the precise problem? [was: Reference cycles in Exception.__traceback__]
On Mon Mar 10 18:56:17 CET 2014 (and earlier quotes), Maciej Fijalkowski wrote: Maciej:>> You should not rely on __del__s being called timely one way or Maciej:>> another. Why would you require this for the program to work Maciej:>> correctly in the particular example of __traceback__? To the extent that I understand, he isn't requiring it for correctness; he is instead saying that without timely __del__, the Quality of Implementation suffers. I suspect there are aspects of tulip (or event processing in general) that make it more common for the frame graph to be painfully cyclic, so that live frames keep dead ones from being collected. It may also be more common to have multiple __del__ methods in the same cycle, if cycles are created by a framework. So the problems aren't new, but they may have become considerably more painful. Victor:> For asyncio, it's very useful to see unhandled exceptions as early as Victor:> possible. Otherwise, your program is blocked and you don't know why. ... Maciej:>> twisted goes around it by attaching errback by hand. Would that work Maciej:>> for tulip? Maciej:>> deferred.addErrback(callback_that_writes_to_log) What do you mean "by hand"? Does the framework automatically add a "log the exception" errback to every task, or every task that doesn't have its own errback of some sort? Or do you mean that users should do so by hand, but that it is a well-known recipe? Maciej:>> I'm very skeptical about changing details of __traceback__ and Maciej:>> frames, just in order to make refcounting work (since it would Maciej:>> create something that would not work on pypy for example). How about just loosening some constraints on exceptions, in order to permit more efficient operation, but in a way that may be particularly useful to a refcounting scheme? Can I assume that you don't object to frame.clear()? How about a hypothethetical traceback.pack() that made it easier to reclaim memory held by frame/traceback cycles? If standard traceback printing were the only likely future use, each frame/traceback pair could be replaced by 4 pointers, and allocating space/copying those 4 would be the only work that wasn't already needed for the eventual deallocation. Today, the setters for __cause__, __context__, and __traceback do typechecks to ensure that those properties are (None or) the expected type; __traceback__ doesn't even allow subclasses. The constructors for frame and traceback are similarly strict. What would be the harm in allowing arbitrary objects, let alone a few specific alternative implementations? -jJ -- If there are still threading problems with my replies, please email me with details, so that I can try to resolve them. -jJ ___ 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] What is the precise problem? [was: Reference cycles in Exception.__traceback__]
On Mon, 10 Mar 2014 16:08:52 -0700 (PDT) "Jim J. Jewett" wrote: > It may also be more common to have multiple __del__ methods in the > same cycle, if cycles are created by a framework. So the problems > aren't new, but they may have become considerably more painful. Multiple __del__s shouldn't change anything compared to a single __del__ or even none (see PEP 442). > Maciej:>> I'm very skeptical about changing details of __traceback__ and > Maciej:>> frames, just in order to make refcounting work (since it would > Maciej:>> create something that would not work on pypy for example). > > How about just loosening some constraints on exceptions, in order to > permit more efficient operation, but in a way that may be particularly > useful to a refcounting scheme? Can I assume that you don't object to > frame.clear()? I posted a prototype change (in this thread) which automatically calls frame.clear(), I didn't get any feedback about it. Regards Antoine. ___ 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] undocumented help() function change in Python 3.4?
On Mon, 10 Mar 2014 14:15:28 +0100, =?UTF-8?B?SnVya28gR29zcG9kbmV0acSH?= wrote: >Hi. > > On 8.3.2014. 6:48, Nick Coghlan wrote: > > Yeah, the changes to help() are doubly indirect - help() uses pydoc > > which uses inspect, and inspect saw a lot of changes. > > > > I'll make a few updates to the What's New to help make the > > consequences of this clearer. > >Just looked through the latest 3.4rc3 release and nothing related to > this seems to have been included yet. The whatsnew updates (including the one for help) weren't copied into rc3. They will be in final though, unless Larry forgets. You can see them here: http://docs.python.org/dev/whatsnew/3.4.html --David ___ 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] Whats New in 3.4 is pretty much done...
Well, I think What's New for 3.4 is done. I've been through all of the NEWS items from the start of 3.4 through the beta1 release. I've gone over the list of changes Serhiy found via the versionadded/versionchanged in the docs. (Since he marked some that didn't turn out to be 3.4 changes, I assume he was over-inclusive rather than under-inclusive and am not going to re-run that particular check myself...thanks Serhiy for doing it!). In addition to the items in Serhiy's list that didn't have news entries, there were a couple of features that were added after Beta1. So there might be some other features with missing versionadded/changed tags in the NEWS sections I didn't go through, but I hope not. Slightly more worrisome is the possibility that I'm missing porting notes from the beta/rc phases. But, I'm pretty much out of time for this project since Final is almost upon us. I'll be making at least one more copy-edit pass over the document, and may reformat some stuff, but the content is pretty much set at this point. If anyone knows of anything that is missing, please let me know about it. --David I track my time as a habit, so for the curious I can tell you with a fair degree of accuracy how long this little project took: about 73 hours total, starting on 12/20 last year. Let me tell you, it felt even longer than that :) ___ 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] Python 4: don't remove anything, don't break backward compatibility
On 10Mar2014 14:55, Victor Stinner wrote: > Last 5 years, I spend significant time to port a lot of Python 2 code > on Python 3. [... troubles ...] > So can we please try to stop scheduling another major Python version > breaking almost all modules and all applications just to be pendantic? > No, we should not remove any old feature in Python 4. Python 4 should > be just a minor release following the previous 3.x release. Maybe that will be the case, when it rolls around in the ordinary sequence of things. Assuming nothing groundbreaks shows up. > I don't want another six, nine or whatever module to fill the gap > between Python 3 and Python 4. But this I do not understand. If 4.0 is in your vision to be a regular release, why should you care that it may be years off? > For example, I propose to release the next major Python version (3.5) > with the version 4.0 but without removing anything. (It's just an > example, it can wait another release.) Just in case this is not a joke or hyperbole: I am -1 on this. Just stick with the expected numbering scheme. If there are no incompatible but desired changes queued up by the time 4.0, perhaps that will be a normal release also. If not, perhaps it will be a good time to bite the bullet. > I mean that any incompatible > change must following the classic transition plan: tag the feature as > deprecated and wait at least one major version before dropping it, or > just keep it forever. We can expect that just changing the major > version (3 => 4) will already break enough applications (where > "python3" or "version == 3" is hardcoded")... I tend to spell this >= 3, etc. Maybe I'm being simplistic. > Instead of asking application developers to try to follow each major > Python release, we should try to keep the maintaince pain in Python > core. > > What do you think? I agree there shouldn't be a major porting pain release just for the sake of a number change; anything like that should need justification. But conversely, I'm dead against bringing forward version 4.0 just to break the expectation of breakage. Cheers, -- Cameron Simpson The nice thing about standards is that you have so many to choose from; furthermore, if you do not like any of them, you can just wait for next year's model. - Andrew S. Tanenbaum ___ 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] Whats New in 3.4 is pretty much done...
Thanks for all of the great work! -- Eric. > On Mar 10, 2014, at 10:05 PM, "R. David Murray" wrote: > > Well, I think What's New for 3.4 is done. I've been through all of the > NEWS items from the start of 3.4 through the beta1 release. I've gone > over the list of changes Serhiy found via the versionadded/versionchanged > in the docs. (Since he marked some that didn't turn out to be 3.4 > changes, I assume he was over-inclusive rather than under-inclusive > and am not going to re-run that particular check myself...thanks > Serhiy for doing it!). > > In addition to the items in Serhiy's list that didn't have news entries, > there were a couple of features that were added after Beta1. So there > might be some other features with missing versionadded/changed tags in > the NEWS sections I didn't go through, but I hope not. Slightly more > worrisome is the possibility that I'm missing porting notes from the > beta/rc phases. But, I'm pretty much out of time for this project since > Final is almost upon us. I'll be making at least one more copy-edit > pass over the document, and may reformat some stuff, but the content is > pretty much set at this point. > > If anyone knows of anything that is missing, please let me know about > it. > > --David > > I track my time as a habit, so for the curious I can tell you with > a fair degree of accuracy how long this little project took: about 73 > hours total, starting on 12/20 last year. Let me tell you, it felt even > longer than that :) > ___ > 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/eric%2Ba-python-dev%40trueblade.com > ___ 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] undocumented help() function change in Python 3.4?
On 11 March 2014 11:29, R. David Murray wrote: > The whatsnew updates (including the one for help) weren't copied into > rc3. They will be in final though, unless Larry forgets. Oh, cool - yes, it will be good to have an up to date What's New shipped, especially as part of the compiled Windows docs. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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] undocumented help() function change in Python 3.4?
In article , Nick Coghlan wrote: > On 11 March 2014 11:29, R. David Murray wrote: > > The whatsnew updates (including the one for help) weren't copied into > > rc3. They will be in final though, unless Larry forgets. > > Oh, cool - yes, it will be good to have an up to date What's New > shipped, especially as part of the compiled Windows docs. I was going to bring that point up today. How are all the new whatsnew updates going to get into the 3.4.0 release? They've, correctly, been being pushed to the default branch. But, AFAIK, for them to show up in the 3.4.0 released docs we ship, all of the doc changes are going to need to be cherry picked (or a big mass diff from the default branch) into the 3.4 release branch, otherwise they will not be part of the release. (They certainly won't be part of the docs included with the installers I build unless they are in the 3.4 releasing branch.) Thank you for all the work you've been putting into the whatsnew doc! -- Ned Deily, n...@acm.org ___ 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] Whats New in 3.4 is pretty much done...
On Mon, Mar 10, 2014 at 8:05 PM, R. David Murray wrote: > Well, I think What's New for 3.4 is done. I've been through all of the > NEWS items from the start of 3.4 through the beta1 release. > > I'm pretty much out of time for this project since > Final is almost upon us. I'll be making at least one more copy-edit > pass over the document, and may reformat some stuff, but the content is > pretty much set at this point. > > > I track my time as a habit, so for the curious I can tell you with > a fair degree of accuracy how long this little project took: about 73 > hours total, starting on 12/20 last year. Let me tell you, it felt even > longer than that :) Thanks for taking the time on something that I image isn't all that fun! -eric ___ 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] Python 4: don't remove anything, don't break backward compatibility
Paul Moore writes:
> I understand that - my concern is that people reading such comments
> out of context might not realise this ("after all, that was what
> Python 3000 meant, then you went and implemented it").
Sure, but why worry about it? The important part of "willful
ignorance" is the "willful". We can't "fix" people who are willing to
accept that crap -- they'll find some other crap to believe.
Python 3 already has undeniable cruft (some Python 2 compatibility
stuff) and arguably some things that could have been done better but
can't really be changed in Python 3 (see the backtrace thread).
Python makes strong promises that those things will *not* become
compatibility breaks within 3.x, even if we're pretty confident that
"nobody" is using them any more, and especially not when we now just
think we could have done a better job on some feature. The flip side
of that is that Python 4000 is going to be mentioned as the
appropriate time for changing them.
If that confuses people, well, we can just unconfuse them (if that's
OK with them...).
___
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] Python 4: don't remove anything, don't break backward compatibility
Am 10.03.2014 23:58, schrieb Allen Li: > I'm not a dev, so my comment doesn't have that much weight, but it is > possible to stop flooding the mailing list with idle chitchat about > something mostly irrelevant and non-productive? > > There's nothing wrong with the current Python versioning scheme. Python > 4 is not planned for the near future. I don't see anything else worthy > of discussion on this topic. Then you should just have a moderator lock the thread, and ... oh wait. Georg ___ 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] undocumented help() function change in Python 3.4?
Am 11.03.2014 06:31, schrieb Ned Deily: > In article > , > Nick Coghlan wrote: >> On 11 March 2014 11:29, R. David Murray wrote: >> > The whatsnew updates (including the one for help) weren't copied into >> > rc3. They will be in final though, unless Larry forgets. >> >> Oh, cool - yes, it will be good to have an up to date What's New >> shipped, especially as part of the compiled Windows docs. > > I was going to bring that point up today. How are all the new whatsnew > updates going to get into the 3.4.0 release? They've, correctly, been > being pushed to the default branch. But, AFAIK, for them to show up in > the 3.4.0 released docs we ship, all of the doc changes are going to > need to be cherry picked (or a big mass diff from the default branch) > into the 3.4 release branch, otherwise they will not be part of the > release. (They certainly won't be part of the docs included with the > installers I build unless they are in the 3.4 releasing branch.) Copying the file from default and doing just one commit in the releasing branch should be the easiest way. Georg ___ 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
