[issue26374] concurrent_futures Executor.map semantics better specified in docs

[Mark Dickinson]

Mark Dickinson added the comment:

I just noticed this point, which may be confusing things:

> Rebut: order is undefined, concurrent_futures specifies map() returns an 
> iterator, where builtin map returns a list.

In Python 3, the built-in map function returns an iterator, not a list.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26385] the call of tempfile.NamedTemporaryFile fails and leaves a file on the disk

[STINNER Victor]

STINNER Victor added the comment:

> I wonder if Victor could clarify why bare except wasn't used in the python3 
> version.

What do you call a "bare except"?

I wrote "except Exception: ; raise", it doesn't ignore the error. 
I want to always call the cleanup code on error.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26385] the call of tempfile.NamedTemporaryFile fails and leaves a file on the disk

[Martin Panter]

Martin Panter added the comment:

Victor: You changed “except Exception:” to bare “except:” in revision 
182f08c0dd45 in Python 2, but the Python 3 code never got such a change.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26385] the call of tempfile.NamedTemporaryFile fails and leaves a file on the disk

[STINNER Victor]

STINNER Victor added the comment:

> Victor: You changed “except Exception:” to bare “except:” in revision 
> 182f08c0dd45 in Python 2, but the Python 3 code never got such a change.

Ah strange :-) Python 3 must also be fixed.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26385] the call of tempfile.NamedTemporaryFile fails and leaves a file on the disk

[Georg Brandl]

Changes by Georg Brandl :


--
nosy:  -georg.brandl

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26382] List object memory allocator

[Catalin Gabriel Manciu]

Catalin Gabriel Manciu added the comment:

Hi Victor,

This patch follows the same idea as your proposal, but it's focused on a single 
object type. I think doing this incrementally is the safer approach, allowing 
us to have finer control over the new 
areas where we enable allocating using the small object allocator and detect 
where this replacement might be detrimental to the performance.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26382] List object memory allocator

[STINNER Victor]

STINNER Victor added the comment:

Catalin Gabriel Manciu: "(...) allowing us to have finer control over
the new areas where we enable allocating using the small object
allocator and detect where this replacement might be detrimental to
the performance"

Ah, interesting, do you think that it's possible that my change can
*slow down* Python? I don't think so, but I'm interested on feedback
on my patch :-) You may try to run benchmarks with my patch.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26390] hashlib's pbkdf2_hmac documentation "rounds" does not match source

[Daan Bakker]

Daan Bakker added the comment:

Good catch. I updated that reference now from rounds to iterations as well.

--
Added file: http://bugs.python.org/file41969/pbkdf2_5.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26382] List object memory allocator

[Catalin Gabriel Manciu]

Catalin Gabriel Manciu added the comment:

Theoretically, an object type that consistently allocates more than the small 
object threshold would perform a bit slower because
it would first jump to the small object allocator, do the size comparison and 
then jump to malloc. There would be a small overhead 
if PyMem_* would be redirected to PyObject_* in this (hypothetical) case and 
the initial choice of PyMem_* over PyObject_* might have 
been determined by knowing about that overhead. This is because many think of 
PyMem_* as the lower-level allocator, PyObject_* as a
higher-level one. Of course, PyMem_Raw* should be used in such cases, but it's 
not as widely adopted as the other two.

I will post some benchmark results on your issue page as soon as I get them.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26382] List object memory allocator

[STINNER Victor]

STINNER Victor added the comment:

"Theoretically, an object type that consistently allocates more than the small 
object threshold would perform a bit slower because it would first jump to the 
small object allocator, do the size comparison and then jump to malloc."

I expect that the cost of the extra check is *very* cheap (completly 
negligible) compared to the cost of a call to malloc().

To have an idea of the cost of the Python code around system allocators, you 
can take a look at the Performance section of my PEP 445 which added an 
indirection to all Python allocators:
https://www.python.org/dev/peps/pep-0445/#performances

I was unable to measure an overhead on macro benchmarks (perf.py). The overhead 
on microbenchmarks was really hard to measure because it was so low that 
benchmarks were very unable.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26382] List object memory allocator

[Alecsandru Patrascu]

Changes by Alecsandru Patrascu :


--
nosy: +alecsandru.patrascu

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26391] Specialized sub-classes of Generic never call __init__

[Kai Wohlfahrt]

New submission from Kai Wohlfahrt:

A specialized sub-class of a generic type never calls __init__ when it is 
instantiated. See below for an example:

from typing import Generic, TypeVar

T = TypeVar('T')
class Foo(Generic[T]):
def __init__(self, value: T):
self.value = value

Bar = Foo[str]

foo = Foo('foo')
bar = Bar('bar')

print(type(foo), end=' ')
print(foo.value)

print(type(bar), end=' ')
print(bar.value) # AttributeError

I would expect Foo[str], Foo[int], etc to be equivalent to Foo at run-time. If 
this is not the case it might deserve an explicit mention in the docs. At the 
moment, behaviour is confusing because an instance of Foo is returned that does 
not have any of its attributes set.

