[issue10319] SocketServer.TCPServer truncates responses on close (in some situations)

[jrodman2]

New submission from jrodman2 :

Behavior exists in at least Python 2.5 through 3.1.

The issue regards the socketserver's handling of the tcp sockets it works with. 
 On object reaping, the sockets are properly closed (in some versions 
explicitly, in others implicitly).  However, closing a socket with unread data 
will in some operating systems prevent sent data from being sent.  Notably this 
occurs on Linux and Windows (I tested on Debian testing x86_64 and Windows 
Vista x86).

Extensive tcpdump sessions and a lot of head scratching finally clarified the 
issue.  The OS would send an RST packet after just the first bit of data handed 
over to the socket implementation, in typical cases meaning hte first line of 
text python is writing would be sent to the client, but no more, causing 
invalid HTTP replies.

Here is a change to force the socket to be drained on close.  It is of no 
matter that more data may arrive on the socket post-drain, because the socket 
implementation in the operating system should be happy to send off what was 
already queued by the python program at this point.

Testing bears this out, across many platforms here.

Here is one way to accomplish this in python 2.x, in 3.x the equivalent file is 
socketserver.py, but has the same issue.  It lacks the explicit request.close() 
call, bgut this seems a matter of aesthetics.

Note that the use of select.select() is documented by Linux to be unsafe for 
this purpose in some circumstances, and may be on other platforms as well.

I sort of would rather have sockets have a socket.drain() function which is 
known to be safe and correct for this type of socket programming issue.  If 
that would be more appropriate, please suggest.

select(2)
   Under  Linux, select() may report a socket file descriptor as "ready for 
reading", while nevertheless a subsequent
   read blocks.  This could for example happen when data has arrived but 
upon examination has wrong checksum  and  is
   discarded.   There may be other circumstances in which a file descriptor 
is spuriously reported as ready.  Thus it
   may be safer to use O_NONBLOCK on sockets that should not block.

--- SocketServer.py.orig2010-11-04 21:36:23.0 -0700
+++ SocketServer.py 2010-11-04 21:38:19.0 -0700
@@ -445,6 +445,13 @@
 
 def close_request(self, request):
 """Called to clean up an individual request."""
+# drain socket
+request.setblocking(0)
+try:
+while True:
+request.recv(4096)
+except socket.error, e:
+pass
 request.close()

--
messages: 120469
nosy: jrodman2
priority: normal
severity: normal
status: open
title: SocketServer.TCPServer truncates responses on close (in some situations)
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1

___
Python tracker 

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

[issue10293] PyMemoryView object has obsolete members

[Kristján Valur Jónsson]

Kristján Valur Jónsson  added the comment:

Ah, the SHADOW member...
Weird.
Anyway, I have been hacking around in the memory view.  One thing that it does, 
and makes me uncomfortable since I think it is breaking the new buffer 
protocol, is to 
a) PyObject_GetBuffer()
b) Modify the resulting local Py_buffer
c) releaseing that modified Py_buffer when it calls PyBuffer_Release()

I don't think one can do that, strictly speaking.  You don't know what the 
buffer_releasebuffer() slot actually does, it might use the Py_buffer's "buf" 
member to release internal data, so I don't think it is permissable to mess 
with it.

I was hacking away at the MemoryView to make it behave differently, perhaps 
more like the SHADOW buffer concept:  When you call buffer_getbuffer on a 
memoryview, it returns a new Py_buffer that reflects its own view of the 
underlying object.  In other words, it doesn't call PyObject_GetBuffer again on 
the underlying object  A memoryview object should, IMHO, only perform that call 
once on the underlying object, and then serve its own view to its clients.

Slicing memoryview objects should also be done differently.  Rather than 
calling PyObject_GetBuffer() on the underlying object, it should rather refer 
to the origina MemoryView object, and create a local modification of that view.

The only problem with this approact that I have found (having run the 
testsuite) is that the buffer_getbuffer slot now has to do more work, since it 
cannot simply call PyObject_GetBuffer() on some underlying object.  It must now 
interpret flags and other things

--

___
Python tracker 

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

[issue10318] "make altinstall" installs many files with incorrect shebangs

[Allan McRae]

New submission from Allan McRae :

The following files are incorrectly installed with a "#!/usr/bin/env python" 
shebang when using "make altinstall":

usr/lib/python2.7/base64.py
usr/lib/python2.7/bsddb/dbshelve.py
usr/lib/python2.7/bsddb/test/test_dbtables.py
usr/lib/python2.7/cgi.py
usr/lib/python2.7/cgi.py
usr/lib/python2.7/Cookie.py
usr/lib/python2.7/cProfile.py
usr/lib/python2.7/difflib.py
usr/lib/python2.7/distutils/tests/test_build_scripts.py
usr/lib/python2.7/distutils/tests/test_install_scripts.py
usr/lib/python2.7/distutils/unixccompiler.py
usr/lib/python2.7/encodings/rot_13.py
usr/lib/python2.7/idlelib/PyShell.py
usr/lib/python2.7/keyword.py
usr/lib/python2.7/lib2to3/pgen2/token.py
usr/lib/python2.7/lib2to3/tests/data/different_encoding.py
usr/lib/python2.7/lib2to3/tests/pytree_idempotency.py
usr/lib/python2.7/mailbox.py
usr/lib/python2.7/mimify.py
usr/lib/python2.7/pdb.py
usr/lib/python2.7/platform.py
usr/lib/python2.7/profile.py
usr/lib/python2.7/pydoc.py
usr/lib/python2.7/quopri.py
usr/lib/python2.7/smtpd.py
usr/lib/python2.7/smtplib.py
usr/lib/python2.7/symbol.py
usr/lib/python2.7/tabnanny.py
usr/lib/python2.7/tarfile.py
usr/lib/python2.7/test/curses_tests.py
usr/lib/python2.7/test/pystone.py
usr/lib/python2.7/test/regrtest.py
usr/lib/python2.7/test/re_tests.py
usr/lib/python2.7/test/test_al.py
usr/lib/python2.7/test/test_anydbm.py
usr/lib/python2.7/test/test_array.py
usr/lib/python2.7/test/test_binhex.py
usr/lib/python2.7/test/test_bsddb.py
usr/lib/python2.7/test/test_bz2.py
usr/lib/python2.7/test/test_cd.py
usr/lib/python2.7/test/test_cl.py
usr/lib/python2.7/test/test_cmd.py
usr/lib/python2.7/test/test_codecencodings_cn.py
usr/lib/python2.7/test/test_codecencodings_hk.py
usr/lib/python2.7/test/test_codecencodings_jp.py
usr/lib/python2.7/test/test_codecencodings_kr.py
usr/lib/python2.7/test/test_codecencodings_tw.py
usr/lib/python2.7/test/test_codecmaps_cn.py
usr/lib/python2.7/test/test_codecmaps_hk.py
usr/lib/python2.7/test/test_codecmaps_jp.py
usr/lib/python2.7/test/test_codecmaps_kr.py
usr/lib/python2.7/test/test_codecmaps_tw.py
usr/lib/python2.7/test/test_dl.py
usr/lib/python2.7/test/test_dumbdbm.py
usr/lib/python2.7/test/test_eof.py
usr/lib/python2.7/test/test_errno.py
usr/lib/python2.7/test/test___future__.py
usr/lib/python2.7/test/test_gl.py
usr/lib/python2.7/test/test_gzip.py
usr/lib/python2.7/test/test_imageop.py
usr/lib/python2.7/test/test_imgfile.py
usr/lib/python2.7/test/test_logging.py
usr/lib/python2.7/test/test_marshal.py
usr/lib/python2.7/test/test_multibytecodec.py
usr/lib/python2.7/test/test_multibytecodec_support.py
usr/lib/python2.7/test/test_multiprocessing.py
usr/lib/python2.7/test/test_popen2.py
usr/lib/python2.7/test/test_popen.py
usr/lib/python2.7/test/test_random.py
usr/lib/python2.7/test/test_sets.py
usr/lib/python2.7/test/test_smtpnet.py
usr/lib/python2.7/test/test_socket.py
usr/lib/python2.7/test/test_tcl.py
usr/lib/python2.7/test/test_urllib2_localnet.py
usr/lib/python2.7/test/test_urllib2net.py
usr/lib/python2.7/test/test_urllibnet.py
usr/lib/python2.7/test/test_urlparse.py
usr/lib/python2.7/test/test_userstring.py
usr/lib/python2.7/test/test_whichdb.py
usr/lib/python2.7/test/test_with.py
usr/lib/python2.7/timeit.py
usr/lib/python2.7/token.py
usr/lib/python2.7/trace.py
usr/lib/python2.7/UserString.py
usr/lib/python2.7/uu.py
usr/lib/python2.7/webbrowser.py
usr/lib/python2.7/whichdb.py

