Re: [Python-Dev] objections to renaming enumobject.h/c in 3.4?

On 3 August 2013 16:20, 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/en

Re: [Python-Dev] objections to renaming enumobject.h/c in 3.4?

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 dec

Re: [Python-Dev] objections to renaming enumobject.h/c in 3.4?

On 3 Aug 2013 13:50, "Eli Bendersky" wrote: > > Hi all, > > 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 decid

[Python-Dev] objections to renaming enumobject.h/c in 3.4?

Hi all, 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 objectio

Re: [Python-Dev] [Python-checkins] peps: Use Guido's preferred wording re: line length

On 3 Aug 2013 12:45, "Terry Reedy" wrote: > > > > On 8/2/2013 10:26 PM, Nick Coghlan wrote: >> >> >> On 3 Aug 2013 11:07, "Terry Reedy" > > wrote: >> > >> > On 8/2/2013 6:19 AM, nick.coghlan wrote: >> > >> >> +The Python standard library is conservative and requires li

Re: [Python-Dev] [Python-checkins] peps: Use Guido's preferred wording re: line length

On 3 Aug 2013 11:07, "Terry Reedy" wrote: > > On 8/2/2013 6:19 AM, nick.coghlan wrote: > >> +The Python standard library is conservative and requires limiting >> +lines to 79 characters (and docstrings/comments to 72). > > > If you (and Guido) mean that as a hard limit, then patchcheck should chec

Re: [Python-Dev] unittest.TestSuite holding references to unittest.TestCase instances too long

On Fri, Aug 2, 2013 at 11:13 AM, Michael Foord wrote: > There's an open bug for this with some discussion and a proposed fix: > > http://bugs.python.org/issue11798 > > The agreed on approach just needs doing. > Thanks for the link. I hadn't found that yet. I'll see if I can contribute there. --

Re: [Python-Dev] unittest.TestSuite holding references to unittest.TestCase instances too long

Sent from my iPhone On 2 Aug 2013, at 19:19, Antoine Pitrou wrote: > Le Fri, 2 Aug 2013 18:13:13 +0300, > Michael Foord a écrit : >> >> On 2 Aug 2013, at 14:51, Matt McClure >> wrote: >> >>> It seems unittest.TestSuite holds references to unittest.TestCase >>> instances after the test runs

Re: [Python-Dev] unittest.TestSuite holding references to unittest.TestCase instances too long

Le Fri, 2 Aug 2013 18:13:13 +0300, Michael Foord a écrit : > > On 2 Aug 2013, at 14:51, Matt McClure > wrote: > > > It seems unittest.TestSuite holds references to unittest.TestCase > > instances after the test runs, until the test suite finishes. In a > > large suite, where the TestCase instan

[Python-Dev] Summary of Python tracker Issues