--
messages: 260519
nosy: Kai Wohlfahrt
priority: normal
severity: normal
status: open
title: Specialized sub-classes of Generic never call __init__
type: behavior
versions: Python 3.5

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23430] socketserver.BaseServer.handle_error() should not catch exiting exceptions

[Berker Peksag]

Changes by Berker Peksag :


--
stage: patch review -> commit review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26366] Use “.. versionadded” over “.. versionchanged” where appropriate

[Tony R.]

Tony R. added the comment:

> Here are the original descriptions of the old LaTeX version.

Holy crap!  You all used to use LaTeX?!  :D  

(I know--LaTeX is still going strong in academia.  I just had no idea it was 
ever part of Python’s documentation, except as an output format.)

> Adding a parameter is explicitly a "versionchanged" kind of change.
> 
> Since the Sphinx items are supposed to be equivalent, this has always been 
> the intention, even if the current devguide deviates.

Ah, okay.  

Well then, if this is the sort of place where the status quo is sacred, then 
there is nothing more to discuss.  

But if anyone reading this is open to the idea, please re-read my previous 
comment in this thread.  The quoted LaTeX docs are clear, but I still believe 
my “all changes = (deprecated-removed changes) + (added changes) + (other 
changes)” interpretation makes more sense than the LaTeX definition.  

I also think it is more helpful to the *reader*--which, I respectfully suggest, 
should be the basis for any documentation’s guidelines--by marking up changes 
according to this grouping.

It’s not my desire to be troublesome by making one more appeal.  I simply want 
to point out that just because somebody wrote the LaTeX definitions a long time 
ago doesn’t mean that we cannot rewrite them.  They were written by somebody 
just like us, after all.  

If it’s not obvious by now, I feel strongly about good semantic markup.  The 
purpose of semantic markup is to describe what something *is*. I just think 
that changes form a hierarchy, with a generic “change” as something of the base 
class, and “deprecated”, “removed”, and “added” as specializations.

If you’re reading this, and you feel similarly--speak up!  

What do you think?


Respectfully,

—Tony

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26366] Use “.. versionadded” over “.. versionchanged” where appropriate

[Fred L. Drake, Jr.]

Fred L. Drake, Jr. added the comment:

On Fri, Feb 19, 2016 at 10:02 AM, Tony R.  wrote:
> Holy crap!  You all used to use LaTeX?!  :D

Python's documentation has a long & colorful history.  :-)

> Well then, if this is the sort of place where the status quo is sacred, then
> there is nothing more to discuss.

Status quo is not sacred, but does have some value.  Changing how busy
people do things is non-trivial.

> But if anyone reading this is open to the idea, please re-read my previous
> comment in this thread.  The quoted LaTeX docs are clear, but I still
> believe my “all changes = (deprecated-removed changes) + (added
> changes) + (other changes)” interpretation makes more sense than the
> LaTeX definition.
>
> I also think it is more helpful to the *reader*--which, I respectfully 
> suggest,
> should be the basis for any documentation’s guidelines--by marking up
> changes according to this grouping.

I think we all agree that the documentation is for the reader.

> It’s not my desire to be troublesome by making one more appeal.
> I simply want to point out that just because somebody wrote the
> LaTeX definitions a long time ago doesn’t mean that we cannot
> rewrite them.  They were written by somebody just like us, after all.

As the person who wrote them, I don't consider them sacred or
unchangeable.

Having some rational basis for whatever we use is good, and it should
be clearly documented clearly.

> If it’s not obvious by now, I feel strongly about good semantic markup.

We're on the same page here.

> The purpose of semantic markup is to describe what something *is*.
> I just think that changes form a hierarchy, with a generic “change” as
> something of the base class, and “deprecated”, “removed”, and “added”
> as specializations.

Again, agreed.  That doesn't imply that the specializations encompass
all changes, though.  For some, 'versionchanged' is reasonable.

Part of the problem is getting the granularity right.  The initial intent was
that 'version*' were annotations for the enclosing object (function, class,
method, etc.).  If we want to have something more granular (parameter
added / deprecated / whatever), we should have distinct markup for that.

That could look something like:

.. parameteradded:: alternate 3.6
   Further explanation goes here.

It's helpful to think of these annotations as pronouns; the antecedent
needs to be clear before they can be interpreted correctly.  It sounds
like that needs to be clarified in the documentation, and possibly
provision added for a more fine-grained form of annotation.

  -Fred

--
nosy: +fdrake
title: Use “.. versionadded” over “.. versionchanged” where appropriate -> Use 
“.. versionadded” over “.. versionchanged” where appropriate

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26366] Use “.. versionadded” over “.. versionchanged” where appropriate

[Georg Brandl]

Georg Brandl added the comment:

> Well then, if this is the sort of place where the status quo is sacred,
> then there is nothing more to discuss.  

That wasn't my intention when quoting the old documenting guide, it was just
to show what the intent was (and still is), and that I didn't just invent it.
As Fred says, the status quo is not sacred, but we are usually pragmatic and
a nontrivial amount of weight is needed to change it.