These should point to /usr/bin/python2.7 instead.

--
components: Build
messages: 120468
nosy: allan
priority: normal
severity: normal
status: open
title: "make altinstall" installs many files with incorrect shebangs
versions: Python 2.7

___
Python tracker 

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

[issue10317] Add TurtleShell to turtle

[Alexander Belopolsky]

New submission from Alexander Belopolsky :

In r84640, Raymond added TurtleShell to the cmd module documentation as an 
example of a simple interpreter that can be written using that module.  I 
propose adding this code to turtle.py and make it runnable as python -m turtle.

--
components: Library (Lib)
keywords: easy
messages: 120466
nosy: belopolsky, rhettinger
priority: normal
severity: normal
stage: needs patch
status: open
title: Add TurtleShell to turtle
type: feature request
versions: Python 3.2

___
Python tracker 

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

[issue1702036] Make Turtle thread-safe so it does not crash

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

On a closer look at the first post, I see that there are two parts to the 
issue.  The first is indeed a duplicate of #6639, but the second is thread 
related.   I am attaching the OP's code in a script file for convenience.  
Running ninja.py under python3 produces 

RuntimeError: main thread is not in main loop

in every ninja thread.  This looks like tkinter limitation, but I think it is 
possible to work around it in turtle, so this is a valid feature request.

+1

--
status: pending -> open

___
Python tracker 

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

[issue1702036] Make Turtle thread-safe so it does not crash

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

I think threading is a red herring here.  The issue is really a duplicate of 
#6639.

--
nosy: +belopolsky
status: open -> pending
superseder:  -> turtle: _tkinter.TclError: invalid command name ".10170160"

___
Python tracker 

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

[issue1926] NNTPS support in nntplib

[Brian Curtin]

Changes by Brian Curtin :


--
nosy:  -brian.curtin

___
Python tracker 

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

[issue1926] NNTPS support in nntplib

[StevenJ]

StevenJ  added the comment:

Hi Julien,

>> I also don't understand why START_TLS and AUTHINFO need to change
>> how the module is interfaced to (separating log in/authentication, etc)

> Because once you have used AUTHINFO, STARTTLS is no longer a valid
> command in a session.

I understand this, but doesn't this mean the init function needs to change to 
something like:

init:
  if capability STARTTLS is advertised 
STARTLS stuff
reget capabilities because STARTTLS changed them probably

  Now handle AUTHINFO Stuff

Is there a case where a server advertises STARTTLS and one would not use it?  
If so then couldn't that just be handled with an option to the class inhibiting 
it?

This is one of the reasons why I proposed dividing the job across two features. 
1. Simple NNTPS which seems to be the most common secured NNTP in use at the 
moment and is easy to implement, and verify (either as an improvement to the 
NNTP class or as a new NNTP_SSL class). 
2. SASL AUTHINFO/STARTTLS Extension handling implementation and improvements.  

There are also other bugs with properly handling capabilities at start related 
to this, are there not? http://bugs.python.org/issue10287

--

___
Python tracker 

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

[issue9675] segfault: PyDict_SetItem: Assertion `value' failed.

[Jesús Cea Avión]

Changes by Jesús Cea Avión :


--
assignee:  -> jcea
resolution:  -> accepted
stage: patch review -> committed/rejected
status: open -> closed

___
Python tracker 

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

[issue9675] segfault: PyDict_SetItem: Assertion `value' failed.

[Jesús Cea Avión]

Jesús Cea Avión  added the comment:

Better bsddb error control. Please, review.

"""
[j...@babylon5 release27-maint]$ ./python
Python 2.7.0+ (release27-maint:86176:86178M, Nov  5 2010, 00:30:) 
[GCC 4.5.1] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> import bsddb
>>> exit()
"""

"""
[j...@babylon5 release27-maint]$ ./python -3
Python 2.7.0+ (release27-maint:86176:86178M, Nov  5 2010, 00:30:) 
[GCC 4.5.1] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> import bsddb
__main__:1: DeprecationWarning: in 3.x, the bsddb module has been removed; 
please use the pybsddb project instead
/home/python/svn-hg/release27-maint/Lib/bsddb/__init__.py:67: 
DeprecationWarning: CObject type is not supported in 3.x. Please use capsule 
objects instead.
  import _bsddb
"""

"""
[j...@babylon5 release27-maint]$ ./python -3 -Werror
Python 2.7.0+ (release27-maint:86176:86178M, Nov  5 2010, 00:30:)
[GCC 4.5.1] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> import warnings
>>> warnings.filterwarnings('ignore',
... "in 3.x, the bsddb module has been removed; please use the pybsddb project 
instead",
... category=DeprecationWarning)
>>> import bsddb
Exception DeprecationWarning: DeprecationWarning('CObject type is not supported 
in 3.x. Please use capsule objects instead.',) in  
ignored
>>> exit()
"""

Why is my "PyErr_Warn()" not being printed?

The code: (py_api is the CObject, will be NULL if an exception happened)

"""
if (py_api) {
PyDict_SetItemString(d, "api", py_api);
Py_DECREF(py_api);
} else { /* Something bad happened */
PyErr_WriteUnraisable(m);
PyErr_Warn(PyExc_RuntimeWarning,
"_bsddb/_pybsddb C API will be not available");
PyErr_Clear();
}
"""

