tom liu added the comment:
similar to issue25228.
--
resolution: -> duplicate
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Changes by tom liu :
--
components: Extension Modules
nosy: tom_lt
priority: normal
severity: normal
status: open
title: Cookies do not correct if cookiename includes [ or ]
type: behavior
versions: Python 3.4
___
Python tracker
<h
Changes by Brian Tom :
--
nosy: btomtom5
priority: normal
severity: normal
status: open
title: exec function fails to properly assign scope to dict like object
type: behavior
versions: Python 3.5
___
Python tracker
<http://bugs.python.org/issue26
New submission from Brian Tom:
http://stackoverflow.com/questions/35993869/passing-a-dictionary-like-object-to-exec-instead-of-dict-object-changes-scope-of
--
___
Python tracker
<http://bugs.python.org/issue26
New submission from Tom Middleton:
I have found that the execution of python scripts is inconsistent from the
following methods:
>From Explorer:
1) Right-Click->Open with->python.exe
2) Right-Click->Open (assuming python.exe being the "default" application)
3) Right-Cli
Tom Middleton added the comment:
That is interesting, in my use #3 seems to work. I am not certain if it matters
whether the default application is already selected as python.exe or not.
FWIW I'm on Windows 7 64 bit using 2.7.11 release install.
**Full Disclosure** I did muck in the reg
Tom Middleton added the comment:
I agree with your assessment Steve. I don't see there being a good fix to this.
I also think it would be a bad idea to have the launcher change the current
working directory.
Example:
c:\foo\> python d:\scripts\bar.py myfile
(where myfile is in c:\
Tom Tanner added the comment:
Any chance to get this into 2.7.10?
--
___
Python tracker
<http://bugs.python.org/issue21114>
___
___
Python-bugs-list mailin
Tom Tanner added the comment:
Are you going to merge it into 2.7.10?
--
___
Python tracker
<http://bugs.python.org/issue21718>
___
___
Python-bugs-list mailin
Tom Hines added the comment:
Done.
On Sun, May 17, 2015 at 8:42 PM, Terry J. Reedy
wrote:
>
> Terry J. Reedy added the comment:
>
> Tom, please sign the PSF Contributor Agreement
> https://www.python.org/psf/contrib/
> https://www.python.org/psf/co
Tom Tanner added the comment:
is this going to be fixed in 2.7.10?
--
___
Python tracker
<http://bugs.python.org/issue21718>
___
___
Python-bugs-list mailin
Tom Tanner added the comment:
The patch is waiting for inclusion in 2.7.10 :/
--
___
Python tracker
<http://bugs.python.org/issue21114>
___
___
Python-bugs-list m
New submission from Tom Cornebize:
It is much faster to construct a Python array from the list and then cast this
array, rather than using the "standard" constructor. See attached file to
compare the performances.
This issue was previously asked on Stackoverflow:
http://stackov
Tom Cornebize added the comment:
Thank you for these explanations.
I understand that we get a generic function to the cost of performances.
However, I think we should at least tell in the documentation that the
constructor (ctypes.c_uint32 * len(t))(*t) is slow and that we can do much
faster
New submission from Tom Clark:
#10673 indicated that the issue should be resolved by clarifying the
documentation. The proposed patch is intended to do this.
--
assignee: docs@python
components: Documentation
files: multiprocessing.patch
keywords: patch
messages: 275943
nosy: docs
Tom Clark added the comment:
I've submitted a documentation patch with #28094.
--
nosy: +tclark
___
Python tracker
<http://bugs.python.org/issue10673>
___
___
Tom Clark added the comment:
I thought that, since Issue <10673> refers to the library rather than the docs,
it was better to create a seperate documentation issue. In other words, I
probably overthought it.
--
___
Python tracker
Tom Clark added the comment:
This patch is intended to document the behaviour of join(). (Originally
submitted to #28094)
--
Added file: http://bugs.python.org/file44586/multiprocessing.patch
___
Python tracker
<http://bugs.python.org/issue10
Tom Christie added the comment:
Confirming that I've also bumped into this for Python 3.5.
A docs update would seem to be the lowest-cost option to start with.
Right now `mimetypes.guess_extension()` isn't terribly useful, and it'd be
better to at least know that upfront.
New submission from tom de wulf :
Probably a parsing bug in email.utils.parseaddr.
How to recreate:
>>> import email.utils
>>> test = 'Subject: I am a bug [Random]\r\nFrom: someone
>>> \r\n\r\n'
>>> email.utils.parseaddr(test)
('',
tom de wulf added the comment:
I do get this data from an IMAP fetch statement, see my code below:
rv, data = imap.fetch(num, "(BODY[HEADER.FIELDS (FROM SUBJECT)])")
if rv != 'OK':
logging.error("Error getting message sender and subjec
New submission from Tom van Leeuwen:
When using socket.sendall() to send a buffer of 2GB or more (for example,
numpy.zeros(2*GB, dtype=numpy.uint8) ), it doesn't send anything at all.
In socketmodule.c, socket.sendall() sock_sendall uses an int for len, while
this should be a Py_ss
401 - 422 of 422 matches
Mail list logo