> But if anyone reading this is open to the idea, please re-read my previous
> comment in this thread.  The quoted LaTeX docs are clear, but I still
> believe my “all changes = (deprecated-removed changes) + (added changes) +
> (other changes)” interpretation makes more sense than the LaTeX definition.

It's one interpretation, yes.  My interpretation (which coincides with the one
written back then by Fred) is that the versionchanged applies to the API item
in whose block it occurs.  And a function is not *added* by the addition of
a parameter, it is *changed* by that.  The parameter itself is not a marked-
up API item.  If the structure was like

.. function:: foo(a, b)
   .. parameter:: a
   .. parameter:: b

then adding a parameter c would definitely be marked up as

   .. parameter:: c
  .. versionadded: 3.x

Anyway.  You think your interpretation is better, others including myself
prefer the current one.  This is exactly the kind of argument where the 
status quo wins because the churn necessary to change is not justified.

> It’s not my desire to be troublesome by making one more appeal.  I simply
> want to point out that just because somebody wrote the LaTeX definitions a
> long time ago doesn’t mean that we cannot rewrite them.  They were written
> by somebody just like us, after all.  

Again, you're mistaking the reason I quoted them.

> If it’s not obvious by now, I feel strongly about good semantic markup.
> The purpose of semantic markup is to describe what something *is*. I just
> think that changes form a hierarchy, with a generic “change” as something
> of the base class, and “deprecated”, “removed”, and “added” as 
> specializations.

That's a nice strawman -- we all feel semantic markup is important, and we
are talking about nothing but semantic markup here.  We're just discussing
the interpretation of one aspect of the semantics.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23061] Update pep8 to specify explicitly 'module level' imports at top of file

[Pas]

Changes by Pas :


--
nosy: +pas

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25668] Deadlock in logging caused by a possible race condition with "format"

[Oliver Ruiz Dorantes]

Oliver Ruiz Dorantes added the comment:

I am logging from a different thread than the thread which actually created the 
object. Though I am getting its reference in a very odd way

I can reproduce the following while is not a deadlock, I believe is related:

Traceback (most recent call last):
  File "/usr/lib/python2.7/logging/__init__.py", line 851, in emit
msg = self.format(record)
  File "/usr/lib/python2.7/logging/__init__.py", line 724, in format
return fmt.format(record)
  File "/usr/lib/python2.7/logging/__init__.py", line 464, in format
record.message = record.getMessage()
  File "/usr/lib/python2.7/logging/__init__.py", line 328, in getMessage
msg = msg % self.args
TypeError: not all arguments converted during string formatting

--
nosy: +Oliver Ruiz Dorantes

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26392] socketserver.BaseServer.close_server should stop serve_forever

[Aviv Palivoda]

New submission from Aviv Palivoda:

Currently if you call server_close you only close the socket. If we  called 
serve_forever and then call server_close without calling shutdown the 
serve_forever loop keep running. Before using the selectors module for doing 
the poll we would have had exception thrown from the select (The socket fd is 
-1) in serve_forever.
IMO you should be able to call server_close at any time and expect it to stop 
the serve_forever. Maybe even adding a block option to server_close that will 
wait on the server_forever if it's running (waiting for issue 12463 to resolve 
before doing this).
Added a patch that closes serve_forever if server_close is called.

--
components: Library (Lib)
files: socketserver_close_stop_serve_forever.patch
keywords: patch
messages: 260524
nosy: palaviv
priority: normal
severity: normal
status: open
title: socketserver.BaseServer.close_server should stop serve_forever
versions: Python 3.5, Python 3.6
Added file: 
http://bugs.python.org/file41971/socketserver_close_stop_serve_forever.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26366] Use “.. versionadded” over “.. versionchanged” where appropriate

[Tony R.]

Tony R. added the comment:

> Part of the problem is getting the granularity right.  The initial intent was
> that 'version*' were annotations for the enclosing object (function, class,
> method, etc.).  If we want to have something more granular (parameter
> added / deprecated / whatever), we should have distinct markup for that.
> 
> That could look something like:
> 
> .. parameteradded:: alternate 3.6
>Further explanation goes here.
> 
> It's helpful to think of these annotations as pronouns; the antecedent
> needs to be clear before they can be interpreted correctly.

Isn’t language fun?!?!  *insane smile* 8)

> It sounds
> like that needs to be clarified in the documentation, and possibly
> provision added for a more fine-grained form of annotation.

Okay.  I can participate in the discussion of that, if it would help...but 
adding a completely new annotation type is outside my current ability to 
contribute.  




> > Well then, if this is the sort of place where the status quo is sacred,
> > then there is nothing more to discuss.  
> 
> That wasn't my intention when quoting the old documenting guide, it was just
> to show what the intent was (and still is), and that I didn't just invent it.

Your intent was clear to me!  I did not mean to say that you -- or anyone -- 
just invented it.  

I only know that mature projects (like Python) tend to hold more strongly to 
the status quo, and that I was advocating a change that was probably going to 
be an uphill battle to convince others as worthwhile.

