[Python-Dev] Issue #25256: Add sys.debug_build?
Hi, I created the issue "Add sys.debug_build public variable to check if Python was compiled in debug mode": http://bugs.python.org/issue25256 I would like to add an obvious way to check if Python was compiled in debug mode, instead of having hacks/tips to check it. On the Internet, I found various recipes to check if Python is compiled is debug mode. Sadly, some of them are not portable. For example, 3 different checks are proposed on StackOverflow but 2 of them are specific to Windows: http://stackoverflow.com/questions/646518/python-how-to-detect-debug-interpreter Even if the exact impact of a debug build depends on the Python implementation and the Python version, we can use it to have the same behaviour on all Python implementations. For example, the warnings module shows warnings by default if Python is compiled in debug mode: Extract of my patch: -if hasattr(sys, 'gettotalrefcount'): +if sys.debug_build: resource_action = "always" else: resource_action = "ignore" Alternative: Add a new sys.implementation.debug_build flag. Problem: extending sys.implementation requires a new PEP, and I don't think that debug_build fits into this object. Berker Peksag likes the idea. Serhiy Storchaka dislike the new flag: "I don't like this. The sys module is one of most used module, but it has too many members, and adding yet one makes the situation worse." (sys has 81 symbols) "Checking for debug mode is not often needed, and mainly in tests. Current way ``hasattr(sys, 'gettotalrefcount')`` works good. You also can check ``'d' in sys.abiflags`` if it looks cleaner to you. Or add a member to test.support." The name "debug_build" comes from the existing sysconfig.is_python_build() function. There is a sys.flags.debug flag, so "sys.debug" can be confusing. I prefer to attach the "build" suffix. First I proposed a function sys.is_debug_build(), but a flag is simpler than a function. There is not need to compute a version it's known at build time. What do you think? Should we add sys.debug_build? Victor ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue #25256: Add sys.debug_build?
On 2 October 2015 at 17:18, Victor Stinner wrote: > What do you think? Should we add sys.debug_build? Spell it as "sys.implementation.debug_build" and I'm in favour. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue #25256: Add sys.debug_build?
2015-10-02 9:37 GMT+02:00 Nick Coghlan : > Spell it as "sys.implementation.debug_build" and I'm in favour. Oh, in fact, I don't have no preference between sys.debug_flag and sys.implementation.debug_flag. If I understood correctly, Serhiy would prefer sys.implementation.debug_flag because he doesn't want to add yet another symbol to the sys namespace. But Berker Peksag wrote: "According to the sys.implementation documentation and PEP 421, we can only add a private attribute without writing a PEP. But I find sys.implementation._debug_build too long and ``from sys import implementation; implementation._debug_build``(or ``from sys import implementation as i; i._debug_build``) is also not easy to write. So I'm +1 to sys.debug_build." Should I write a PEP for a new field in sys.implementation? Victor ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue #25256: Add sys.debug_build?
Whats wrong with:
>>> sysconfig.get_config_var('Py_DEBUG')
0
Nir
On Fri, Oct 2, 2015 at 10:18 AM, Victor Stinner
wrote:
> Hi,
>
> I created the issue "Add sys.debug_build public variable to check if
> Python was compiled in debug mode": http://bugs.python.org/issue25256
>
> I would like to add an obvious way to check if Python was compiled in
> debug mode, instead of having hacks/tips to check it. On the Internet,
> I found various recipes to check if Python is compiled is debug mode.
> Sadly, some of them are not portable. For example, 3 different checks
> are proposed on StackOverflow but 2 of them are specific to Windows:
>
> http://stackoverflow.com/questions/646518/python-how-to-detect-debug-interpreter
>
> Even if the exact impact of a debug build depends on the Python
> implementation and the Python version, we can use it to have the same
> behaviour on all Python implementations. For example, the warnings
> module shows warnings by default if Python is compiled in debug mode:
> Extract of my patch:
>
> -if hasattr(sys, 'gettotalrefcount'):
> +if sys.debug_build:
> resource_action = "always"
> else:
> resource_action = "ignore"
>
> Alternative: Add a new sys.implementation.debug_build flag. Problem:
> extending sys.implementation requires a new PEP, and I don't think
> that debug_build fits into this object.
>
> Berker Peksag likes the idea.
>
> Serhiy Storchaka dislike the new flag: "I don't like this. The sys
> module is one of most used module, but it has too many members, and
> adding yet one makes the situation worse." (sys has 81 symbols)
> "Checking for debug mode is not often needed, and mainly in tests.
> Current way ``hasattr(sys, 'gettotalrefcount')`` works good. You also
> can check ``'d' in sys.abiflags`` if it looks cleaner to you. Or add a
> member to test.support."
>
> The name "debug_build" comes from the existing
> sysconfig.is_python_build() function. There is a sys.flags.debug flag,
> so "sys.debug" can be confusing. I prefer to attach the "build"
> suffix.
>
> First I proposed a function sys.is_debug_build(), but a flag is
> simpler than a function. There is not need to compute a version it's
> known at build time.
>
> What do you think? Should we add sys.debug_build?
>
> Victor
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/nirsof%40gmail.com
>
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue #25256: Add sys.debug_build?
2015-10-02 13:16 GMT+02:00 Nir Soffer :
> Whats wrong with:
>
sysconfig.get_config_var('Py_DEBUG')
> 0
Again, refer to my first message "On the Internet, I found various
recipes to check if Python is compiled is debug mode. Sadly, some of
them are not portable."
I don't think that sysconfig.get_config_var('Py_DEBUG') will work on
other Python implementations.
On Windows, there is no such file like "Makefile" used to fill
syscofig.get_config_vars() :-( sysconfig._init_non_posix() only fills
a few variables like BINDIR or INCLUDEPY, but not Py_DEBUG.
Victor
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue #25256: Add sys.debug_build?
Speaking of other python implementations - why would you even care?
(the pypy debug build has very different properties and does very
different stuff for example). I would be very happy to have this
clearly marked as implementation-dependent and that's why it would be
cool to not be in sys (there are already 5 symbols there for this
reason, so hasattr totalrefcount is cool enough)
On Fri, Oct 2, 2015 at 2:19 PM, Victor Stinner wrote:
> 2015-10-02 13:16 GMT+02:00 Nir Soffer :
>> Whats wrong with:
>>
> sysconfig.get_config_var('Py_DEBUG')
>> 0
>
> Again, refer to my first message "On the Internet, I found various
> recipes to check if Python is compiled is debug mode. Sadly, some of
> them are not portable."
>
> I don't think that sysconfig.get_config_var('Py_DEBUG') will work on
> other Python implementations.
>
> On Windows, there is no such file like "Makefile" used to fill
> syscofig.get_config_vars() :-( sysconfig._init_non_posix() only fills
> a few variables like BINDIR or INCLUDEPY, but not Py_DEBUG.
>
> Victor
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/fijall%40gmail.com
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue #25256: Add sys.debug_build?
On Oct 02, 2015, at 11:46 AM, Victor Stinner wrote: >Should I write a PEP for a new field in sys.implementation? Specifically PEP 421 says that a PEP is needed if the new sys.implementation attribute is required to be defined in all implementations, i.e. it's a new required attribute. Will debug_build be required of all implementations? The PEP can be short. https://www.python.org/dev/peps/pep-0421/#id30 If it's only relevant for CPython then an underscore-prefix symbol in sys.implementation is the right place for it, and no PEP is needed. Just open an issue on the tracker. Cheers, -Barry ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue #25256: Add sys.debug_build?
On 02.10.15 10:18, Victor Stinner wrote: I would like to add an obvious way to check if Python was compiled in debug mode, instead of having hacks/tips to check it. On the Internet, I found various recipes to check if Python is compiled is debug mode. Sadly, some of them are not portable. I agree with Maciej. Why do you need to check if Python is compiled in debug mode? Because either you need to use some feature that is available only in debug mode (such as sys.gettotalrefcount), or to distinguish debug and non-debug binaries (in sysconfig and distutils), or make the behaviour different in debug mode (in warnings), or handle other behaviour differences (such as additional asserts or different stack consumption). In the first case you should just explicitly check the existence of related function. In the second case I suggest to use sys.abiflags as a suffix (likely you want to distinguish pymalloc from non-pymalloc build), or at least make a suffix depended on sys.abiflags. In the third case perhaps we have to set default warning level depending on sys.flags.debug, or sys.flags.verbose, or other dynamic flags. In the fourth case there is no good solution, but in any case this behaviour is implementation specific, and other implementation can have different consistency checks and different limits. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2015-09-25 - 2015-10-02) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open5155 (+13) closed 31906 (+57) total 37061 (+70) Open issues with patches: 2286 Issues opened (48) == #25235: EmailMessage.add_attachment() creates parts with spurious MIME http://bugs.python.org/issue25235 opened by groner #25237: Add doc for tkinter commondialog.Dialog and subclasses http://bugs.python.org/issue25237 opened by terry.reedy #25238: Version added of context parameter for xmlrpc.client.ServerPro http://bugs.python.org/issue25238 opened by desbma #25239: HTMLParser handle_starttag replaces entity references in attri http://bugs.python.org/issue25239 opened by frogcoder #25240: Stack overflow in reprlib causes a core dump http://bugs.python.org/issue25240 opened by ceridwen #25242: Failed tests for Python 3.5.0 on shared virtual host http://bugs.python.org/issue25242 opened by Open Genomes #25243: decouple string-to-boolean logic from ConfigParser.getboolean http://bugs.python.org/issue25243 opened by jab #25244: Idle: refine right-click behavior http://bugs.python.org/issue25244 opened by terry.reedy #25246: Alternative algorithm for deque_remove() http://bugs.python.org/issue25246 opened by rhettinger #25247: Tkinter modules built successfully but removed because they co http://bugs.python.org/issue25247 opened by abrantesasf #25251: Unknown MS Compiler version 1900 http://bugs.python.org/issue25251 opened by Matt.Hickford #25252: Hard-coded line ending in asyncio.streams.StreamReader.readlin http://bugs.python.org/issue25252 opened by eric.smith #25254: Idle: debugger source line highlighting fails again http://bugs.python.org/issue25254 opened by terry.reedy #25256: Add sys.debug_build public variable to check if Python was com http://bugs.python.org/issue25256 opened by haypo #25257: In subject line email library inserts unwanted space after a t http://bugs.python.org/issue25257 opened by SegundoBob #25258: HtmlParser doesn't handle void element tags correctly http://bugs.python.org/issue25258 opened by Chenyun Yang #25259: readline macros can segfault Python http://bugs.python.org/issue25259 opened by gumnos #25263: test_tkinter fails randomly on the buildbots "AMD64 Windows10" http://bugs.python.org/issue25263 opened by haypo #25264: test_marshal always crashs on "AMD64 Windows10 2.7" buildbot http://bugs.python.org/issue25264 opened by haypo #25266: mako benchmark not working in Python 3.6 http://bugs.python.org/issue25266 opened by florin.papa #25268: Support pointing frozen modules to the corresponding source fi http://bugs.python.org/issue25268 opened by eric.snow #25269: Add method to detect if a string contains surrogates http://bugs.python.org/issue25269 opened by r.david.murray #25270: codecs.escape_encode systemerror on empty byte string http://bugs.python.org/issue25270 opened by reaperhulk #25272: asyncio tests are getting noisy http://bugs.python.org/issue25272 opened by gvanrossum #25274: sys.setrecursionlimit() must fail if the current recursion dep http://bugs.python.org/issue25274 opened by haypo #25275: Documentation v/s behaviour mismatch wrt integer literals cont http://bugs.python.org/issue25275 opened by shreevatsa #25276: Intermittent segfaults on PPC64 AIX 3.x http://bugs.python.org/issue25276 opened by haypo #25277: test_eintr hangs on randomly on "AMD64 FreeBSD 9.x 3.x" http://bugs.python.org/issue25277 opened by haypo #25278: Unexpected socket exception on SFTP 'STOR' command http://bugs.python.org/issue25278 opened by blanquier #25282: regex: Support for recursive patterns http://bugs.python.org/issue25282 opened by Sworddragon #25283: Make tm_gmtoff and tm_zone available on all platforms http://bugs.python.org/issue25283 opened by belopolsky #25285: regrtest: run tests in subprocesses with -j1 on buildbots http://bugs.python.org/issue25285 opened by haypo #25286: views are not sequences http://bugs.python.org/issue25286 opened by akira #25287: test_crypt fails on OpenBSD http://bugs.python.org/issue25287 opened by haypo #25289: test_strptime hangs sometimes on AMD64 Windows7 SP1 3.x buildb http://bugs.python.org/issue25289 opened by haypo #25290: csv.reader: minor docstring typo http://bugs.python.org/issue25290 opened by wasserverein #25291: better Exception message for certain task termination scenario http://bugs.python.org/issue25291 opened by ovex #25292: ssl socket gets into broken state when client exits during han http://bugs.python.org/issue25292 opened by ovex #25293: Hooking Thread/Process instantiation in concurrent.futures. http://bugs.python.org/issue25293 opened by Antony.Lee #25294: Absolute imports fail in some cases where relative imports wou http://bugs.python.org/issue25294 opened by Patrick Maupin #25295: fun
[Python-Dev] Migrating to Python 3: the python 3 install issue
On python-list, Chris Warrick reported (thread title): "The Nikola project is deprecating Python 2.7 (+2.x/3.x user survey results)" This is for the November release, with 2.7 dropped in the next version next year. (Nikola is a cross-platform unicode-based app for building static websites and blogs from user-written templates and (marked-up) text files. https://getnikola.com/ ) Since users do not write code to use Nikola, the survey was about installation of Python 3. At present, 1/2 have 3.x only, 1/3 2.x only, and 1/6 both. (So much for 'nobody uses 3.x for real work'.) Most of the 2.x only people are able and willing to install 3.x. https://getnikola.com/blog/env-survey-results-and-the-future-of-python-27.html When Stefan Behnel asked why they did not drop the hard-to-maintain 2.7 version once they ported to 3.3, Chris answered > We did it now because it all started with frustration with 2.7 [0]. > Also, doing it back in 2012/2013 would be problematic, because back > then not all Linux distros had an easily installable Python 3 stack > (and RHEL 7 still doesn’t have one in the default repos) > > [0]: http://ralsina.me/weblog/posts/floss-decision-making-in-action.html -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Migrating to Python 3: the python 3 install issue
Thanks for the info, Terry! Glad people are realizing that Python 3 is now available widely enough that applications can seriously consider dropping Python 2 support now. I still think 2016 is going to see this happen more and more once the Linux distros make their switches to Python 3. On Fri, 2 Oct 2015 at 15:16 Terry Reedy wrote: > On python-list, Chris Warrick reported (thread title): > "The Nikola project is deprecating Python 2.7 (+2.x/3.x user survey > results)" This is for the November release, with 2.7 dropped in the > next version next year. (Nikola is a cross-platform unicode-based app > for building static websites and blogs from user-written templates and > (marked-up) text files. https://getnikola.com/ ) > > Since users do not write code to use Nikola, the survey was about > installation of Python 3. At present, 1/2 have 3.x only, 1/3 2.x only, > and 1/6 both. (So much for 'nobody uses 3.x for real work'.) Most of > the 2.x only people are able and willing to install 3.x. > > https://getnikola.com/blog/env-survey-results-and-the-future-of-python-27.html > > When Stefan Behnel asked why they did not drop the hard-to-maintain 2.7 > version once they ported to 3.3, Chris answered > > > We did it now because it all started with frustration with 2.7 [0]. > > Also, doing it back in 2012/2013 would be problematic, because back > > then not all Linux distros had an easily installable Python 3 stack > > (and RHEL 7 still doesn’t have one in the default repos) > > > > [0]: > http://ralsina.me/weblog/posts/floss-decision-making-in-action.html > > -- > Terry Jan Reedy > > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/brett%40python.org > ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Migrating to Python 3: the python 3 install issue
Fedora 23 (scheduled for the end of this month) will only come with python3 (/usr/bin/python3), no python2 (nor python), *in the base system*. Obviously, it will be possible to install Python 2 to install applications not compatible with Python 3 yet. Note: the current development version is Fedora 23, Fedora 24 is the next one. Ubuntu is still working on a similar change. Victor 2015-10-03 0:55 GMT+02:00 Brett Cannon : > Thanks for the info, Terry! Glad people are realizing that Python 3 is now > available widely enough that applications can seriously consider dropping > Python 2 support now. I still think 2016 is going to see this happen more > and more once the Linux distros make their switches to Python 3. > > On Fri, 2 Oct 2015 at 15:16 Terry Reedy wrote: >> >> On python-list, Chris Warrick reported (thread title): >> "The Nikola project is deprecating Python 2.7 (+2.x/3.x user survey >> results)" This is for the November release, with 2.7 dropped in the >> next version next year. (Nikola is a cross-platform unicode-based app >> for building static websites and blogs from user-written templates and >> (marked-up) text files. https://getnikola.com/ ) >> >> Since users do not write code to use Nikola, the survey was about >> installation of Python 3. At present, 1/2 have 3.x only, 1/3 2.x only, >> and 1/6 both. (So much for 'nobody uses 3.x for real work'.) Most of >> the 2.x only people are able and willing to install 3.x. >> >> https://getnikola.com/blog/env-survey-results-and-the-future-of-python-27.html >> >> When Stefan Behnel asked why they did not drop the hard-to-maintain 2.7 >> version once they ported to 3.3, Chris answered >> >> > We did it now because it all started with frustration with 2.7 [0]. >> > Also, doing it back in 2012/2013 would be problematic, because back >> > then not all Linux distros had an easily installable Python 3 stack >> > (and RHEL 7 still doesn’t have one in the default repos) >> > >> > [0]: >> http://ralsina.me/weblog/posts/floss-decision-making-in-action.html >> >> -- >> Terry Jan Reedy >> >> >> ___ >> Python-Dev mailing list >> [email protected] >> https://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: >> https://mail.python.org/mailman/options/python-dev/brett%40python.org > > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/victor.stinner%40gmail.com > ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Migrating to Python 3: the python 3 install issue
(grr, again i sent a draft by mistake, sorry about that) Fedora 23 (scheduled for the end of this month) will only come with python3 (/usr/bin/python3), no python2 (nor python), *in the base system*. Obviously, it will be possible to install Python 2 to install applications not compatible with Python 3 yet. https://fedoraproject.org/wiki/Releases/23/ChangeSet#Python_3_as_the_Default_Implementation https://twitter.com/_solotraveller/status/645559393627435008 Ubuntu is also working on a similar change. I don't know when it will happen. Victor 2015-10-03 0:55 GMT+02:00 Brett Cannon : > Thanks for the info, Terry! Glad people are realizing that Python 3 is now > available widely enough that applications can seriously consider dropping > Python 2 support now. I still think 2016 is going to see this happen more > and more once the Linux distros make their switches to Python 3. > > On Fri, 2 Oct 2015 at 15:16 Terry Reedy wrote: >> >> On python-list, Chris Warrick reported (thread title): >> "The Nikola project is deprecating Python 2.7 (+2.x/3.x user survey >> results)" This is for the November release, with 2.7 dropped in the >> next version next year. (Nikola is a cross-platform unicode-based app >> for building static websites and blogs from user-written templates and >> (marked-up) text files. https://getnikola.com/ ) >> >> Since users do not write code to use Nikola, the survey was about >> installation of Python 3. At present, 1/2 have 3.x only, 1/3 2.x only, >> and 1/6 both. (So much for 'nobody uses 3.x for real work'.) Most of >> the 2.x only people are able and willing to install 3.x. >> >> https://getnikola.com/blog/env-survey-results-and-the-future-of-python-27.html >> >> When Stefan Behnel asked why they did not drop the hard-to-maintain 2.7 >> version once they ported to 3.3, Chris answered >> >> > We did it now because it all started with frustration with 2.7 [0]. >> > Also, doing it back in 2012/2013 would be problematic, because back >> > then not all Linux distros had an easily installable Python 3 stack >> > (and RHEL 7 still doesn’t have one in the default repos) >> > >> > [0]: >> http://ralsina.me/weblog/posts/floss-decision-making-in-action.html >> >> -- >> Terry Jan Reedy >> >> >> ___ >> Python-Dev mailing list >> [email protected] >> https://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: >> https://mail.python.org/mailman/options/python-dev/brett%40python.org > > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/victor.stinner%40gmail.com > ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] VS 2010 compiler
On Wed, Sep 30, 2015 at 3:57 PM, Carl Kleffner wrote: > Concerning the claims that mingw is difficult: > > The mingwpy package is a sligthly modified mingw-w64 based gcc toolchain, > that is in development. It is designed for simple use and for much better > compatibility to the standard MSVC python builds. It should work out of the > box, as long as the \Scripts folder is in the PATH. > Indeed, I tested it with 2.7.9 x86/x64, and wheres before I had to apply at least http://bugs.python.org/issue4709, and http://bugs.python.org/issue16472 and then generate the .a files to get it to work, this worked out of the box! (except of course still needing to change distutils.cfg). I do wonder though, which may be slightly off topic here, whether putting the mingw binary stub files (?) in python/Scripts, rather than directly having python/shared/mingwpy/bin be on the path, is the best approach? I suppose it's no worse than having the other stuff in python/scripts on the path (although with e.g. pip you could do the python -m pip trick). Are there guidelines about this (using python/scripts) for Windows? I didn't see anything mentioned when python -m pip install ... vs. pip install is discussed. Although I hope a 7z version of that mingw will be separately available for those that want to share a copy between versions of python, since the files in share/mingwpy is presumably the same between python versions for a specific bitness? Matt ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Migrating to Python 3: the python 3 install issue
On Oct 03, 2015, at 01:05 AM, Victor Stinner wrote: >Ubuntu is also working on a similar change. I don't know when it will happen. For the desktop, we're aiming for 16.04 LTS. Cheers, -Barry ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
