Re: [Python-Dev] PEP 8 modernisation

2013-08-02 Thread Alexander Shorin 
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 will hit the PEP rule :

> While sometimes it's okay to put an if/for/while with a small body on the 
> same line, never do this for multi-clause statements. Also avoid folding such 
> long lines!

On Fri, Aug 2, 2013 at 12:29 AM, Terry Reedy  wrote:
>> and/or to remove duplicates (especially for sorted groupby case)?
> I do not understand this.

See [Python-Dev] Lambda [was Re: PEP 8 modernisation] thread for example:
http://mail.python.org/pipermail/python-dev/2013-August/127715.html

On Fri, Aug 2, 2013 at 12:35 AM, Terry Reedy  wrote:
>> I understand this, but I'm a bit confused about fate of lambdas with
>> such guideline since I see no more reasons to use them with p.9
>> statement: long lines, code duplicate, no mock and well tests etc. -
>> all these problems could be solved with assigning lambda to some name,
>> but now they are looks useless (or useful only for very trivial cases)
>
>I do not understand most of that, but...
>The guideline is not meant to cover passing a function by parameter name.  
>mylist.sort(key=lambda x: x[0]) is still ok. Does "Always use a def statement 
>>instead of assigning a lambda expression to a name." need 'in an assignment 
>statement' added?