ACTIVITY SUMMARY (2013-07-26 - 2013-08-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: open4128 (+14) closed 26274 (+54) total 30402 (+68) Open issues wit

Re: [Python-Dev] unittest.TestSuite holding references to unittest.TestCase instances too long

Sent from my iPhone On 2 Aug 2013, at 14:51, Matt McClure wrote: > It seems unittest.TestSuite holds references to unittest.TestCase instances > after the test runs, until the test suite finishes. In a large suite, where > the TestCase instances consume memory during execution, that can lead

[Python-Dev] unittest.TestSuite holding references to unittest.TestCase instances too long

It seems unittest.TestSuite holds references to unittest.TestCase instances after the test runs, until the test suite finishes. In a large suite, where the TestCase instances consume memory during execution, that can lead to exhausting all available memory and the OS killing the test process. What

Re: [Python-Dev] PEP 446: Open issues/questions

Le Fri, 2 Aug 2013 02:27:43 +0200, Victor Stinner a écrit : > 2013/7/28 Antoine Pitrou : > >> (A) How should we support support where os.set_inheritable() is not > >> supported? Can we announce that os.set_inheritable() is always > >> available or not? Does such platform exist? > > > > FD_CLOEXEC

Re: [Python-Dev] PEP 446: Open issues/questions

Le Fri, 2 Aug 2013 13:30:56 +0200, Victor Stinner a écrit : > Is it possible to implement atfork on Windows? > > A Python lock would be ignored by other C threads. It is unsafe if > Python is embedded. It is unsafe if Python is embedded *and* the embedding application uses fork() + exec(). Rega

Re: [Python-Dev] PEP 446: Open issues/questions

On 02/08/2013 12:30pm, Victor Stinner wrote: Is it possible to implement atfork on Windows? On Windows the patch does expose atfork.getlock() and uses it in subprocess. (It should also modify os.spawn?(), os.startfile() etc.) But atfork.atfork() is Unix only. A Python lock would be ignore

Re: [Python-Dev] PEP 446: Open issues/questions

Is it possible to implement atfork on Windows? A Python lock would be ignored by other C threads. It is unsafe if Python is embedded. Victor ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe

Re: [Python-Dev] PEP 446: Open issues/questions

http://support.microsoft.com/kb/315939/en-us Ah yes, we may implement pass_handles on Windows using a critical section to inherit *handles*. File descriptors cannot be inherited using CreateProcess(), only using spawn(). Or can we rely on the undocumented fields used by spawn()? Victor _

Re: [Python-Dev] PEP 446: Open issues/questions

Le 2 août 2013 08:32, "Charles-François Natali" a écrit : > > 2013/8/2 Victor Stinner : > > 2013/7/28 Antoine Pitrou : > >>> (A) How should we support support where os.set_inheritable() is not > >>> supported? Can we announce that os.set_inheritable() is always > >>> available or not? Does such pl

Re: [Python-Dev] PEP 8 modernisation

On Fri, Aug 2, 2013 at 1:10 PM, Nick Coghlan wrote: > Lambda was almost removed in Python 3. > >> >> Using `dict` to store lambdas: >> >> > op = { 'add': lambda x,y: x*y, 'mul': lambda x, y: x+y} >> >> Shows the hack to bypass PEP8 guides. Do you like to see code above >> instead of: >> >> add =

Re: [Python-Dev] PEP 8 modernisation

On 2 Aug 2013 17:31, "Alexander Shorin" wrote: > > Hi Terry, > > On Fri, Aug 2, 2013 at 12:29 AM, Terry Reedy wrote: > > def f(x): return 2*x > > f = lambda x: 2*x > > Three spaces is seldom a crucial difference. If the expression is so long it go past the limit (whatever we decide it is), it can

Re: [Python-Dev] PEP 446: Open issues/questions

On 02/08/2013 1:21am, Victor Stinner wrote: 2013/7/30 Victor Stinner : I would be nice to have a "pass_handles" on Windows. I'm not sure that it's possible to implement this atomically. It's probably better to leave the application to choose how the inheritance is defined. Example: for handl

Re: [Python-Dev] PEP 446: Open issues/questions

On 02/08/2013 12:59am, Victor Stinner wrote: On Windows, a file cannot be removed if at least one process opened it. If you create a temporary file, run a program, and delete the temporary file: the deletion fails if the program inherited the file and the program is not done before the deletion.

Re: [Python-Dev] PEP 446: Open issues/questions

On 02/08/2013 7:44am, Charles-François Natali wrote: Then how about changing the default to creating file descriptors unheritable on Windows (which is apparently the default)? Then you can implement keep_fds by setting them inheritable right before creation, and resetting them right after: sure t

Re: [Python-Dev] PEP 8 modernisation

Hi Terry, On Fri, Aug 2, 2013 at 12:29 AM, Terry Reedy wrote: > def f(x): return 2*x > f = lambda x: 2*x > Three spaces is seldom a crucial difference. If the expression is so long it > go past the limit (whatever we decide it is), it can be wrapped. and if I have multiple lambda-like def`s it