Peter Otten added the comment:
Your code relies on the assumption that when the lambda is invoked the global t
is still bound to the Thread instance you are starting. It seems that this is
not always the case, and I don't see why it should be guaranteed either.
I don't know whether it's a good
Peter Eisentraut added the comment:
I understand the reasoning here, but I want to say booh to this change in
3.6.0a2 because it breaks my tests. It used to be that type(x) returned a
predictable string, and that was an easy way to verify the result types of
things.
Perhaps a __str__
Peter Williams added the comment:
I'm experiencing a variation of this problem on a project where I'm trying to
make an application that will work with both 2.7.x and 3.4.x
and am mostly successful. The application uses a number of pickle files
and I want to make it so that it doesn't matter
Peter Eisentraut added the comment:
The affected tar is indeed a BSD-ish tar (OS X). With GNU tar I can proceed.
It says "gtar: Removing leading `../' from member names".
So with that I agree that it's not worth rerolling th
New submission from Peter Eisentraut:
The file Python-3.6.0a2.tgz contains paths that start with "..", e.g.,
$ tar tf Python-3.6.0a2.tgz | head
../Python-3.6.0a2/
../Python-3.6.0a2/Doc/
../Python-3.6.0a2/Grammar/
../Python-3.6.0a2/Include/
../Python-3.6.0a2/LICENSE
../Python-3
Hans-Peter Jansen added the comment:
Sorry guys for not providing this earlier.
It turned out, that the sub optimal behaviour is related to a unfortunate
policy choice: email.policy.SMTP.
--
Added file: http://bugs.python.org/file43417/email_flatten.py
Hans-Peter Jansen added the comment:
Sorry guys for not providing this earlier.
It turned out, that the sub optimal behaviour is related to a unfortunate
policy choice: email.policy.SMTP.
--
Added file: http://bugs.python.org/file43416/email_flatten.py
Hans-Peter Jansen added the comment:
Sorry guys for not providing this earlier.
It turned out, that the sub optimal behaviour is related to a unfortunate
policy choice: email.policy.SMTP.
--
Added file: http://bugs.python.org/file43415/email_flatten.py
Hans-Peter Jansen added the comment:
In a couple of systems, I have to stick with 3.4. Is there a chance to have
this patch in 3.4 as well, if a new release 3.4 is made?
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.p
Hans-Peter Jansen added the comment:
Dear Stephen,
thanks for your care. I'm glad, that you're able to reproduce it.
This header is added from the email provider (the biggest here in Germany), so
yes, it deserves an entry in the defects list, but must not traceback, of
course
New submission from Hans-Peter Jansen:
Attached mail, parsed with email.message_from_binary_file results in:
Traceback (most recent call last):
File "./mail_filter.py", line 616, in
ret = main.run()
File "./mail_filter.py", line 605, in run
self.process(fp)
Fi
New submission from Hans-Peter Jansen:
In the course of replacing an old Python 2.7 email filter tool with a rewritten
Python3 version, I stumbled across a ugly case, where such an header:
To: unlisted-recipients: ;,
""@pop.kundenserver.de (no To-header on input
Changes by Hans-Peter Jansen <h...@urpla.net>:
Added file: http://bugs.python.org/file43286/mf.9__mi0bf.out
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
New submission from Hans-Peter Jansen:
In the course of replacing an old Python 2.7 email filter tool with a rewritten
Python3 version, I stumbled across a ugly case, where such an header:
X-Microsoft-Exchange-Diagnostics:
=?utf-8?B?MTtCTDJQUjAyTUI1MTQ7MjM6bEtRRlNaUHQvVTk5WCttdktlOUVrUGQvVFBH
Peter Inglesby added the comment:
Given the difference between the documented and the actual behaviours, and
given that it's apparently not obvious what the correct fix should be, would a
patch that updates the docs (to say that %Z only matched GMT and UTC) be
welcome?
--
nosy
Hans-Peter Jansen added the comment:
Poor old bug.
Just being bitten from it today, while trying to package pyftpdlib on the
openSUSE build service, which creates a clean reproducible build environment
for all packages, and testing fails.
Part of the game: openssl 1.0.1k, Python 2.7.8
https
New submission from Peter Norvig:
mean([True, True, True, False]) should be 0.75, but it returns 0.25.
The fix is to change _sum so that when the type is bool, the result should be
coerced to int, not bool.
Why it is important for statistics.mean to work with bools:
It is natural to say
Peter L added the comment:
Gonna close it since it seems to be related to
http://bugs.python.org/issue22359
and solved with
https://hg.python.org/cpython/rev/66e40df31fac
--
resolution: -> duplicate
status: open -> closed
___
Python tracke
Peter L added the comment:
Hmmm. Solves half the problem. Still fails when trying to run
"_freeze_importlib".
This works though:
https://hg.python.org/cpython/rev/66e40df31fac
--
___
Python tracker <rep...@bugs.python.org>
<htt
Peter L added the comment:
Originally posted:
https://bugs.gentoo.org/show_bug.cgi?id=581304
--
keywords: +patch
Added file: http://bugs.python.org/file42654/python-3.5-crosscompile.patch
___
Python tracker <rep...@bugs.python.org>
New submission from Peter L:
Cross-compiling python-3.5.x fails with "Parser/pgen: Parser/pgen: cannot
execute binary file" (CBUILD="x86_64-pc-linux-gnu" and
CHOST="armv7a-hardfloat-linux-gnueabi").
python-3.5.x requires "pgen" and "_freeze_imp
Hans-Peter Jansen added the comment:
v7:
- reorder test code in order to improve edibility
--
Added file:
http://bugs.python.org/file42586/python-urllib-prefer-lowercase-proxies-v7.diff
___
Python tracker <rep...@bugs.python.org>
Hans-Peter Jansen added the comment:
> In Python 2, it looks like the proxy_bypass_etc() functions are defined
> in urllib and imported into urllib2, so it makes sense to include the
> tests in test_urllib rather than test_urllib2.
The tests are in test_urllib. test_urllib2 is test
Hans-Peter Jansen added the comment:
* blatant error fixed
* one test case added
--
Added file:
http://bugs.python.org/file42582/python-urllib-prefer-lowercase-proxies-v6.diff
___
Python tracker <rep...@bugs.python.org>
<http://bugs.p
New submission from Hans-Peter Jansen:
ConfigParser fails in interesting ways, when using default_section and
ExtendedInterpolation options. Running the attached script results in:
ConfigParser() with expected result:
global: [('loglevel', 'WARNING'), ('logfile', '-')]
section1: [('key_a
Hans-Peter Jansen added the comment:
v5: don't require the proxies argument in proxy_bypass_environment()
--
Added file:
http://bugs.python.org/file42565/python-urllib-prefer-lowercase-proxies-v5.diff
___
Python tracker <rep...@bugs.python.
Hans-Peter Jansen added the comment:
Here's the finalized version of this patch, including unit tests.
--
Added file:
http://bugs.python.org/file42552/python-urllib-prefer-lowercase-proxies-v4.diff
___
Python tracker <rep...@bugs.python.org>
Hans-Peter Jansen added the comment:
Here we go:
v3 fixes following issues:
* prefer lowercase proxy environment settings, if multiple (disagreeing)
settings are specified with differing case schemes (e.g. HTTP_PROXY vs.
http_proxy)
* an empty proxy variable value resets the related setting
Hans-Peter Jansen added the comment:
Hi Martin, hi Senthil,
please find a new patch attached, that incorporates your suggestions.
* added a comment to get_proxies doc in urllib.rst
* documented and fixed the mixed case scheme
* added a note to proxy_bypass_environment, that behaves
Hans-Peter Jansen added the comment:
Hi Martin, hi Senthil,
thanks for the valuable comments.
Will incorporate your suggestions later today.
Yes, Martin, it's a bug, and should be fixed for 2.7 and 3.5 as well, but I was
unsure, if I get some feedback at all... Hence, this is a very nice
Changes by Hans-Peter Jansen <h...@urpla.net>:
--
versions: +Python 3.6 -Python 3.5
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
New submission from Hans-Peter Jansen:
During programming a function, that replaces a wget call, I noticed, that
something is wrong with urllibs proxy handling.
I usually use the scheme "http_proxy= wget -N -nd URL" when I need to bypass
the proxy. Hence I was prett
New submission from Peter Inglesby:
I get the following test failure against changeset 100576 on OSX 10.9.5:
$ ./python.exe -m test test_import
[1/1] test_import
test test_import failed -- Traceback (most recent call last):
File "/Users/peteringlesby/src/cpython/Lib/test/test_import/__i
Peter Inglesby added the comment:
I found it while reading the source. Patch attached.
--
keywords: +patch
Added file: http://bugs.python.org/file42188/issue26560.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Peter Inglesby added the comment:
The problem is that I have PYTHONDONTWRITEBYTECODE set in my environment.
Should the setUp and tearDown methods ensure that PYTHONDONTWRITEBYTECODE is
cleared and reset?
--
___
Python tracker <
Peter Inglesby added the comment:
I can reproduce it reliably.
I ran ./configure with --with-pydebug.
I'm not using NFS, and I'm not aware of anything else unusual about my
filesystem.
The fact that a timestamp overflows in the failing test is a red herring -- the
following also fails
New submission from Peter Inglesby:
The line:
assert int(status[:3]),"Status message must begin w/3-digit code"
should be something like:
assert status[:3].isnumeric(), "Status message must begin w/3-digit code"
--
components: Library (Lib)
messages: 261773
no
Peter Pan added the comment:
Here is a small test for the new version.
(To see the original ftplib.py version failing copy+paste the code from my
initial post into a python file and run)
--
Added file: http://bugs.python.org/file42100/test_ftp.py
Peter Pan added the comment:
I've updated "ftplib.py" from the 3.5.1 source code release.
This should fix issues:
http://bugs.python.org/issue25458
http://bugs.python.org/issue25491
--
Added file: http://bugs.python.org/file42099
Peter Pan added the comment:
The problem in my example is ftplib reports a "226" response to command "NOOP"
which is nonsense. ftplib received "226" before "ftp.sendcmd('NOOP')" was
called.
Since "transfercmd()" returns a socket, ftpli
New submission from Peter:
This is a regression in Python 3.5 tested under Linux and Mac OS X, spotted
from a failing test in Biopython
https://github.com/biopython/biopython/issues/773 where we would parse a file
from the internet. The trigger is partially reading the network handle line
Peter Brady added the comment:
Yes. The patch you suggested restores the old behavior of the lru_cache.
--
resolution: -> fixed
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Peter Otten added the comment:
There seems to be a connection to hash randomization. I consistently get
$ PYTHONHASHSEED=1 python3.6 ./normbug.py
BUG ('The aenid oevre', '!=', 'The AEnid oevre')
$ PYTHONHASHSEED=0 python3.6 ./normbug.py
OK ('The AEnid oevre', '==', 'The AEnid oevre
Peter Otten added the comment:
Not a bug. In your XFORMS dict you have
>>> ord("Æ") == 0xC6
True
Whether the value of "Æ" or 0xC6 is used by str.maketrans() depends on the
order of the dict entries which in turn is determined by the keys' hash. Remove
one
Peter Otten added the comment:
How would you disambiguate -1 and (for example) 2**64-1 on a 64-bit machine?
Python's int is not limited to a specific number of bits.
--
nosy: +peter.otten
___
Python tracker <rep...@bugs.python.org>
New submission from Peter Pan:
When handling the transfer socket manually the asynchronous status message "226
transfer complete" on the control socket is falsely taken as response for the
last sent command.
ftplib reads the response too late and the command/response order becomes
i
Peter Wirtz added the comment:
Here is a patch that provides support for the Sitemap extension.
--
keywords: +patch
Added file: http://bugs.python.org/file40791/robotparser_site_maps_v1.patch
___
Python tracker <rep...@bugs.python.org>
Peter Wirtz added the comment:
On further inspection of the tests, it appears that the way in which the tests
are written, a test case can only be tested for one useragent at a time. I will
attempt to work on the tests so work correctly. Any advice would be much
appreciated
Peter Wirtz added the comment:
Ok, for the mean time, I reworked the test so it appears to test correctly and
tests passes. There does seem to be some magic, so I do hope I did not overlook
anything. Here is the new patch.
--
Added file: http://bugs.python.org/file40784
Peter Wirtz added the comment:
I would like to tackle this issue. Should I wait for issue25400 to be resolved
first?
--
nosy: +pwirtz
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
New submission from Peter Wirtz:
After changeset http://hg.python.org/lookup/dbed7cacfb7e, calling the
crawl_delay method for a robots.txt files that has a crawl-delay for *
useragents always returns None.
Ex:
Python 3.6.0a0 (default:1aae9b6a6929+, Oct 9 2015, 22:08:05)
[GCC 4.2.1
Peter Wirtz added the comment:
This fix breaks the unit tests though. I am not sure how to go about checking
those as this would be my first contribution to python and an open source
project in general.
--
___
Python tracker <rep...@bugs.python.
Peter Donis added the comment:
Investigating further, the problem appears to be with the SSLFakeFile object
used for SSL/TLS connections. Here is a console session showing the issue (I
have redacted the host name and port number used for privacy reasons):
>>> import smtplib
Peter Donis added the comment:
I am having the same problem; the error occurs in the call to the login method
of the smtplib.SMTP object. That method takes two arguments, username and
password, and that is what I am calling it with.
--
nosy: +pdonis
Peter Donis added the comment:
It looks like this was fixed some time in between my Python 3.2 version (3.2.3)
and the current one (3.2.6); the code in the current 3.2 head in the repository
has a size parameter in the readline function for SSLFakeFile:
https://hg.python.org/cpython/file/3.2
Changes by Peter Funk <p...@users.sourceforge.net>:
--
nosy: +pefu
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue20658>
___
_
Changes by Peter Funk <p...@users.sourceforge.net>:
--
nosy: +pefu
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue4926>
___
__
Peter Brady added the comment:
As a sanity check I removed the stored hashvalue in Raymond Hettinger's
backported lru_cache (which we use to support 2.6-3.2) and end up with errors
as well. So it seems like 24483 is the appropriate fix to restore the old
behavior. Thanks for looking
Peter Law added the comment:
Awesome, thanks for fixing this.
--
nosy: +PeterJCLaw
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Peter Bray added the comment:
While I have not tested the patch provided, the following ls(1) command on Sun
Solaris 10 Update 8 and Oracle Solaris 10 Update 11, show that on (at least)
X86 systems, there is no -lcrypt for 64-bit builds. So a patch is required on
64-bit builds, and possibly
Peter added the comment:
This comment is just to note that this change broke our (exotic?) usage of
unittest.TestLoader().loadTestsFromName(name) inside a try/except since under
Python 3.5 some expected exceptions are no longer raised.
My nasty workaround hack:
https://github.com/biopython
Peter Landry added the comment:
Pradeep, that error seems to be in Barbican. This bug and patch only addresses
content-length headers in MIME multipart messages.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24764
Peter Landry added the comment:
Yeah, I think that makes the most sense to me as well. I tried to make a
minimum-impact patch, but this feels cleaner.
If we remove the Content-Length header, the `limit` kwarg might occur at an odd
place in the part itself, but that feels unavoidable
Peter Landry added the comment:
A new patch that simply removes Content-Length from part headers when present.
--
Added file: http://bugs.python.org/file40145/cgi_multipart.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
New submission from Peter Eastman:
The following script demonstrates a bug in the exec() function in Python 3.4.
(It works correctly in 2.7).
script =
print(a)
print([a for i in range(5)])
exec(script, globals(), {a:5})
It produces the following output:
5
Traceback (most recent call last
Peter Eastman added the comment:
I don't believe that explanation is correct. You can just as easily get the
same problem without explicitly passing a map to exec(). For example:
def f():
script =
print(a)
print([a for i in range(5)])
a = 5
exec(script)
f
Peter Eastman added the comment:
Then fix the documentation. This behavior directly contradicts the
documentation of the exec() function. The question is not what scope the
comprehension runs in, it's what scope the script runs in. See my third
example. A comprehension in the f() function
Peter Otten added the comment:
The sniffer actually changes its mind in the fourth line:
Python 3.4.0 (default, Jun 19 2015, 14:20:21)
[GCC 4.8.2] on linux
Type help, copyright, credits or license for more information.
import csv
csv.Sniffer().sniff(\
... Invoice File,Credit Memo,Amount
Peter Lovett added the comment:
Updated patch to 3.6
urlretrieve now has a decent docstring; this patch just adds a docstring to
urlcleanup.
--
nosy: +PeterLovett
versions: +Python 3.6 -Python 2.7
Added file: http://bugs.python.org/file40121/issue-24021.patch
Peter Lovett added the comment:
Tiny change on case of Windows file 'mercurial.ini'
Although Windows is case-insensitive on filenames, the file itself is named in
lowercase (I'm using TortoiseHg v3.4.2; I'm assuming older versions of
TortoiseHg also name it in this way.)
--
nosy
Peter Lovett added the comment:
Also a similar change to patch.rst
./python.exe
should be:
PCbuild\target\python.exe
--
Added file: http://bugs.python.org/file40124/issue17570-2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Peter Landry added the comment:
I realized my formatting was poor, making it hard to quickly test the issue.
Here's a cleaner version:
import cgi
from io import BytesIO
BOUNDARY = JfISa01
POSTDATA = --JfISa01
Content-Disposition: form-data; name=submit-name
Content
New submission from Peter Landry:
`cgi.FieldStorage` can't parse a multipart with a `Content-Length` header set
on a part:
```Python 3.4.3 (default, May 22 2015, 15:35:46)
[GCC 4.2.1 Compatible Apple LLVM 6.1.0 (clang-602.0.49)] on darwin
Type help, copyright, credits or license for more
Peter Otten added the comment:
Here's a variant that builds on your code, but makes for a nicer API.
Single-line docstrings can be passed along with the attribute name, and with
namedtuple.with_docstrings(... all info required to build the class ...) from a
user perspective the factory looks
Shinto Peter added the comment:
check this this link :
http://jodal.no/post/5779178001/log-from-the-debugging-of-a-segfault/
tells about Segfault
--
nosy: +shinto
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24050
Peter McCormick added the comment:
This definitely works for the _socket.listen use case!
In terms of generating such a signature using Argument Clinic, currently this
is required:
backlog: int(py_default=builtins.min(SOMAXCONN, 128),
c_default=Py_MIN(SOMAXCONN, 128)) = 000
Peter McCormick added the comment:
I missed the fact that Larry's patch obviates the need for the `builtins.`
prefix, shortening the Argument Clinic parameter specification into:
backlog: int(py_default=min(SOMAXCONN, 128), c_default=Py_MIN(SOMAXCONN,
128
Peter McCormick added the comment:
The smallest of typo fixes.
--
Added file: http://bugs.python.org/file39068/pdm-iofile_typo-v1.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20175
Changes by Peter McCormick pe...@pdmccormick.com:
--
nosy: +pdmccormick
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20175
___
___
Python-bugs
Changes by Peter McCormick pe...@pdmccormick.com:
--
nosy: +pdmccormick
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23935
___
___
Python-bugs
Peter McCormick added the comment:
I am working on revising the Argument Clinic definitions for socketmodule.c.
--
nosy: +pdmccormick
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20174
Peter McCormick added the comment:
Removed unrelated doc changes.
--
Added file: http://bugs.python.org/file38909/issue_10933-2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10933
Changes by Peter McCormick pe...@pdmccormick.com:
--
nosy: +pdmccormick
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10933
___
___
Python-bugs
Peter Marsh added the comment:
The consensus seems to be that this is simple enough for people to implement
themselves (if they need it) and it's probably not worth adding to argparse, so
I've closed this :)
--
resolution: - rejected
status: open - closed
New submission from Peter Marsh:
Hello,
Reasonably frequently I find myself needing to pass a date as a command line
argument to a Python script I've written. Currently, argparse does not have a
built support for dates - this adds a new class to argparse (much like the
existing FileType
Peter added the comment:
Test 1
Python 3.4.3 built by GCC 4.9.2 is:
str(memoryview(b'abcdefghijklmnopqrstuvwxyz')[1:], 'ascii')
'bcdefghijklmnopqrstuvwxyz'
Test 2
Python 3.4.3 built by GCC 4.6.2 is (no patches applied)
This build will core dump if I run -m test test_hash.
str(memoryview
Peter added the comment:
So this morning I got around to rebuilding the tool chain using GCC 4.9.2 and
I'm happy to report that this problem goes away (no patch required)! So it must
be some sort of problem with the 4.6 GCC.
I've still got the old tool chain around, and I'm happy to further
Peter added the comment:
OK I recompiled with ./configure --prefix=/usr/local --enable-shared
--with-pydebug and reran the test, unfortunately...
$ LD_LIBRARY_PATH=/usr/local/src/Python-3.4.3 ./python -m test test_hash
[1/1] test_hash
1 test OK.
I then applied the patch in msg239385
Peter added the comment:
Sorry I copied the wrong term buffer :-)
This is the output after I commented out the HashEqualityTestCase class which
causes the core dump.
LD_LIBRARY_PATH=/usr/local/src/Python-3.4.3 ./python -m test -v test_hash
== CPython 3.4.3 (default, Mar 27 2015, 08:45:04) [GCC
Peter added the comment:
Hi haypo,
I just realized you had created a patch too, the fnv_memcpy.patch worked!
$ LD_LIBRARY_PATH=/usr/local/src/Python-3.4.3 ./python -m test test_hash
[1/1] test_hash
1 test OK.
Running the full regression test now, but I bet everything passes
Peter added the comment:
I went and recompiled with:
$ ./configure --prefix=/usr/local --enable-shared
--with-hash-algorithm=siphash24
But this crashed as well.
test_unaligned_buffers (test.test_hash.HashEqualityTestCase) ... Fatal Python
error: Bus error
Current thread 0x0001 (most
New submission from Peter:
I compiled Python 3.4.3 on Solaris 11, and when I ran the regression test, I
get a core dump when the hash() function was being used. I went through the bug
database looking for something similar but couldn't find anything.
Tests like:
test_unaligned_buffers
Peter added the comment:
That's not a valid option on SPARC, (see
https://gcc.gnu.org/onlinedocs/gcc/SPARC-Options.html ) the flag is only
available on ARM it seems.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23786
Peter added the comment:
I've compiled Python 3.3.6 using the same options (./configure
--prefix=/usr/local --enable-shared) and build system and that passes almost
all the tests (test_uuid fails for an ignorable reason).
Specifically test_hash passes fully:
$ LD_LIBRARY_PATH=/usr/local/src
Changes by Peter Otten __pete...@web.de:
--
nosy: +peter.otten
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23639
___
___
Python-bugs-list
Peter J C Law added the comment:
Hi,
Sorry for the overkill demo. I've attached a much shorter version, the key
portion of which seems to be that, for the case of UK summer time the timezone,
the tzinfo's `dst()` and `utcoffset()` methods return the same value.
This results in the delta
Changes by Peter Otten __pete...@web.de:
--
nosy: +peter.otten
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23495
___
___
Python-bugs-list
Changes by Peter Otten __pete...@web.de:
--
nosy: +peter.otten
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23551
___
___
Python-bugs-list
New submission from Peter J C Law:
There's a difference in behaviour between the ``fromutc`` method on a tzinfo
between Python 2 and Python 3, though only under the specific case of Summer
Time in regions whose usual offset is 0.
From what I can tell, it's the Python 3 one which is wrong
Shinto Peter added the comment:
please attach MIB file also
--
nosy: +shinto
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23386
___
___
Python
201 - 300 of 656 matches
Mail list logo
