Joe added the comment:
We are running into this all the time, ever since the Proactor became the
default on Windows in 3.8.
Usually it comes up when the program terminates due to an unhandled exception
during a highly concurrent operation. The resulting cascade of RuntimeErrors
often
New submission from Joe :
It would be nice, if you could offer the Windows version also as a zi
package, besides the msi installer.
--
components: Windows
messages: 91890
nosy: Joe
severity: normal
status: open
title: Python as zip package
type: feature request
Joe added the comment:
I meant as a zip archive package
--
___
Python tracker
<http://bugs.python.org/issue6767>
___
___
Python-bugs-list mailing list
Unsub
Joe added the comment:
Because, I don't need/want an installation. I only need the files whith
its directory structure.
--
___
Python tracker
<http://bugs.python.org/i
New submission from Joe:
In Python 3k releases leading up to 3.5.2, distutils.config imported
"ConfigParser", but now imports "RawConfigParser" in the latest release.
The documentation indicates "RawConfigParser" is considered legacy and
"ConfigParser&quo
New submission from Vertu Joe :
I intentionally made some corrupted zip archive files for testing.
If some contents were removed from the archive instead of changing the bits.
when trying to read such files, the zipfile will raise an uncaught OSError,
instead of a badzipfile error as
New submission from Joe Cool :
unicodedata.name gives ValueError for control characters, for example:
>>> unicodedata.name('\x00')
Traceback (most recent call last):
File "", line 1, in
ValueError: no such name
>>> unicodedata.name('\t')
Trac
New submission from Joe Shaw :
Start a non-SSL server on port 2525:
$ python -m smtpd -n -c DebuggingServer localhost:2525
In another terminal, fire up a python interpreter and run the following code:
>>> import smtplib
>>> s = smtplib.SMTP_SSL("localhost", 2525)
Joe Shaw added the comment:
>From some experimentation, closing the underlying socket isn't enough. You
>also need to close the SSL socket, so you'd need to do something like:
new_socket = socket.create_connection((host, port), timeout)
ssl_socket = ssl.wrap_socket(new_sock
New submission from Joe Hu :
When multiple threads create child processes simultaneously and redirect their
stdout using subprocess.Popen, at least one thread will stuck on reading the
stdout after its child process exited, until all other processes are also
exited.
The test case reproduces
Joe Metcalfe added the comment:
Turtle is built on top of Tk, which is currently at version 8.5 - this has no
ability to rotate text. When Tk version 8.6 arrives it should be able to write
rotated text (see
http://mail.python.org/pipermail/tkinter-discuss/2010-November/002490.html) and
Changes by Joe Metcalfe :
--
versions: -Python 3.2
___
Python tracker
<http://bugs.python.org/issue10531>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Joe Peterson :
Internaldate2tuple() is broken in several ways. The last two issues have
existed in the code for some time.
New issues in Python 3:
1. It crashes with "KeyError". This is because the Mon2num dictionary's keys
are strings, not bytes obj
Changes by Joe Peterson :
--
type: -> crash
___
Python tracker
<http://bugs.python.org/issue10921>
___
___
Python-bugs-list mailing list
Unsubscri
Changes by Joe Peterson :
--
title: imaplib: Internaldate2tuple crashes, does not handle negative TZ
offsets, does not handle DST correctly, and outputs localtime (not UTC) ->
imaplib: Internaldate2tuple() crashes, does not handle negative TZ offsets,
does not handle DST correc
Joe Peterson added the comment:
Regarding problem #4, it actually appears that returning local time is the
right thing to do, since it matches the behavior of Time2Internaldate().
Returning UTC, as the doc states, would potentially break IMAP append() that
can include an internaldate
Changes by Joe Peterson :
Removed file: http://bugs.python.org/file20419/imaplib_Internaldate2tuple.patch
___
Python tracker
<http://bugs.python.org/issue10921>
___
___
Changes by Joe Peterson :
--
components: -Documentation
___
Python tracker
<http://bugs.python.org/issue10921>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Joe Peterson :
--
components: +Documentation
___
Python tracker
<http://bugs.python.org/issue10921>
___
___
Python-bugs-list mailing list
Unsubscribe:
Joe Peterson added the comment:
> I assume this means it raises a KeyError when given a bytes object as an
> argument.
Yes, a KeyError is raised when arg is bytes, but passing a string also fails
(raising TypeError). The latter might also be a separate bug, in that strings
cannot be
New submission from Joe Bennett :
Hi, am running Python 2.6.5 on Unbuntu 10.04 and am seeing no FIN when a
self.close() is issued... I do see a reset issued, but it looks like some of
the M$ servers do not appreciate on a reset and would like a graceful
teardown... I understand that an RST
Joe Peterson added the comment:
Added fix for ParseFlags (another string/bytes issue) and now accept strings as
args to ParseFlags and Internaldate2tuple.
Also added unit tests for changes.
--
assignee: -> docs@python
components: +Tests
title: imaplib: Internaldate2tuple() cras
Changes by Joe Peterson :
Removed file: http://bugs.python.org/file20420/imaplib_Internaldate2tuple.patch
___
Python tracker
<http://bugs.python.org/issue10921>
___
___
Changes by Joe Peterson :
Removed file:
http://bugs.python.org/file20430/imaplib_Internaldate2tuple_python32.patch
___
Python tracker
<http://bugs.python.org/issue10
Changes by Joe Peterson :
Added file:
http://bugs.python.org/file20431/imaplib_Internaldate2tuple_python32.patch
___
Python tracker
<http://bugs.python.org/issue10
Changes by Joe Peterson :
Removed file:
http://bugs.python.org/file20426/imaplib_Internaldate2tuple_python27.patch
___
Python tracker
<http://bugs.python.org/issue10
Changes by Joe Peterson :
Added file:
http://bugs.python.org/file20432/imaplib_Internaldate2tuple_python27.patch
___
Python tracker
<http://bugs.python.org/issue10
Joe Peterson added the comment:
>There are at least 3 issues here: a documentation issue, a py3k bug and at
>least one feature request.
Which is a feature request? In these patches, I am attempting to fix the DST
problems and regain the previous behavior in Python 2. Are you talking
New submission from Joe Peterson :
Patched documentation for Internaldate2tuple() to correctly state it returns
local time.
Also, Time2Internaldate() (its inverse) did not state that it needs local time
as input, so patched this as well.
Patches for 3.2 and 2.7 are attached
Changes by Joe Peterson :
Added file:
http://bugs.python.org/file20439/imaplib_Internaldate2tuple_doc_python27.patch
___
Python tracker
<http://bugs.python.org/issue10
Joe Peterson added the comment:
I have started splitting these up as recommended. First one (documentation)
is: issue 10934. I will split out more later today...
--
___
Python tracker
<http://bugs.python.org/issue10
New submission from Joe Peterson :
There are two issues with conversion to Python 3:
1. It raise "KeyError". This is because the Mon2num dictionary keys are
strings (str), not bytes objects (note that many other strings in imaplib have
been updated, but not Mon2num).
2. The sign
Changes by Joe Peterson :
--
title: imaplib: Internaldate2tuple fails to parse month and does not work with
negative TZ offset due to bytes/str issues -> imaplib: Internaldate2tuple
raises KeyError parsing month and does not work with negative TZ offset due to
bytes/str iss
New submission from Joe Peterson :
DST is not handled correctly. Specifically, when the input date/time, ignoring
the TZ offset (and treated as if it is local time) is on the other side of the
DST changeover from the actual local time represented, the result will be off
by one hour. This
Changes by Joe Peterson :
--
keywords: +patch
Added file:
http://bugs.python.org/file20446/imaplib_Internaldate2tuple_dst_fix_python32.patch
___
Python tracker
<http://bugs.python.org/issue10
Changes by Joe Peterson :
Added file:
http://bugs.python.org/file20447/imaplib_Internaldate2tuple_dst_fix_python27.patch
___
Python tracker
<http://bugs.python.org/issue10
Joe Peterson added the comment:
Two more issues split out into their own issues:
issue 10939 (bytes/str issues)
issue 10941 (DST handled incorrectly)
--
___
Python tracker
<http://bugs.python.org/issue10
New submission from Joe Peterson :
In imaplib, there is currently a mix of bytes array and str use.
Time2Internaldate(), e.g., returns (and accepts) str. Internaldate2tuple() and
ParseFlags() only accept a bytes object, and the latter returns a tuple of
bytes objects. Of course, these were
Joe Peterson added the comment:
This issue has been split, as suggested by Alexander Belopolsky, into separate
issues:
issue 10934 - doc change to correctly reflect return of local time vs. UTC
issue 10939 - bytes/str issues
issue 10941 - DST handled incorrectly
issue 10947 - compatibility
Joe Peterson added the comment:
Hey Alexander,
Looks great. Just a few small things:
* In hunk 2 of the imaplib.rst file patch section, insert word "to" (i.e.
"Convert *date_time* to an IMAP4 ``INTERNALDATE`` representation.")
* Two lines, down there's only one
Joe Peterson added the comment:
These are all good comments. And I agree that the naming of the functions is
not good (and the CamelCase).
Overall, yes, it should be made consistent and the types returned and passed in
should be appropriate. I did a little experimenting, using more imaplib
Joe Peterson added the comment:
Yep, I agree, and in light of this, we should probably just close this issue
and work toward reviewing/improving imaplib in the ways you are suggesting.
As I migrate my imap stuff more to Python3, I'll see if I run into any problems
with using bytes throu
Joe Peterson added the comment:
Sebastian,
Yes, in fact Alexander Belopolsky (belopolsky) brought up the the locale issue
for this very function in one of the other issue comments.
The invert function, Internaldate2tuple(), actually does its own parsing using
a regex match (and so does not
Joe Peterson added the comment:
Yes, that's serious, certainly.
A patch should be fairly straightforward, given that part of the formatting
logic is already there (for the TZ offset at the end). You just need to format
the 6 values, and do a lookup for the month name.
If you want to t
Joe Peterson added the comment:
OK, I attached a patch that should work. Note that this patch works for Python
2 and Python 3.
As an aside, the str type is still returned as before (even in Python 3), and
the _month_names list uses str. As has been discussed, it may be more proper
to
Changes by Joe Peterson :
Removed file:
http://bugs.python.org/file20556/imaplib_Time2Internaldate_locale_fix.patch
___
Python tracker
<http://bugs.python.org/issue11
Changes by Joe Peterson :
Added file:
http://bugs.python.org/file20557/imaplib_Time2Internaldate_locale_fix.patch
___
Python tracker
<http://bugs.python.org/issue11
Changes by Joe Peterson :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue10947>
___
___
Python-bugs-list mailing list
Unsubscri
Joe Peterson added the comment:
> Also, isn't day supposed to be space- rather than 0- padded?
This is not clear to me. RFC2822 (referenced from RFC3501 for internal date)
discusses date formats, but as used in the header. In this case, day is
specified as "([FWS] 1*2DIGIT)&qu
Joe Peterson added the comment:
Our messages crossed... :)
Hm, I see that in RFC 3501, as well (which obsoletes 2060).
But... I wonder: does "(SP DIGIT) / 2DIGIT" mean that " 1" and "01" are both
OK? It seems ambiguous to me.
I still don't see why major
Changes by Joe Peterson :
Removed file:
http://bugs.python.org/file20557/imaplib_Time2Internaldate_locale_fix.patch
___
Python tracker
<http://bugs.python.org/issue11
Joe Peterson added the comment:
Here's a new patch. I would still like to discuss the leading space vs.
leading zero issue, but I have reverted to using a leading space in this patch
- fewer changes that way.
The long line is also fixed (sorry about that - yes, long lines are ugly). A
Changes by Joe Peterson :
Removed file:
http://bugs.python.org/file20444/imaplib_Internaldate2tuple_bytes_fixes_python32.patch
___
Python tracker
<http://bugs.python.org/issue10
Changes by Joe Peterson :
Removed file:
http://bugs.python.org/file20587/imaplib_Time2Internaldate_locale_fix.patch
___
Python tracker
<http://bugs.python.org/issue11
Changes by Joe Peterson :
Added file:
http://bugs.python.org/file20588/imaplib_Internaldate2tuple_bytes_fixes_python32.patch
___
Python tracker
<http://bugs.python.org/issue10
Changes by Joe Peterson :
Added file:
http://bugs.python.org/file20589/imaplib_Time2Internaldate_locale_fix.patch
___
Python tracker
<http://bugs.python.org/issue11
Changes by Joe Peterson :
Removed file:
http://bugs.python.org/file20589/imaplib_Time2Internaldate_locale_fix.patch
___
Python tracker
<http://bugs.python.org/issue11
Joe Peterson added the comment:
Not cryptic at all - looks great! New patch attached with associated tweaks.
--
Added file:
http://bugs.python.org/file20591/imaplib_Time2Internaldate_locale_fix.patch
___
Python tracker
<http://bugs.python.
Joe Peterson added the comment:
Good catch on the test. Note that for issue 10941, we'll want a new
non-timezone-dependent test case that can catch the DST-related problem. I'll
post a new patch to issue 10941 now and describe this some
Joe Peterson added the comment:
Alexander, looks like you hit a weirdness in the Europe/London timezone for
dates before 31-Oct-1971, as if DST was in effect even in winter. And the fail
of the test is caused by the same bug that causes issue 10941: the use of
mktime to interpret the values
Joe Peterson added the comment:
Here is a new patch that adds a test to the tests committed for issue 10939.
This new test case is needed to trigger the DST issue. This test is not
timezone-dependent (in the sense that one does not have to have a specific
timezone set for it to work), but
Joe Peterson added the comment:
More info on the Europe/London "near the epoch" thing (there is no weirdness in
the tz stuff - it's just issue 10941 causing the test to fail)...
I looked at the sources for the tz data, and here is the definition for
Europe/London
Changes by Joe Peterson :
Removed file: http://bugs.python.org/file20613/issue10941.diff
___
Python tracker
<http://bugs.python.org/issue10941>
___
___
Python-bugs-list m
Joe Peterson added the comment:
I like the idea of adding the decorator. New patch added.
--
Added file: http://bugs.python.org/file20615/issue10941.diff
___
Python tracker
<http://bugs.python.org/issue10
Joe Peterson added the comment:
[just carrying over some info from issue 10939 that is related to this issue]
Here is another manifestation of this issue, related to the local time
assumption, but not to DST, per se:
Here is the definition for Europe/London in the unix tz data:
# Zone NAME
Joe Amenta added the comment:
Yes, the idea was that it doesn't seem outlandish for someone to do:
def file(something):
do_stuff()
You can use lib2to3.fixer_util.is_probably_builtin for this... modified the
patch and attached.
--
Added file: http://bugs.python.org/file
Joe Cool added the comment:
Note: This is an issue for all chars in the ordinal range 0 thru 31.
--
___
Python tracker
<https://bugs.python.org/issue46
Joe Cool added the comment:
My recommendation would be to add a keyword parameter, defaulting to False, to
name(), something like give_full_alias, or maybe errors=“give_full_alias” like
the IO functions.
In the meantime, as the author of perllib, I had to make my own dict to return
to the
New submission from Joe Cool :
os.stat on windows doesn't take an open file even though os.stat in
os.supports_fd
>>> fd = open('tmp.tmp', 'w')
>>> fd
<_io.TextIOWrapper name='tmp.tmp' mode='w' encoding='cp1252
New submission from Joe Marshall :
There's a couple of wrong function signatures in dictobject.c,
dictkeys_reversed and dictitems_reversed are defined as single arg functions
like so: PyObject *(PyObject *), and are then passed around and called as
PyCFunctions, which should be PyO
Change by Joe Marshall :
--
keywords: +patch
pull_requests: +24703
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/26062
___
Python tracker
<https://bugs.python.org/issu
Joe Wells added the comment:
I would like to request that this bug be repopened and fixed.
I've changed (or at least tried to change, I'm not sure if it will let me) the
title of the bug to point out that the failure happens in
FrameSummary.__init__. It does not
Joe Wells added the comment:
Here are my thoughts inspired by Andrei's insightful comments.
1. In response to the major issue Andrei raises, I agree that it is desirable
that repr would never raise an exception. The reasons Andrei mentions seem
quite correct to me. However, I thin
Joe Wells added the comment:
I'm sorry Andrei: I misread your alteration of my example and misunderstood its
purpose.
For anyone else reading these messages: In my most recent comment above, please
ignore the part of my comment about Andrei's example.
So yes, Andrei, that is
Joe Wells added the comment:
Andrei, thanks very much for the pointer to bug/issue
https://bugs.python.org/issue39228. I had not noticed the earlier comment by
Irit pointing to that bug. (Is there some way to merge bugs so that someone
visiting one of the bugs will see the merged stream
Joe Wells added the comment:
In the hopes of convincing someone to install a fix to this bug, I will mention
a few additional points.
When I mention “the capture_locals feature”, I mean calls of the form
traceback.TracebackException(..., capture_locals=True) and
Joe Wells added the comment:
1. As background, it is worth remembering that a major motivation for why
FrameSummary.__init__ stringifies the local variable values in its parameter
locals is to prevent the resulting data structure from keeping those values
live. This enables them to be
Joe Wells added the comment:
Some quick comments on Martin's pull request.
1. The changes are sufficient to let the user make things work the way it is
requested that they work and anyone who does not start using the new
format_locals parameter will get the old behavior.
2. A side co
Joe Cool added the comment:
Proposed solution:
if comspec.endswith('sh.exe') or comspec.endswith('sh'):#
issue 40467
args = '{} -c "{}"'.format (comspec, args)
New submission from Joe Gordon :
Python 3 fails to encode dictionary view objects. Assuming this is an expected
behavior, what is the thinking behind it? I was unable to find any
documentation around this.
> import json; json.dumps({}.values())
"TypeError: Object of type dict_value
New submission from Joe Cool :
TimedRotatingFileHandler doesn’t handle the switch to/from DST when using
daily/midnight rotation. It does not adjust the rollover time so the rollover
will be off by an hour.
Parameters: when=‘midnight’, utc=False
--
components: Library (Lib)
messages
Joe Cool added the comment:
Never mind. I was looking for the DST code in computeRollover, and I found it
in doRollover.
--
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/i
New submission from Joe Rumsey :
I have reproduced this crash in Apple's default 2.7.1 python, and in 2.7.3
built from source myself. But only in release mode. If I rebuild 2.7.3 in
debug, the crash goes away.
The attached file reproduces the issue, which has to do with a union conta
Joe Rumsey added the comment:
I just built python 3.2.2 from source, and reproduced the issue there as well.
Same location. Here's the slightly more informative stack trace from my
release-with-symbols 3.2.2 build:
#0 _ctypes_alloc_callback (callable=0x7fff5fbfef20, converters=0x1000
Joe Rumsey added the comment:
Thanks for that. This does seem to be the case. I rebuilt with CC=gcc-4.2 and
my short sample and the full library I took it from both work fine.
--
___
Python tracker
<http://bugs.python.org/issue14
Joe Rumsey added the comment:
It's maybe not directly relevant to fixing this, but I worked around it on the
project where this came up by redefining dice as (c_int * 4) and col as
(c_uint8 * 3) in the union, then using ctypes.cast to get those as pointers to
the actual struct. That
New submission from Joe Jevnik :
When using PyType_FromSpec, the memory for PyType_Spec.name, Py_tp_methods, and
Py_tp_members needs to somehow outlive the resulting type. This makes it hard
to use this interface to generate types without just leaking the memory for
these arrays, which is
Change by Joe Jevnik :
--
keywords: +patch
pull_requests: +13925
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/14066
___
Python tracker
<https://bugs.python.org/issu
New submission from Joe Jacobs:
Windows 7 Ultimate: SP1. Fully pathed as of July 4th, 2017
My Windows 7 install has multiple user accounts. The main install account is
set up with "Administrator" privledges.
Some point in the past I had installed Python 3.6.1 on the main account.
Joe Jacobs added the comment:
I checked, there are no install logs.
Just realized, maybe an issue with the web installer rather than the base
installer.
python-3.6.1-amd64-webinstall
Had downloaded this file and tried to run it. I wouldn't even get to the
screen that asks you to
Joe Jacobs added the comment:
So, with the feedback, i uninstalled everything and tried installing again, but
in the %appdata% folder for both users and everything worked fine. Both users
have python installed. If i run the web launcher, the first time it installs
on the second account and
Joe Jevnik added the comment:
I added a benchmark suite (using Victor's perf utility) to cnamedtuple. The
results are here: https://github.com/ll/cnamedtuple#benchmarks
To summarize: type creation is much faster; instance creation and named
attribute access are a bit f
New submission from Joe Tsai:
The original V7 header only allocates 100B to store the file path. If a path
exceeds this length, then either the PAX format or GNU formats must be used,
which can represent arbitrarily long file paths. When doing so, most tar
writers just store the first 100B of
New submission from Joe Jevnik :
The new _tuplegetter objects for accessing fields of a namedtuple are no longer
serializable with pickle. Cloudpickle, a library which provides extensions to
pickle to facilitate distributed computing in Python, depended on being able to
pickle the members of
Change by Joe Jevnik :
--
keywords: +patch
pull_requests: +12006
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue36068>
___
___
Py
Joe Jevnik added the comment:
Thank you for reviewing this so quickly!
--
___
Python tracker
<https://bugs.python.org/issue36068>
___
___
Python-bugs-list mailin
New submission from Joe Jevnik:
I opened a pr to remove a line in the docs about $ needing to follow | in
PyArg_ParseTupleAndKeywords. In practice, you can just use a $ to create
required keyword arguments which intuitively makes sense. I was told this
should raise a SystemError; however, you
Changes by Joe Jevnik :
--
assignee: -> docs@python
components: +Documentation
nosy: +docs@python
___
Python tracker
<http://bugs.python.org/issue30180>
___
_
New submission from Joe Jevnik:
The old error of tuple.index(x): x not in tuple seemed very confusing to me. It
was also harder to quickly understand what the program was doing wrong. This
saves people a second pass through the program under the debugger because they
can just see what the
Joe Jevnik added the comment:
I agree, "%R in tuple" is enough information for me. This would also remove the
need to manually repr the object.
--
type: enhancement ->
___
Python tracker
<http://bugs.pytho
1 - 100 of 274 matches
Mail list logo
