Re: [Python-Dev] objections to renaming enumobject.h/c in 3.4?
On Fri, Aug 2, 2013 at 11:20 PM, Raymond Hettinger wrote: > > On Aug 2, 2013, at 8:47 PM, Eli Bendersky wrote: > > I was looking around the Objects directory and noticed that we have > enumobject.h/c with the enumobject structure for "enumerate" and "reversed". > This is somewhat confusing now with Lib/enum.py and will be doubly confusing > if we ever decide to have a C implementation of enums. > > Any objections to renaming the files and the internal structure & static > functions with s/enum/enumerate/ ? This would more accurately reflect the > use of the code, and avoid confusion with enums. These structures/types are > not part of the stable ABI defined by PEP 384. > > > I wouldn't mind renaming enumobject.c/h to enumerateobject.c/h, but I think > it is going overboard to rename all the internal structures and static > functions. The latter is entirely unnecessary. The C language itself has > enums and there has never been any confusion with the enumerate iterator. > My reasoning is this: Objects/enumobject.c currently has functions like enum_new, enum_dealloc, etc. If we ever implement enums in C, we're going to either have to find creative names for them, or have two sets of same-named static functions in two different files. While valid formally, it's confusing for code navigation and similar reasons. However, this can really be delayed until we actually do decide to implement enums in C. For now, just renaming the files should solve most of the problem. Eli ___ 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] objections to renaming enumobject.h/c in 3.4?
On 3 August 2013 22:39, Eli Bendersky wrote: > On Fri, Aug 2, 2013 at 11:20 PM, Raymond Hettinger > wrote: >> >> On Aug 2, 2013, at 8:47 PM, Eli Bendersky wrote: >> >> I was looking around the Objects directory and noticed that we have >> enumobject.h/c with the enumobject structure for "enumerate" and "reversed". >> This is somewhat confusing now with Lib/enum.py and will be doubly confusing >> if we ever decide to have a C implementation of enums. >> >> Any objections to renaming the files and the internal structure & static >> functions with s/enum/enumerate/ ? This would more accurately reflect the >> use of the code, and avoid confusion with enums. These structures/types are >> not part of the stable ABI defined by PEP 384. >> >> >> I wouldn't mind renaming enumobject.c/h to enumerateobject.c/h, but I think >> it is going overboard to rename all the internal structures and static >> functions. The latter is entirely unnecessary. The C language itself has >> enums and there has never been any confusion with the enumerate iterator. >> > > My reasoning is this: Objects/enumobject.c currently has functions > like enum_new, enum_dealloc, etc. If we ever implement enums in C, > we're going to either have to find creative names for them, or have > two sets of same-named static functions in two different files. While > valid formally, it's confusing for code navigation and similar > reasons. > > However, this can really be delayed until we actually do decide to > implement enums in C. For now, just renaming the files should solve > most of the problem. Yep, this is an area where laziness is definitely a virtue - if work is only needed to handle a hypothetical future change, then it can be deferred and handled as part of that change. :) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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] unittest.TestSuite holding references to unittest.TestCase instances too long
Michael Foord voidspace.org.uk> writes:
> On 2 Aug 2013, at 19:19, Antoine Pitrou pitrou.net> wrote:
> > The patch is basically ready for commit, except for a possible doc
> > addition, no?
>
> Looks to be the case, reading the patch it looks fine. I'm currently on
holiday until Monday.
> If anyone is motivated to do the docs too and commit that would be great.
Otherwise I'll
> get to it on my return.
It looks like the patch is based on what will become 3.4. Would backporting
it to 2.7 be feasible? What's involved in doing so?
I took a crack at the docs.
# HG changeset patch
# User Matt McClure
# Date 1375538965 14400
# Node ID d748d70201929288c230862da4dbdba33d61ae9f
# Parent bf43956356ffe93e75ffdd5a7a8164fc68cf14ae
[11798] Document TestSuite.{__iter__, run} changes
diff --git a/Doc/library/unittest.rst b/Doc/library/unittest.rst
--- a/Doc/library/unittest.rst
+++ b/Doc/library/unittest.rst
@@ -1470,15 +1470,24 @@
Tests grouped by a :class:`TestSuite` are always accessed by
iteration.
Subclasses can lazily provide tests by overriding :meth:`__iter__`.
Note
- that this method maybe called several times on a single suite
- (for example when counting tests or comparing for equality)
- so the tests returned must be the same for repeated iterations.
+ that this method may be called several times on a single suite (for
+ example when counting tests or comparing for equality) so the tests
+ returned by repeated iterations before :meth:`TestSuite.run` must be
the
+ same for each call iteration. After :meth:`TestSuite.run`, callers
should
+ not rely on the tests returned by this method unless the caller uses
a
+ subclass that overrides :meth:`TestSuite._removeTestAtIndex` to
preserve
+ test references.
.. versionchanged:: 3.2
In earlier versions the :class:`TestSuite` accessed tests
directly rather
than through iteration, so overriding :meth:`__iter__` wasn't
sufficient
for providing tests.
+ .. versionchanged:: 3.4
+ In earlier versions the :class:`TestSuite` held references to each
+ :class:`TestCase` after :meth:`TestSuite.run`. Subclasses can
restore
+ that behavior by overriding :meth:`TestSuite._removeTestAtIndex`.
+
In the typical usage of a :class:`TestSuite` object, the :meth:`run`
method
is invoked by a :class:`TestRunner` rather than by the end-user test
harness.
diff --git a/Lib/unittest/suite.py b/Lib/unittest/suite.py
--- a/Lib/unittest/suite.py
+++ b/Lib/unittest/suite.py
@@ -65,6 +65,7 @@
return result
def _removeTestAtIndex(self, index):
+"""Stop holding a reference to the TestCase at index."""
try:
self._tests[index] = None
except TypeError:
--
Matt McClure
http://matthewlmcclure.com
http://www.mapmyfitness.com/profile/matthewlmcclure
___
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] unittest.TestSuite holding references to unittest.TestCase instances too long
On Sat, 03 Aug 2013 10:27:30 -0400, Matt McClure wrote: > Michael Foord voidspace.org.uk> writes: > > On 2 Aug 2013, at 19:19, Antoine Pitrou pitrou.net> wrote: > > > The patch is basically ready for commit, except for a possible doc > > > addition, no? > > > > Looks to be the case, reading the patch it looks fine. I'm currently on > holiday until Monday. > > If anyone is motivated to do the docs too and commit that would be great. > Otherwise I'll > > get to it on my return. > > It looks like the patch is based on what will become 3.4. Would backporting > it to 2.7 be feasible? What's involved in doing so? That depends on how likely Michale thinks it is that it might break things. > I took a crack at the docs. Thanks. Please post your patch to the issue, it will get lost here. --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] unittest.TestSuite holding references to unittest.TestCase instances too long
On Aug 3, 2013, at 12:07 PM, "R. David Murray" wrote: > Thanks. Please post your patch to the issue, it will get lost here. I'm trying to register, but I'm not receiving a confirmation email to complete the registration. -- http://matthewlmcclure.com http://about.mapmyfitness.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] unittest.TestSuite holding references to unittest.TestCase instances too long
Sent from my iPhone On 3 Aug 2013, at 19:07, "R. David Murray" wrote: > On Sat, 03 Aug 2013 10:27:30 -0400, Matt McClure > wrote: >> Michael Foord voidspace.org.uk> writes: >>> On 2 Aug 2013, at 19:19, Antoine Pitrou pitrou.net> wrote: The patch is basically ready for commit, except for a possible doc addition, no? >>> >>> Looks to be the case, reading the patch it looks fine. I'm currently on >> holiday until Monday. >>> If anyone is motivated to do the docs too and commit that would be great. >> Otherwise I'll >>> get to it on my return. >> >> It looks like the patch is based on what will become 3.4. Would backporting >> it to 2.7 be feasible? What's involved in doing so? > > That depends on how likely Michale thinks it is that it might break > things. > It smells to me like a new feature rather than a bugfix, and it's a moderately big change. I don't think it can be backported to 2.7 other than through unittest2. Michael >> I took a crack at the docs. > > Thanks. Please post your patch to the issue, it will get lost here. > > --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] objections to renaming enumobject.h/c in 3.4?
On Sat, Aug 3, 2013 at 9:17 AM, Nick Coghlan wrote: > Yep, this is an area where laziness is definitely a virtue - if work > is only needed to handle a hypothetical future change, then it can be > deferred and handled as part of that change. :) > I would say that even renaming the files can wait until we actually have a conflict. Note that reimplementing enum.py in C will not cause a conflict because that code will likely go to Modules/enum.c or Modules/_enum.c and not in Objects/enumobject.c. If any renaming in Objects/ directory is in order, I would start with longobject.c and unicodeobject.c rather than enumobject.c. It is fairly obvious to look for enumerate code next to range code and tab-completion gets me to the right file fairly quickly. On the other hand, I've been trying to find intobject.c in 3.x code on more than one occasion. ___ 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] Allowing to run certain regression tests in subprocesses
Hi All, Today the issue of cross-test global env dependencies showed its ugly head again for me. I recall a previous discussion (http://mail.python.org/pipermail/python-dev/2013-January/123409.html) but there were many more over the years. The core problem is that some tests modify the global env (particularly importing modules) and this sometimes has adverse effects on other tests, because test.regrtest runs all tests in a single process. In the discussion linked above, the particular culprit test__all__ was judged as a candidate to be moved to a subprocess. I want to propose adding a capability to our test harness to run specific tests in subprocesses. Each test will have some simple way of asking to be run in a subprocess, and regrtest will concur (even when running -j1). test__all__ can go there, and it can help solve other problems. My particular case is trying to write a test for http://bugs.python.org/issue14988 - wherein I have to simulate a situation of non-existent pyexpat. It's not hard to write a test for it, but when run in tandem with other tests (where C extensions loaded pyexpat) it becomes seemingly impossible to set up. This should not be the case - there's nothing wrong with wanting to simulate this case, and there's nothing wrong in Python and the stdlib - it's purely an artifact of the way our regression suite works. Thoughts? Eli ___ 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] Allowing to run certain regression tests in subprocesses
On Sat, Aug 3, 2013 at 4:36 PM, Eli Bendersky wrote: > Hi All, > > Today the issue of cross-test global env dependencies showed its ugly > head again for me. I recall a previous discussion > (http://mail.python.org/pipermail/python-dev/2013-January/123409.html) > but there were many more over the years. > > The core problem is that some tests modify the global env > (particularly importing modules) and this sometimes has adverse > effects on other tests, because test.regrtest runs all tests in a > single process. In the discussion linked above, the particular culprit > test__all__ was judged as a candidate to be moved to a subprocess. > > I want to propose adding a capability to our test harness to run > specific tests in subprocesses. Each test will have some simple way of > asking to be run in a subprocess, and regrtest will concur (even when > running -j1). test__all__ can go there, and it can help solve other > problems. > > My particular case is trying to write a test for > http://bugs.python.org/issue14988 - wherein I have to simulate a > situation of non-existent pyexpat. It's not hard to write a test for > it, but when run in tandem with other tests (where C extensions loaded > pyexpat) it becomes seemingly impossible to set up. This should not be > the case - there's nothing wrong with wanting to simulate this case, > and there's nothing wrong in Python and the stdlib - it's purely an > artifact of the way our regression suite works. > > Thoughts? > > Eli FWIW the problem is also discussed here: http://bugs.python.org/issue1674555, w.r.t. test_site Eli ___ 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] PEP 8 modernisation
On Thu, Aug 1, 2013 at 8:44 AM, Nick Coghlan wrote: > > 9. Explicit guideline not to assign lambdas to names (use def, that's > what it's for) Would you consider changing the formatting in the recommended example from def f(x): return 2*x to def f(x): return 2*x ? What is the modern view on single-line def? The "Other Recommendations" section allows but discourages single-line if/for/while, but is silent about def. ___ 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] Allowing to run certain regression tests in subprocesses
On Sat, 03 Aug 2013 16:47:37 -0700, Eli Bendersky wrote: > On Sat, Aug 3, 2013 at 4:36 PM, Eli Bendersky wrote: > > Hi All, > > > > Today the issue of cross-test global env dependencies showed its ugly > > head again for me. I recall a previous discussion > > (http://mail.python.org/pipermail/python-dev/2013-January/123409.html) > > but there were many more over the years. > > > > The core problem is that some tests modify the global env > > (particularly importing modules) and this sometimes has adverse > > effects on other tests, because test.regrtest runs all tests in a > > single process. In the discussion linked above, the particular culprit > > test__all__ was judged as a candidate to be moved to a subprocess. > > > > I want to propose adding a capability to our test harness to run > > specific tests in subprocesses. Each test will have some simple way of > > asking to be run in a subprocess, and regrtest will concur (even when > > running -j1). test__all__ can go there, and it can help solve other > > problems. > > > > My particular case is trying to write a test for > > http://bugs.python.org/issue14988 - wherein I have to simulate a > > situation of non-existent pyexpat. It's not hard to write a test for > > it, but when run in tandem with other tests (where C extensions loaded > > pyexpat) it becomes seemingly impossible to set up. This should not be > > the case - there's nothing wrong with wanting to simulate this case, > > and there's nothing wrong in Python and the stdlib - it's purely an > > artifact of the way our regression suite works. > > > > Thoughts? > > > > Eli > > FWIW the problem is also discussed here: > http://bugs.python.org/issue1674555, w.r.t. test_site Can't you just launch a subprocess from the test itself using script_helpers? --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] Allowing to run certain regression tests in subprocesses
On 4 Aug 2013 09:43, "Eli Bendersky" wrote: > > Hi All, > > Today the issue of cross-test global env dependencies showed its ugly > head again for me. I recall a previous discussion > (http://mail.python.org/pipermail/python-dev/2013-January/123409.html) > but there were many more over the years. > > The core problem is that some tests modify the global env > (particularly importing modules) and this sometimes has adverse > effects on other tests, because test.regrtest runs all tests in a > single process. In the discussion linked above, the particular culprit > test__all__ was judged as a candidate to be moved to a subprocess. > > I want to propose adding a capability to our test harness to run > specific tests in subprocesses. Each test will have some simple way of > asking to be run in a subprocess, and regrtest will concur (even when > running -j1). test__all__ can go there, and it can help solve other > problems. > > My particular case is trying to write a test for > http://bugs.python.org/issue14988 - wherein I have to simulate a > situation of non-existent pyexpat. It's not hard to write a test for > it, but when run in tandem with other tests (where C extensions loaded > pyexpat) it becomes seemingly impossible to set up. This should not be > the case - there's nothing wrong with wanting to simulate this case, > and there's nothing wrong in Python and the stdlib - it's purely an > artifact of the way our regression suite works. I'm not actively opposed to the suggested idea, but is there a specific reason "test.support.import_fresh_module" doesn't work for this test? Cheers, Nick. > > Thoughts? > > Eli > ___ > 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/ncoghlan%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] Allowing to run certain regression tests in subprocesses
On Sat, Aug 3, 2013 at 6:59 PM, Nick Coghlan wrote: > > On 4 Aug 2013 09:43, "Eli Bendersky" wrote: >> >> Hi All, >> >> Today the issue of cross-test global env dependencies showed its ugly >> head again for me. I recall a previous discussion >> (http://mail.python.org/pipermail/python-dev/2013-January/123409.html) >> but there were many more over the years. >> >> The core problem is that some tests modify the global env >> (particularly importing modules) and this sometimes has adverse >> effects on other tests, because test.regrtest runs all tests in a >> single process. In the discussion linked above, the particular culprit >> test__all__ was judged as a candidate to be moved to a subprocess. >> >> I want to propose adding a capability to our test harness to run >> specific tests in subprocesses. Each test will have some simple way of >> asking to be run in a subprocess, and regrtest will concur (even when >> running -j1). test__all__ can go there, and it can help solve other >> problems. >> >> My particular case is trying to write a test for >> http://bugs.python.org/issue14988 - wherein I have to simulate a >> situation of non-existent pyexpat. It's not hard to write a test for >> it, but when run in tandem with other tests (where C extensions loaded >> pyexpat) it becomes seemingly impossible to set up. This should not be >> the case - there's nothing wrong with wanting to simulate this case, >> and there's nothing wrong in Python and the stdlib - it's purely an >> artifact of the way our regression suite works. > > I'm not actively opposed to the suggested idea, but is there a specific > reason "test.support.import_fresh_module" doesn't work for this test? I'm not an expert on this topic, but I believe there's a problem unloading code that was loaded by C extensions. import_fresh_module is thus powerless here (which also appears to be the case empirically). Eli ___ 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] Fwd: Allowing to run certain regression tests in subprocesses
On Sat, Aug 3, 2013 at 6:57 PM, R. David Murray wrote: > On Sat, 03 Aug 2013 16:47:37 -0700, Eli Bendersky wrote: >> On Sat, Aug 3, 2013 at 4:36 PM, Eli Bendersky wrote: >> > Hi All, >> > >> > Today the issue of cross-test global env dependencies showed its ugly >> > head again for me. I recall a previous discussion >> > (http://mail.python.org/pipermail/python-dev/2013-January/123409.html) >> > but there were many more over the years. >> > >> > The core problem is that some tests modify the global env >> > (particularly importing modules) and this sometimes has adverse >> > effects on other tests, because test.regrtest runs all tests in a >> > single process. In the discussion linked above, the particular culprit >> > test__all__ was judged as a candidate to be moved to a subprocess. >> > >> > I want to propose adding a capability to our test harness to run >> > specific tests in subprocesses. Each test will have some simple way of >> > asking to be run in a subprocess, and regrtest will concur (even when >> > running -j1). test__all__ can go there, and it can help solve other >> > problems. >> > >> > My particular case is trying to write a test for >> > http://bugs.python.org/issue14988 - wherein I have to simulate a >> > situation of non-existent pyexpat. It's not hard to write a test for >> > it, but when run in tandem with other tests (where C extensions loaded >> > pyexpat) it becomes seemingly impossible to set up. This should not be >> > the case - there's nothing wrong with wanting to simulate this case, >> > and there's nothing wrong in Python and the stdlib - it's purely an >> > artifact of the way our regression suite works. >> > >> > Thoughts? >> > >> > Eli >> >> FWIW the problem is also discussed here: >> http://bugs.python.org/issue1674555, w.r.t. test_site > > Can't you just launch a subprocess from the test itself using script_helpers? > [sorry, sent privately by mistake; forwarding to pydev] I can, but such launching will be necessarily duplicated across all tests that need this functionality (test_site, test___all__, etc). Since regrtest already has functionality for launching whole test-suites in subprocesses, it makes sense to reuse it, no? Eli ___ 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] Allowing to run certain regression tests in subprocesses
On 4 Aug 2013 12:03, "Eli Bendersky" wrote: > > On Sat, Aug 3, 2013 at 6:59 PM, Nick Coghlan wrote: > > > > On 4 Aug 2013 09:43, "Eli Bendersky" wrote: > >> > >> Hi All, > >> > >> Today the issue of cross-test global env dependencies showed its ugly > >> head again for me. I recall a previous discussion > >> (http://mail.python.org/pipermail/python-dev/2013-January/123409.html) > >> but there were many more over the years. > >> > >> The core problem is that some tests modify the global env > >> (particularly importing modules) and this sometimes has adverse > >> effects on other tests, because test.regrtest runs all tests in a > >> single process. In the discussion linked above, the particular culprit > >> test__all__ was judged as a candidate to be moved to a subprocess. > >> > >> I want to propose adding a capability to our test harness to run > >> specific tests in subprocesses. Each test will have some simple way of > >> asking to be run in a subprocess, and regrtest will concur (even when > >> running -j1). test__all__ can go there, and it can help solve other > >> problems. > >> > >> My particular case is trying to write a test for > >> http://bugs.python.org/issue14988 - wherein I have to simulate a > >> situation of non-existent pyexpat. It's not hard to write a test for > >> it, but when run in tandem with other tests (where C extensions loaded > >> pyexpat) it becomes seemingly impossible to set up. This should not be > >> the case - there's nothing wrong with wanting to simulate this case, > >> and there's nothing wrong in Python and the stdlib - it's purely an > >> artifact of the way our regression suite works. > > > > I'm not actively opposed to the suggested idea, but is there a specific > > reason "test.support.import_fresh_module" doesn't work for this test? > > I'm not an expert on this topic, but I believe there's a problem > unloading code that was loaded by C extensions. import_fresh_module is > thus powerless here (which also appears to be the case empirically). Sure, it's just unusual to have a case where "importing is blocked by adding None to sys.modules" differs from "not actually available", so I'd like to understand the situation better. Cheers, Nick. > > Eli ___ 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] PEP 8 modernisation
On 4 Aug 2013 11:30, "Alexander Belopolsky" wrote: > > > On Thu, Aug 1, 2013 at 8:44 AM, Nick Coghlan wrote: > > > > 9. Explicit guideline not to assign lambdas to names (use def, that's > > what it's for) > > > Would you consider changing the formatting in the recommended example from > > def f(x): return 2*x > > to > > def f(x): > return 2*x > > ? I consider a single line def acceptable when replacing an equivalent lambda. Restricting it to a single line makes it solely about the spelling of the assignment operation, without any vertical whitespace considerations. Cheers, Nick. > > What is the modern view on single-line def? The "Other Recommendations" section allows but discourages single-line if/for/while, but is silent about def. ___ 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] PEP 8 modernisation
On 02/08/13 06:52, Alexander Belopolsky wrote: On Thu, Aug 1, 2013 at 4:29 PM, Terry Reedy wrote: def f(x): return 2*x f = lambda x: 2*x Am I the only one who finds the second line above much more readable than the first? The def statement is not intended to be written in one line. The readability suffers because the argument is separated from the value expression by return keyword. You are not the only one. I will continue to write "f = lambda ..." at the interactive interpreter without shame, although I rarely (never?) use it in code. -- Steven ___ 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] [RELEASED] Python 3.4.0a1
On behalf of the Python development team, I'm pleased to announce the first alpha release 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 so far include: * PEP 435, a standardized "enum" module * 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 To download Python 3.4.0a1 visit: http://www.python.org/download/releases/3.4.0/ Please consider trying Python 3.4.0a1 with your code and reporting any issues you notice to: http://bugs.python.org/ Enjoy! -- 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 http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RELEASED] Python 3.4.0a1
On 08/03/2013 11:22 PM, Larry Hastings wrote: * PEP 435, a standardized "enum" module * 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 Whoops, looks like I missed a couple here. I was in a hurry and just went off what I could find in Misc/NEWS. I'll have a more complete list in the release schedule PEP in a minute, and in the announcements for alpha 2. If you want to make sure your PEP is mentioned next time, by all means email me and rattle my cage. My apologies to those I overlooked, //arry/ ___ 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