> That's a nice strawman -- we all feel semantic markup is important, and we
> are talking about nothing but semantic markup here.  We're just discussing
> the interpretation of one aspect of the semantics.

It was not my wish to set up a strawman.  (I have no formal training in logic, 
anyways; I’d probably screw it up if I deliberately tried!)  

The reason I was stressing semantic markup is because I anticipated resistance 
from the mindset of “Ugh, I don’t want to deal with this tedious crap!”  I  
wanted to emphasize semantic markup as something valuable -- worth making an 
effort for, even if it might appear tedious or trivial at first glance.  



That said, I think it’s time for me to bow out of this conversation.  I’ve 
never made a successful contribution to any part of Python, including the 
documentation.  There was some talk of updating the devguide or adding new 
annotations, so I hope that something good comes out of that!  But the issue 
patch is where my comfort level is right now, and it appears that it’s a no-go.

Thank you for your time, your consideration, and the discussion!

—Tony

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26366] Use “.. versionadded” over “.. versionchanged” where appropriate

[Fred L. Drake, Jr.]

Fred L. Drake, Jr. added the comment:

Another reason to value the status-quo in this case is that this isn't just
a matter for the Python documentation; it's about the recommended usage for
the markup, which is used by many other packages.

Questions that should be discussed include:

1. Should we clarify the documentation for the current annotations to
   the intended use is more consistently understood, or should we leave
   it as-is?

2. Are other distinct kinds of annotations (such as per-parameter notes)
   needed?

   If so, we'll need to consider specific reader / information-content
   needs and determine how they should be marked using new constructs.

   This is independent of implementation, which is likely straightforward.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26376] Tkinter root window won't close if packed.

[Sam Yeager]

Sam Yeager added the comment:

I've reverted to ActiveTcl 8.5.18. Issue persists.

Uploading screenshots before and after attempting to close root window.

--
Added file: http://bugs.python.org/file41972/1 Before closing root window.png

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26376] Tkinter root window won't close if packed.

[Sam Yeager]

Changes by Sam Yeager :


Added file: http://bugs.python.org/file41973/2 After closing root window.png

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21878] wsgi.simple_server's wsgi.input read/readline waits forever in certain circumstances

[tzickel]

tzickel added the comment:

Just encountered this issue as well.

It's not related to newlines, but to not supporting HTTP or persistent 
connections (the wsgi.input is the socket's I/O directly, and if the client 
serves a persistent connection, then the .read() will block forever).

A simple solution is to use a saner wsgi server (gevent works nicely).
Here is their implmentation of the socket I/O wrapper class (Input), and it's 
read/readlines functions:
https://github.com/gevent/gevent/blob/a65501a1270c1763e9de336a9c3cf52081223ff6/gevent/pywsgi.py#L303

--
nosy: +tzickel

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26377] Tkinter dialogs will not close if root window not packed.

[Sam Yeager]

Changes by Sam Yeager :


Added file: http://bugs.python.org/file41975/2 After closing window and box.png

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26377] Tkinter dialogs will not close if root window not packed.

[Sam Yeager]

Changes by Sam Yeager :


Added file: http://bugs.python.org/file41974/1 Before closing window and box.png

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26393] random.shuffled

[Aviv Palivoda]

New submission from Aviv Palivoda:

I am suggesting adding random.shuffled to the random module. This is very 
similar to the shuffle function just return a new shuffled list instead of in 
place shuffle. This is very similar to the sorted and list.sort.

As you can see in the patch the shuffled function just return random.sample(x, 
len(x)) as this is what i usually do when i want to get back a shuffled list.

--
components: Library (Lib)
files: random-shuffled.patch
keywords: patch
messages: 260529
nosy: mark.dickinson, palaviv, rhettinger
priority: normal
severity: normal
status: open
title: random.shuffled
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file41976/random-shuffled.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25668] Deadlock in logging caused by a possible race condition with "format"

[Vinay Sajip]

Vinay Sajip added the comment:

@Oliver Ruiz Dorantes I don't see how yuou reach that conclusion from what 
you're showing - it just looks like s mismatch bertween format string and 
arguments. If you can shrink it down to a small standalone script that 
demonstrates the problem, it would be helpful for diagnosis; the stack trace 
you provide isn't enough for this, as I have seen similar traces many a time 
due to mismatched format string and arguments.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5715] listen socket close in SocketServer.ForkingMixIn.process_request()

[Martin Panter]

Martin Panter added the comment:

Replying to Donghyun’s last message, I understand UDPServer is derived from the 
TCPServer, so it would inherit TCPServer.server_close(), and therefore would 
close the one and only UDP socket. I think you may have to add a new 
prepare_child() method, or add a special case somewhere for forked TCP (or 
stream) servers.

--
nosy: +martin.panter
stage: patch review -> needs patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26392] socketserver.BaseServer.close_server should stop serve_forever

[Martin Panter]

Martin Panter added the comment:

I thought the purpose of server_close() was to clean up resources after you 
have finished calling serve_forever() or handle_request(). Just like you call 
close() on a file after you have finished reading or writing it. If you try to 
read or write a closed file, that is a programmer error.

This proposal sounds like a new feature, but you are overloading or redefining 
the purpose of server_close().

>From the test case I presume you intend to use server_close() in a separate 
>thread from the thread running serve_forever(). But closing a file descriptor 
>while it is being used in another thread does not seem robust to me. It could 
>cause serve_forever() to raise EBADF. In the worst case, consider what happens 
>if an unrelated third thread makes the server’s file descriptor valid again by 
>opening a file.

What is your use case? If you want to use multithreading, why can’t you use the 
shutdown() method? For a single-threaded server, maybe see Issue 13749, and 
maybe Issue 23430 would help by allowing exceptions like SystemExit to stop the 
server.

--
nosy: +martin.panter
type:  -> enhancement

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1429] FD leak in SocketServer when request handler throws exception

[Martin Panter]

Martin Panter added the comment:

Jeff has tried many times over two years to produce the originally reported bug 
without success. By code inspection, I cannot see how a request handler 
exception could cause a leak. Therefore I am closing this as “works for me”.

Working backwards from all the spurious version changes (I wish people wouldn’t 
do that!), I figure that this was originally opened against Python 2.4 only. It 
is possible that the bug got fixed in the meantime.

For the question of coping with exceptions from handle_error(), the change 
proposed in Issue 25139 should cover that.

--
resolution:  -> works for me
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13354] tcpserver should document non-threaded long-living connections

[Martin Panter]

Martin Panter added the comment:

Bas: I think you need to provide more information. Are you talking about 
protocols like HTTP, where multiple high-level (HTTP-level) requests are made 
over a single low-level (socket-level) connection? Some example code might help.

Overriding shutdown_request() sounds like a bad idea. I think you eventually 
would want to truly shutdown the connection. Perhaps it is better to override 
process_request() and avoid it calling shutdown() until it is ready.

--
status: open -> pending

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26377] Tkinter dialogs will not close if root window not packed.

[Sam Yeager]

Changes by Sam Yeager :


--
type:  -> behavior

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26351] Occasionally check for Ctrl-C in long-running operations like sum

[Terry J. Reedy]

Terry J. Reedy added the comment:

Great idea.  In Windows, closing the window with [x] will kill the process, at 
the cost of loosing its contents.  In IDLE's Shell, Restart Shell will do the 
same without killing IDLE, but it is easy to not know of or forget that option 
in a moment of panic.

--
nosy: +terry.reedy

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26351] Occasionally check for Ctrl-C in long-running operations like sum

[STINNER Victor]

STINNER Victor added the comment:

> Great idea.  In Windows, closing the window with [x] will kill the process, 
> at the cost of loosing its contents.

Note: after a few years, I heard that Windows supports something like SIGKILL: 
CTRL+Pause kills the current process ;-) You loose the process, but you don't 
have to close the terminal, confirm and reopen a new terminal, go back to your 
working directly, etc.

Note 2: Even more off-topic, type .~ in an SSH session to kill it, again 
it avoids to reopen a terminal window ;-)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26358] mmap.mmap.__iter__ is broken (yields bytes instead of ints)

[Terry J. Reedy]

Changes by Terry J. Reedy :


--
nosy: +twouters
versions:  -Python 3.2, Python 3.3, Python 3.4

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22468] Tarfile using fstat on GZip file object

[Roundup Robot]

Roundup Robot added the comment:

New changeset 94a94deaf06a by Martin Panter in branch '3.5':
Issues #22468, #21996, #22208: Clarify gettarinfo() and TarInfo usage
https://hg.python.org/cpython/rev/94a94deaf06a

New changeset e66c476b25ec by Martin Panter in branch 'default':
Issue #22468: Merge gettarinfo() doc from 3.5
https://hg.python.org/cpython/rev/e66c476b25ec

New changeset 9d5217aaea13 by Martin Panter in branch '2.7':
Issues #22468, #21996, #22208: Clarify gettarinfo() and TarInfo usage
https://hg.python.org/cpython/rev/9d5217aaea13

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26367] importlib.__import__ does not fail for invalid relative import

[Terry J. Reedy]

Terry J. Reedy added the comment:

Manuel, welcome to the tracker and thank you for submitting patches.  I agree 
that 5 lines is past the threshhold.  Your profile has been CLA-updated, so we 
are good to go.

--
nosy: +terry.reedy

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21996] gettarinfo method does not handle files without text string names

[Roundup Robot]

Roundup Robot added the comment:

New changeset 94a94deaf06a by Martin Panter in branch '3.5':
Issues #22468, #21996, #22208: Clarify gettarinfo() and TarInfo usage
https://hg.python.org/cpython/rev/94a94deaf06a

New changeset 9d5217aaea13 by Martin Panter in branch '2.7':
Issues #22468, #21996, #22208: Clarify gettarinfo() and TarInfo usage
https://hg.python.org/cpython/rev/9d5217aaea13

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22208] tarfile can't add in memory files (reopened)

