[Python-Dev] 2to3 porting HOWTO: setup.py question
http://docs.python.org/py3k/howto/pyporting.html#during-installation What's the point in making implicit Python 3 check here: try: # Python 3 from distutils.command.build_py import build_py_2to3 as build_py except ImportError: # Python 2 from distutils.command.build_py import build_py instead of explicit check like: import sys if sys.version_info[0] >= 3: from distutils.command.build_py import build_py_2to3 as build_py ? -- anatoly t. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Print policy for deprecated modules
What is a print policy for deprecated modules? "new" module is deprecated in 2.6, but 2.7.3 doesn't print any warnings. Is it a bug? python -Wd -c "import new" -- anatoly t. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2to3 porting HOWTO: setup.py question
On Sun, 22 Jul 2012 11:21:38 +0300, anatoly techtonik wrote: > http://docs.python.org/py3k/howto/pyporting.html#during-installation > > What's the point in making implicit Python 3 check here: > try: # Python 3 > from distutils.command.build_py import build_py_2to3 as build_py > except ImportError: # Python 2 > from distutils.command.build_py import build_py > > instead of explicit check like: > import sys > if sys.version_info[0] >= 3: > from distutils.command.build_py import build_py_2to3 as build_py It's called testing for the thing that actually matters, rather than testing a constant with a much broader meaning. Yes, in this case the results are the same, but IMO it is better programming practice to test the thing that actually matters when you can. --David ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] venv scripts for fish and csh shells
These are new features, please do not commit before 3.3 is released. Georg On 07/22/2012 02:12 AM, Andrew Svetlov wrote: > I created http://bugs.python.org/issue15417 with required activation scripts. > If there are no objections I like to commit it after, say, three days. > > On Thu, Jul 19, 2012 at 7:31 PM, Carl Meyer wrote: >> On 07/19/2012 10:26 AM, Andrew Svetlov wrote: >>> virtualenv has virtualenv.csh and virtualenv.fish files. >>> Is there any reason for restricting venv to bash/zsh only? >> >> No. As far as I'm concerned, a patch to port the virtualenv csh and fish >> activate scripts to pyvenv would be welcome (though I can't commit said >> patch, so it might be good to hear if Vinay has a different opinion). >> >> Carl >> >> ___ >> Python-Dev mailing list >> Python-Dev@python.org >> http://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: >> http://mail.python.org/mailman/options/python-dev/andrew.svetlov%40gmail.com > > > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] venv scripts for fish and csh shells
Georg, sorry, I've committed it before you answered. If you want, I will revert it back. But, please, describe me why those scripts are to late for 3.3? I strongly checked correctness of both activation script for fish and csh/tsch shells. Works fine. It's not *new feature*, it is just extending support to csh and fish shells. Virtualenv (base for venv) already contains this activation scripts. I just converted those files to venv with replacing virtualenv specific environment variables to schema supported by venv. I see nothing bad for adding to venv support for fish and csh as well as already supported bash/zsh Say again, I triple checked correctness of added scripts. With defining VIRTUAL_ENV_DISABLE_PROMPT as well as without it. My addition is safe, trivial, correct and it is not new feature — just fixing of missing support for widely used shells. Anyway. You are Release Manager — the main person for 3.3 release. If you feel what my changes is potentially dangerous and should be removed from 3.3 — I'll do it. But, please, do benevolent. On Sun, Jul 22, 2012 at 6:21 PM, Georg Brandl wrote: > These are new features, please do not commit before 3.3 is released. > > Georg > > On 07/22/2012 02:12 AM, Andrew Svetlov wrote: >> I created http://bugs.python.org/issue15417 with required activation scripts. >> If there are no objections I like to commit it after, say, three days. >> >> On Thu, Jul 19, 2012 at 7:31 PM, Carl Meyer wrote: >>> On 07/19/2012 10:26 AM, Andrew Svetlov wrote: virtualenv has virtualenv.csh and virtualenv.fish files. Is there any reason for restricting venv to bash/zsh only? >>> >>> No. As far as I'm concerned, a patch to port the virtualenv csh and fish >>> activate scripts to pyvenv would be welcome (though I can't commit said >>> patch, so it might be good to hear if Vinay has a different opinion). >>> >>> Carl >>> >>> ___ >>> Python-Dev mailing list >>> Python-Dev@python.org >>> http://mail.python.org/mailman/listinfo/python-dev >>> Unsubscribe: >>> http://mail.python.org/mailman/options/python-dev/andrew.svetlov%40gmail.com >> >> >> > > > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/andrew.svetlov%40gmail.com -- Thanks, Andrew Svetlov ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] venv scripts for fish and csh shells
On 07/22/2012 06:10 PM, Andrew Svetlov wrote: > Georg, sorry, I've committed it before you answered. After you wrote that you'd wait three days... anyway, I can't find the commit in the repository, so that's fine. > If you want, I will revert it back. > But, please, describe me why those scripts are to late for 3.3? > I strongly checked correctness of both activation script for fish and > csh/tsch shells. > Works fine. "Works fine" is not good enough. There are hundreds of potential patches on the tracker implementing new features of which the same could be said. > It's not *new feature*, it is just extending support to csh and fish shells. That is a new feature in my view. If it was an important feature, someone would have thought of it while features were allowed. > Virtualenv (base for venv) already contains this activation scripts. > I just converted those files to venv with replacing virtualenv > specific environment variables to schema supported by venv. > I see nothing bad for adding to venv support for fish and csh as well > as already supported bash/zsh > > Say again, I triple checked correctness of added scripts. With > defining VIRTUAL_ENV_DISABLE_PROMPT as well as without it. > My addition is safe, trivial, correct and it is not new feature — just > fixing of missing support for widely used shells. > > Anyway. > You are Release Manager — the main person for 3.3 release. > If you feel what my changes is potentially dangerous and should be > removed from 3.3 — I'll do it. > But, please, do benevolent. The point of feature freeze is that there are no new features. Where can I draw the line, when everybody argues like that and I agree? Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] venv scripts for fish and csh shells
Ok. Sorry for my mistake — there are really no commits for http://bugs.python.org/issue15417 It's look important for me — but you are release manager. If you consider the patch as potentially dangerous — I have to agree with you. You are the master :) On Sun, Jul 22, 2012 at 7:50 PM, Georg Brandl wrote: > On 07/22/2012 06:10 PM, Andrew Svetlov wrote: >> Georg, sorry, I've committed it before you answered. > > After you wrote that you'd wait three days... anyway, I can't find the > commit in the repository, so that's fine. > >> If you want, I will revert it back. >> But, please, describe me why those scripts are to late for 3.3? >> I strongly checked correctness of both activation script for fish and >> csh/tsch shells. >> Works fine. > > "Works fine" is not good enough. There are hundreds of potential patches > on the tracker implementing new features of which the same could be said. > >> It's not *new feature*, it is just extending support to csh and fish shells. > > That is a new feature in my view. If it was an important feature, someone > would have thought of it while features were allowed. > >> Virtualenv (base for venv) already contains this activation scripts. >> I just converted those files to venv with replacing virtualenv >> specific environment variables to schema supported by venv. >> I see nothing bad for adding to venv support for fish and csh as well >> as already supported bash/zsh >> >> Say again, I triple checked correctness of added scripts. With >> defining VIRTUAL_ENV_DISABLE_PROMPT as well as without it. >> My addition is safe, trivial, correct and it is not new feature — just >> fixing of missing support for widely used shells. >> >> Anyway. >> You are Release Manager — the main person for 3.3 release. >> If you feel what my changes is potentially dangerous and should be >> removed from 3.3 — I'll do it. >> But, please, do benevolent. > > The point of feature freeze is that there are no new features. Where > can I draw the line, when everybody argues like that and I agree? > > Georg > > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/andrew.svetlov%40gmail.com -- Thanks, Andrew Svetlov ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] venv scripts for fish and csh shells
On Sun, 22 Jul 2012 20:39:15 +0300 Andrew Svetlov wrote: > Ok. > Sorry for my mistake — there are really no commits for > http://bugs.python.org/issue15417 > It's look important for me — but you are release manager. > If you consider the patch as potentially dangerous — I have to agree with you. > You are the master :) This is not because Georg is the master. When a release is nearing we think it is important to avoid introducing potential regressions, except when fixing existing bugs. That's why we have a feature freeze which extends to many kinds of "enhancements", including performance improvements: really, it is more of a "bugfix-only period". One could propose other mechanisms for release preparation, but in the meantime, it is important as a community that we all follow similar rules. Regards Antoine. -- Software development and contracting: http://pro.pitrou.net ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] 2to3 porting HOWTO: setup.py question
On 22 July 2012 14:08, R. David Murray wrote: > On Sun, 22 Jul 2012 11:21:38 +0300, anatoly techtonik > wrote: > > http://docs.python.org/py3k/howto/pyporting.html#during-installation > > > > What's the point in making implicit Python 3 check here: > > try: # Python 3 > > from distutils.command.build_py import build_py_2to3 as build_py > > except ImportError: # Python 2 > > from distutils.command.build_py import build_py > > > > instead of explicit check like: > > import sys > > if sys.version_info[0] >= 3: > > from distutils.command.build_py import build_py_2to3 as build_py > > It's called testing for the thing that actually matters, rather than > testing a constant with a much broader meaning. Yes, in this case the > results are the same, but IMO it is better programming practice to test > the thing that actually matters when you can. I recently changed a setup.py from try/ImportError to an explicit sys.version_info check. I'm not totally sure how to reproduce this but I had a problem where I was installing into a 2.x virtualenv and it was running 2to3 during install and subsequently failing to import the 3.x code (the problem didn't occur when using the same python that generated the virtualenv). I may be wrong but I imagined that sometimes build_py_2to3 is importable on 2.x, perhaps for cross-building or something. In any case 'testing the thing that matters' means testing what version of Python you are about to install into not whether the python version supports running 2to3. Cheers, Oscar. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2to3 porting HOWTO: setup.py question
Benjamin sent me this message separately(*) privately and I responded privately. Here is my response. (*) or his mailer did On Sun, 22 Jul 2012 20:22:50 +0100, Oscar Benjamin wrote: > On 22 July 2012 14:08, R. David Murray wrote: > > > On Sun, 22 Jul 2012 11:21:38 +0300, anatoly techtonik > > wrote: > > > http://docs.python.org/py3k/howto/pyporting.html#during-installation > > > > > > What's the point in making implicit Python 3 check here: > > > try: # Python 3 > > > from distutils.command.build_py import build_py_2to3 as build_py > > > except ImportError: # Python 2 > > > from distutils.command.build_py import build_py > > > > > > instead of explicit check like: > > > import sys > > > if sys.version_info[0] >= 3: > > > from distutils.command.build_py import build_py_2to3 as build_py > > > > It's called testing for the thing that actually matters, rather than > > testing a constant with a much broader meaning. Yes, in this case the > > results are the same, but IMO it is better programming practice to test > > the thing that actually matters when you can. > > > I recently changed a setup.py from try/ImportError to an explicit > sys.version_info check. I'm not totally sure how to reproduce this but I > had a problem where I was installing into a 2.x virtualenv and it was > running 2to3 during install and subsequently failing to import the 3.x code > (the problem didn't occur when using the same python that generated the > virtualenv). > > I may be wrong but I imagined that sometimes build_py_2to3 is importable on > 2.x, perhaps for cross-building or something. In any case 'testing the > thing that matters' means testing what version of Python you are about to > install into not whether the python version supports running 2to3. I'm not familiar with distutils, really, so you could be right about what it is important to test. I was commenting based on the code snippet presented, which just deciding which "build" object to use. If build_py_2to3 can be imported by python2 and subsequently screws up the build, then yes the logic is incorrect. But I have to defer to the packaging people on that. (I wish I had time to help with packaging because it is important, but it doesn't seem like a sensible place for me personally to spend my currently available time.) --David ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Print policy for deprecated modules
On Sun, Jul 22, 2012 at 12:18 PM, anatoly techtonik wrote: > What is a print policy for deprecated modules? "new" module is > deprecated in 2.6, but 2.7.3 doesn't print any warnings. Is it a bug? > python -Wd -c "import new" In theory this should show a warning, but for some reason it doesn't. Reading the messages on http://bugs.python.org/issue1247765 it seems that there wasn't a clear consensus about the deprecation schedule, so that might be the reason. If the warning is missing just because no one remembered to add it, I guess it can still be fixed on 2.7, but for 2.6 is too late now. FWIW you get a warning if you use the -3 flag: $ python -Wd -3 -c "import new" -c:1: DeprecationWarning: The 'new' module has been removed in Python 3.0; use the 'types' module instead. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2to3 porting HOWTO: setup.py question
On 22 July 2012 20:57, R. David Murray wrote: > Benjamin sent me this message separately(*) privately and I responded > privately. Here is my response. > (*) or his mailer did > I think I accidentally replied from my work email address (which is not subscribed to python-dev) and so the second copy I sent to python-dev wasn't posted. > > On Sun, 22 Jul 2012 20:22:50 +0100, Oscar Benjamin > wrote: > > On 22 July 2012 14:08, R. David Murray wrote: > > > > > On Sun, 22 Jul 2012 11:21:38 +0300, anatoly techtonik < > techto...@gmail.com> > > > wrote: > > > > http://docs.python.org/py3k/howto/pyporting.html#during-installation > > > > > > > > What's the point in making implicit Python 3 check here: > > > > try: # Python 3 > > > > from distutils.command.build_py import build_py_2to3 as build_py > > > > except ImportError: # Python 2 > > > > from distutils.command.build_py import build_py > > > > > > > > instead of explicit check like: > > > > import sys > > > > if sys.version_info[0] >= 3: > > > > from distutils.command.build_py import build_py_2to3 as build_py > > > > > > It's called testing for the thing that actually matters, rather than > > > testing a constant with a much broader meaning. Yes, in this case the > > > results are the same, but IMO it is better programming practice to test > > > the thing that actually matters when you can. > > > > > > I recently changed a setup.py from try/ImportError to an explicit > > sys.version_info check. I'm not totally sure how to reproduce this but I > > had a problem where I was installing into a 2.x virtualenv and it was > > running 2to3 during install and subsequently failing to import the 3.x > code > > (the problem didn't occur when using the same python that generated the > > virtualenv). > > > > I may be wrong but I imagined that sometimes build_py_2to3 is importable > on > > 2.x, perhaps for cross-building or something. In any case 'testing the > > thing that matters' means testing what version of Python you are about to > > install into not whether the python version supports running 2to3. > > I'm not familiar with distutils, really, so you could be right about > what it is important to test. I was commenting based on the code > snippet presented, which just deciding which "build" object to use. > If build_py_2to3 can be imported by python2 and subsequently screws up > the build, then yes the logic is incorrect. But I have to defer to the > packaging people on that. (I wish I had time to help with packaging > because it is important, but it doesn't seem like a sensible place for > me personally to spend my currently available time.) > I'm not currently able to reproduce the problem on this machine. I think I was using pip/easy_install to install distribution X from PyPI that depended on distribution Y also on PyPI into an isolated 2.x virtualenv and found that distribution Y was converted with 2to3 when it was automatically installed. It could be a bug but I'm not confident enough with virtualenv to say that it wasn't just me messing things up somehow. Either way I still think that in this particular case a version check is the most explicit and appropriate thing to do. The author of a distribution that is distributed as Python 2.x code and installed on Python 3.x using 2to3 knows precisely when they want 2to3 to run and when they don't so why not make that explicit? As an aside, I find the check slightly easier to read if it is written like: if sys.version_info >= (3, 0): from distutils.build_py import build_py_2to3 as build_py Cheers, Oscar. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Print policy for deprecated modules
On Sun, Jul 22, 2012 at 2:06 PM, Ezio Melotti wrote: > On Sun, Jul 22, 2012 at 12:18 PM, anatoly techtonik > wrote: >> What is a print policy for deprecated modules? "new" module is >> deprecated in 2.6, but 2.7.3 doesn't print any warnings. Is it a bug? >> python -Wd -c "import new" > > In theory this should show a warning, but for some reason it doesn't. > Reading the messages on http://bugs.python.org/issue1247765 it seems > that there wasn't a clear consensus about the deprecation schedule, so > that might be the reason. > If the warning is missing just because no one remembered to add it, I > guess it can still be fixed on 2.7, but for 2.6 is too late now. > > FWIW you get a warning if you use the -3 flag: > $ python -Wd -3 -c "import new" > -c:1: DeprecationWarning: The 'new' module has been removed in > Python 3.0; use the 'types' module instead. IIRC we decided not to add new deprecations to 2.7, since the deprecation would only affect the Python 3 line anyway -- nothing that exists in Python 2 is going away in Python 2... -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (merge 3.2 -> default): Merge #15232: correctly mangle From lines in MIME preamble and epilogue
On Sun, Jul 22, 2012 at 8:55 PM, r.david.murray
wrote:
> http://hg.python.org/cpython/rev/80b81658455b
> changeset: 78246:80b81658455b
> parent: 78244:c43d73277756
> parent: 78245:b97f65f2298d
> user:R David Murray
> date:Sun Jul 22 21:53:54 2012 -0400
> summary:
> Merge #15232: correctly mangle From lines in MIME preamble and epilogue
>
> files:
> Lib/email/generator.py| 12 -
> Lib/test/test_email/test_email.py | 22 +++
> Misc/NEWS | 3 ++
> 3 files changed, 35 insertions(+), 2 deletions(-)
I'm not quite sure what happened, but something seems to have gone wrong
with this merge. After doing the following while on the "default" branch:
$ hg merge 3.2
I see:
$ hg st
M Lib/email/generator.py
M Lib/test/test_email/test_email.py
M Misc/NEWS
and a bunch of conflicts in 'Misc/NEWS'.
>
> diff --git a/Lib/email/generator.py b/Lib/email/generator.py
> --- a/Lib/email/generator.py
> +++ b/Lib/email/generator.py
> @@ -252,7 +252,11 @@
> msg.set_boundary(boundary)
> # If there's a preamble, write it out, with a trailing CRLF
> if msg.preamble is not None:
> -self.write(msg.preamble + self._NL)
> +if self._mangle_from_:
> +preamble = fcre.sub('>From ', msg.preamble)
> +else:
> +preamble = msg.preamble
> +self.write(preamble + self._NL)
> # dash-boundary transport-padding CRLF
> self.write('--' + boundary + self._NL)
> # body-part
> @@ -270,7 +274,11 @@
> self.write(self._NL + '--' + boundary + '--')
> if msg.epilogue is not None:
> self.write(self._NL)
> -self.write(msg.epilogue)
> +if self._mangle_from_:
> +epilogue = fcre.sub('>From ', msg.epilogue)
> +else:
> +epilogue = msg.epilogue
> +self.write(epilogue)
>
> def _handle_multipart_signed(self, msg):
> # The contents of signed parts has to stay unmodified in order to
> keep
> diff --git a/Lib/test/test_email/test_email.py
> b/Lib/test/test_email/test_email.py
> --- a/Lib/test/test_email/test_email.py
> +++ b/Lib/test/test_email/test_email.py
> @@ -1283,6 +1283,28 @@
> Blah blah blah
> """)
>
> +def test_mangle_from_in_preamble_and_epilog(self):
> +s = StringIO()
> +g = Generator(s, mangle_from_=True)
> +msg = email.message_from_string(textwrap.dedent("""\
> +From: f...@bar.com
> +Mime-Version: 1.0
> +Content-Type: multipart/mixed; boundary=XXX
> +
> +From somewhere unknown
> +
> +--XXX
> +Content-Type: text/plain
> +
> +foo
> +
> +--XXX--
> +
> +From somewhere unknowable
> +"""))
> +g.flatten(msg)
> +self.assertEqual(len([1 for x in s.getvalue().split('\n')
> + if x.startswith('>From ')]), 2)
>
>
> # Test the basic MIMEAudio class
> diff --git a/Misc/NEWS b/Misc/NEWS
> --- a/Misc/NEWS
> +++ b/Misc/NEWS
> @@ -52,6 +52,9 @@
> Library
> ---
>
> +- Issue #15232: when mangle_from is True, email.Generator now correctly
> mangles
> + lines that start with 'From' that occur in a MIME preamble or epilogue.
> +
> - Issue #15094: Incorrectly placed #endif in _tkinter.c.
>Patch by Serhiy Storchaka.
>
>
> --
> Repository URL: http://hg.python.org/cpython
>
> ___
> Python-checkins mailing list
> python-check...@python.org
> http://mail.python.org/mailman/listinfo/python-checkins
>
--
# Meador
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