Commit r86180.

Now I have to up-port this patch to the upcoming pybssddb 5.1.1.

--

___
Python tracker 

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

[issue10316] tkFileDialog.askopenfilenames scrambling multiple file selection

[Ned Deily]

Ned Deily  added the comment:

Works for me on a current Debian Linux system with a Debian Python 2.5.5 + 
Tcl/Tk 8.5 and with Python 2.6.1 + Tcl/Tk 8.5 on OS X 10.6 and with Python 2.7 
+ Tcl/Tk 8.4 on OS X 10.6. In all cases, the tkFileDialog.askopenfilenames 
returns a tuple of absolute file paths.  (BTW, only security issues are 
accepted for Python 2.5 at this time).

--
nosy: +ned.deily
resolution:  -> works for me
status: open -> closed

___
Python tracker 

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

[issue10279] test_gc failure on Windows x64

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Committed in r86179.

--
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

___
Python tracker 

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

[issue5412] extend configparser to support mapping access(__*item__)

[Łukasz Langa]

Łukasz Langa  added the comment:

Patch updated yet again:

 * optional .get() arguments are now keyword only. This is a bit
   backwards incompatible but:

   * protects users of mapping protocol access from invoking get() as if
 the last positional argument was the `fallback` value (it would be
 `raw` for (Safe)ConfigParsers and `vars` for RawConfigParsers)

   * so it will improve API compatibility between Raw and others

   * it will make the client code more readable, e.g.:

  anyParser.get('section', 'value', fallback=True)

  vs.

  rawParser.get('section', 'value', {}, True)
  safeParser.get('section', 'value', 0, {}, True)
  parserUsedWrong('section', 'value', True) # NOT a fallback! 

 * mapping protocol access is now quite thoroughly documented

 * renamed `default` arguments to get() to `fallback`. This is *not*
   backwards incompatible because those arguments were just recently
   added by me. I chose to rename them since because of DEFAULTSECT
   there already is a well-defined "default value" concept. Now the
   situation is much clearer, e.g. the docs can simply state: "default
   values have precedence over fallback values." and this is
   unambiguous.

As for some suggestions to just provide the section dictionaries
directly, this won't work because of interpolation and the terrific
DEFAULT section special case, e.g.  if a config file contains a DEFAULT
section and other sections lack a value, it will be returned instead on
get(). Also, DEFAULT values are used in interpolations. On top of that,
the provided section proxies ensure while setting that the database
holds only strings (which it should by design).

There is still one paragraph to be finished (Customizing Parser
Behaviour). This has to wait for tomorrow.

--
Added file: http://bugs.python.org/file19501/issue5412.diff

___
Python tracker 

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

[issue5412] extend configparser to support mapping access(__*item__)

[Łukasz Langa]

Changes by Łukasz Langa :


Removed file: http://bugs.python.org/file19010/issue5412.diff

___
Python tracker 

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

[issue10279] test_gc failure on Windows x64

[Brian Curtin]

Brian Curtin  added the comment:

Works for me.

--
assignee: brian.curtin -> pitrou

___
Python tracker 

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

[issue10302] Add class-functions to hash many small objects with hashlib

[Raymond Hettinger]

Raymond Hettinger  added the comment:

I concur with Overlord Antoine ;-)

The API of "hashfunc *files" looks like something that should be done at the 
command line in bash.   For the most part, I think users are better-off using 
normal Python loops so they can do something with the computed hashes as the 
files are read.

--
nosy: +rhettinger

___
Python tracker 

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

[issue6305] islice doesn't accept large stop values

[Terry J. Reedy]

Terry J. Reedy  added the comment:

In 3.1.2, range handles large numbers.
>>> list(range(10, 500, 100))
[10, 110, 210, 310, 410]
# those are all billions

This means that the 'equivalent' code in the doc will work.

--
nosy: +terry.reedy

___
Python tracker 

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

[issue10302] Add class-functions to hash many small objects with hashlib

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> Thanks for your comment; it is a very valid point to consider.
> However, as a vector-based implementation is roughly three to four
> times faster  than what the current API can provide by design (reduced
> overhead and GIL-relaxation not included), I may disagree with it.

I fear that this kind of optimization is a moving target. If some CPU
architecture gains hardware support for cryptographic hashes, OpenSSL
will support it and be much faster than Python's parallel version.

> I'm willing to make a proposal (read: patch) if you and the other
> overlords have enough confidence in this API-change and it has a
> chance to get submitted.

If the only advantage is some speedup on parallel hashing of
many-small-strings, I don't think a new API is warranted for such a
specialized use case.

--

___
Python tracker 

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

[issue7061] Improve 24.5. turtle doc

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

I am attaching a patch that adds a hack that allows to run turtle doctests 
using turtle.run_doctests() function.  Running this function has revealed 
numerous mistakes in doctests that are corrected in the patch.

The patch is against release27 branch because there are even more problems in 
py3k.

I don't think run_doctests hack belongs to turtle module.  I think it would be 
more appropriate to place it in test.test_turtle.

I have also not been able to figure out how to make global functions' doctests 
runnable.  The current patch disables them by mangling the >>> prompts in 
docstrings.

--
Added file: http://bugs.python.org/file19500/issue7061-docstrings-r27.diff

___
Python tracker 

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

[issue10279] test_gc failure on Windows x64

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Could you check the following patch works for you?

--
assignee:  -> brian.curtin
keywords: +patch
Added file: http://bugs.python.org/file19499/gcprint.patch

___
Python tracker 

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

[issue10279] test_gc failure on Windows x64

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Well, the issue seems to be simpler. This piece of code calls PyErr_WarnFormat, 
which doesn't use the platform's printf but Python's own format codes as 
documented in http://docs.python.org/dev/c-api/unicode.html#PyUnicode_FromFormat

--
nosy: +georg.brandl

___
Python tracker 

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