[Roundup Robot]

Roundup Robot added the comment:

New changeset 94a94deaf06a by Martin Panter in branch '3.5':
Issues #22468, #21996, #22208: Clarify gettarinfo() and TarInfo usage
https://hg.python.org/cpython/rev/94a94deaf06a

New changeset 9d5217aaea13 by Martin Panter in branch '2.7':
Issues #22468, #21996, #22208: Clarify gettarinfo() and TarInfo usage
https://hg.python.org/cpython/rev/9d5217aaea13

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22468] Tarfile using fstat on GZip file object

[Martin Panter]

Martin Panter added the comment:

Hoping my clarification in the documentation is enough to call this fixed

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 2.7, Python 3.6 -Python 3.4

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21996] gettarinfo method does not handle files without text string names

[Martin Panter]

Changes by Martin Panter :


--
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed
versions: +Python 3.6 -Python 3.4

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26369] doc for unicode.decode and str.encode is unnecessarily confusing

[Terry J. Reedy]

Terry J. Reedy added the comment:

The intended use for str.encode is for same-type transcoding, like this:

I was unaware of the seemingly useless behavior you quote.

>>> 'abc'.encode('base64')
'YWJj\n'
>>> 'YWJj\n'.decode('base64')
'abc'

Here is a similar use for unicode.decode.

>>> u'abc'.encode('base64')
'YWJj\n'
>>> u'YWJj\n'.decode('base64')
'abc'

Any doc change should make the intended use clear if not already.

(Note that the above give lookup errors in 3.x
>>> 'abc'.encode('base64')
...
LookupError: 'base64' is not a text encoding; use codecs.encode() to handle 
arbitrary codecs)

--
nosy: +terry.reedy

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26375] Python 2.7.10 and 3.4.4 hang on imaplib.IMAP4_SSL()

[Terry J. Reedy]

Terry J. Reedy added the comment:

where was the 'RC4 cipher' removed from.  Do you know the issue or commit that 
did so?

--
keywords: +3.4regression
nosy: +terry.reedy
stage:  -> test needed
title: New versions of Python hangs on imaplib.IMAP4_SSL() -> Python 2.7.10 and 
3.4.4 hang on imaplib.IMAP4_SSL()
versions: +Python 3.5, Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26376] Tkinter root window won't close if packed.

[Terry J. Reedy]

Terry J. Reedy added the comment:

No problem on Windows either, where the minimum window width is wide enough to 
acommodate all 3 frame buttons (-  []  X).

Please run your test.py directly, either in the terminal or however else one 
does so on OSX, without IDLE, to make absolutely sure that IDLE has no effect 
on the behavior.  (It really ought not to.)

--
components:  -IDLE
nosy: +terry.reedy

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26377] Tkinter dialogs will not close if root window not packed.

[Terry J. Reedy]

Terry J. Reedy added the comment:

Try adding 'parent=rootWin' to the messagebox call.  Otherwise, I expect that 
this is, as far as cause, a duplicate of #2637, in which case my comment 
https://bugs.python.org/issue26376#msg260544 applies.

--
components:  -IDLE
nosy: +terry.reedy

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26379] zlib decompress as_bytearray flag

[Terry J. Reedy]

Changes by Terry J. Reedy :


--
nosy: +nadeem.vawda, twouters

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13354] tcpserver should document non-threaded long-living connections

[Bas Wijnen]

Bas Wijnen added the comment:

For example, I have some programs which are HTTP servers that implement 
WebSockets.  For regular web page requests, it is acceptable if the connection 
is closed after the page is sent.  But for a WebSocket it isn't: the whole 
point of that protocol is to allow the server to send unsolicited messages to 
the browser.  If the connection is closed, it cannot do that.  The 
documentation currently suggests that the only way to avoid handle() closing 
the connection is to not return.  That means that the only way to do other 
things is by using multi-processing or (shiver) multi-threading.

My suggestion is to add a short explanation about how connections can be kept 
open after handle() returns, so that a single threaded event loop can be used.  
Of course the socket must then be manually closed when the program is done with 
it.

If I understand you correctly, overriding process_request would allow handle() 
to return without closing the socket.  That does sound better than overriding 
shutdown_request.

In the current documentation (same link as before, now for version 3.5.1), 
there is no mention at all about close() or shutdown() of the accepted sockets. 
 The only information on the subject is that if you want asynchronous handling 
of data, you must start a new thread or process.  This is not true, and in many 
cases it is not what I would recommend.  I think event loops are much easier to 
maintain and debug than multi-process applications, and infinitely easier than 
multi-threading applications.  I don't mind that other people disagree, and I'm 
not suggesting that those ways of handling should be removed (multi-process has 
its place, and I can't convince everyone that multi-threading is evil).  What 
I'm saying is that the ability to use an event loop to handle asynchronous data 
with this class deserves to be mentioned as well.

Obviously, it does then need to have the explanation about what to override to 
make it work.  My suggestion is simply what I ended up with after seeing it 
fail and reading the code.  If what you describe is the recommended way, please 
say that instead.  My point is that the scenario should presented as an option, 
I don't have an opinion on what it should say.

--
status: pending -> open

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26380] Add an http method enum