I wrote about that lambda`s use case become too small to use them in
real code. If they are dishonoured - need to write so and clearly, but
not limiting their use cases step by step till every Python devs will
think like "Lambdas? Why? Remove them!".

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 = lambda x,y: x*y
mul = lambda x, y: x+y

Probably, I don't since dict is a blackbox and I have to check things
first before use them.

Disclaimer:  I don't try to stand for lambdas, I'm not using them
everywhere in my code, but I'd like to know answer for the question
"Why lambdas?". Currently, it is "Handy shorthand functions - use them
free", but with new PEP-8 statement I really have to think like
"Lambdas? Really, why?".

P.S.

On Thu, Aug 1, 2013 at 3:36 PM, Terry Reedy  wrote:
> Please stop both the top-posting and the FUD.

Sorry, different ML, different rules. You know mail client with allows
to have per-address reply setting? I don't, but would like to see your
suggestions in private answer. Thanks.
--
,,,^..^,,,


On Fri, Aug 2, 2013 at 12:56 AM, Terry Reedy  wrote:
> On 8/1/2013 11:35 AM, Alexander Belopolsky wrote:
>
>> Here is one use-case where .. =  lambda .. cannot be replaced with def ..
>>
>> op['add'] = lambda x,y: x+y
>> op['mul'] = lambda x, y: x*y
>
>
> Yes, you are binding the functions to named slots, not to names, so not
> covered by the PEP. Once might still want to replace the expressions
> themselves, at the cost of more typing, for the advantage of better
> representations.
>
> op = { 'add': lambda x,y: x*y, 'mul':  lambda x, y: x+y}
> print(op)  # no apparent problem
> # {'add':  at 0x0227F730>,
> # 'mul':  at 0x033867B8>}
>
> def add(x, y): return x + y
> def mul(x, y): return x * y
> # These can be unittested individually
>
> op = {'add': mul, 'mul': add}  # mistake easily seen in original code
> print(op)
> # {'add': ,
> # 'mul': }
> # problem apparent to user who import this object and prints it when code
> fails
>
> If op has 20 such functions, names become even more of an advantage
>
> --
> Terry Jan Reedy
>
>
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/kxepal%40gmail.com
___
Python-Dev mailing list
[email protected]
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 446: Open issues/questions

2013-08-02 Thread Richard Oudkerk 

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 there's a race
in a multi-threaded program, but AFAICT that's already the case right
now, and Windows API doesn't leave us any other choice.
Amusingly, they address this case by recommending putting process
creation in a critical section:
http://support.microsoft.com/kb/315939/en-us

This way, we keep default platform behavior on Unix and on Windows (so
user using low-level syscalls/APIs won't be surprised), and we have a
clean way to selectively inherit FD in child processes through
subprocess.


http://bugs.python.org/issue16500 is a proposal/patch for adding atfork. 
 But it also has a public recursive lock which is held when starting 
processes using fork()/subprocess/multiprocessing.  This is so that 
users can safely manipulate fds while holding the lock, without these 
sorts of race conditions.  For example


with atfork.getlock():
fd = os.open("somefile", os.O_CREAT | os.O_WRONLY, 0600)
flags = fcntl.fcntl(fd, fcntl.F_GETFL)
fcntl.fcntl(fd, fcntl.F_SETFL, flags | fcntl.FD_CLOEXEC)

--
Richard

___
Python-Dev mailing list
[email protected]
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 446: Open issues/questions

2013-08-02 Thread Richard Oudkerk 

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. Is this correct?


It depends whether the handles use FILE_SHARE_DELETE.  The Python module 
tempfile uses the O_TEMPORARY flag which implies FILE_SHARE_DELETE. 
This means that the file *can* be deleted/moved while there are open 
handles.  Annoyingly the folder containing that file still cannot be 
deleted while there are open handles.


--
Richard

___
Python-Dev mailing list
[email protected]
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 446: Open issues/questions

2013-08-02 Thread Richard Oudkerk 

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 handle in handles:
 os.set_inheritable(handle, True)
subprocess.call(...)
for handle in handles:
 os.set_inheritable(handle, False)

This example is safe if the application has a single thread (if a
single thread spawn new programs). Making handles non-inheritable
again may be useless.


If we have a recursive lock which is always held when Python starts a 
process then you could write:


  with subprocess.getlock():
  for handle in handles:
  os.set_inheritable(handle, True)
  subprocess.call(...)
  for handle in handles:
  os.set_inheritable(handle, False)

This should be used by fork() and multiprocessing too.

--
Richard

___
Python-Dev mailing list
[email protected]
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

2013-08-02 Thread Nick Coghlan 
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 be wrapped.
>
> and if I have multiple lambda-like def`s it will hit the PEP rule :
>
> > While sometimes it's okay to put an if/for/while with a small body on
the same line, never do this for multi-clause statements. Also avoid
folding such long lines!
>
> On Fri, Aug 2, 2013 at 12:29 AM, Terry Reedy  wrote:
> >> and/or to remove duplicates (especially for sorted groupby case)?
> > I do not understand this.
>
> See [Python-Dev] Lambda [was Re: PEP 8 modernisation] thread for example:
> http://mail.python.org/pipermail/python-dev/2013-August/127715.html
>
> On Fri, Aug 2, 2013 at 12:35 AM, Terry Reedy  wrote:
> >> I understand this, but I'm a bit confused about fate of lambdas with
> >> such guideline since I see no more reasons to use them with p.9
> >> statement: long lines, code duplicate, no mock and well tests etc. -
> >> all these problems could be solved with assigning lambda to some name,
> >> but now they are looks useless (or useful only for very trivial cases)
> >
> >I do not understand most of that, but...
> >The guideline is not meant to cover passing a function by parameter
name.  mylist.sort(key=lambda x: x[0]) is still ok. Does "Always use a def
statement >instead of assigning a lambda expression to a name." need 'in an
assignment statement' added?
>
> I wrote about that lambda`s use case become too small to use them in
> real code. If they are dishonoured - need to write so and clearly, but
> not limiting their use cases step by step till every Python devs will
> think like "Lambdas? Why? Remove them!".

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 = lambda x,y: x*y
> mul = lambda x, y: x+y
>
> Probably, I don't since dict is a blackbox and I have to check things
> first before use them.

People are free to write their own style guides that disagree with pep 8 (a
point which is now made explicitly in the PEP).

>
> Disclaimer:  I don't try to stand for lambdas, I'm not using them
> everywhere in my code, but I'd like to know answer for the question
> "Why lambdas?". Currently, it is "Handy shorthand functions - use them
> free", but with new PEP-8 statement I really have to think like
> "Lambdas? Really, why?".

Use them for an anonymous function as an expression. All PEP 8 is now
saying is that giving a lambda a name is to completely misunderstand what
they're for.

Cheers,
Nick.
___
Python-Dev mailing list
[email protected]
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

2013-08-02 Thread Alexander Shorin 
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 = lambda x,y: x*y
>> mul = lambda x, y: x+y
>>
>> Probably, I don't since dict is a blackbox and I have to check things
>> first before use them.
>
> People are free to write their own style guides that disagree with pep 8 (a
> point which is now made explicitly in the PEP).
>
>>
>> Disclaimer:  I don't try to stand for lambdas, I'm not using them
>> everywhere in my code, but I'd like to know answer for the question
>> "Why lambdas?". Currently, it is "Handy shorthand functions - use them
>> free", but with new PEP-8 statement I really have to think like
>> "Lambdas? Really, why?".
>
> Use them for an anonymous function as an expression. All PEP 8 is now saying
> is that giving a lambda a name is to completely misunderstand what they're
> for.
>
> Cheers,
> Nick.

Thanks for explanations, Nick, I'd got the point.

--
,,,^..^,,,
___
Python-Dev mailing list
[email protected]
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 446: Open issues/questions

2013-08-02 Thread Victor Stinner 
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 platform exist?
> >>
> >> FD_CLOEXEC is POSIX:
> >> http://pubs.opengroup.org/onlinepubs/9699919799/functions/fcntl.html
> >
> > Ok, but this information does not help me. Does Python support
> > non-POSIX platforms? (Windows has HANDLE_FLAG_INHERIT.)
> >
> > If we cannot answer to my question, it's safer to leave
> > os.get/set_inheritable() optional (need hasattr in tests for example).
>
> On Unix platforms, you should always have FD_CLOEXEC.
> If there were such a platform without FD inheritance support, then it
> would probably make sense to make it a no-op

Ok, and os.get_inheritable() can also always return False.

It would prefer to fail with a compiler error is the platform is unknown. A
platform might support FD inheritance, but with something different than
fcntl() or ioctl() (ex: Windows).

Victor
___
Python-Dev mailing list
[email protected]
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 446: Open issues/questions

2013-08-02 Thread Victor Stinner 
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
___
Python-Dev mailing list
[email protected]
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 446: Open issues/questions

2013-08-02 Thread Victor Stinner 
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
[email protected]
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 446: Open issues/questions

2013-08-02 Thread Richard Oudkerk 

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 ignored by other C threads. It is unsafe if
Python is embedded.


True.

--
Richard

___
Python-Dev mailing list
[email protected]
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 446: Open issues/questions

2013-08-02 Thread Antoine Pitrou 
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().

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
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 446: Open issues/questions

2013-08-02 Thread Antoine Pitrou 
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 is POSIX:
> > http://pubs.opengroup.org/onlinepubs/9699919799/functions/fcntl.html
> 
> Ok, but this information does not help me. Does Python support
> non-POSIX platforms? (Windows has HANDLE_FLAG_INHERIT.)

Python works under POSIX and Windows. Not sure what else you are
thinking about :-)

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2013-08-02 Thread Matt McClure 
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 do you think of a change like this?

$ hg diff
diff -r 3bd55ec317a7 Lib/unittest/suite.py
--- a/Lib/unittest/suite.py Thu Aug 01 23:57:21 2013 +0200
+++ b/Lib/unittest/suite.py Fri Aug 02 07:42:22 2013 -0400
@@ -90,7 +90,12 @@
 if getattr(result, '_testRunEntered', False) is False:
 result._testRunEntered = topLevel = True

-for test in self:
+while True:
+try:
+test = self._tests.pop(0)
+except IndexError:
+break
+
 if result.shouldStop:
 break

See also the conversation on django-developers[1] that led me here.

[1]: https://groups.google.com/forum/#!topic/django-developers/XUMetDSGVT0

-- 
Matt McClure
http://matthewlmcclure.com
http://www.mapmyfitness.com/profile/matthewlmcclure
___
Python-Dev mailing list
[email protected]
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

2013-08-02 Thread Michael Foord 


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 to 
> exhausting all available memory and the OS killing the test process.

Well individual tests not releasing resources could be seen as a bug in those 
tests.

That aside, 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. 

Michael


> 
> What do you think of a change like this?
> 
> $ hg diff
> diff -r 3bd55ec317a7 Lib/unittest/suite.py
> --- a/Lib/unittest/suite.py   Thu Aug 01 23:57:21 2013 +0200
> +++ b/Lib/unittest/suite.py   Fri Aug 02 07:42:22 2013 -0400
> @@ -90,7 +90,12 @@
>  if getattr(result, '_testRunEntered', False) is False:
>  result._testRunEntered = topLevel = True
>  
> -for test in self:
> +while True:
> +try:
> +test = self._tests.pop(0)
> +except IndexError:
> +break
> +
>  if result.shouldStop:
>  break
>  
> See also the conversation on django-developers[1] that led me here.
> 
> [1]: https://groups.google.com/forum/#!topic/django-developers/XUMetDSGVT0
> 
> -- 
> Matt McClure
> http://matthewlmcclure.com
> http://www.mapmyfitness.com/profile/matthewlmcclure
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Summary of Python tracker Issues

2013-08-02 Thread Python tracker 

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 with patches: 1856 


Issues opened (53)
==

#10241: gc fixes for module m_copy attribute
http://bugs.python.org/issue10241  reopened by pitrou

#18562: Regex howto: revision pass
http://bugs.python.org/issue18562  opened by akuchling

#18563: No unit test for yiq to rgb  and rgb to yiq converting functio
http://bugs.python.org/issue18563  opened by vajrasky

#18564: Integer overflow in socketmodule
http://bugs.python.org/issue18564  opened by maker

#18566: In unittest.TestCase docs for setUp() and tearDown() don't men
http://bugs.python.org/issue18566  opened by py.user

#18567: Python 2.7.5 CENTOS6 Error building dbm using bdb
http://bugs.python.org/issue18567  opened by Denise.Mauldin

#18570: OverflowError in division: wrong message
http://bugs.python.org/issue18570  opened by marco.buttu

#18571: Implementation of the PEP 446: non-inheriable file descriptors
http://bugs.python.org/issue18571  opened by haypo

#18572: Remove redundant note about surrogates in string escape doc
http://bugs.python.org/issue18572  opened by stevenjd

#18574: BaseHTTPRequestHandler.handle_expect_100() sends invalid respo
http://bugs.python.org/issue18574  opened by Nikratio

#18575: Fixing tarfile._mode when using gzip via ":gz"
http://bugs.python.org/issue18575  opened by edulix

#18576: Rename and document test.script_helper as test.support.script_
http://bugs.python.org/issue18576  opened by ncoghlan

#18577: lru_cache enhancement: lru_timestamp helper function
http://bugs.python.org/issue18577  opened by [email protected]

#18578: Rename and document test.bytecode_helper as test.support.bytec
http://bugs.python.org/issue18578  opened by ncoghlan

#18579: Dereference after NULL check in listobject.c merge_hi()
http://bugs.python.org/issue18579  opened by christian.heimes

#18581: Duplicate test and missing class test in test_abc.py
http://bugs.python.org/issue18581  opened by vajrasky

#18582: PBKDF2 support
http://bugs.python.org/issue18582  opened by christian.heimes

#18583: Idle: enhance FormatParagraph
http://bugs.python.org/issue18583  opened by terry.reedy

#18585: Add a text truncation function
http://bugs.python.org/issue18585  opened by pitrou

#18586: Allow running benchmarks for Python 3 from same directory
http://bugs.python.org/issue18586  opened by brett.cannon

#18588: timeit examples should be consistent
http://bugs.python.org/issue18588  opened by claymation

#18590: 'Search' and 'Replace' dialogs don't work on quoted text in Wi
http://bugs.python.org/issue18590  opened by Sarah

#18591: threading.Thread.run returning a result
http://bugs.python.org/issue18591  opened by James.Lu

#18592: IDLE: Unit test for SearchDialogBase.py
http://bugs.python.org/issue18592  opened by philwebster

#18594: C accelerator for collections.Counter is slow
http://bugs.python.org/issue18594  opened by scoder

#18595: zipfile: symlinks etc.
http://bugs.python.org/issue18595  opened by ronaldoussoren

#18596: enable usage of AddressSanitizer in CPython [PATCH]
http://bugs.python.org/issue18596  opened by halfie

#18597: On Windows sys.stdin.readline() doesn't handle Ctrl-C properly
http://bugs.python.org/issue18597  opened by Drekin

#18598: Importlib, more verbosity please
http://bugs.python.org/issue18598  opened by Lukáš.Němec

#18600: email.policy doc example passes 'policy' to as_string, but tha
http://bugs.python.org/issue18600  opened by r.david.murray

#18602: "_io" module names itself "io"
http://bugs.python.org/issue18602  opened by pitrou

#18603: PyOS_mystricmp unused and no longer available
http://bugs.python.org/issue18603  opened by christian.heimes

#18604: Consolidate gui available checks in test.support
http://bugs.python.org/issue18604  opened by terry.reedy

#18605: 2.7: test_threading hangs on Solaris 9
http://bugs.python.org/issue18605  opened by automatthias

#18606: Add statistics module to standard library
http://bugs.python.org/issue18606  opened by stevenjd

#18609: test_ctypes failure on AIX in PyEval_CallObjectWithKeywords
http://bugs.python.org/issue18609  opened by David.Edelsohn

#18610: wsgiref.validate expects wsgi.input read to give exactly one a
http://bugs.python.org/issue18610  opened by Robin.Schoonover

#18611: Mac: Some Python Launcher issues
http://bugs.python.org/issue18611  opened by ronaldoussoren

#18612: More elaborate documentation on how list comprehensions and ge
http://bugs.python.org/issue18612  opened by uglemat

#18614: Enhanced \N{} escapes for Unicode strings
http://bugs.python.org/issue18614  opened by stevenjd

#18615: sndhdr.whathdr could return a namedtuple
http://bugs.python.org/issue18615  opened by Claudiu.Popa

#18616: enable more ssl socket options

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

2013-08-02 Thread Antoine Pitrou 
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 instances consume memory during
> > execution, that can lead to exhausting all available memory and the
> > OS killing the test process.
> 
> Well individual tests not releasing resources could be seen as a bug
> in those tests.
> 
> That aside, 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. 

The patch is basically ready for commit, except for a possible doc
addition, no?

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
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

2013-08-02 Thread Michael Foord 


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, 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.
>> 
>> Well individual tests not releasing resources could be seen as a bug
>> in those tests.
>> 
>> That aside, 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.
> 
> 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.

Michael 



> 
> Regards
> 
> Antoine.
> 
> 
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk
___
Python-Dev mailing list
[email protected]
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

2013-08-02 Thread Matt McClure 
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.

-- 
Matt McClure
http://matthewlmcclure.com
http://www.mapmyfitness.com/profile/matthewlmcclure
___
Python-Dev mailing list
[email protected]
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] peps: Use Guido's preferred wording re: line length

2013-08-02 Thread Nick Coghlan 
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
check line lengths as well as trailing whitespace.

That raises issues when modifying existing non-compliant files, because it
removes the human judgement on whether a non-compliance is worth fixing or
not.

Cheers,
Nick.

> ___
> Python-checkins mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-checkins
___
Python-Dev mailing list
[email protected]
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] peps: Use Guido's preferred wording re: line length

2013-08-02 Thread Nick Coghlan 
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 limiting
>>  >> +lines to 79 characters (and docstrings/comments to 72).
>>  >
>>  >
>>  > If you (and Guido) mean that as a hard limit, then patchcheck should
>> check line lengths as well as trailing whitespace.
>>
>> That raises issues when modifying existing non-compliant files, because
>> it removes the human judgement on whether a non-compliance is worth
>> fixing or not.
>
>
> I meant tools/scripts/patchcheck.py, not the pre-commit hook. The check
would inform (especially for old files) or remind (for new files) so that
judgment could be applied.

Ah, right. Yeah, that may be reasonable.

A warning option on reindent.py may be a place to start if someone wanted
to implement it. Whether or not patchcheck used that option would likely
depend on the initial results of running it manually :)

Cheers,
Nick.
>
> ___
> Python-checkins mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-checkins
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2013-08-02 Thread Eli Bendersky 
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 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.

Eli
___
Python-Dev mailing list
[email protected]
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?

2013-08-02 Thread Nick Coghlan 
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 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.

Sounds good to me.

Cheers,
Nick.

>
> Eli
>
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
http://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
>
___
Python-Dev mailing list
[email protected]
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?

2013-08-02 Thread Raymond Hettinger 

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.


Raymond




___
Python-Dev mailing list
[email protected]
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?

2013-08-02 Thread Nick Coghlan 
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/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.

Oops, I missed the part about renaming things in the code. I'm with
Raymond on that part (i.e. not worth it) - I was just agreeing to
renaming the files.

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com