[issue9675] segfault: PyDict_SetItem: Assertion `value' failed.

[Jesús Cea Avión]

Jesús Cea Avión  added the comment:

Move the CObject use to a py3k warning instead of an error in r86178.

I still need to solve improve error management in bsddb. This bug remains open 
for a while.

--

___
Python tracker 

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

[issue10302] Add class-functions to hash many small objects with hashlib

[Lukas Lueg]

Lukas Lueg  added the comment:

Thanks for your comment; it is a very valid point to consider. However, as a 
vector-based implementation is roughly three to four times faster  than what 
the current API can provide by design (reduced overhead and GIL-relaxation not 
included), I may disagree with it.

I'm willing to make a proposal (read: patch) if you and the other overlords 
have enough confidence in this API-change and it has a chance to get submitted.

--

___
Python tracker 

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

[issue10279] test_gc failure on Windows x64

[Antoine Pitrou]

Antoine Pitrou  added the comment:

%Id is actually the expansion of PY_FORMAT_SIZE_T.

Include/pyport.h says:

/* PY_FORMAT_SIZE_T is a platform-specific modifier for use in a printf
 * format to convert an argument with the width of a size_t or Py_ssize_t.
 * C99 introduced "z" for this purpose, but not all platforms support that;
 * e.g., MS compilers use "I" instead.

Perhaps this is outdated or simply wrong?

--
nosy: +pitrou

___
Python tracker 

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

[issue9611] FileIO not 64-bit safe under Windows

[Martin v . Löwis]

Martin v. Löwis  added the comment:

Am 04.11.2010 22:28, schrieb Amaury Forgeot d'Arc:
> 
> Amaury Forgeot d'Arc  added the comment:
> 
>> Why do you think this would be somehow an example for a blocking stream
>> that does not write all data without raising an exception?
> Well, that's what "clamping" means, isn't it?

Ah, then I misunderstood. We certainly should discard any data.
I understood the proposal as rejecting write attempts for larger blocks
with an exception.

--

___
Python tracker 

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

[issue10283] New parameter for an NNTP newsgroup pattern in LIST ACTIVE

[Antoine Pitrou]

Antoine Pitrou  added the comment:

That's a fine addition, I've committed it in r86177.

--
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

___
Python tracker 

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

[issue9611] FileIO not 64-bit safe under Windows

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> On a second thought... is there another example where a *blocking*
> stream does not write all the data without raising an exception?

It can happen with pipes or sockets, if some buffer can only store part
of the data. Or any regular stream if a signal is received after part of
the data has been written.

--

___
Python tracker 

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

[issue9611] FileIO not 64-bit safe under Windows

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

> Why do you think this would be somehow an example for a blocking stream
> that does not write all data without raising an exception?
Well, that's what "clamping" means, isn't it?

--

___
Python tracker 

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

[issue9611] FileIO not 64-bit safe under Windows

[Martin v . Löwis]

Martin v. Löwis  added the comment:

> On a second thought... is there another example where a *blocking* stream 
> does not write all the data without raising an exception?

Why do you think this would be somehow an example for a blocking stream
that does not write all data without raising an exception?

--

___
Python tracker 

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

[issue9611] FileIO not 64-bit safe under Windows

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

On a second thought... is there another example where a *blocking* stream does 
not write all the data without raising an exception?

--

___
Python tracker 

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

[issue10313] Reassure user: test_os BytesWarning is OK

[R. David Murray]

R. David Murray  added the comment:

Ah, then this report is probably out of date.  I just realized that I ran my 
3.2a3 test incorrectly, so my report that I didn't see them there is invalid.

--

___
Python tracker 

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

[issue10302] Add class-functions to hash many small objects with hashlib

[Antoine Pitrou]

Antoine Pitrou  added the comment:

This sounds dangerously like a micro-optimization to me, and I'm not sure an 
additional API is ok for that.

--
nosy: +gregory.p.smith, pitrou

___
Python tracker 

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

[issue10243] Packaged Pythons

[Ned Deily]

Ned Deily  added the comment:

It's called Python because that's the way frameworks on OS X are generally 
structured: the shared library file has the same name as the framework.  The 
Apple developer docs have lots of information on frameworks.

Prior to 2.7 and the upcoming 3.2 releases, python.org installers (including 
for 3.1) have been 32-bit only.  Starting with 2.7 and the latest 3.2 alpha, 
there are two OS X installer downloads for each release, one 32-bit only (10.3 
and later) and the other 32-bit/64-bit for use on 10.6.  Also the 
Apple-supplied Python 2.6 in 10.6 is 32-bit/64-bit.  Otherwise, if you need 
64-bit for earlier releases, you will need to look elsewhere.  For example, 
some of the third-party open source distributors for OS X like MacPorts support 
64-bit builds of Python 2.6 and 3.1. Or you will need to build from scratch.

--

___
Python tracker 

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

[issue10313] Reassure user: test_os BytesWarning is OK

[Antoine Pitrou]

Antoine Pitrou  added the comment:

I guess you're not seeing them because Victor silenced them a couple of days 
ago in r85902.
Hallvard, if you update your py3k working copy, do these warnings disappear?

--
nosy: +pitrou

___
Python tracker 

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

[issue10316] tkFileDialog.askopenfilenames scrambling multiple file selection

[Peter Hall]

Changes by Peter Hall :


--
type:  -> behavior

___
Python tracker 

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

[issue10316] tkFileDialog.askopenfilenames scrambling multiple file selection

[Peter Hall]

New submission from Peter Hall :

I am running the following :

Linux Centos version 2.6.18
Python version 2.5
tk version 8.5
tcl version 8.5


I have a Python GUI program (importing Tkinter and tkFileDialog)
which prompts the user to select a (one to many) list of file names. 
The code is :

fileList = tkFileDialog.askopenfilenames(initialdir=self.startfiledir,
 title="Select Files for Processing",
 filetypes=self.ftypes, multiple=1)

where "startfiledir" and "ftypes" are defined elsewhere.
When this code is run a file selection box pops up
listing the chosen directory. Selecting just one file works fine.

To select multiple files the user highlights a selection
of the displayed files by dragging the cursor over them 
with "SHIFT left-mouse-button" pressed. 
It also lists ALL the selected files in the "File names:" selection field
at the bottom of the selection box. These are separated by spaces.
Clicking "Open" results in the selection box program trying to treat
the entire list as a single file name.
IE. It looks for a single file called "/home/mydir/file1 file2 file3 file4".
Since there is no such file an error pop-up box appears with a 
"File ... does not exist." message.

It appears that the file name list is not being parsed into indivdual file 
names.
I have tried combinations with "askopenfilename" instead of "askopenfilenames"
and including/omitting "multiple=1". 
I have also tried "multiple=bool(1)" and "multiple=xxx"
where "xxx=1" and "xxx=bool(1)".
None of these change the behaviour.

Is there a fault with my code ?
Is this a bug in "tkFileDialog.askopenfilenames" ?
Is there a workaround ?

Suggestions are welcome.

--
components: Tkinter
messages: 120438
nosy: pfhall
priority: normal
severity: normal
status: open
title: tkFileDialog.askopenfilenames scrambling multiple file selection
versions: Python 2.5

___
Python tracker 

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

[issue3699] test_bigaddrspace broken

[Antoine Pitrou]

Antoine Pitrou  added the comment:

I've made cosmetic changes and applied in r86175 (3.2) and r86176 (3.1). Thank 
you!

--
priority: high -> normal
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

___
Python tracker 

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

[issue10293] PyMemoryView object has obsolete members

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Done in r86174.

--
resolution:  -> fixed
status: open -> closed

___
Python tracker 

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

[issue10293] PyMemoryView object has obsolete members

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Well, there's this strange-looking thing in PyMemoryView_GetContiguous:

if (buffertype == PyBUF_SHADOW) {
/* return a shadowed memory-view object */
view->buf = dest;
mem->base = PyTuple_Pack(2, obj, bytes);

... but I don't really want to bother. Let's remove it.

--

___
Python tracker 

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

[issue10243] Packaged Pythons

[Martin v . Löwis]

Changes by Martin v. Löwis :


Removed file: http://bugs.python.org/file19498/unnamed

___
Python tracker 

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

[issue9611] FileIO not 64-bit safe under Windows

[Martin v . Löwis]

Martin v. Löwis  added the comment:

> If I'm not mistaken, WriteFile takes the length as a DWORD, which is
> still 32 bits under Win64.

Oops, ignore me, then... I agree that clamping is fine, assuming the
buffering layer takes that into account.

--

___
Python tracker 

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

[issue10243] Packaged Pythons

[Max Skaller]

Max Skaller  added the comment:

On Thu, Nov 4, 2010 at 5:19 PM, Ned Deily  wrote:

>
> Ned Deily  added the comment:
>
> For what it's worth, the python.org installers for Mac OS X do include a
> libpython shared library.  As of Python 2.7 (and 3.2), the installer
> includes a symlink to make it easier to find:
>
> $ cd /Library/Frameworks/Python.framework/Versions/2.7/lib
> $ ls -l libpython2.7.dylib
>

Ok.. so why is it called Python instead of Python.dylib?

/Library/Frameworks/Python.framework>file Python
Python: broken symbolic link to Versions/Current/Python

/Library/Frameworks/Python.framework/Versions/3.1>file Python
Python: Mach-O universal binary with 2 architectures
Python (for architecture ppc):  Mach-O dynamically linked shared library ppc
Python (for architecture i386): Mach-O dynamically linked shared library
i386

Hmm .. i386? Oh dear, I'm running Snow Leopard and I generate 64 bit code.

--
Added file: http://bugs.python.org/file19498/unnamed

___
Python tracker 

___On Thu, Nov 4, 2010 at 5:19 PM, Ned Deily 
rep...@bugs.python.org> 
wrote:

Ned Deily n...@acm.org> added the 
comment:

For what it's worth, the http://python.org"; 
target="_blank">python.org installers for Mac OS X do include a libpython 
shared library.  As of Python 2.7 (and 3.2), the installer includes a symlink 
to make it easier to find:


$ cd /Library/Frameworks/Python.framework/Versions/2.7/lib
$ ls -l libpython2.7.dylibOk.. so why is it called 
Python instead of 
Python.dylib?/Library/Frameworks/Python.framework>file 
PythonPython: broken symbolic link to Versions/Current/Python
/Library/Frameworks/Python.framework/Versions/3.1>file PythonPython: 
Mach-O universal binary with 2 architecturesPython (for architecture 
ppc):  Mach-O dynamically linked shared library ppcPython (for 
architecture i386): Mach-O dynamically linked shared library i386
Hmm .. i386? Oh dear, I'm running Snow Leopard and I generate 64 bit 
code.
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10315] smtplib.SMTP_SSL new in 2.6

[Henning Hraban Ramm]

New submission from Henning Hraban Ramm :

The docs tell us that smtplib.SMTP_SSL was only changed in 2.6, but it is new 
(i.e. it didn't exist in 2.5.x).

--
assignee: d...@python
components: Documentation
messages: 120432
nosy: d...@python, hraban
priority: normal
severity: normal
status: open
title: smtplib.SMTP_SSL new in 2.6
versions: Python 2.6

___
Python tracker 

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

[issue9611] FileIO not 64-bit safe under Windows

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> I propose a different solution: On Windows, instead of calling
> write(), we call WriteFile directly.

If I'm not mistaken, WriteFile takes the length as a DWORD, which is
still 32 bits under Win64.

--

___
Python tracker 

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

[issue9611] FileIO not 64-bit safe under Windows

[Martin v . Löwis]

Martin v. Löwis  added the comment:

I propose a different solution: On Windows, instead of calling write(), we call 
WriteFile directly. We try to faithfully follow the CRT implementation as much 
as possible, knowing that what we write to actually is a binary file (in 
particular, the file handle should get locked). We should perhaps make an 
exception for the standard handles (0,1,2), and fall back to call the CRT write 
unless we determine they are also in binary mode.

--

___
Python tracker 

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

[issue960325] "--require " option for configure/make (fail if building not possible)

[Terry J. Reedy]

Terry J. Reedy  added the comment:

I am closing this as some combination of wrong, inapplicable, out-of-date, and 
postponed.

1. In 3.1, ssl *is* documented as optional in the sense of dependent on an 
external library. "This module uses the OpenSSL library. It is available on all 
modern ... platforms, as long as OpenSSL is installed on that platform." For 
bz2, there is "This module provides a comprehensive interface for the bz2 
compression library." If the library is not there, then the module obviously 
cannot function. Tkinter depends on tcl/tT being installed. I believe some 
crypto modules also require possibly absent libraries. (The PSF/Löwis Windows 
installer nicely provides all.) 

If someone wants to review the docs for all such dependencies (and perhaps 
whatever build docs or help strings or comments there are) and propose doc 
revision, that could be a separate issue.

2. I think the current default build process is right for most users.

3. Except for the PSF provided binaries, building is ultimately out of our 
hands. Distributions do what they do. I presume individual persons and 
organizations can patch the default build files to be stricter if they wish. If 
they cannot, neither can we ;-).

4. This seems to have become pretty much a non-issue. The OP says he has no 
further concrete interest because "It's been a while since I had a computer 
without these libraries...". I am suspecting this is pretty much true for 
everyone who might otherwise care enough to provide a patch.

--
resolution:  -> out of date
stage:  -> needs patch
status: open -> closed

___
Python tracker 

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

[issue10243] Packaged Pythons

[Martin v . Löwis]

Changes by Martin v. Löwis :


--
resolution:  -> wont fix
status: open -> closed

___
Python tracker 

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

[issue1926] NNTPS support in nntplib

[Julien ÉLIE]

Julien ÉLIE  added the comment:

Hi Steven,

> I also don't understand why START_TLS and AUTHINFO need to change
> how the module is interfaced to (separating log in/authentication, etc)

Because once you have used AUTHINFO, STARTTLS is no longer a valid command in a 
session.
The authentication part is currently delt with in the init function (in 
nntplib) so it needs to be separated because one could want to first use 
STARTTLS, and then AUTHINFO. Currently, AUTHINFO is sent just after the initial 
log in; it is therefore better to have AUTHINFO handled in another function.

--

___
Python tracker 

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

[issue3699] test_bigaddrspace broken

[Sandro Tosi]

Sandro Tosi  added the comment:

The attached patch implements the same tests of byte for string objects.

--
assignee:  -> sandro.tosi
stage:  -> patch review
Added file: http://bugs.python.org/file19497/issue3699-py3k-v2.patch

___
Python tracker 

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

[issue10198] wave module writes corrupt wav file for zero-length writeframes

[Éric Araujo]

Éric Araujo  added the comment:

Perfect, sorry for doubting you ;)

--

___
Python tracker 

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

[issue10298] zipfile: incorrect comment size will prevent extracting

[Éric Araujo]

Changes by Éric Araujo :


--
keywords: +needs review
nosy: +alanmcintyre
stage:  -> patch review
versions: +Python 3.1, Python 3.2

___
Python tracker 

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

[issue10198] wave module writes corrupt wav file for zero-length writeframes

[Georg Brandl]

Georg Brandl  added the comment:

I always to the backports batched for these minor and docs fixes.

--

___
Python tracker 

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

[issue10313] Reassure user: test_os BytesWarning is OK

[R. David Murray]

R. David Murray  added the comment:

Running it with -E and seeing if that changes the behavior would also be useful.

--

___
Python tracker 

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

[issue10313] Reassure user: test_os BytesWarning is OK

[R. David Murray]

R. David Murray  added the comment:

Can you give the exact command line you are using to run it, and the OS and 
version, and perhaps a printenv?  I can't reproduce it in 3.1 or 3.2a3.

--

___
Python tracker 

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

[issue6081] str.format_map()

[Eric Smith]

Eric Smith  added the comment:

Committed to 3.2 in r86170.

--
stage: patch review -> committed/rejected
status: open -> closed

___
Python tracker 

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

[issue6081] str.format_map()

[Eric Smith]

Changes by Eric Smith :


--
title: str.format_from_mapping() -> str.format_map()

___
Python tracker 

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

[issue10198] wave module writes corrupt wav file for zero-length writeframes

[Éric Araujo]

Éric Araujo  added the comment:

I asked that because I didn’t see the fix backported :)

--

___
Python tracker 

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

[issue10314] Improve JSON encoding with sort_keys=True

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Ok, committed in r86169.

--
resolution:  -> fixed
status: open -> closed

___
Python tracker 

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

[issue10314] Improve JSON encoding with sort_keys=True

[Raymond Hettinger]

Raymond Hettinger  added the comment:

+1

--
nosy: +rhettinger

___
Python tracker 

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

[issue10314] Improve JSON encoding with sort_keys=True

[Antoine Pitrou]

New submission from Antoine Pitrou :

This patch makes sorting of keys when encoding a dict into JSON faster by not 
calling pure Python code.

--
components: Library (Lib)
files: jsonsort.patch
keywords: patch
messages: 120418
nosy: pitrou
priority: normal
severity: normal
status: open
title: Improve JSON encoding with sort_keys=True
type: performance
versions: Python 3.2
Added file: http://bugs.python.org/file19496/jsonsort.patch

___
Python tracker 

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

[issue10030] Patch for zip decryption speedup

[Shashank]

Changes by Shashank :


Added file: http://bugs.python.org/file19495/zipdecrypt.patch

___
Python tracker 

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

[issue10030] Patch for zip decryption speedup

[Shashank]

Changes by Shashank :


Removed file: http://bugs.python.org/file19494/zipdecrypt.patch

___
Python tracker 

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

[issue10030] Patch for zip decryption speedup

[Shashank]

Shashank  added the comment:

I had uploaded an incorrect patch. New corrected patch against trunk (on Mac OS 
uploaded).

--
Added file: http://bugs.python.org/file19494/zipdecrypt.patch

___
Python tracker 

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

[issue1602] windows console doesn't print utf8 (Py30a2)

[Christos Georgi ou]

Χρήστος Γεωργίου (Christos Georgiou)  added the 
comment:

http://blogs.msdn.com/b/michkap/archive/2008/03/18/8306597.aspx

If you want any kind of Unicode output in the console, the font must be an 
“official” MS console TTF (“official” as defined by the Windows version); I 
believe only Lucida Console and Consolas are the ones with all MS private 
settings turned on inside the font file.

--

___
Python tracker 

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

[issue1602] windows console doesn't print utf8 (Py30a2)

[STINNER Victor]

STINNER Victor  added the comment:

sys_write_stdtout.patch: Create sys.write_stdout() test function to call 
WriteConsoleOutputA() or WriteConsoleOutputW() depending on the input types 
(bytes or str).

--
keywords: +patch
Added file: http://bugs.python.org/file19493/sys_write_stdout.patch

___
Python tracker 

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

[issue1602] windows console doesn't print utf8 (Py30a2)

[STINNER Victor]

STINNER Victor  added the comment:

I wrote a small function to call WriteConsoleOutputA() and  
WriteConsoleOutputW() in Python to do some tests. It works correclty, except if 
I change the code page using chcp command. It looks like the problem is that 
the chcp command changes the console code page and the ANSI code page, but it 
should only changes the ANSI code page (and not the console code page).


chcp command


The chcp command changes the console code page, but in practice, the console 
still expects the OEM code page (eg. cp850 on my french setup). Example:

C:\...> python.exe -c "import sys; print(sys.stdout.encoding")
cp850
C:\...> chcp 65001
C:\...> python.exe
Fatal Python error: Py_Initialize: can't initialize sys standard streams
LookupError: unknown encoding: cp65001
C:\...> SET PYTHONIOENCODING=utf-8
C:\...> python.exe
>>> import sys
>>> sys.stdout.write("\xe9\n")
é
2
>>> sys.stdout.buffer.write("\xe9\n".encode("utf8"))
é
3
>>> sys.stdout.buffer.write("\xe9\n".encode("cp850"))
é
2

os.device_encoding(1) uses GetConsoleOutputCP() which gives 65001. It should 
maybe use GetOEMCP() instead? Or chcp command should be fixed?

Set the console code page looks to be a bad idea, because if I type "é" using 
my keyboard, a random character (eg. U+0002) is displayed instead...


WriteConsoleOutputA() and WriteConsoleOutputW()
===

Without touching the code page
--

If the character can be rendered by the current font (eg. U+00E9): 
WriteConsoleOutputA() and WriteConsoleOutputW() work correctly.

If the character cannot be rendered by the current font, but there is a 
replacment character (eg. U+0141 replaced by U+0041): WriteConsoleOutputA() 
cannot be used (U+0141 cannot be encoded to the code page), 
WriteConsoleOutputW() writes U+0141 but the console contains U+0041 (I checked 
using ReadConsoleOutputW()) and U+0041 is displayed. It works like the mbcs 
encoding, the behaviour looks correct.

If the character cannot be rendered by the current font, but there is a 
replacment character (eg. U+042D): WriteConsoleOutputA() cannot be used (U+042D 
cannot be encoded to the code page), WriteConsoleOutputW() writes U+042D but 
U+003d (?) is displayed instead. The behaviour looks correct.

chcp 65001
--

Using "chcp 65001" command (+ "set PYTHONIOENCODING=utf-8" to avoid the fatal 
error), it becomes worse: the result depends on the font...

Using raster font:
 - (ANSI) write "\xe9".encode("cp850") using WriteConsoleOutputA() displays 
U+00e9 (é), whereas the console output code page is cp65001 (I checked using 
GetConsoleOutputCP())
 - (ANSI) write "\xe9".encode("utf-8") using WriteConsoleOutputA() displays é 
(mojibake!)
 - (UNICODE) write "\xe9" using WriteConsoleOutputW() displays... a random 
character (U+0002, U+0008, U+0069, U+00b0, ...)

Using Lucida (TrueType font): 
 - (ANSI) write "\xe9".encode("cp850") using WriteConsoleOutputA() displays 
U+ !?
 - (UNICODE) write "\xe9" using WriteConsoleOutputW() works correctly (display 
U+00e9), even with "\u0141", it works correctly (display U+0141)

--

___
Python tracker 

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

[issue10311] Signal handlers must preserve errno

[Antoine Pitrou]

Antoine Pitrou  added the comment:

By the way, I'd like to clear out a potential misunderstanding: the function 
you are patching doesn't call Python signal handlers in itself (those 
registered using signal.signal()). It only schedules them for later execution. 
If you want to save errno around Python signal handlers themselves, 
PyErr_CheckSignals must be patched as well.

--

___
Python tracker 

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

[issue10311] Signal handlers must preserve errno

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> ["this" = only saving/restoring errno when needed]
> True, but practically nothing is officially safe to do in signal
> handlers, so it's good to avoid code which can be avoided there.
> If one can be bothered to, that is.

I think it is extremely unlikely that mutating errno in a signal handler is 
unsafe (after all, the library functions called from that handler can mutate 
errno too: that's the whole point of the patch IIUC). Adding some configure 
machinery for this seems unwarranted to me.

--

___
Python tracker 

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

[issue10273] Clean-up Unittest API

[Ezio Melotti]

Changes by Ezio Melotti :


--
nosy: +flox, gregory.p.smith

___
Python tracker 

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

[issue10313] Reassure user: test_os BytesWarning is OK

[Hallvard B Furuseth]

Hallvard B Furuseth  added the comment:

R. David Murray writes:
> I don't see any bytes warnings when I run test_os with -b or -bb on
> linux on py3k trunk.  (If there were such a warning and it was expected,
> the fix would be to capture the warning and ignore it.)
> 
> Under what circumstances do you see this warning?

Python 3.2a3, test_os with python -b.

--

___
Python tracker 

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

[issue10313] Reassure user: test_os BytesWarning is OK

[R. David Murray]

R. David Murray  added the comment:

I don't see any bytes warnings when I run test_os with -b or -bb on linux on 
py3k trunk.  (If there were such a warning and it was expected, the fix would 
be to capture the warning and ignore it.)

Under what circumstances do you see this warning?

--
nosy: +r.david.murray

___
Python tracker 

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

[issue10311] Signal handlers must preserve errno

[Hallvard B Furuseth]

Hallvard B Furuseth  added the comment:

Amaury Forgeot d'Arc writes:
> OTOH this is really a micro optimization.

["this" = only saving/restoring errno when needed]
True, but practically nothing is officially safe to do in signal
handlers, so it's good to avoid code which can be avoided there.
If one can be bothered to, that is.

--

___
Python tracker 

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

[issue960325] "--require " option for configure/make (fail if building not possible)

[Hallvard B Furuseth]

Hallvard B Furuseth  added the comment:

Once upon a time, Terry J. Reedy wrote:
> Hallvard, do you still consider this a live issue?

If this general behavior remains, yes.

It's been a while since I had a computer without these libraries to
test it on.  (Which is why I punted and then forgot to answer, sorry.)

--

___
Python tracker 

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

[issue10313] Reassure user: test_os BytesWarning is OK

[Hallvard B Furuseth]

New submission from Hallvard B Furuseth :

A test giving a strange warning can make a poor user nervous.  Here's
a minimal patch to calm his nerves.  It would be better to only give
the message if python -b (not -bb) is active, but I do not know how.

diff -prU2 Lib/test/test_os.py Lib/test/test_os.py
--- Lib/test/test_os.py
+++ Lib/test/test_os.py
@@ -443,4 +443,7 @@ class EnvironTests(mapping_tests.BasicTe
 test_env = {'PATH': os.pathsep.join(test_path)}
 
+if os.supports_bytes_environ:
+print("This test may give some 'BytesWarning's.", file=sys.stderr)
+
 saved_environ = os.environ
 try:

--
components: Tests
messages: 120407
nosy: hfuru
priority: normal
severity: normal
status: open
title: Reassure user: test_os BytesWarning is OK
type: feature request
versions: Python 3.2

___
Python tracker 

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

[issue10311] Signal handlers must preserve errno

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

> Nice.  Then I suggest a config macro for whether this is needed.
> Either a test for windows, or an autoconf thing in case some Unixes
> are equally sensible.  (Linux isn't, I checked.)

I'm quite sure that all Unixes invoke signal handlers in some existing thread. 
So even if errno is thread-local, it needs to be saved and restored.
OTOH this is really a micro optimization.

--

___
Python tracker 

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

[issue10311] Signal handlers must preserve errno

[Hallvard B Furuseth]

Hallvard B Furuseth  added the comment:

Amaury Forgeot d'Arc writes:
> This issue is not really relevant on Windows:
> - signals are actually run in a new thread specially created.
> - errno is a thread-local variable; its value is thus local to the
>   signal handler, same for WSAGetLastError().

Nice.  Then I suggest a config macro for whether this is needed.
Either a test for windows, or an autoconf thing in case some Unixes
are equally sensible.  (Linux isn't, I checked.)

--

___
Python tracker 

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

[issue9931] test_ttk_guionly hangs on XP5

[Hirokazu Yamamoto]

Changes by Hirokazu Yamamoto :


--
dependencies:  -test_issue_8959_b fails when run from a service

___
Python tracker 

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

[issue9931] test_ttk_guionly hangs on XP5

[Hirokazu Yamamoto]

Hirokazu Yamamoto  added the comment:

I've created the patch to fix this. (This patch comes from
#9055)

--
keywords: +patch
Added file: 
http://bugs.python.org/file19492/py3k_check_if_gui_is_really_available.patch

___
Python tracker 

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

[issue10311] Signal handlers must preserve errno

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

This issue is not really relevant on Windows:
- signals are actually run in a new thread specially created.
- errno is a thread-local variable; its value is thus local to the signal 
handler, same for WSAGetLastError().

--
nosy: +amaury.forgeotdarc

___
Python tracker 

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

[issue10306] Weakref callback exceptions should be turned into warnings.

[Julian]

Julian  added the comment:

Thank you, Antoine, you make a good point.

In my example, I am suppressing the warning, which, I agree isn't a good idea.

In my real life usage, I was getting an unexpected exception in a callback in 
code written by another person. I wanted not to suppress the warning, but to 
turn it into an exception to help trace the cause.

Thinking about this further, (if it was a warning, as I suggest,) I now believe 
that would raise that exception into the garbage collector which might have 
some unpredictable consequences. I have rejected my own Issue for this reason.

I maintain that the current solution isn't terribly helpful. Getting this 
output to stderr is neither helpful to me, in development (i.e. nothing in the 
error indicated it was related to the weakref functionality) nor my users in 
production (fortunately the problem was caught before then!)

However, I concede my proposal isn't the right solution.

Thank you again for your comment.

--
resolution:  -> rejected
status: open -> closed

___
Python tracker 

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

[issue10312] intcatcher() can deadlock

[Hallvard B Furuseth]

Changes by Hallvard B Furuseth :


--
versions: +Python 2.7, Python 3.1

___
Python tracker 

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

[issue10309] dlmalloc.c needs _GNU_SOURCE for mremap()

[Hallvard B Furuseth]

Changes by Hallvard B Furuseth :


--
versions: +Python 3.1

___
Python tracker 

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

[issue10308] Modules/getpath.c bugs

[Hallvard B Furuseth]

Changes by Hallvard B Furuseth :


--
versions: +Python 2.7, Python 3.1

___
Python tracker 

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

[issue10133] multiprocessing: conn_recv_string() broken error handling

[Hallvard B Furuseth]

Changes by Hallvard B Furuseth :


--
versions: +Python 2.7, Python 3.1

___
Python tracker 

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

[issue10231] SimpleHTTPRequestHandler directory bugs

[Hallvard B Furuseth]

Changes by Hallvard B Furuseth :


--
versions: +Python 2.7, Python 3.1

___
Python tracker 

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

[issue10306] Weakref callback exceptions should be turned into warnings.

[Antoine Pitrou]

Antoine Pitrou  added the comment:

The behaviour of weakrefs here mirrors what is already done for __del__ 
exceptions. Using warnings would mean that exceptions can get silenced 
implicitly (for example, if an exception happens twice at the same location) 
which is not very Pythonic: generally, if you want to silence an exception, you 
have to do it explicitly through try...except.

--
nosy: +pitrou

___
Python tracker 

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

[issue10310] signed:1 bitfields rarely make sense

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
nosy: +amaury.forgeotdarc
stage:  -> patch review
versions: +Python 2.7, Python 3.1

___
Python tracker 

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

[issue10309] dlmalloc.c needs _GNU_SOURCE for mremap()

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
assignee:  -> theller
nosy: +theller

___
Python tracker 

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

[issue10311] Signal handlers must preserve errno

[Hallvard B Furuseth]

Hallvard B Furuseth  added the comment:

Parser/intrcheck.c:intcatcher() should do the same.  Covered in Issue
10312.

Antoine Pitrou writes:
> This is a good idea IMO. It would be better if you minimized style
> changes, so that the patch is easier to review.

I'm afraid the un-rearranged code would be fairly ugly, so I cleaned
up first.  Single exit point.

> Also, is the while loop around write() necessary here?

Whoops, I'd forgotten I did that too, it was on my TODO list to
check if Python makes it unnecessary by making write restartable.
I don't remember if that's possible to ensure on all modern Posixes

--

___
Python tracker 

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

[issue10312] intcatcher() can deadlock

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
nosy: +benjamin.peterson

___
Python tracker 

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

[issue10312] intcatcher() can deadlock

[Hallvard B Furuseth]

New submission from Hallvard B Furuseth :

Parser/intrcheck.c:intcatcher() can do FILE* operations, which can
deadlock if the interrupt happens while a FILE* operation on the same
FILE holds a mutex for the FILE.  I've seen this happen elsewhere.

It'd rather be a pity to remove Py_Exit(), so I suggest
switch(interrupted++) gets a case 3 or 4: which does _exit(1),
and 'interrupted = 0;' is moved there from case 2.

Also 'interrupted' should be volatile sig_atomic_t, and
the function should save/restore errno as in Issue 10311.

BTW, you could use strlen(message) instead of sizeof(message)-1.

--
components: Interpreter Core
files: intrcheck.diff
keywords: patch
messages: 120399
nosy: hfuru
priority: normal
severity: normal
status: open
title: intcatcher() can deadlock
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file19491/intrcheck.diff

___
Python tracker 

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

[issue5391] mmap: read_byte/write_byte and object type

[Hirokazu Yamamoto]

Hirokazu Yamamoto  added the comment:

Thank for pointing this out. I've looked at bytearray and
bytes implementations, they actually return unsigned value.
I fixed this in r86159(py3k) and r86160(release31-maint).

--

___
Python tracker 

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

[issue10311] Signal handlers must preserve errno

[Antoine Pitrou]

Antoine Pitrou  added the comment:

This is a good idea IMO. It would be better if you minimized style changes, so 
that the patch is easier to review.
Also, is the while loop around write() necessary here?

--
nosy: +exarkun, loewis, pitrou
stage:  -> patch review
versions: +Python 2.7, Python 3.1

___
Python tracker 

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

[issue9732] Addition of getattr_static for inspect module

[Michael Foord]

Changes by Michael Foord :


Added file: http://bugs.python.org/file19490/test_static.py

___
Python tracker 

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

[issue9732] Addition of getattr_static for inspect module

[Michael Foord]

Michael Foord  added the comment:

Further updated implementation. Now handles data descriptors correctly but 
removes the code that resolves the builtin descriptors (calling __get__ on slot 
and attribute descriptors).

As it was resolving some descriptors but not all, and resolving getset 
descriptors could still trigger execution in C extensions, Benjamin felt it was 
more consistent and cleaner to return descriptor objects rather than resolving 
them. As a bonus it makes the code shorter too.

I would add to the documentation some example code showing how to handle the 
descriptor if the user wants to resolve them herself. (Example code shown in 
the tests.)

The only remaining cases that are handled incorrectly are pathological ones. 
(See the notes in the tests.)

--
Added file: http://bugs.python.org/file19489/static.py

___
Python tracker 

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

[issue10311] Signal handlers must preserve errno

[Hallvard B Furuseth]

New submission from Hallvard B Furuseth :

Signal handlers that can change errno, must restore it.
I enclose a patch for <2.7, 3.2a3>/Modules/signalmodule.c
which also rearranges the code to make this a bit easier.

The patch does   if (errno != save_errno) errno = save_errno;
instead of just  errno = save_errno;
in case it's less thread-safe to write than to read errno,
which would not surprise me but may be pointless paranoia.

I don't know what needs to be done on non-Unix systems,
like Windows' WSAError stuff.

--
components: Interpreter Core
files: signalmodule-errno.diff
keywords: patch
messages: 120395
nosy: hfuru
priority: normal
severity: normal
status: open
title: Signal handlers must preserve errno
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file19488/signalmodule-errno.diff

___
Python tracker 

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

[issue9611] FileIO not 64-bit safe under Windows

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> About the issue, I'd suggest to just clamp the length to 2**32-1, and
> don't bother retrying; leave this to the buffered layer.

Yes, I think it's reasonable.
(or perhaps clamp to something page-aligned, such as 2**32-4096).
Also, the signal issue which was raised by Martin above has since been fixed in 
r84239.

--

___
Python tracker 

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

[issue9732] Addition of getattr_static for inspect module

[Michael Foord]

Changes by Michael Foord :


Removed file: http://bugs.python.org/file19484/test_static.py

___
Python tracker 

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

[issue9732] Addition of getattr_static for inspect module

[Michael Foord]

Changes by Michael Foord :


Removed file: http://bugs.python.org/file19483/static.py

___
Python tracker 

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

[issue9611] FileIO not 64-bit safe under Windows

[STINNER Victor]

Changes by STINNER Victor :


--
nosy: +haypo

___
Python tracker 

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