[Terry J. Reedy]

Terry J. Reedy added the comment:

If I were deciding, I would be inclined to reject this.  Part of the 
understanding when enums were added was that they would not automatically be 
used in the stdlib anywhere there could be used.

To answer 'why not', there is an obvious gain to naming arbitrary numerical 
code, as with HTTPStatus.xyz.  I do not see any gain from replacing 'GET'*  
with HTTPMethod.GET.  Just more work to write and read.

*Does http require uppercase for the methods?

To answer 'best practice',  I disagree with the premise that 'hardcoding' such 
short meaningful names is bad.  I think that this is a mis-application of a 
sometimes valid principle.

If people who do like such replacements are changing spellings, other than to 
lower case the words (enum value do not have to be uppercase), in the process, 
shame on them. Otherwise, typing HTTPMethod.OPTIONS is harde to type correctly, 
not easier, than 'OPTIONS'.  If you posted evidence as to your claim, I might 
be more favorably inclined.  On the other hand, if everyone used the quoted 
strings, 'GET', etc, there would be no problem with inconsistency.

My personal experience with turning constant strings into constant names is 
with tkinter, which has about 50 assignments like "E = 'e'", "RAISED = 
'raised'", and so on.  I consider them more a nuisance than a help.  CAPS are 
harder to type than letters, and they give TOO MUCH EMPHASIS to rather minor 
configuration issues.  If one does 'import tkinter' or 'import tkinter as tk' 
instead of 'from tkinter import *', then "relief=tk.RAISED" is definitely 
harder to write as "relieve='raised'", and to me uglier.

To me, your later throw-in comment about static analyzers might be the most 
persuasive point you made

--
nosy: +terry.reedy

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26382] List object memory allocator

[Terry J. Reedy]

Terry J. Reedy added the comment:

My impression is that we do not do such performance enhancements to 2.7 for the 
same reason we would not do them to current 3.x -- the risk of breakage.  Have 
I misunderstood?

--
nosy: +terry.reedy

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26385] the call of tempfile.NamedTemporaryFile fails and leaves a file on the disk

[Terry J. Reedy]

Terry J. Reedy added the comment:

`except:` is equivalent to `except BaseException:`.  When I introduced the 
former into idlelib, a couple of years ago, I was told to do the latter in a 
follow-up patch, so that there would be no doubt as to the intent.  The same 
should be done here.

--
nosy: +terry.reedy

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26382] List object memory allocator

[STINNER Victor]

STINNER Victor added the comment:

Terry J. Reedy added the comment:
> My impression is that we do not do such performance enhancements to 2.7 for 
> the same reason we would not do them to current 3.x -- the risk of breakage.  
> Have I misunderstood?

Breakage of what? The change looks very safe.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26385] the call of tempfile.NamedTemporaryFile fails and leaves a file on the disk

[STINNER Victor]

STINNER Victor added the comment:

I prefer "except:" over "except BaseException:". What is the benefit
of passing explicitly BaseException?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26380] Add an http method enum

[Martin Panter]

Martin Panter added the comment:

The RFC for HTTP says the method is case-sensitive, although I have seen one 
person use lowercase (probably by accident). So “over the wire” it has to be 
uppercase b"GET".

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26386] tkinter - Treeview - .selection_add and selection_toggle

[Terry J. Reedy]

Terry J. Reedy added the comment:

The 3.5 version of 2015 Dec 6 is 3.5.1. A traceback is not a crash for the 
purpose of this tracker.

It is generally a good idea to mention OS, OS version, and Tk Version. (IDLE 
displays TkVersion in Help => About IDLE.)  However, on Win 10 (8.6.4), I was 
able to reproduce with all four of the .selection_xyz(items) methods, which are 
all specializations of the .selection(op, items) methods.

import tkinter as tk
from tkinter import ttk
root = tk.Tk()
tree = ttk.Treeview(root)
tree.pack()
tree.insert('', 1, iid='a b', text='id with space')
for item in tree.get_children():
print(item)
#tree.selection_add(item)  # fail
#tree.selection_toggle(item)  # fail
#tree.selection_set(item)  # fail
#tree.selection_remove(item)  # fail
tree.selection('add', item)  # fail

getting

a b
Traceback (most recent call last):
  File "F:\Python\mypy\tem.py", line 10, in 
tree.selection_toggle(item)
  File "C:\Programs\Python35\lib\tkinter\ttk.py", line 1415, in selection_toggle
self.selection("toggle", items)
  File "C:\Programs\Python35\lib\tkinter\ttk.py", line 1395, in selection
return self.tk.call(self._w, "selection", selop, items)
_tkinter.TclError: Item a not found

tkinter 


These are the only Treeview methods in which a single argument can be multiple 
items.  The doc string and doc do not define the form of 'items'.  The 
unofficial but generally helpful doc, 
http://infohost.nmt.edu/tcc/help/pubs/tkinter/web/ttk-Treeview.html says "The 
argument may be either a single iid or a sequence of iids."  I would expect 
sequence mean a tuple of strings, not space-separated fields in a string (a tcl 
sequence).

The .delete and .detach methods have signature '*items', meaning that each item 
is passed as a separate argument.  The methods them pass the tuple of strings 
to tk.  This should have been the signature of the selection methods.

Putting a single string in a tuple solves the problem, as in.

tree.selection('add', (item,))

My suggested fix is to add a statement to .selection

def selection(self, selop=None, items=None):
"""If selop is not specified, returns selected items."""
if isinstance(items, str):  # new
items = (items,)
return self.tk.call(self._w, "selection", selop, items)

--
nosy: +serhiy.storchaka, terry.reedy
type: crash -> behavior

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26386] tkinter - Treeview - .selection_add and selection_toggle

[Terry J. Reedy]

Changes by Terry J. Reedy :


--
stage:  -> test needed
versions: +Python 2.7, Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26389] Expand traceback module API to accept just an exception as an argument

[Terry J. Reedy]

Terry J. Reedy added the comment:

You title and post don't seem to match.  The title says to expand the API and 
the post says there is no reason to expand the API.  Did you mean 'good 
reason'?  Also, I think you meant 'grab the traceback' (from the exception) 
rather than 'grab the exception'.

How would you get from here to there and change required etype, value, tb to 
just required value, without breaking old code?

--
nosy: +terry.reedy

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26385] the call of tempfile.NamedTemporaryFile fails and leaves a file on the disk

[Martin Panter]

Martin Panter added the comment:

Eryk Sun: The patch proposes to add an unlink() call after the file has been 
closed:

except Exception:
_os.close(fd)  # This automatically deletes the file right?
_os.unlink(name)  # Won’t this raise FileNotFoundError?
raise

By your explanation, it sounds like it would be better to call unlink() before 
close().

Terry & Victor: Writing the explicit “except BaseException:” makes it clear you 
weren’t being lazy in figuring out what exceptions you want to catch. But in 
this case the “raise” at the end of the the exception handler make it clear 
enough for me. I would be happy with either option.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26351] Occasionally check for Ctrl-C in long-running operations like sum

[Terry J. Reedy]

Terry J. Reedy added the comment:

I verified that ^Break(pause) works.  It even causes ^C to be printed.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26385] the call of tempfile.NamedTemporaryFile fails and leaves a file on the disk

[Terry J. Reedy]

Terry J. Reedy added the comment:

It makes it clearer that you know that it will 'everything' and intend to catch 
do so and that you did not casually toss in 'except:', as used to be the habit 
of many.  There are over 20 bare excepts in idlelib and I suspect many or most 
are unintentionally over-broad.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13354] tcpserver should document non-threaded long-living connections

[Martin Panter]

Martin Panter added the comment:

Thanks for the fast response!

There is a paragraph right at the end of 
 
that mentions this technique: “. . . maintain an explicit table of partially 
finished requests . . .”. Perhaps that is the suggestion that you couldn’t find 
before.

I once wrote an RTSP proxy that uses a related technique. It still handles each 
high-level RSTP request or RTP packet synchronously, but uses the “selectors” 
module to switch between the various connections and listening sockets after 
each high-level request had been handled. Code at 
.

Do you want to propose some specific additions or a patch to the documentation?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26389] Expand traceback module API to accept just an exception as an argument

[Martin Panter]

Martin Panter added the comment:

There is precedent with Python 2’s “raise” statement for accepting an exception 
instance for the first parameter (where an exception class would otherwise be 
passed). Also, generator.throw() supports this; see Issue 14911 for clarifying 
its documentation.

I would support changing the following signatures so that the first parameter 
could hold the value, not just the type:

print_exception(etype, value=None, tb=None, limit=None, ...)
format_exception_only(etype, value=None)
format_exception(etype, value=None, tb=None, limit=None, ...)
TracebackException(exc_type, exc_value=None, exc_traceback=None, *, ...)

--
nosy: +martin.panter
type:  -> enhancement

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13354] tcpserver should document non-threaded long-living connections

[Mark Lawrence]

Changes by Mark Lawrence :


--
nosy:  -BreamoreBoy

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4928] Problem with tempfile.NamedTemporaryFile

[Martin Panter]

Martin Panter added the comment:

I am surprised at the report that Red Hat Linux automatically removed the file. 
What system calls are involved? On my Arch Linux setup with current 3.6 code it 
leaves the file behind (same as the Solaris report).

However the the Windows version does automatically deleting the file once all 
file handles are closed:

# Setting O_TEMPORARY in the flags causes the OS to delete
# the file when it is closed.  This is only supported by Windows.

Perhaps this behaviour should be documented.

--
nosy: +martin.panter

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26261] NamedTemporaryFile documentation is vague about the `name` attribute

[Martin Panter]

Martin Panter added the comment:

Here is my proposed patch.

--
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file41977/tempfile-name.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com